Richard Bartle's Pages

The basics of MUAs are the same as for any normal adventure game, but they impose more constraints on the game author and fewer on the player. For example, the games have to be open-format rather than directed - you can't have the whole game based on a series of closely-interacting puzzles which lead you gradually through rooms in a pre-defined partial order. Small areas like that are OK, eg. getting to the druids' treasure chamber in MUD, but they have to be linked in fashion so as to enable the players to change to another puzzle if the original one has already been done. This usually implies a large set of freely-connected rooms through which the players can roam at will.

A corollary is that MUAs cannot easily be made quest-orientated. The goal can't be eg. "to retrieve the lost oracle of Thridd from the wyrmholes of Nagkha" because once someone has done that it stops the game from being solved again in the near future, and stops the player wanting to continue any more, Further, if it was a single-quest game, then it would be difficult to stop players from telling each other the complete "solution" on-line, which they tend to do with even the most minor puzzles..!

So the MUA has to be written in such a way as to have goals, yes, but be open-ended. MUD's use of wizzes (ie. wizards/witches) is now the standard way of doing this, but the are are other, alternative approaches that are being (or have been) developed which have different ways to address the problem. It will be interesting to see how these fare after being in use for some time.

MUA-authors also have to include a set of new interactive-style commands, and ensure that use of these doesn't destroy their carefully-constructed world. Many of these commands (GIVE, STEAL, TELL, SHOUT) are already creeping into SUAs to interact with game-generated characters, but even these have to be catered for more in a MUA (eg. what if someone tries to steal a boat you are actually using? Or gives you a bar of gold which makes your total weight enough to break the ice you're standing on?).

It can be seen, therefore, that the main danger is not what players do to the game, but what they do to each other! Spells are particularly hazardous in this respect; SUMMON, for example, makes you drop everything you're carrying because otherwise you might be summoned to an area carrying a forbidden object, eg. to MUD's swamp carrying a lit brand. DEAFEN and BLIND impose severe restrictions on how rooms and objects are described, and how the effects of actions are described. It's a real pain as an author having to check every time whether or not to cut out chunks of atmospheric text describing howling winds over desolate moors if the observer is deaf...

In SUAs, there are four core commands: TRANSFER, QUIT, KILL and LOOK (you might also add HELP, and there may be commands which change objects' properties, but these aren't strictly necessary) . These are general categorisations - SAVE is a form of QUIT, for example. TRANSFER is almost always written separately as GET, DROP, and the various movement commands; in fact, I'm convinced that many writers haven't even contemplated that these commands do basically the same thing, and that consequently they treat objects, rooms, containers and players as unrelated entities with different internal representations in the program (which makes it hard to write general commands that work on all object types, eg MUD's SUPERDROP for wizzes) .

MUAs have extra standard-issue TRANSFERs (STEAL, DROP, SUMMON) plus extensions to the LOOK type of command (WHO, WHERE, SNOOP). They also have a completely new COMMUNICATION primitive. Originally, this was just used for TELL, SAY, SHOUT and WRITE, but it also includes WISH and the "special effects" commands like PROOF, ACT, ILLUSION, EMOTION. There are some COMMUNICATION type commands which might rely on counting players engaged in the same task (eg. via ASSIST) but these are few and far between; most just convey player-generated information to other players.

Now the interesting thing here is that the COMMUNICATION category of commands is the only major difference between what SUAs have, and what MUAs have, that is in favour of MUAs. MUAs impose restrictions on the game author (and therefore on the game) in many other areas, as I mentioned earlier in this article. SUAs can do all that MUAs can, but MUAs can't cope with all SUA concepts. The only exception is free-form COMMUNICATION.

The astonishing thing is, communication doesn't DO anything to the game world. If you communicate, the environment is not changed in any way. Objects don't move or change properties, descriptions don't alter, rooms are connected in the same way as before. All that has changed is the recipient of the message, the player who reads what you communicated. You have slightly influenced their perception of you, and of whatever you included in the message.

This seemingly innocuous command, though, more than makes up for the constraints imposed by having a multi-user environment. It adds variety, spice, excitement, power, and FUN! That's why even otherwise badly-written MUAs can be enjoyed if they have a half-decent communication system, it's why people will continue to write MUAs in the future, and, most important of all, why people will still want to play them.