Determining Staff Policy, Part 1

In this post, I’m going to try to focus on the reasons why a stable staff policy is absolutely vital, and the reasons why many MUDs out there seem to lack a coherent, quantified staffing policy. I won’t touch yet what I think makes a good staff policy – but I want to provide background for how I think problems arise, and how they can continue to persist even in successful games, and lay the groundwork later for discussing how to avoid these pitfalls.

In my experience, the genesis of most MUDs (note: my experience is almost exclusively limited to RP encouraged or “RPI” MUDs) is not a well-planned thing. Most MUDs come about either spontaneously, as when a few close individuals with a similar idea have ready access to a code base and the tech know-how to set up a MUD, or reactively, as when a (again) few close individuals disillusioned with their current game decide to create a better, idealized game for themselves, lacking in the same perceived problems their original game had.

Shadows of Isildur was created by staff who were disillusioned with their current game’s direction and left to make their own, better game. Likewise, Lost Tales of Beleriand was created by former SOI staff disillusioned with the current direction of Shadows of Isildur. Atonement, too, was created by staff who were disillusioned with Shadows of Isildur’s direction and left. Parallel RPI, Mirrors, and the various other MUDs that grew out of the RPI++ Engine were largely founded by (again) disillusioned staff upset with Atonement’s direction – or lack of direction after it closed. They left to forge their own way. Shadows of Isildur itself, disillusioned with previous incarnations of Shadows of Isildur, closed and reopened several times under largely new staff direction each time. Black Sands, created using the RPI Engine, was created by players disillusioned by the direction of another well known RPI, Armageddon. Black Sands isn’t the only MUD (not by far) created in reaction to disillusionment with Armageddon staffing policies and direction, but it is probably the most successful of the attempts. As I’m most familiar with the RPI Engine family of games, I’ve focused my attentions there. And I think I’ve made my point.

Again, not all games are created as a direct result of disillusionment and jaded staff (or players) – for example, take a new MUD, currently in its early Alpha stage, running on the RPI++ Engine: Lautolae Springs. It’s the perfect example of a MUD’s genesis being influenced by a few close friends and a shared goal. At any point in time, there are nearly half a dozen MUDs in development like Lautolae Springs, created by friends and run by friends. Whether they succeed or fail matters very little to me for the purpose of this discussion – what matters is that, almost exclusively, these games are run by a close-knit community that will police itself to its own unspoken standards.

Staff who know each other and trust each other do not need to worry about codifying a detailed set of rules and standards, and because they do not need to worry, often do not bother with staff policy at all beyond a few broadly stated ideals that can be largely boiled down to: “be fair.”

While games are small, and the staff who maintain those games are close-knit and trustworthy, the rule “be fair” is often enough. But staff turnover in MUDs is historically quite high, and often after a game is opened to players, divisions arise where previously there had been none. When games are still being built, everyone is on the same page, and it’s “us against the world” – but once those games allow players to create and play characters, real life tends to encroach, or boredom, or staff members realize that they would rather play in the world they have created than oversee it. Even though staff members are volunteers, their workload can be as tedious and mind-numbing as in a real job.

Regardless of how it happens, new faces replace old ones, and staff numbers tend to expand. New staff members, rather than being a part of the close-knit circle of staff who originally created the game, have their own friendships and loyalties outside of staff. Staff members are no longer close-knit, but instead become competing heads of various cults of personality. “Us against the world” becomes “me against you” – and it’s not uncommon once that occurs for staff members to complain that other staff members are ruining their fun, destroying their sphere, harming their clan, or unfairly biased against their favored players. Sometimes their complains are legitimate (after all, it’s now “me against you” for all parties involved) but other times these are knee-jerk accusations leveled at staff members who are still trying very hard to adhere to the golden rule of “be fair.”

As Atonement sits more freshly in my mind than Shadows of Isildur, and those are the two MUDs I am arguably most familiar with, I’m going to use Atonement as an example of… well, all of the above.

Atonement was created by the Northlands sphere staff of Shadows of Isildur. Their sphere lead, Songweaver, was upset with the direction of the game – more specifically, he was upset with some of the other members of staff, and the abuses of power he had witnessed during his own tenure. The Northlands team left to create their own MUD, united from their struggle against power abuses, but wholly lacking a unified idea from which to base a game. Instead, a number of ideas cropped up: one staff member wanted the setting of the game to feel very much like the Wild West, with a small town positioned on a trade route between large nations. Another wanted a sleek, sexy cyberpunk game with lots of neon glow, and a chic Parisian atmosphere. Another staff member wanted the game to take place on a prison ship orbiting Earth, where gangs fought over automated shuttles delivering food. Another staff member wanted the game to take place on a terraformed Moon, while the Earth hung holocaustic and dead above the horizon.

To appease everyone, compromises were made that ended up alienating everyone instead. It was determined that each setting would be given its own pride of place eventually. The first stage of the game would take place on a space ship with limited resources. The second stage of the game would take place in a small town on the moon, with a Wild West vibe. The third stage would take place on Earth, in a glossy, glamorous future Paris. The staff member who championed their setting would become the lead of the stage that their setting sat in. Crisis averted.

The problem, of course, was that this compromise averted nothing. The staff member who championed the spaceship setting was not a builder and had no interest in building the game. The staff members who did build had no interest in building Alpha because it was not their version of the game, and they had nothing invested in it. Interest waned. Those staff members who were waiting for the later stages of the game to roll around ended up leaving as other games, and real life, took precedence. When the Alpha stage of the game was eventually completed using volunteer builders, the game had nearly no staff left to speak of out of their original crew. New staff were eventually hired. Staffing policies were not ever clearly detailed, which would lead to friction down the road when those new staff (now running the game with newer staff under them) came into conflict with players over accusations of staff abuse, favoritism and corruption.

As tempting as it is to put off a robust staff policy until the game is more popular and stable, there’s a good chance that if it isn’t built alongside the rooms, objects and NPCs of a MUD, the staff policy won’t be fully actualized at all. Without clearly detailed policies, there will always be mistrust between players and staff – and confusion among staff on how to act among their peers, as caretakers of the game.

The question remains: just what the hell makes for good staff policy?

Welcome to the Lab (alternatively: Watch This Space)

Hold onto your pants. With FutureMUD development proceeding smoothly, it’s finally time to get the ball moving on LabMUD.

Wait, what is LabMUD?

LabMUD is, as evidenced by the header, a demonstration MUD. It’s meant to showcase the FutureMUD engine during early development, and to act as a platform for balancing and bug-fixing while still running as a fully functional RPI. That means it is (or will be) fully open to players, volunteer staff members, and be as (in time, at least) full featured as any future FutureMUD engine game. Roleplay will be enforced. Permadeath will still exist. The difference between LabMUD and, say, any other fledgling RPI with an evolving codebase is that LabMUD exists primarily to introduce new systems and code to unfamiliar players and staff members in a controlled, (hopefully) fun way. While LabMUD may outlive the development cycle of FutureMUD, it is not envisioned as a standalone game that continues without end, but rather as a stepping stone toward full release.

So, where are we now?

Right now, we’re focusing on getting the MUD finished, which means wrapping up all building and backend stuff. There are no rooms left to describe, the game world is linked in and most objects have, at this point, been completed. Skills have been finished. Culture has been finished. Ethnicities are being finished as we speak. Chargen has been tweaked to be LabMUD appropriate (rather than FutureMUD appropriate) but may require additional fixes before it’s ready. Still, that’s not a big issue. Time, celestial objects, and language are complete.

Helpfiles are NOT ready yet, but I’m of the opinion personally that if we launch with the bare minimum necessary, we can always add more as the game progresses. Ideally, I’d like to see a way to log what helpfiles are most commonly searched for by players, so staff can focus on what’s actually being searched for rather than wasting their time on every little esoteric command in the game.

We’re also still working on getting the website finished. This includes the forums. While they are fully functional at the moment, they are ugly. 

When can we see LabMUD open to players?

Plainly? Whenever it opens. While the game is almost completely built, it does still lack certain coded systems. FutureMUD does not yet have (for example) a combat system, or a crafting system, or weather. LabMUD will probably open before crafting, or even weather, is complete, but we would like to see combat in its very basic form (at least) before throwing the door open.

So, yeah. Watch this space. Periodically, we’ll be posting updates and (should our fancy be tickled) narrative fluff. You can also follow us on Twitter if you’d like. We have one of those now.