Traditionally we have a pretty democratic approach in 4D. There has always been four co-owners, with imp level and shell access. Right now one of these four, our former coder, is inactive and absent, but we have a forth implementor without shell access, who is also a builder.

Currently all decisions are taken in concensus by 3 persons, the Head coder and 2 Head builders, because the 4th imp isn't very active, (although he still logs on every day). The same three people also do most of the admin work. We have never had any problems to get along in the executive group. Occasionally we disagree on details, but all in all we pull in the same direction.

We have worked together for so long now that we think along the same lines and quite often say the same thing almost simultaneously. (This sometimes leads to funny situations, like when my Headbuilder collegue and I lost patience with a loudmouthed player and hit the mute button at exactly the same time, so that he got muted by one and unmuted by the other. Noticing this, we immediately hit the same button again, and only in the fifth try did we manage to actually execute the command).

As for the rest of the staff we have kept the 5 basic imm levels that came with the code, but they don't really matter in praxis. Instead we have separated all imm commands in different command groups, so that we can give the staff exactly the commands they need to do their job. There is for instance an 'OLC group', that all builders get in the Buildport, but we are very restrictive with it in the game port for obvious reasons. There is a 'Kill group', a 'Heal group', a 'Quest Group', a 'Teleport group' and so on.

We have no 'formal' tasks, all the imms do a little of everything, apart from coding which is too specialised. We all pitch in with administration, 'babysitting', quests and RP events, and several different imms tinker with the webpage. But we also have our main preferences. I prefer to create new zones myself, while my collegue luckily is more interested in fixing typos on the fly and updating old zones. Other imms work with personalised equipment, restrings and player houses, and a bunch of us share the task of checking new zones before allowing them in the game port. The ones with special interest for roleplay concentrate on that aspect, but big events need a lot of administration that tends to spill over on my table, (which I am not altogether happy with).

This informal way of running things probably works so well because our playerbase is pretty small, we rarely peak over 30 players. We also have 2 groups of morts with extended responsibilities and commands, Heroes and Newbiehelpers and are in the process of installing a third group, Roleplay Leaders. The idea behind this is to give the pllayers some positions to strive for, while at the same time relieving the staff of some of the daily tasks.

I recently worked on a MUSH that had a large hierarchical staff. It worked very well, but it was run by some amazing people. We had over 40 people log in on opening night: most of them came because of the owner's previous, very successful, games. The head coder I worked under was the best boss* I've ever had. Period. ('Full stop' for you Brits.)

My previous experiences, however, have been decidedly dreadful. So while I say yes, it can work, you really need to have maxxed charisma and patience stats.

Thus, on my mud, I am the Sourcerer (35). Below me are Demons (34) who wield all the nasty commands to be used on troublemakers. Then there are the Wizards (33), who have enough power to solve player problems and keep themselves entertained. Actually, each Wizard is invited to create a Demon character, but most haven't bothered, and none have ever been needed. Then there are Students (32) with very few IMM commands, a temporary level for Wizards in training to get their bearings, and Immortals (31) with goto, gecho, stat, and not much more. The Immortal level is really just for winners and visitors. If one of you dropped by to chat, for instance, I'd make you level 31 so you could poke around and see the place without having to empty my larder.

In short, I do everything myself and have a bunch of newbie helpers to keep the players happy so I can code in peace. And, any similarity to my hierarchy's style and that of a MUSH are purely intentional.

Perhaps this isn't a fair answer in a thread like this, as many of you are doubtless hoping for 100's of players. You're also likely to be trying to "open" as soon as possible. Been there, done that, I'm retired now, I like my peace, and you guys keep giving me great ideas, so I'll likely never finish!

Sandi

* This would be more meaningful if I told you how old I am and how short a time I've kept most jobs, but either would be embarassing. Just take my word for it, that is NOT the way to become an expert on management styles!

Wouldn't I :D. But seriously you made a bit of a leap there, I was talking about strictly within the MUD environment. All power within the mud is controlled by the coder do you dispute this?

I think it depends on your perspective, as well as the style of mud and the policies it uses. The coder generally has access to the inner workings of the game, but this doesn't necessarily give them more power within the mud itself.

Quote:

My main point here is that hierarchies don't make sense in an environment where only one person has any real power.

Compare it with a software company - the coders are like the developers, and the owner is like the manager. The developers could do all sorts of stuff to the product which the manager probably wouldn't understand, but that doesn't mean they should all be at the same position as the manager, nor does it mean that they have all the power.

Quote:

KaVir wrote:

I think that really depends on the individuals in question - there'll only be as much corruption as the top admin allows.

But why does it need to depend on the individuals in question? I'm naivly looking for the perfect solution not a system of checks and balances (balances move and sway and eventualy come to equilibrium, a perfect solution is always perfect), and I'm assuming corruption comes from a position of perceived power- therfore in my mind by eliminating such positions you eliminate corruption.

Ah, but I know that I'm not corrupt ;) Besides which, you can't really eliminate the owners position of power, because it's something they can take back whenever they wish.

Quote:

I dont see why newbie greeters have to be part of the staff. Slap a fancy title and a newbiepack command on a few high level players that play at different time intervals and you have your greeters.

You can do it that way as well, but it really depends on what sort of role they're performing. In some cases they really need access to certain immortal-style commands in order to properly help the newbies, and it wouldn't really be appropriate to let normal players have access to such options.

Quote:

Restrict the term staff to mean those that can directly affect the game's content.

I don't think it's as clear cut as that.

Someone could spend several hours a day developing and maintaining your mud's website, organising online staff meetings, and running quests for newbies, all without directly affecting the game's content. Surely such an individual should be classified as a member of staff?

On the other hand, a mud might allow players to develop their own game content - yet that wouldn't make everyone a member of staff.

Compare it with a software company - the coders are like the developers, and the owner is like the manager. The developers could do all sorts of stuff to the product which the manager probably wouldn't understand, but that doesn't mean they should all be at the same position as the manager, nor does it mean that they have all the power.

But you really can't make that analagy because the manager has the power to control the developer's income, whereas in a MUD environment the admin has nothing that I as a coder want or need. Therefore he/she can hold no influence over me that I don't allow them to have. True a developer might also find another job, but realistically this will not happen unless something drastic forshadows it. On a mud, finding another place to code is as simple as- 'coder looking for work (will do DBZ or SWR)' on TMC... you keep trying to bring in external influences that I am not interested in dealing with in my treatment of the subject. Perhaps it is my naive miopia but I really think MUD administration is much simpler than you all make it out to be, and that by including all these complexities you are perpetuating a self-fullfilling prophesy...

KaVir wrote:

Besides which, you can't really eliminate the owners position of power, because it's something they can take back whenever they wish.

Yes, but thats meaningless for the same reason stated above. This is a coder's market and always will be.

Basically what Molly stated in her post was exactly the type of administration I am talking about, and I am happy to hear it works well for her.

But you really can't make that analagy because the manager has the power to control the developer's income, whereas in a MUD environment the admin has nothing that I as a coder want or need. Therefore he/she can hold no influence over me that I don't allow them to have. True a developer might also find another job, but realistically this will not happen unless something drastic forshadows it. On a mud, finding another place to code is as simple as- 'coder looking for work (will do DBZ or SWR)' on TMC... you keep trying to bring in external influences that I am not interested in dealing with in my treatment of the subject. Perhaps it is my naive miopia but I really think MUD administration is much simpler than you all make it out to be, and that by including all these complexities you are perpetuating a self-fullfilling prophesy...

Yeah, you can get a position on any Podunk Mud you want to, but I imagine most programmers of decent repute (of course, I can only speak for this one) would rather either work on their own muds or on a well-respected, stable project that they actually like, in terms of management and the game itself. These are not quite as easy to come by. And that's not even considering the amount of work they are most likely abandoning by leaving. Yes it's true that you can walk out anytime you want, but so can anyone else on the staff. This doesn't really mean anything. And if the owner walks out, well, it's not just a matter of getting new coders then, is it?

As for MUD administration being simpler than we all make it out to be, there are muds with hundreds of concurrent players and hundreds of zones, hundreds of thousands of lines of code, etc. Managing all of this is not quite trivial. Most large projects of any kind have at least some sort of division of labor. MUDs are not really any different. As I said, this is really a function of size. For a typical mud whose player count tops out in the low-to-mid double digits, of course you don't need a very complex structure.

Yeah, you can get a position on any Podunk Mud you want to, but I imagine most programmers of decent repute (of course, I can only speak for this one) would rather either work on their own muds or on a well-respected, stable project that they actually like, in terms of management and the game itself.

Well said. To pick the common thread from most of these posts, it's clear that the structure of an administration is less important than the quality and management abilities of those wearing the captains' hats.

I think most (if not all) succesful muds have an owner who is the head coder as well. That's about all I know about it.

Depends how you define successful. With over 14 years under its belt, and a stable playerbase of 20-30 players online (which is the number the mud is designed for, more or less), I would call Midnight Sun successful. Not only don't we have an owner who'd be the head coder - we don't have an owner at all. The mud is hosted on university bandwidth and on a box bought from player and immortal donations. The original creator is long gone, and all important decisions are made by admin vote. If we were to pull the plug, the admins would have to agree on that decision. But no single person on the mud has the ultimate authority (okay, except the guy who occassionally trips over the cable in the lab).

Well, we are an LP mud, so the distinction is not that sharp. The mudlib is maintained and developed by all the active admins (typically between 2 and 4 people), who coordinate their work, but some mudlib coding tasks may be even delegated to other staff members.

Well, we are an LP mud, so the distinction is not that sharp. The mudlib is maintained and developed by all the active admins (typically between 2 and 4 people), who coordinate their work, but some mudlib coding tasks may be even delegated to other staff members.

I'm also part of an ownerless mud. Well, seemingly ownerless. The owner remains hidden to the players and wants no creative control or power; he wants only for the mud to continue and thrive because he's always enjoyed it. The distinction is also not clear in our case - and I think it works great. But it might work great because of the personalities at hand, none of the staff is power hungry - they only want to help the game itself.

I can't imagine some other games I've played going this route; someone would want to take the reigns and declare himself the boss. So to answer the first post - what works in terms of staff hierachy's and whatnot really does depend on the people involved, in my opinion.

I think most (if not all) succesful muds have an owner who is the head coder as well. That's about all I know about it.

We are a H&S diku derivative, pretty successful, and our owner can code but isn't really the head coder. In fact, we don't really HAVE a head coder - we have about four people who are pretty good coders and code varying amounts (the owner is one of them, but he codes very little), and maybe four more who are less good coders and code with advice from the first four. We don't treat coding decisions as different from any other sort of administrative decision.

The imms had basic powers such as teleportation, moving things, working on help files and making emotes, and basic building. The gamemaster rank had all the imm privs, as well as roleplaying based privs, and the admin ones had everything including all the coders debugging tools.

Now we've busted out to 5 ranks. They are as follows:

Apprentices can use teleportation commands, help and emote editing commands.

Builders have all the powers for building mobs, objects, rooms, configuring areas, cloning things and search powers for all building related databases.

GMs have the powers of the below, plus roleplaying tools. This rank hasn't been expanded much yet as we're still not open to the public. They also have things such as organisation management and creation, access to player records and player management tools(such as kicking and banning).

Admins have all the previous powers, as well as bulk building tools and deletion tools. To save against screw ups, we use double-switched commands that require the comfirmation of another online admin or above for many admin commands, such as all the deletion commands. Admin can also promote normal users to apprentices or builders.

Coders are the highest rank. They have access to everything, and have a few coder only powers which are mainly debugging tools for when things go wrong. They can see all untrapped bugs as they happen, as well as histories of errors and what caused them online. I'm very happy with the error monitoring tools, they look sort of like this:

Coders can also make GMs, and admins. There is a hidden level 6 which I am, which can be used to make coders.

Thats it in a nutshell. We do this mainly to keep some of the more dangerous commands only in the hands of those who really know what they're doing with them. We keep the organisation of the mud very democratic, which is probably odd for a commercial mud. I find people create the best when they all have an equal say in how things will work.

Well, I don't know what system you would call it, but KISS ( Keep it simple stupid)

At Darksun, we run like this.

3 Overseers
Thse are your head admins who have complete control over who gets on staff and who doesn't. They handle just about everything that needs it that cannot be handled by the other staff. The reason why 3 and not 4 is to keep it without argument. This means, that if we vote on something, it's going to be 3:0 or 2:1 no matter what.

Senior Staff
These are the guys you trust to look out for your other staff, help them, make sure they're doing their job. Basically your supervisors, but they also work.

Staff
These are your all around staffers who do what their told and take on projects of their own with approval from Senior Staff.

Most everything gets passed by the OV's by emailing the mud address that is monitored by the OV's.

So far, this system has proved invaluable. We have trust, our staff work, and we get along.

Personally, I think the organization of staff on a game depends on the actual size of the game and how many people you have working for you. On Medievia, we have 100+ active gods/goddesses at any given time. Because we have so many, we have a heirarchal structure. Throughout the years we have developed our god system and it is very well tuned and works very well. All the volunteers who work for us know exactly who to go to for help and/or training because of the structure we have created. Each level of gods/goddesses have different privileges within the game and different commands they have access to.