2. Game Architecture.

2.1 Technical Aspects.

To gain the most from reviews of MUAs, some understanding is required of how such games work. In essence, they can be regarded as high-level operating systems. Players log in to a host computer interactively over an appropriate network. The host computer usually has a fast processor and lots of disc space, because MUAs are computationally expensive. Players type commands on their own home micro, which are passed through the network to the host computer. This takes commands from all players, executes these commands (usually asynchronously - ie. in turn - but sometimes synchronously under timesharing), and sends information back based on how the commands were interpreted in the game context. This information is then displayed on the players' computers. Thus, it can be seen that players' own computers act as 'front-end' processors for the host, handling all i/o. Although most front-ends are dumb, in that they send raw commands and print raw output, some are intelligent enough that they can draw pictures when instructed, word-wrap, produce sound effects, and so on.

The game running on the host computer will be either 'Interpreted' or 'compiled'. Interpreted games are written in a MUA-specific definition language of the programmer's own design, and are flexible, easy to modify, robust and slow. Compiled games are hard-coded in a standard implementation language such as C, and are inflexible, hard to make changes to, fragile and fast. The better games are interpreted and use fast hardware.

The way games behave is determined by a definition file, commonly called a 'database'. For interpreted games, it is rarely a database in the conventional sense of the word, being more akin to a program. It becomes a database when converted into internal data structures and loaded into memory. Even compiled games rarely use a true database for definition purposes.

Interpreted games can behave radically different given contrasting databases as input. Compiled games will generally use the database only for text. Interpreted games are managed by an interpreter program, which can take as input the database of any game written in the appropriate definition language. Thus, having written an interpreter for one target machine, any MUA written for it will automatically run on all other machines for which interpreters exist. This is not the case for compiled games, which must be written virtually from scratch for each game.

In executing players' commands, the process is one of database management. Players issue commands in a stylised form of (usually) English. This is parsed into a tuple normally of the form verb/object/instrument. The game uses these tuples to look up instructions in an internalised database query language, and those instructions are then executed to interrogate or modify the database. Success/failure messages are passed back to the player who issued the command, and to other players entitled to receive them.

2.2 Operational Aspects.

From the players' point of view, the underlying mechanisms are of little or no interest. To them, MUAs are environments where things happen. Players have 'personae', which exist in a world elsewhere. The computer is their interface to this otherworld, carrying out their orders and reporting back to them what has happened. MUAs are sprawling landscapes, richly described, and you can try anything (within reason) that you like.

Taking a less poetic view, MUAs are made up of 'objects', which have properties. Some of the objects represent rooms, others represent players, and others represent ordinary/non-special objects. Rooms are linked together in a network by means of 'exit' properties, and each has a 'contents' property (ie. a list of objects the room contains - it can be the empty list). If a player object is in one room, then executing for that player a movement command (eg. "north") involves taking the following steps:

1. Find the room which has, in its contents property list, the object that represents the player who issued the command.
2. On the inter-room network (the 'travel table'), follow the north exit property for this room to find another room.
3. Remove from the contents property list of the first room the object representing the player who issued the command.
4. Add that object to the contents property list of the second room.
5. Check through all other objects in the contents property list of the first room: for any that represent a player, send the message "<name> has left." to that player's front-end, where <name> is a string property associated with the persona of the player who issued the command.
6. Check through all other objects in the contents property list of the second room: for any that represent a player, send the message "<name> has arrived." to that player's front-end.
7. Send to the front-end of the player who issued the command the description property of the second room.

From this example, it can be seen that MUAs are really little more than a framework of discrete objects which players can manipulate by commands, with an additional facility for persona-directed message-sending. In a well-designed game, the ways in which objects can be manipulated bear a close resemblance to the real world, so that when a player uses a command like "drop" the result can be predicted relatively easily. Poorer games may not allow objects to be handled in ways that one might expect they should be, eg. it might be impossible to place one object inside another. Some MUAs are underconstrained in this respect, eg. you can place a large object inside a smaller one.

In addition to objects representing players and rooms, there is a third category of special object in many games, 'mobiles'. These objects represent "intelligent" inhabitants of the MUA's environment, but rather than being controlled by players, instead they act under the instructions of the game itself. At worst, this means they act mindlessly, moving around on a fixed course and attacking things at random. At best, they can communicate, pick up and drop objects, and have at their disposal the full set of commands available to "real" players.

To become games, rather than clever but boring world modelling systems, players have to be given a goal. The commonest way to implement this is by associating with players a score property that can be incremented if the player performs the right series of actions. Normally, this involves seeking out objects designated as treasure, and depositing them in some given location. However, in most games such points can also be gained for solving puzzles, or for winning fights against mobiles or other players. When players have accumulated enough points, they go up a level of experience, and gain more powers. Reaching the final level is the overall goal, and at that stage powers are granted which are so considerable that the player can use them to change the very character of the game, hopefully to its benefit. This top level is usually 'wiz' (short for 'wizard/witch'), but recently the word 'god' has become increasingly popular in newer games whose authors want to emphasise the rewards of reaching the top. There is sometimes an 'arch-wiz' level, which is invitation-only and used for game-management purposes.

Fighting is part and parcel of most MUAs, although some deliberately omit the concept, either for programming reasons, moral reasons, or both. In fights, a player or mobile attempts to cause damage to another player or mobile. If more damage is given than the victim can receive in total, then the fight finishes and the victim "dies". What happens to their persona then depends on the game: it is either eliminated, or it is allowed to return (but usually at a lower points total). The loser's fate may also depend on who started the fight. Fights proceed either automatically, with blows occurring until one player flees or is killed, or on a blow-by-blow basis. The former is fairer in fights against players with fast comms links or against mobiles, but the latter is more realistic.

The concept of the 'reset' is central to many MUAs. With several people in the game, puzzles will rapidly be solved and objects swiftly removed from play. After a time, there is nothing left to do. At this point, the game resets, ie. it starts afresh, with only players' personae remaining as they were previously. Doors that were opened are closed, dead mobiles are resurrected, and objects are arranged in their original places. In some games, players can continue to play earlier sessions until they quit, and in others everyone is ejected. With 'rolling resets', objects are replaced individually without disrupting the flow of the game. Although this is less harsh on the players, it can make planning your future actions difficult, and the game is usually lacking in complex puzzles as these can be hard to invert. Games that don't have any sort of reset either exist around the concept of performing quests of some kind, are primarily for building your own worlds, or are incredibly boring to play.

A recent trend has emerged for MUAs which do not place much emphasis on puzzle-solving, but instead focus on world-design issues. Players are allowed to add rooms and objects (rarely commands) indiscriminately. Other players then explore these areas. Little goes on here that could be called "gaming", and the whole exercise can be seen as a means of providing common subject matter for people to talk about in what is really just a thinly-veiled chatline. Nevertheless, there are conventional MUAs where object-creation by wizzes is encouraged as a means of providing new and original puzzles for non-wizzes (mortals) to solve. As this is a post-MUD1 concept, however, most of the older games and their descendents are not specified highly enough to be able to implement it.

Since they are all descended from MUD1, MUAs have a common core of commands, the following of which are the bare minimum necessary: movement commands, 'get', 'drop', 'quit', 'say', 'inventory', 'score' and 'help'. Most also have 'kill', although some do not (by design).

2.3 Managerial Aspects.

Running a MUA is not simply a case of mounting a game on a computer and inviting all-comers to play. MUAs arouse such emotions in their players that they will often resort to lying, cheating and vitriolic abuse to achieve whatever goals they have set themselves. Many games have suffered from poor management; what seems good in the short term can have serious long-term consequences concerning the game's playability and its attractiveness to players.

As well as the rules which are encapsulated by what the game will allow players to do, MUAs also have a set of (usually unwritten) rules that define the boundaries of reasonable behaviour. Although some MUAs may allow swearing, for example, others will not. Many MUAs disallow a practice known as 'looby-looing', where one persona takes all the risks to gain points for another persona (normally owned by the same player). MUAs with fighting will generally take a grim view of players who 'pslam' (ie. hang up the phone) during combat. When people reach wiz level, they have powers to harass and victimise mortals beyond all endurance, and should keep themselves in check. What happens if they don't, though? Should they be punished? If so, how?

Answering these questions is the essence of game management. Good managers with years of experience behind them are rare in MUAs - most new MUA managers have little or no idea of this aspect of the game when they start up. Once they have gained the required expertise, it's often too late to do anything about it, especially in a pay MUA where customers would lose the results of years of effort were the persona file to be reinitialised (the last resort!).

Although under-management is the most common fault in MUAs, over-management (when it happens) is worse. The consequences of accusing innocent players of doing things they haven't will drive away more players than will allowing a guilty player to play unchallenged.

It is beyond the brief of this report to go into details of how a MUA should properly be managed; it is sufficient to point out that games can be wrecked by the antics of the people in overall control (however well-meaning they are). To give some flavour of what can and does go wrong, though, here is a list of common mistakes:

• Granting too much power to inexperienced people. Players who are given the ability to interfere with other players without fear of repercussions will do so unless they have learned already the full consequences of such actions.

  Usual cause: too few points required to reach wiz.

• Giving too much power to stupid people. As above, except that the player is too dim to realise they're doing wrong. Sad, because some dim people plod on for years striving to make wiz.

  Usual cause: no way for non-stupid people to eliminate the stupid people, eg. death by fighting.

• Reinstating people who "lose" points through no fault of the game's. What happens is that people take advantage, claiming for "lost" points they never had in the first place. Points should only be given back if they were lost through a game fault, and then only if a small number of players were affected.

  Usual cause: belief that no-one would lie to you.

• Failing to remove persistent offenders. If you allow disruptive elements to continue playing, they'll just push the limits of acceptable behaviour back even further the next time. Getting rid of one bad guy and ten hangers-on will net more good guys in the long run.

  Usual cause: giving "one last chance" too often.

• Favouring some players over others, and letting them off when they make a mistake because you know they didn't mean it, or they're friendly, or they were drunk, or they have twenty messages of support from friends. The majority of players may remain silent, but they won't forget the inconsistency when you hammer someone else for committing basically the same offence.

  Usual cause: believing the flattery of others.

2.4 Scenarios.

MUAs implement an imaginary world. There are no constraints on this at all, except those imposed by the operations allowed on the database and the objects the database can represent.

MUD1 was set in a fantasy environment, ie. a vaguely medieval world where magic works and dragons are real. Most of the first generation of lookalike games stayed in the genre, partly because the authors liked that kind of game (or they wouldn't have played MUD1), and partly because MUD1 could be used as a source of ideas for commands, spells, monsters and so forth.

As MUD1 was interpreted, it was possible to use the same shell to interpret alternative databases, and experiments were done into other domains. These included ITV's Fraggle Rock, Essex University's computing department, various aborted science fiction worlds, and more assorted fantasy environments.

Nowadays, although fantasy still predominates, MUAs are set in the whole range of scenarios popular among face-to-face role-playing games players (cyberpunk, 1920's Lovecraftian horror, Arthurian Britain) plus others beside. Some of the DIY-style MUAs have all of them together in a colourful tapestry (or hotch-potch, depending on your degree of cynicism) of intermingled milieux.

The setting of a MUA is one of the most important things about it. In choosing between two competing MUAs, players will select the one with the atmosphere they like the best, be it a gloomy, dark future, mystique-laden high fantasy, or dreamy spirit-world. Although the other players contribute greatly to this, the primary source of atmosphere is the game itself. For text-based MUAs (which almost all are), the impact of well-written room and objects descriptions on new players cannot be understated. However, writing these descriptions is no easy thing - an average sized game can easily have a novel's worth of material embedded in the way it describes locations.

2.5 Clients.

Although they are not strictly part of a game, clients can greatly enhance its attractiveness to players. Authors of these programs command respect from the MUA-playing community commensurate with that of MUA authors.

Clients are programs that are run on the front-end of a MUA, and their purpose is to make playing the game easier. They are basically comms programs, and although they preponderate in the academic MUA world, nevertheless there are clients for commercial games. Usually, a client is written specific to one MUD, but some function adequately with others.

As well as basic i/o and network management, clients let you do things like:

• gag a player (not print any lines containing that player's persona name)
• highlight a player (print that player's persona name in reverse video or a stronger colour)
• log all i/o to a file for later perusal
• define macros, so a few keystrokes can expand into a longer command string
• load files and transmit them as if they had been typed directly
• perform screen functions, directing text of different origin to different windows
• log in to a MUA automatically (sometimes also concurrently)
• set trigger commands to be executed automatically when a given event occurs
• use command buffering to pull back previous command lines, edit them them, and transmit them to the MUA
• repeat commands any number of times
• fork a shell process to gain access to the operating system

Clients can also be used to do sound effects and graphics, but are always MUA-specific in such cases.

2.6 Bots.

Bots ("robots") are programs which play MUAs using the same interface as players. Like clients, they are not part of the MUA per se, but their programmers are considered important individuals in the MUA field. Apart from some experimental versions in the commercial sector, all present-day bots run on academic MUA sites. On the face of it, bots are indistinguishable from players, although from their reaction to events and communication they can invariably be recognised for what they are. Bots predominate on MUAs which are not sophisticated enough to have intelligent mobiles, however in the future there may be some mobiles that evolve into bots so they can be run on another CPU.

Bots are not as popular now as they were at first, because after the novelty wore off they lacked any real lustre, and people became bored with them. Also, they tend to crash the (surprisingly fragile) academic MUAs upon which they run, and can generate lots of background "noise" that irritates players. When several bots were run at once on individual MUAs, that also angered human players.

Bots are usually able to perform the following types of action:

• mapping
• reaction to keywords
• the registering and forgetting of players over time
• liking and disliking players
• obeying commands from authorised players (including repeat-until commands)
• the ability to log data to disc
• the ability to give help to players
• movement
• the creation and use their own macros
• communication with players (usually not too well, but sometimes using an expert system interface)

2.7 Indicators.

To compare MUAs against one another scientifically, some means of assessing their strengths and weaknesses in important areas must be established. It is beyond the scope of this report to suggest a formal approach to this; however, the main parameters by which a MUA is commonly judged should be expressed, so as to help place the reviews of individual MUAs in a wider context.

When considering a MUA, then, experienced players and reviewers look at the following indicators:

'Breadth'

'Depth'

'Selective depth' is where the system can handle a concept when applied to one kind of object, but not to another. For example, rooms may be able to contain objects, but boxes might not; players may be able to carry objects but mobiles might not; a box may be able to contain another box, but not if that second box contains another object; players may be able to enter a vehicle, but not drop things into it from outside. Selective depth problems are usually caused by omissions in the initial design of a MUA or by having parts of the database designed by different people.

All MUAs are based on discrete objects, and are consequently pressed when obliged to represent continuous quantities such as fluids. Most MUAs can handle containers, but almost all MUAs are unable to model what happens when a jug containing 5 litres of water is poured into a bowl with a 3 litre capacity. Likewise, it is beyond the definition languages of most MUAs even to express concepts like temperature or density, let alone provide a working ontology.

Another representational problem concerns compositionality. If 1,300 matchsticks have been made into a model of the Eiffel Tower, and 700 are removed, does that leave a 600-matchstick model? What if 1,299 were removed? What if only 1 was? What if the matchsticks were made into something else? Even the best MUAs have tremendous difficulty in this area, and it is therefore either avoided completely or simplified by use of a "make" command that only works with certain other objects as ingredients.

Since the idea of rooms is central to MUAs, there is often a problem with things that happen across room boundaries. Line-of-sight is hard to implement, as are determining the direction from which distant noises come, representing smoke or weather that covers a wide area, and inclusion of "small" rooms that can only hold a certain volume, eg. inside a grandfather clock. Some MUAs are (co-ordinate) point-based rather than room-based, which makes directional calculations easier, but they have related problems in dealing with objects larger than the granularity of the points.

MUAs with great depth can suffer if too much detail is given to the players. Players do not like being asked over which joint of which finger of which hand they wish a ring to be placed. They don't like being informed of how many petals there are on the flower they have just picked, nor do they want a 400-line description of the painting they are looking at. If a MUA deals with details, it should only bring them to the attention of players when it is important to do so (either for breadth or puzzle-solving reasons). Detail for its own sake is tedious.

'Size'

Some of the world-construction MUAs do actually have thousands of rooms in the conventional sense. Even though they have large numbers of people playing simultaneously, they are nevertheless sparse. Unless players can easily find out where other players are located, and can easily get to those locations, these games may as well be single-user.

There are other factors determining the feel of how big a game is, such as the mean distance of rooms from the start, and how many people play at once. These are flexible, though, and for a commercial MUA any figure from about 200 rooms to 1,000 will probably be OK. New games that boast thousands of rooms are not, on the whole, to be taken seriously.

'Parser'

Good parsers allow adverbs, and will fold these and prepositions into the verb to produce a new verb: the sentence "go west quickly" might, for example, convert into the tuple run/west; "put the apple in the box" might convert into insert/apple/box. Similarly, good parsers allow adjectives to apply to nouns, as in "get the gnarled stick".

In commercial MUAs, where speed is of the essence, a good parser will make life easier for players by accepting abbreviations ("k z w ls" - "kill the zombie with the longsword"), and by allowing players to define their own abbreviations (synonyms) and macros. Easy ways to repeat commands are also common (eg. "w.." to mean "go west twice"), as are pronouns (eg. "tickle him" instead of "tickle Aloysius").

These syntactic features can easily be incorporated into a client, rather than be part of the parser. However, clients can not help at the semantic level. Some commands imply things by their use which are not stated explicitly. The simplest example is the implied string ("say this is interesting" instead of "say 'this is interesting'"), but there are also implied objects ("open door" meaning "open the door using whatever key I'm holding that fits") and implied bindings ("drop weapon" meaning "drop the weapon I'm holding, not the one on the floor").

'Binding' is the process whereby a parser ties a noun to a set of specific objects, and it functions best when there is a classification hierarchy defining a partial order over all objects. For example, if a spoon is of type gold, and gold is of type metal, and metal is of type solid, then any of "drop spoon", "drop gold", "drop metal" or "drop solid" will drop the spoon, along with other objects of the class named. Most older MUAs do not have a classification hierarchy, but, with the advent of object-oriented programming, many newer ones do.

'Players'

The first metric to use when assessing players is their number. There's a minimum population for every MUA, below which the game is not sustainable and will die. This varies for each MUA, but if you play for extended periods and see few other players, the chances are that it needs an influx of newcomers to survive. Games that aren't intrinsically much fun to play need a larger user base than those that are, if they're to remain viable. Any game on a large network is likely to be popular if it has no challengers.

After number, the type of player is worth considering. MUAs which are played mainly by teenagers are more likely to be violent and acrimonious than those played mainly by adults in their thirties. Although it is true that certain scenarios will attract a given type of player and others will not, and that therefore the type of players are really only a reflection of the design of the game itself, this does not always follow: an expensive game will tend to be played only by people with sufficient disposable income, and would thereby effectively disqualify students from it. The gender of players is also a good indicator of how a game will be played: if there are more of one gender than another, eg. 10% female to 90% male, then gender tends to matter little; with a more even distribution, eg. 45% female to 65% male, games can rapidly become little more than dating agencies if improperly managed. In almost all cases, there are more males than females who play a MUA (that's in real life: the gender of the persona a player is controlling does not have to be the same as that of the player).

A further signal that a game might be less entertaining than it should be is the wiz/mortal ratio. If there are more players with game-altering powers at their disposal than there are without, playing as a mortal can be hell, with constant interference from above. It also devalues the overall goal if there are so many wizzes that it seems "anyone" can become one. Top-heavy games are hard to deal with, because once players have reached wiz level it is often impossible to remove them without causing even worse problems.

Finally, if you really want to know what a MUA is like, the players are the best way to find out. Just ask them. After a few minutes of conversation, you'll have learned more about the MUA than hours of playing would ever tell you.

'Role-playing'

The role-playing issue can be looked on as a distinction between 'hidden depth' and 'open depth'. A game with open depth (lots of fussy, detailed information made available to the players) looks more impressive on the face of it than one with hidden depth (players have to find out things for themselves). Although the former are exciting to newcomers, the latter are more rewarding in the long term.

'Wiz Powers'

There is less consistency in the naming of wiz commands than there is for normal commands. This is because people who write their own MUAs have not always reached wiz level in another MUA, and are thus unaware of existing conventions.

Having wide-ranging wiz powers is usually a good thing, although having too few can be a blessing in disguise for games with an over-large wiz/mortal ratio. Most MUAs strive to provide a comprehensive range of powers for their wizzes, although many of the most potent wiz-only command often require facilities which the implementation is unable to deliver. Among these are:

• 'snooping'
  Being able to copy someone else's textual i/o to your own machine, while continuing to play yourself. Multiple snoops are where several people can be watched simultaneously.
• 'attaching'
  Being able to control another player or mobile using normal commands, receiving incoming text from their point of view as if you were playing them yourself. A lesser ability is 'dubbing', where your speech appears to issue from the dubbed object, but otherwise your commands refer to your own persona.
• multiple levels of invisibility
  Not all games offer a means for players to disappear from the view of others, but some do. Of those, few permit selective invisibility, where one category of player (eg. mortals) cannot see you, yet another (eg. wizzes) can.
• object creation
  The ability to manufacture arbitrary objects, rooms, mobiles, whatever, and place them in the game. These additions may or may not be permanent. Some games allow anyone to perform such feats, notably in the academic sector.
• command definition
  Like object definition, but commands can be added. Very dangerous, in practice, because commands are, in effect, programs, and can thus crash, hang, hog the cpu, and perform arbitrary alterations to the game's data structures. Be wary of playing any new game offering this facility until you obtain cast-iron assurances that it's safe.
• 'proofing'
  The ability to display arbitrary messages on players' screens which they cannot distinguish from those the game itself would send. Sometimes called 'illusion'. Primitive proofs are commonly available, but multi-line proofs are uncommon, as are proofs which are sent selectively to either individual players, players in one location, or players satisfying some audio-visual requirement (eg. players who are in the dark should not receive messages telling them that a butterfly is fluttering by).
• 'FODding'
  The ability to delete a persona from the game, completely. Sometimes known as 'blotting' or 'toading'. "FOD" stands for "finger of death".
• 'teleporting'
  The ability to move to an arbitrary location. Can be extended to allow the movement of any object from one locale to another, although this can cause problems without the proper checks (objects that are allowed to contain themselves can readily cause crashes).
• 'pre/post-fixing'
  Being able to change the way in which players are described. Some games allow players to do this themselves, which can have depressing results...
• 'tinkering'
  Having the capacity to change anything in the game whatsoever, akin to poking a Basic program. Very dangerous, and if it's offered to more than a handful of trusted people it will speedily render a game unplayable.

As a postscript, the presence of some wiz commands can greatly influence the way a game is played and managed. In particular, if nowhere is safe from the snoop command (or any form of logging), this greatly discourages people from indulging in imaginative sexually-oriented talk, and thus makes such MUAs more acceptable to the parents of younger players and to moral guardians.

'Age'

New games, on the other hand, are likely to be unstable yet fresh, and can revitalise a user base that another MUA has saturated. New MUAs will often contain experimental features unavailable in most other games, but if they're the authors' first attempt at a MUA then they can still be fossilised, albeit in a more contemporary setting. Only MUAs that are complete rewrites of an earlier version are usually able to keep up with future developments, since by then the design team has acquired a degree of awareness of the generality needed to maintain and improve upon their MUA.

The ideal situation is where an old yet second-generation MUA is given access to either an untapped user base or one which existing MUAs have saturated.

'Gameplay'

Implicit in the way a game interprets players' commands is a set of "rules" that decree what the game will allow, and what activities are favoured. These should support the game scenario, and not get in the way. For example, a game with fifteen different character classes and complex procedures for training to acquire weapon and spell skills may go well with a "city-state" scenario where there exists a complex society and a legislature; however, it would get in the way of a "wandering knights battling dragons" scenario. Players should really be able to do what they want, and if the game prevents them then there should be a sound reason for it. New games announcing that players can be elves, dwarfs, trolls, bunny rabbits and so on have to be able to justify why these different types are present. Artificial constraints ("if you want to be a magic-user you can't be a troll") may give a veneer of attention to detail, but rarely does it ever make much difference.

One often-overlooked aspect of a MUA is its treatment of newcomers. It is not good for a novice to join a game, have no idea how to talk to people (and be unable to find out), and to wander around for half an hour and not see anything that could be picked up. Ideally, there should be some mechanism to ensure that even when a game is near to being played out of points-giving objects and puzzles, novices should still be able to find something. There should be on-line help, and it's desirable to have the game provide unsolicited hints if it is advanced enough to recognise when a player is having trouble. For commercial games, a guest account should be provided, and game walk-throughs (or, if undertaken interactively, 'tours') ought to be available. Rules and regulations should be kept to a minimum - a daunting 100-page booklet describing how to play the game may be intended to impress with its depth, but it's more likely to scare off new players in the long run.

Gameplay is immensely important, but only to people who play primarily for gaming reasons. Compare MUAs with board games: "real" boardgamers look at the rules, decide on strategies, try them out, and play to win; "occasional" boardgamers don't care much for game realism if that means lots of rules to learn, and they only indulge in games on social occasions, not really caring whether they win or lose. MUAs can be geared to be suitable for either serious or trivial users; the best MUAs can cater for both.

'Atmosphere'

It is difficult to determine whether a game truly has atmosphere without playing it for some time, however there are some things to watch out for which are certainly not conducive to it.

A good sign that a game will lack atmosphere is shoddy descriptions. Misspellings, poor punctuation, incorrect grammar, tortuous phrases that dismally fail to promote the feeling of brooding terror that its thesaurus-wielding author hoped they would - all these interrupt the flow of narrative and bring the player momentarily into the real world instead of that of the game. Other signals are improper articles ("a ox", "a water"), bad gender possessives ("Susan taps you with his bat") and numbered objects ("There is a rat22 here").

Subject matter plays a part. A wrecked pirate ship with a vacuum cleaner in the hold may be supposed to be funny, but it will jar on players' sensibilities. If players have the ability to add things to the game without their creations first being checked out for consistency by someone with editorial control, there is a very good chance that any overall sense of atmosphere or mystique will be completely non-existent.

Different games have different atmospheres at different times, and the same MUA may cycle between murderous hack-and-slay and jovial sweetness-and-light every six months. Something to beware of, though, is the MUA which radiates joy and kindness all the time: this is usually imposed on players in dictatorial fashion from above, in "you will be nice!" style. Since no-one can possibly get on with everyone else forever, a seething mass of hatred builds up, and when it bubbles over there are terrible recriminations.

Games can have their atmosphere disturbed by external factors, such as an uncertain future or a price rise, and almost every MUA has its prophets of doom who will tell anyone willing to listen that the game has gone downhill since the "fun" days of yesteryear, and it's only a matter of time before it keels over. Reviewers who are talking to players should be ready to hear this kind of morose rambling, and only give it credit if it is substantiated in talks with others.