Character Creation Open

Hello everyone,

If you can read this post, character creation is live on LabMUD! You are all most welcome to create an account and submit a character. Character creation will be open for probably a little under a week and we speculate a full go-live date next weekend.

If you have any questions or feedback, please feel free to discuss the process on the forums or in our new chat widget.

Welcome to the Lab!

Opening Chargen

As I believe I’ve mentioned elsewhere, we have been making fairly good progress on getting combat and its ancillary systems set up in the FutureMUD engine. (And by ‘we’ I mean almost exclusively Japheth. I mostly just sit back, waiting for my chance to break things later on.)  So with that in mind, I’m going to put myself out there and say that we are still on track for an April release. Moreover, I am personally confident enough in the engine, and the game, to open up LabMUD to character creation starting Sunday the 26th of April. That’s Australian time, folks, so for you Americans, you can look into getting into character generation late Saturday night, or whenever we wake up. The intention is that, while character generation is ongoing, we (again, mostly Japheth) can monitor the process and fix any game breaking bugs, crashes, etc. whenever they crop up. And I do expect them to crop up, despite our best efforts to make the process as smooth as possible – our testing until now has been with small groups of people, or individuals, or with just ourselves banging away.

This does not mean you’ll get to play the game on the 26th of April – only that you will be able to create a character. The MUD itself will still be wizlocked until a later date, when we’re fully confident the bare minimum requirements for a RPI MUD have been met.

It does mean we’re getting closer to our stepping off point, though, and that’s pretty exciting.

With that said, I want to reiterate that LabMUD is an Alpha – and is, in fact, the Alpha of an Alpha. Unlike other MUDs that have branded themselves with the ‘Alpha stage’ moniker in the recent past, we are not running on an established engine with most of the kinks worked out. We are not going to launch with an established economy, or a mini-fort system, or sailing. LabMUD was not built with the intention to be, and is not going to be, a [insert your ex-favourite MUD here] killer. It is a testing platform for the FutureMUD engine that just so happens to also be a RPI MUD. Things may be wildly unbalanced, or even broken. I would be seriously surprised, and more than a little worried, if they were not. Things may even be boring for the first few weeks, though I’ll endeavor to try and make sure this is not the case, until we can get some better progs in place to keep players entertained without constant admin supervision – or fix crippling balance issues. Please try to be patient with us, and put on your kindest rose-coloured glasses.

So yeah, make a note in your diaries.

Later on, maybe tomorrow, I’ll try to get a post up about how to report bugs and crashes during character generation.

LabMUD Server Upgraded

In preparation for going live this month, I have upgraded the server which LabMUD runs on. While the MUD itself actually wasn’t having any difficulty on the old server, the webserver was a bit sluggish. Hopefully the new server will be nice and quick.

We’re looking forward to seeing you all in the Lab very soon.

Quick Update

Here’s where we’re sitting, in terms of building required to get LabMUD open to player characters:

  1. Progs (15 or so, of varying difficulty.)
  2. Set up forage system.
  3. Build two/three more NPCs.
  4. Fix time/celestial object issues.
  5. Complete helpfiles (at least the basic ones.)

Obviously the opening of the game still hinges on combat being in in its most basic form, but that’s up to Japheth. From a building perspective, things are getting pretty spare… And that’s even with me making up work for myself to feel accomplished. Arguably, #4 is a bug, and requires some digging around in the code to sort out. #1 and #2 will take the most time. #3 will probably take an hour, hour and a half or so, tops. #5 may require some work as well to flesh out fully.

Also:

There are a total of 423 rooms, 115 items and 3 NPCs built.

In terms of number of rooms, that should be relatively stable now come launch. Items will uptick a bit, as I’ll need to put 20 or so in for foraging to feel varied, and the number of NPCs will increase slightly.

Anyway, we’re still (hopefully) on track for a mid-April release. Won’t likely be in time for an April 1st launch but… well, I can dream.

Staffer? I hardly knew her!

So, there’s been this sort of under-argument taking place on a few forums and elsewhere, about whether or not staffers should play characters. Those that argue for staffers playing characters say that any staff without a character has no idea how the game is actually going player-side, that they’re too omnipresent to see the plights of the little man – they, to use a phrase from my upbringing, can’t see the trees for the forest. Meanwhile, those on the other end of the argument say that staffers get too involved with their characters, and are more apt to cheat in one of a hundred ways.

I can see the argument from both perspectives, really. I’ve been playing MUDs, RPIs in particular, for over ten years now (eleven this June). I have seen staff who have built their 0RPP characters up to godhood. I’ve seen staff without characters with their heads so far up their own asses that I wondered if they even knew what game they were playing. I’ve similarly seen staff that favor the arguments – ones with characters that used them to get a firmer knowledge of how the numbers worked so they could tweak things, and others without characters that were totally non-corrupt and had a good handling on the numbers. (If that was confusing, it’s because it totally got away from me. But bear with me here.)

Anyway, a thought occurred to me: what if you had a player, or a couple of players, or by God even a group of players, that knew what all the numbers were and how the code worked, but had no staff powers? They couldn’t see anything staff did, or have any other out-of-character knowledge, they would just be players that the staff gave numbers to, who would effectively serve as balancers. So, say for example staff released two new weapons, five new pieces of armor, and three mobs. The staff would give these few players all the numbers (oh, those weapons do 2d5 damage, the armor is 5 AC, and the mobs have 80HP, 3AC, and do 3d6 damage) and the players would then, after actually playing the game, be able to report how the numbers felt while doing so (example: the swords feel a little weak, and in PvP no one can damage the armor, while the mobs rip the heads clean off of everyone. Up the damage on swords, lower the AC on armor, nerf some stats on the mobs).

But Krelm! Some of you might be saying. Wouldn’t the players who knew all the numbers have the upper hand!?

Not really. I helped build Atonement ALPHA and BETA from pretty much the ground up. Parallel used a bunch of the mobs and items I built (from what I saw), and I built a good chunk of the newest incarnation of SoI. I saw every single number that Atonement had to throw at you, and most of SoI’s. I could see the sdesc of a sword and tell you instantly that it was the best or worst or most average sword in the game. Does that mean I had the sword? No. I could see a mob and tell you exactly how much of your shit it was going to wreck. Did that give me an intrinsic knowledge of defeating said mob? Nope. Am I just unintelligent? Maybe.

But Krelm! You say again. Couldn’t a corrupt staffer just lie and make some cool crap for his best friend and report numbers falsely!?

Well, yeah, but there are already a bunch of handy new tools in the FutureMUD engine for catching stuff like that (for instance, if you’re below a certain “staffer level,” you essentially make a draft of objects and then submit them for higher-level staffers to approve to be put IG. If I’m remembering that right.). As far as staff just lying, well, you’ll just have to trust them.

As for how this fits into LabMUD – I likely won’t be staffing, but I’ll definitely make a character. I’ll likely see a bunch of numbers between here and then, too. And, I’ll likely use that knowledge of numbers to help Wolfsong and Japheth tweak the combat system and balance out bugs and whatnot. And it’d probably be a whole lot easier if there were  a couple more people who could do stuff like that. (Of course, there’s also the possibility that Japheth is coding something wicked-cool that will auto-balance all combat in FutureMUD forever, and there won’t ever be any numbers and this post will be moot, but if it isn’t!)

That said, that’s likely the position I’ll take when LabMUD opens. Just a player who knows a lot of crap about stuff and can use that to help staff tweak things. Is my proposal a good idea? I think it is. Everyone else will just have to take it up on the forums.

You’ve been a great audience, folks.

Staff Promise

In a previous post, I mentioned that I would be talking about our Staff Promise to you. Basically, the Staff Promise is a high level statement of our conduct as staff and the minimum standards that we set for ourselves. In many respects, it is the foundational statement for the MUD.

Below is the text of the Staff Promise (which can also be found here):

  • We promise that the game will be freely available to all, insofar as reasonably possible. We will never charge to access to the game, pay for perks, or ask for donations. It is our privilege to make LabMUD available to you and you do not owe us anything for participating.

  • We promise that we will not discriminate as to who may access the game, participate in the forums or contribute to the community, except in cases of gross misconduct such as harassment, threats, or extremely disruptive behaviour. If we must remove somebody’s access for any reason, we will ensure that it is fair, even-handed, transparent and in line with community eexpectations

  • We promise that we will make a reasonable effort to remove barriers to participation for individuals. For example, we will make a reasonable effort to consider the needs of vision impaired players using a screen reader. While we will use an application review process, we will also ensure that our focus in reviewing the applications is to correct errors and get the person into the game rather than forcing them to reapply.

  • We promise that we will maintain an immersive and internally consistent environment for play. While some suspension of disbelief will always be necessary for the introduction of new engine features or the discovery of bugs, we will make every effort to downplay the impact of these and maintain a serious roleplaying environment.

  • We promise that as far as is humanly possible, we will show no bias towards players despite their status, history or attitude. We will actively endeavour to spread our time evenly amongst all the playerbase, and we shall not make exceptions to the rules or create admin-initiated plots that directly benefit or harm individuals.

  • We promise that we will not play characters in LabMUD. You never have to worry about another PC being a staff PC because there are none.

  • We promise that we will accept criticism of the engine, the setting, the rules, our words or our actions with an open mind and a fair approach. You will not be punished for speaking your mind.

  • We promise that if you can do it in code, you are allowed to do it. As long as their is in-character justification for your actions, you should be able to use your character’s coded capabilities without fear of being labeled a “twink” or “cheater”.

Why LabMUD?

Hello everyone,

As you may have guessed from the title, today’s post is about why we are making LabMUD. We’ve already established that LabMUD is a “flagship” for the FutureMUD engine, but what does that really mean? I am sure that there are many questions as to how the MUD will be run and what you can expect as a player, and I will try to answer them here.

The story starts with FutureMUD, the engine that LabMUD runs on. I am the primary developer of FutureMUD, and that remains my main role. I won’t dwell too long on FutureMUD here, but in essence I have reached a point in the development of the engine where I need some hardcore real world testing – not just to find bugs, but to actually test the look, feel and balance of the engine itself. There is a limit to how much of this testing I as a developer can do, and I also know the engine intimately – so things that seem obvious and easy to me may not necessarily be so to someone else. So, I realised that I needed at least someone running an real live FutureMUD server to provide me with this feedback.

Once people start using the engine, they will have feedback – bugs found, issues raised, changes requested. That will drive development for a while, and that’s all good stuff! If that was the extent of it, I’d be looking at releasing a general Alpha right now. What has actually emerged though is that this is a new engine – and that means nobody is familiar with it. On the player side, it is very similar to existing Diku-style MUDs, and few RPI players should have any difficulty figuring out what to do, even intuitively. Unfortunately for admins, that is not the case from the admin side – it is very, very different. Additionally, I have not really documented a lot of this stuff and even I forget it half the time (and have to go looking in the code). Up to this point, I also wasn’t 100% sure what was absolutely necessary for the MUD to run – the bare minimum world file I could ship for instance.

As such, I figured it would be easier to have a Flagship MUD for the first few months. This would be like a limited sandbox for the engine – I could get the feedback and testing I needed without being TOTALLY overwhelmed by supporting a dozen people setting up a MUD in a brand new engine from scratch. It would also buy me some time to write documentation, and also to polish the admin/builder experience before the community got its hands on it. So, I started thinking about who should make the flagship – certainly I didn’t want to do it myself, because I couldn’t commit the kind of time and energy that the MUD needs without sacrificing development of the engine. Long ago when I first started thinking about this my idea was either to have Kithrater build something or Methuselah (probably the longest-serving and most active follower of the FutureMUD project). Kithrater however isn’t interested in MUDs anymore and Methuselah is now fully committed to SOI. SOI itself was also a candidate, and while I would one day love to see FutureMUD edge out the RPI Engine even for existing MUDs, it is most definitely not there yet.

So I asked Wolfsong (my wife) whether she would be willing to make a MUD. She had some conditions of the readiness of the engine, but we eventually got there and so it came time to select which MUD to make. Both Wolfsong and I have several MUD ideas for MUDs that may eventually get made. We mulled over making a few of them, but what we realised was that they weren’t good matches for this kind of project. I really didn’t want the pressure of the flagship being someone’s “dream”. If things didn’t go perfectly, if core systems weren’t in place, if there were bugs and instability…I might ruin someone’s shot (or even my own shot) at making that MUD they’ve always dreamed of.

We realised that the flagship MUD had to be nobody’s dream MUD. It should be a MUD that is easy to make, easy to document, easy for players to get into, and easy for everyone to shrug off or let go if it becomes necessary. It still would need to be gripping and engaging, but it didn’t need to be our Magnum Opus of world building and setting, a MUD that would stand the test of time. It just needed to be a place where players could go and explore the engine and tell a story.

LabMUD is just that – it’s a Lab. You all are the test subjects, and the engine is the test. The theme is designed so that we can introduce new engine features and have it be remotely in-character. It’s also designed to require very little day-to-day admin intervention (something I am a big believer in). Of course, we will run RPTs and events and such, but hopefully most of the game’s events will be player driven. In future posts, I will comment on what you as a player can expect (our promise to you) and also some thoughts on fairness in testing outcomes.

Just to clarify, Wolfsong is the Head Admin for LabMUD. She has the ultimate responsibility for decision making, building, plots and the like. I am also an admin here, but mostly to teach her about the engine and get a perspective on how people are using the engine. Krelm may be doing some building for us, but won’t be an admin once we open (his choice – he’d rather be a player).

Towards the end of the LabMUD project (which might be months or years – who knows), I will probably also invite other people who are serious about using FutureMUD for their own projects to the staff for the purposes of training them. I won’t be doing this at first though because I want to give the MUD a chance to be a real MUD before it is a training ground. Wolfsong and I will probably be the sole admins for the MUD for now.

A LabMUD Introduction

Hello Everyone,

I suppose the news of LabMUD has finally broken and pretty quickly people have been signing up and even trying to log in to the game. We’re not actually ready for people to begin logging in and making characters as yet, so this has highlighted the need for me to properly make a maintenance mode!

We are rapidly approaching a state where we would be comfortable opening, and we are looking forward to having you all join us. I am mostly focusing on engine development, whereas the MUD itself is effectively built and run by Wolfsong. You will hear more from both of us over the coming weeks as we approach readiness for players.

As a bit of a teaser for you all, I thought I would post the “Welcome Blurb” for character creation to wet your appetites. Much of this is similar to the existing introduction post, but this one is official!

LabMUD is the flagship MUD of the FutureMUD Engine (http://www.futuremud.com). Both the engine and the MUD itself are in Alpha status and both bugs and instability are to be expected. While every effort will be made to ensure that your playing experience will be both as high quality and as uninterrupted and smooth as possible, we cannot always guarantee that this will be the case.

You may feel free to discuss engine-specific topics on the forums at FutureMUD’s website, where you can also report any bugs or issues that you find (http://bugs.futuremud.com) – however, every day support should be sought through the LabMUD website and in-game. If you are interested, you can read more about LabMUD on the website at https://www.labmud.com/ or join us at our forums.

LabMUD is a roleplay intensive, permadeath MUD. That means that “in-character” actions (or, playing as your character, based on your character’s described personality, aspirations and physical limits, and not necessarily as yourself) are enforced at all times, and character death is permanent.

The setting of LabMUD is vague by design: your character, for reasons unknown to them or anyone, has woken up in a facility closed off from the outside world, with no memory of their past, and no familiarity with their current surroundings. For the sake of character creation, it can be inferred that the time period the game takes place in is roughly contemporary with present day, and that the game occurs either on Earth, or on a planet functionally identical to Earth. While your character should have no knowledge of specific events or places from Earth, they may be familiar with philosophical, political, social, even professional, concepts and ideas. Treat your character as akin to a highly functioning individual suffering from severe amnesia.

To play LabMUD, you will first need to create a character. You do so by completing, and submitting, a character application. Once submitted, your application will be put in for review by staff members or community guides. Once approved, you will be able to log into your character and play the game. This process may be almost instantaneous, or may take up to a day. While you wait, consider heading over to the forums at https://www.labmud.com/forum and introducing yourself.

Determining Staff Policy, Part 3

As in my last post, I’m going to continue discussing some of the questions that tend to come to the fore during staff policy debate, such as whether or not (in games large enough to warrant it) staff should rotate between spheres, or be permanently assigned to one sphere.

Rotating assignments vs. permanent positions?

Shadows of Isildur was, and continues to be, a prime example of permanent positions among members of staff. On SOI, you were generally hired to do a particular thing, in a particular area, and were expected to remain in that area for the duration of your administration. You might move within that sphere, from trainee to senior leadership, but you never generally left that sphere. Those who did leave often only did so because that area of the game had been closed, or because another area had lost all qualified staff and required immediate, emergency oversight. Meanwhile, Armageddon is an example of the opposite principle at work: staff rotation. Staff are hired on and rotated among the different areas of the game, spending a scheduled amount of time in each area before being cycled elsewhere. While they are hired on to perform certain tasks, they are not hired on to do them solely in a single area of the game.

Both positions have their advantages and drawbacks, but the obvious edge goes to, in my opinion, rotating staff assignments.

In permanent positions, it is easy for a staff member to become too endeared to their own specific sphere. This endearment can cause friction between other members of staff, in separate areas of the game, and friction between players outside of that sphere – especially if they are antagonistic to that sphere. Everyone, after all, wants “their side” to win. And while one of the obvious benefits of permanent placement on staff is that the staff member in question collects a wealth of knowledge about their own sphere, and understands its intricacies intrinsically, that same staff member, taken outside of their sphere, knows nothing. If they are the only soul online among administrative staff, and a player comes to them with a question, and it is outside of their sphere, they will often inform the PC it is outside the scope of their ability and then wash their hands of it. More times than I can count, as a player in Shadows of Isildur, I was told there were no staff online who could help me with a simple request because “it was outside their sphere” – despite there being three or four staff members online at the time. Rotational staff positions at least force the individual staff member to familiarize themselves with other areas of the game, in addition to also limiting some over-familiarity with any single sphere, and allow the staff member to assist in resolving more issues among players than they would have been able to do otherwise.

How do you fairly investigate complaints about staff members?

Another question that crops up from time to time involves formal staff complaints and how they are handled among members of staff. Do you allow the accused staff member to prosecute themselves, do you appoint a jury of their peers to judge them, or does one head staff member personally investigate the claims? And what constitutes a legitimate claim? Are all claims of abuse investigated, regardless of the source, or are some players less reputable than others, and are their claims then less valid?

There is no easy answer to any of the above, and regardless of how you decide to handle complaints against staff, there will always be players who cry bias against themselves and corruption elsewhere. And they will always be half-right; there is always that potential for abuse, even if it goes unrealized. In many cases, speaking as a former indignant player, the potential for abuse is enough.

The most ideal situation is probably impossible. In my opinion, the best solution would be to contract out the investigation of complaints against staff to a third party – a group that is unfamiliar with both the players and staff of your particular MUD, but has experience with MUDs in general. It would allow them to be as impartial as possible, limiting the accusations of bias, while still remaining familiar with how MUDs work. Given how small the MUD community, and the RPI MUD community specifically, is, however, I doubt this would be realistic.

What may be more feasible is a triumvirate of investigators – one appointed to lead the group by the game owner, and two others to weigh in on evidence for or against the accused: one, appointed by staff as a whole, and the other voted in by players. These three individuals would be players in that they would have no admin privileges – they would not be able to log into the game as an admin, would have no access to staff forums, etc. Or, at least, not until a complaint is raised. Then the lead investigator would be given the ability to browse certain staff forums and to, with discretion, browse game logs pertinent to the issue. They would gather evidence, and detail that evidence to the other two investigators in a forum dedicated to such things. The three would then come to a conclusion and present their findings to head staff – punishment would be meted out based on predetermined rules and regulations. The triumvirate would return to being players solely, until a complaint is raised again.

All complaints would be investigated equally, but there would be clearly stated punishments for players who submit repeated, blatantly false reports. And there would be transparency – players would be informed of major infractions by staff members, should they be found guilty, and when/if a staff member is fired for a major infraction, players would be made aware. There would be no graceful exit for staff who have broken the rules. Those staff members who do not break the rules, however, and are being fired for other reasons (such as generally just being useless) would be allowed to step down gracefully.

Perfect solution? Certainly not. In fact, I’m still not certain I like the setup, and have no idea if it would work in practice in a game. But until I find something better, that’s where my thoughts lie.

Determining Staff Policy, Part 2

In my experience, there are a few common questions that tend to get floated in discussion about staff policy. I’m going to limit my aimless rambling a bit, and attempt to address those here – but more than ever, the following post is written from my own very specific perspective, coloured by my own experiences as both a former member of staff, and a former player on various RPI MUDs.

Should staff be able to play PCs?

Years ago, Shadows of Isildur used to have a policy for new staff members: upon joining staff, you would be required to retire your current PC. You were not limited from playing new PCs once on staff, but there were some theoretical limitations regarding just how far in an organization that player-character could now climb, etc. Unlike players, staff on SOI were also not limited to playing only one PC. Instead, they were given unlimited player-character slots, and usually given as much RPP (roleplay points, a currency used by players to buy the ability to play different roles and restricted races) as they needed in order to create characters of their choice. By the time I was a staff member on Shadows of Isildur, this policy of retirement was largely gone. Instead, staff members were often as much hired to administrate, build, and run plots as to oversee the clans their own PCs had risen in the ranks of. For example, certain staff members, as players, had created player-run clans. These certain staff members, upon becoming administrators, turned these player-run clans into staff sanctioned organizations with a firm place in the lore of the game, and high levels of support, and made their own characters (who they still played, who still ran these same clans) often into the equivalents of barons, lord captains, or kings.

I believe Armageddon has a similar staff policy, and that new staff members are required to retire (or, in Armageddon terms, store) their current PC upon becoming staff members. As in Shadows of Isildur, Armageddon staff are not forbidden from playing PCs, only from playing PCs within the area they are currently staffing within (and I’m not even sure if that is a hard rule, or just rumor.)

So, should staff be able to play PCs?

In my opinion? No.

When staff members are allowed to play PCs, whether these be characters they created before or after becoming an admin, friction is introduced between that staff member and every other player-character that potentially interacts with their PC.

MUDs, RPI MUDs especially, are intentionally very intimate games. They encourage players to invest in their characters – to invest in them repeatedly, mentally and emotionally. And when these characters die, all that expended effort goes up in smoke: all that time is wasted, all the clever things you wanted that character to say are left unsaid, all their plans are undone, and all those emotional ties formed between that character – and yourself – and other characters are severed. Losing a PC can be, at best, a frustrating experience. At worst, it can be depressing and, for some, quite traumatic. Often years are put into a PC, and often the death of that PC is senseless. Players form close bonds with their characters. Sometimes, too, those bonds cause the line between OOC and IC to blur – people begin to identify too closely to their PC, and take fictional threats against their PC as legitimate offenses against their own self. Players become defensive, fostering a “me against the world” attitude. They become reactionary.

Staff members should never, at any point, be put into a position to develop and display this attitude. The role of an administrator on a RPI MUD is, in my opinion, that of a facilitator. When staff members are allowed PCs of their own, regardless of the situation, they develop attachments that bias them against other players and staff members. They may not intend for it to happen, but it is unavoidable. And reactionary staff members no longer facilitate for others.

Why do RPI MUDs allow their staff to play PCs if there is so much potential for harm, intentional or unintentional?

Fun.

A MUD is a game, and games are supposed to be fun. Players have fun by playing their characters, by developing them – skilling them up, making friends, gathering good equipment, exploring strange lands, crafting new items, etc. By depriving staff members of their characters, there is the general belief that you are depriving staff members of fun. And let’s face it, staff members are volunteers. They aren’t getting paid for any of their hard, often tedious, thankless work. Shouldn’t they be allowed to have a little fun to preserve them from burn-out and frustration down the road?

No. No, because staff members that require a character to enjoy themselves are the wrong sort of staff to be hiring on in the first place. There are a variety of gamers out there – not all of them get their rocks off on that emotional bond that forms between themselves and their character, and their character and other characters. There are plenty of people who do not need to play a character to enjoy themselves, and those are the sorts of people who thrive best in administrative roles on MUDs. These people derive enough enjoyment out of world building and the creation of stories, and the reactions of player-characters to their stories, to make playing a PC pointless. But they aren’t often the people who end up on staff. The people who tend to end up on staff usually have had staff watching them for ages before being approached, or accepted – and they’re being watched in the first place because of the quality of their character, and the intensity of character-to-character interactions. And anyone defined by their character, first and foremost, is likely the sort of person to truly miss not playing a PC. Depriving them of a character will make them miserable, and they will not be a good staff member for it. Not depriving them of their character, and allowing them to administrate on a MUD, will encourage them to lash out preemptively against any threats to their PC. They will feather their own nest at the expense of others.

In Shadows of Isildur, there was a player who joined staff. They identified strongly with their character – and had a history of doing so with their characters. Their character happened to be in a moderately powerful position, and was moderately long-lived by the time they joined staff. They were chosen to join staff because their character was long-lived, and had proven successful in their leadership position. (Leadership qualities, the ability to create roleplay for others, were highly prized in staffing applications.) In addition, they proved through the successful, multi-faceted persona of their PC that they could create deep, enjoyable characters. After joining staff, they were not required to retire their PC. Their character’s organization became a mini-sphere within their area of the game, and they were put in charge of it directly. Their character became the equivalent of a duke, with unparalleled power – though they were still beneath NPCs, in theory, there were no PCs above them. They could execute any PC at their leisure, for any reason (or no reason.) And, besides, the NPCs above them were directly animated by them.

This staff member began to religiously snoop the rivals of their character. They began to build custom weapons, armor and clothing for their character, and the friends of their character. These weapons and armor were some of the best in the game. Rooms were added onto the game to house this staff member’s clan. An entire mini-sphere was constructed, just for their character’s groupies. They built NPCs that were wildly unbalanced, to serve as their character’s personal bodyguards, and, if any other members of staff commented on it, became rabid and aggressive against them. They began to ignore other portions of their assigned sphere, prompting another call for new staff members to pick up the slack, and instead began to focus exclusively on their own character’s monkey sphere.

One day, a PC, after offending that staff member’s character, was arrested by NPC guards animated by that staff member, and thrown into a prison that staff member had built exclusively for their character’s organization to utilize. That player, complaining of bias, logged off after being told by that staff member OOCly that they were going to be executed – after a long rant at the PC by the staff member, berating them for their “unfounded accusations” against their character. The staff member, incensed, removed all RPP from that player’s account, retired their PC for them, and then created a NPC clone of that player’s PC. They then, multi-boxing to play both their staff avatar and their own PC at roughly* the same time, brought the NPC prisoner, the NPC guards, and their own PC to a public square. They announced across the zone that a mini-RPT was in progress. When people arrived to see what was going on, they staged an elaborate execution of the NPC of that player’s PC, in (likely) one of the most confusing and neurotically smug events in the mad history of that section of the game. They roleplayed that the NPC had pissed themselves in fear, had blubbered and begged for their life, and sobbed like a baby during the affair.

When the player logged into their account at a later date, attempted to log into their PC, and questioned why they couldn’t, they were informed their PC had been executed and they were now banned for a week because of their own poor attitude. The player logged back out, and never made another PC on Shadows of Isildur – despite, prior to this event, having had an exemplary track record, a history of mid-level leadership in clans, and an investment in roleplay.

Thus – staff members should not be allowed to play PCs during their tenure on staff, regardless of the situation. Staff members should instead be hired who derive their enjoyment of the game through world-building, the creation and successful implementation of plots, and through the observation of the interweaving stories of the characters in game. If staff members truly miss those interactions with player-characters so much, let them either animate NPCs for brief periods at a time, furthering their own enjoyable plots for the sake of others – or let them resign and return to being a player.

No exceptions.

 

(*On SOI, you couldn’t log into two characters at once from the same computer. It was possible, however, to force one character to go “link-dead” without quitting the game legitimately, by crashing the client or resetting your internet connection, leaving them in the game, and then log on afterwards as your staff avatar.)