Back to index

The copyright situation for this article is unclear. It does not belong to the author of this site. Please see the copyright notice. If you have information about the copyright contact me!

Working in a Group

by Patrick Dughi

The single most important idea when working on a joint project can be summed up in one word: "Responsibility". You need to know who is responsible for what. These can be broad, but the more specific you can get, the better it gets. Let us go back to what I said in Part I:

".. sounds mindless, and it is. It ought to be".
A light sabre!

Nice Sword?

I admit, that sentence was deliberately worded to incite. It would be more accurate to say "A person in the role of 'programmer' is responsible for generating code and nothing else". Wow. That sounds pretty bad too. Maybe I should include the concept that any one person can play several roles at once. Your mud owner is sometimes also the head builder. Your builders are sometimes privy to development team issues, and so on. Your programmer may have been the guy to introduce the whole idea in the first place. On the flip side though, the programmer is also responsible for not adding in his own special changes, even if he did create it. Roles may be spread, shared, or grouped, but each should be distinct. Job names (like programmer, builder, etc) are suggestive, whereas roles are absolute.

(I am a 34'th level multiclass Programmer/Administrator/Enforcer!)

The actual writing of code then, is not mindless. It is just that there is no effort expended by a programmer role-person to figure out what to program. It is rarely mindless to determine how to best write that in code. The 'programmer' is just the well-defined role which gets a project outline, fills it in as best they can, and is not so creative as to scribble outside the lines. It is up to them though, if they are going to write the code upside-down while wearing clothes made entirely out of meat, or right-side up while yodeling.

The roles required for your game are usually apply only directly to your game. It is hard to have a 'Vampire Conduct Administrator' role if you do not have vampires in your system. All the same, there are many reoccurring types which do surface. Though I cover some all-too-briefly here, you must identify and flush out the roles for YOUR game. These descriptions are not to be taken seriously, they are your reward for reading this far.

Mud Owner

You can tell if you are a mud owner if you can say "This is MY mud," before you ban someone from the mud for life. You made the game in the first place, after all.

Administrator

You can tell if you are an administrator, if you can say "This is MY mud," but you know you are lying to yourself. You are probably an ex-administrator if you ended up stealing someone else's code to start your own game ;) Administrator's often use the phrase "I saw this great feature on this other mud I play, and I think we should put it in here."

World Builder

If you fear the phrase "When will your zone be done?", you are probably a builder. If you like tacky color combinations like "An amazing sword." or think you are a gifted poet despite the fact that your 5-8 line gothic prose makes your teachers mock you when they confiscate notes you pass in class …. You have the potential to be a Builder. ;)

Player Helper

You are probably a player helper if you have been playing for a long time, and have just started in an administrator position. If you work for Verant, or Origin Systems, and are not being paid, you are a player helper. Another way to say this is no one trusts you enough to perform a real job, but they feel sorry enough to keep you around. Quit 'helping' the characters of the opposite sex so much, you letch.

Enforcer

Your sentence structure is easy to remember, in pseudo-adlib style:
"I had to [mute | @toad | freeze | ban | kill |offend] [you |a player | an administrator | another enforcer | myself] because of [repeated rule violations | failure to comply with orders | disrespect | inability to play well with others | manufacture of atomic weapons | being part of the 'red' threat] , and I recommend that they stay that way [until the end of time | forever | till pigs fly | till they are dead | hell freezes]."

Generally, you feel good when others cry. It means either you have a job to do, and you do it with vigor, or you just did your job, and did it well.

Coder

If you know more about the game than anyone else, even longtime players, and are prepared to face down the wrath of the mud owner just to prove that a given skill really does confer +3 damage, and not +2 as had been commonly assumed, you are potentially a programmer. It is your job to 'make things go'. You keep the mud up, which is ironic, because it is your mistakes that are most likely the cause of it crashing in the first place. If you can explain how the crashes are actually the Builder's/players fault, then you are a coder.

Idea Mill/Development Team

This role is rarely singular, and often is shared among every staff member, on most muds. Players often try to fill this role as well, and god help you if you let them in. This is where the projects for the advancement of the mud come from. If you are ever said "Well, if the programmer would just write the damn AI already, we would already be half way done," or "I saw 'The Matrix' today. Let us make the mud exactly like that. I will beta test, if you can have it done tomorrow." Delusions based on effort required to produce a given goal are common.

My advice to you is to lay off the heavy drugs. We are worried about you, okay?

Back to something approaching seriousness, you have to find the roles for your mud. You have to define these in such a way that there will not be confusion, as to which person should and is allowed to do which task. When you have less contention between roles, you will usually end up with less contention overall. I will finish this section with a real life example showing what happens when the definition of a role is poor;

Macbeth and Anne are both Administrators charged with the 'role playing administrator' responsibilities. A role playing administrator's job is defined as:

"Run one quest each week. A quest is a role playing event that emphasizes character (not player) interactions. Your job is to provide atmosphere, story, plot, side characters, etc. You may also seek to promote role play (character-character interactions, as opposed to player) any time you see it."

Seems okay so far.

They both are avid players, and usually only log on their administrator characters to perform their duties. Anne is playing her character when she notices a role playing group spontaneously forming. She hops on with her administrator character, goes invisible, and immediately gives the group purpose by animating and talking though an NPC. About 5 minutes into it, Macbeth logs in, and notices that same role playing group. He sees Anne, but decides that he, being the older player, is more qualified to run any role playing session. He tells Anne so, and tells her to join with her player if she wants to be a part of it.

Yes, their roles were apparently well defined, but not specific enough - unlike the enforcers that had rules stating "No one may overrule a punishment of an enforcer except by that enforcer's consent", the role play role was internally without structure. There were no definitions about how someone relates to another. That above scenario played out over a few days, and involved Macbeth being fired, and Anne quitting. Also a decent amount of hostility among players and friends of these two older characters. These roles needed to be better defined when they were created. The proof, as they say, is in the pudding.

I do not know anyone who actually says that.

Of course, this will not happen in all circumstances, just the same as keeping the roles well defined will head off all arguments. The trick is that if there were solid rules stating what a player can and can not do as a role play administrator - even to other role play administrators - this would not have happened.

Picking the right people is a good trick too, but you will have to figure that one out on your own.


Patrick is a long time mud player, builder, and programmer, paper RPGer, frequent contributor to the CircleMUD, and more recently mud-dev mailing lists. Currently programming for IBM, and not currently associated with any particular mud - just sort of free lancing and working on my own projects, though he has been head programmer on several muds in the last 8 years or so. A man who owns his own claymore.