Nel dicembre del 1990, Richard Bartle, autore con Roy Trubshaw del primo MUD della storia, invia a British Telecom un rapporto sui MUDs destinato a contribuire alle scelte commerciali dell’azienda. Contemporaneamente, manda in linea una versione ridotta del documento, da cui abbiamo tratto alcuni capitoli che ci sembrano ancora di grande interesse e attualità.

Nota: Nel suo rapporto, Bartle utilizza l’acronimo MUA (Multi-Users Adventures) ritenendolo meno ambiguo di MUD, che a suo avviso andrebbe utilizzato esclusivamente per il gioco da lui scritto nel 1979.

• Technical Aspects
• Operational Aspects
• Managerial Aspects
• Scenarios
  

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.

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:

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).

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:

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.