7105 lines
356 KiB
Plaintext
7105 lines
356 KiB
Plaintext
Interactive Multi-User Computer Games
|
||
|
||
Dr Richard Bartle,
|
||
MUSE Ltd.,
|
||
34, Grantham Road,
|
||
Great Horkesley, Colchester, Essex.
|
||
CO6 4TU, UK.
|
||
|
||
email: Richard%tharr.UUCP@ukc.ac.uk
|
||
|
||
Copyright (c) MUSE Ltd, British Telecom plc.
|
||
December, 1990.
|
||
|
||
|
||
Abstract:
|
||
|
||
This is a short research report covering the field of
|
||
interactive, multi-user computer games. Its main component is
|
||
a comprehensive overview of what presently constitute the most
|
||
important products in this category. The report ends in a
|
||
discussion of ways by which existing services may be improved
|
||
to the benefit of both the user and the vendor.
|
||
|
||
Author's note: this document grew from a longer report
|
||
commissioned by British Telecom plc. It is commercially
|
||
oriented, so was delayed for six months after delivery prior to
|
||
being made publicly available. Certain commercially sensitive
|
||
details have still had to be struck out, in particular a
|
||
comprehensive contact list of leading people in the field.
|
||
Furthermore, some of the information (particularly that
|
||
concerning game access) has been superseded since it was
|
||
written. I hope that what remains is nevertheless of some use.
|
||
|
||
|
||
Table of Contents
|
||
|
||
|
||
1. Introduction. 4
|
||
|
||
1.1 The Field of Study. 4
|
||
1.2 Narrowing the Field of Study. 4
|
||
1.3 Acceptance Criteria. 5
|
||
1.4 Categories of IMPCGs. 5
|
||
1.5 Brief History (Industry). 6
|
||
1.6 Brief History (Academia). 7
|
||
|
||
2. Game Architecture. 8
|
||
|
||
2.1 Technical Aspects. 8
|
||
2.2 Operational Aspects. 8
|
||
2.3 Managerial Aspects. 10
|
||
2.4 Scenarios. 11
|
||
2.5 Clients. 12
|
||
2.6 Bots. 12
|
||
2.7 Indicators. 13
|
||
Breadth 13
|
||
Depth 13
|
||
Size 14
|
||
Parser 15
|
||
Players 15
|
||
Role-playing 16
|
||
Wiz Powers 16
|
||
Age 18
|
||
Gameplay 18
|
||
Atmosphere 19
|
||
|
||
3. Reviewing Strategy. 20
|
||
|
||
3.1 Review Format. 20
|
||
3.2 Accuracy. 20
|
||
3.3 Locations. 20
|
||
3.4 Genealogy. 22
|
||
|
||
4. Reviews - UK. 24
|
||
|
||
4.1 Federation II. 24
|
||
4.2 Gods. 26
|
||
4.3 MirrorWorld. 29
|
||
4.4 MUD2. 32
|
||
4.5 Shades. 36
|
||
4.6 AberMUG. 41
|
||
4.7 Avalon. 41
|
||
4.8 Bloodstone. 44
|
||
4.9 Empyrion. 47
|
||
4.10 MIST. 48
|
||
4.11 Mosaic. 49
|
||
4.12 Prodigy. 51
|
||
4.13 Quest. 53
|
||
4.14 Realm. 54
|
||
4.15 Trash. 55
|
||
4.16 Void. 57
|
||
4.17 Zone. 59
|
||
4.18 Chaos World of Wizards. 62
|
||
4.19 Rock. 64
|
||
4.20 Sector 7. 64
|
||
4.21 Other MUAs. 65
|
||
|
||
Table of Contents (continued)
|
||
|
||
|
||
5. Reviews - Rest of the World. 71
|
||
|
||
5.1 British Legends. 71
|
||
5.2 Gemstone III. 72
|
||
5.3 Other Commercial MUAs. 73
|
||
5.4 AberMUD. 75
|
||
5.5 LPMUD. 77
|
||
5.6 TinyMUD. 79
|
||
5.7 TinyMUCK. 83
|
||
5.8 TinyMUSH. 84
|
||
5.9 TinyMOO. 85
|
||
5.10 UberMUD. 86
|
||
5.11 Other InterNet MUAs. 87
|
||
|
||
6. Reviews - Non-MUAs. 92
|
||
|
||
6.1 Fantasy Sports. 94
|
||
6.2 Island of Kesmai. 94
|
||
6.3 Sniper! 98
|
||
6.4 The Spy. 99
|
||
|
||
7. Discussion. 101
|
||
|
||
7.1 Organisation. 101
|
||
7.2 Why Do People Play? 101
|
||
7.3 Why Do People Not Play? 107
|
||
7.4 Why Do People Stop Playing? 109
|
||
7.5 What Does the Future Hold? 112
|
||
7.6 Conclusion. 114
|
||
|
||
1. Introduction.
|
||
|
||
1.1 The Field of Study.
|
||
|
||
"Interactive, multi-user computer games": despite containing three
|
||
adjectives, the phrase is wide-ranging in its coverage. The first task in
|
||
reviewing the area must therefore be to formulate a set of criteria that can be
|
||
used to determine whether a system should, or should not, be the object of
|
||
study.
|
||
|
||
The term 'games' refers to those pastimes which are undertaken
|
||
primarily for the purpose of entertaining the user (or, in this context,
|
||
player). Although games can be designed for business or educational use,
|
||
rather than solely for leisure-time activity, nevertheless to qualify they must
|
||
somehow be "fun". They also need a set of rules, and, if competitive, some
|
||
means of gauging how close the player is to "winning" (ie. meeting a
|
||
predefined overall objective). Additionally, most require some skill on the
|
||
part of the players. In cases where modelling the real world is a significant
|
||
aspect of a game, it may be referred to as a 'simulation' (although not all
|
||
simulations are games).
|
||
|
||
'Computer games' are games which are played against, moderated by, or
|
||
played using, a computer. In rare cases, they can be played between computers.
|
||
|
||
'Multi-player computer' games are computer-run games that several
|
||
individuals can play simultaneously.
|
||
|
||
'Interactive, multi-player computer games' are those computer-run games
|
||
where the individual players can issue commands which affect the way the game
|
||
treats other players.
|
||
|
||
This specific-seeming definition nevertheless admits such activities as
|
||
two friends playing a pinball down at the local pub. It's a game, there's a
|
||
computer inside it controlling everything, it'll entertain up to four players
|
||
taking turns, and one player's score affects the extent to which the other
|
||
players will take risks (and, hence, is a means of interaction). Nevertheless,
|
||
a pinball is not what is generally regarded as an interactive, multi-player
|
||
computer game; indeed, if it were, then the range of other games that also fit
|
||
the definition would reduce any overall analysis to a level of vague
|
||
generalities.
|
||
|
||
1.2 Narrowing the Field of Study.
|
||
|
||
It is necessary to discard from consideration those games which lie
|
||
outside the spirit of the definition. 'Computer games' in this context are
|
||
those games which run solely on general-purpose computers. This excludes
|
||
machines hard-wired to play one game (chess, space invaders, pinball), but
|
||
still includes certain categories of games machine (Sega, Nintendo, modern
|
||
video games).
|
||
|
||
If a game is to be 'multi-player', there are three alternatives:
|
||
several people playing on the same machine in the same room; several people
|
||
playing over a LAN; several people playing over a public network. In practice,
|
||
only the latter is worth considering: games in the first category tend to be
|
||
commercial flops unless the multi-player facility is merely a gimmicky
|
||
extension to an essentially single-player game; games in the second category
|
||
rarely sell, because most LANs are company-owned and are unavailable for
|
||
leisure activities (although within the next few years they may be introduced
|
||
into amusement arcades).
|
||
|
||
Thus, 'multi-player computer games' can be reduced to those which
|
||
individuals contact over some public network, eg. that of the telephone.
|
||
However, this further constrains the architecture of such games, in that unless
|
||
users all have similar, tamper-proof machines, the bulk of processing must be
|
||
centralised within a single computer (or a cluster). Otherwise, system security
|
||
would be compromised. Although some processing can be done locally (graphics,
|
||
sound effects, parsing etc.), nothing multi-user can be trusted to a user's
|
||
home machine. Even in situations where all players are known to have identical
|
||
hardware and software (as is the case with games consoles), unless one machine
|
||
is in overall control there is a dangerous susceptibility to the sudden system
|
||
failure of a component machine. Distributed games are not, for the moment at
|
||
least, viable.
|
||
|
||
A special case is that of two-player games. With players who can trust
|
||
one another not to cheat, modem-to-modem games can be played in distributed
|
||
fashion. If finding a player is difficult, contact agencies can pair people up
|
||
(CompuServe in the USA, for example, has a "Challenge Forum" for people wishing
|
||
to find opponents for tandem games such as Falcon, Flight Simulator 3, Modem
|
||
Wars, 'Vette and Omega). In this instance, the host machine is merely acting as
|
||
a bulletin board or matchmaker. However, there do exist two-player games where
|
||
major processing is done on the contact machine itself.
|
||
|
||
This leaves us with a set of games where the players have computers
|
||
which they use as front-ends to access a (usually larger) computer, upon which
|
||
the games themselves run. There are some games of the FIST variety where the
|
||
user can dial telephone numbers to issue commands, but no such games have
|
||
anything that is not subsumed by some aspect of play-by-modem games; not even
|
||
the emerging voice-activated telephone games are much of an advance.
|
||
|
||
Finally, what is meant by the term 'interactive' when applied to
|
||
multi-player computer games? Actually, the word is ambiguous: it can mean
|
||
"allowing players to act upon one another", but also merely "on-line" (in a
|
||
computer sense). Both these meanings are, to some extent, already implied.
|
||
Although being multi-player indicates that there is some degree of awareness of
|
||
other individuals playing at the same time (if you can't tell by playing that
|
||
it's multi-player, it may as well not be), 'interactive' emphasises the
|
||
requirement that players be able to do things with and to each other. This is
|
||
exemplified by the ability to communicate freely. Limited forms of
|
||
communication using standard protocols are possible in certain games (eg.
|
||
bridge), but in general the players have to be able to send messages to one
|
||
another in free-form natural language if they are to communicate effectively.
|
||
|
||
Inter-player communication not the end of it, however, because an
|
||
ordinary chatline program can perform such a function; a chatline, though, is
|
||
not a game. There may be conventions observed by participants, but there are
|
||
no formal rules of play, and there is no way to "win" - or even advance in
|
||
status - on a chatline. To be an interactive, multi-player game,
|
||
communication between players is necessary, but not sufficient; players need to
|
||
be able to do things to one another that, within the framework of the game,
|
||
will have a tangible effect.
|
||
|
||
1.3 Acceptance Criteria.
|
||
|
||
To summarise, then, for the purposes of the remainder of this report,
|
||
an interactive, multi-player computer game (IMPCG) is something which satisfies
|
||
the following criteria:
|
||
|
||
- It is played by people primarily for fun.
|
||
- It has a set of rules, and an overall game-dependent objective.
|
||
- You need a general-purpose computer to play it.
|
||
- It runs primarily on a central computer, connected to the players'
|
||
computers over a public network.
|
||
- More than one person can play it simultaneously.
|
||
- Players can communicate with one another in real time, using a natural
|
||
language (eg. English).
|
||
- Players can issue commands independently which may affect the status
|
||
of other players within the game.
|
||
|
||
1.4 Categories of IMPCGs.
|
||
|
||
Existing interactive, multi-player computer games satisfying the above
|
||
criteria are, in the main, programs sharing a common heritage known variously
|
||
as MUGs (Multi-User Games), MUDs (Multi-User Dungeons, Multi-User Dimensions)
|
||
and MUAs (Multi-User Adventures). Although the terms are often used
|
||
interchangeably, there are technical distinctions:
|
||
|
||
MUG - Used mainly by journalists and people who don't know any better.
|
||
A UK-only term. Vague - soccer is a "multi-user game" - but
|
||
employed in the present context the term refers to any on-line
|
||
computer game, whether interactive or not. Scrabble by modem is
|
||
a MUG (and, on Minitel, a very popular one).
|
||
|
||
MUD - Ambiguous in that it can refer not only to a class of
|
||
interactive, multi-player computer games, but also to a
|
||
particular game (the first one of this genre). In the UK,
|
||
normally the specific form is used, but elsewhere 'MUDs' is
|
||
generic.
|
||
|
||
MUA - Perhaps the most accurate description. Multi-user adventures
|
||
are, simply, adventure games for more than one player. Adventure
|
||
is a term already used to refer to a popular form of
|
||
single-player computer game, such as those produced by Infocom,
|
||
Level 9 and Magnetic Scrolls. The very first adventure game (now
|
||
called Colossal Cave) was originally entitled Adventure. MUA is
|
||
used by purists, but rarely appears in non-technical magazine
|
||
articles due to its being hard to incorporate into witty
|
||
headlines.
|
||
|
||
However, for the remainder of this report the acronym MUA will be used
|
||
to refer to this kind of IMPCG. This is because MUG is too general (and unused
|
||
outside the UK), and MUD is ambiguous.
|
||
|
||
MUAs are not the only IMPCGs, just the dominant form. There are other
|
||
games which satisfy our adopted criteria, but they are one-off individuals, not
|
||
classes of games. Examples are Island of Kesmai, You guessed it! and Sniper on
|
||
CompuServe. All are characterised by communication and interaction, and they
|
||
do not play the same as MUAs. They can, however, each be seen as a specialised
|
||
form of MUA, and could, for example, readily be programmed in the better MUA
|
||
definition languages.
|
||
|
||
This report will therefore concentrate on MUAs as best exemplifying
|
||
IMPCGs, while making reference to other games that also qualify when
|
||
appropriate.
|
||
|
||
1.5 Brief History (Industry).
|
||
|
||
Present day MUAs are all descendents of a single game known as MUD
|
||
(Multi-User Dungeon; to avoid confusion with the generic term, the game will be
|
||
referred to as MUD1 for the remainder of this report). Although there were
|
||
early attempts to turn single-player adventures such as Colossal Cave and Zork
|
||
into multi-player adventures, and there may have been attempts to write MUAs
|
||
from scratch, these came to nothing or petered out. MUD1 was the first proper,
|
||
workable multi-user adventure game.
|
||
|
||
MUD1 was written by Roy Trubshaw and Richard Bartle at Essex University
|
||
on a DECsystem-10 mainframe. Trubshaw began in Autumn 1979, and Bartle took
|
||
over in Summer 1980. Initially, the game was playable only by students at the
|
||
university and guests using (what was then) EPSS. After a year or so, however,
|
||
external players began to direct-dial from home using modems, and the game's
|
||
popularity grew.
|
||
|
||
Many of MUD1's players found it difficult to get a slot in the game,
|
||
since the number of dial-up ports on the university machine was limited, and
|
||
because the game was only available late at night when there was spare
|
||
processing capacity. Some of these players wrote their own MUAs, based on MUD1
|
||
and using similar commands. Among these were AMP, Gods and Shades.
|
||
|
||
After a flurry of articles in computer hobby magazines around 1984,
|
||
MUD1's fame spread even wider. Bartle and Trubshaw formed MUSE Ltd to rewrite
|
||
the game as MUD2, and run it on VAXes owned by a division of BT then known as
|
||
NIS (Network Information Services). Due to an internal dispute between NIS and
|
||
Prestel, Prestel declined to take MUD2 as "their" MUA, and chose the lookalike
|
||
game Shades instead. MUD1 was, for two years, available on the CompuNet network
|
||
in the UK, but it was removed when CompuNet discarded their DECsystem-10s. A
|
||
version of MUD1 still runs on CompuServe in the USA, and, despite its venerable
|
||
age, continues to be one of their most profitable leisure products.
|
||
|
||
After a time, people who had played games based on MUD1 wrote their own
|
||
MUAs, and the process snowballed. Nowadays, there are some twenty or more MUAs
|
||
in the UK of varying degrees of sophistication, six of which (MUD2, Shades,
|
||
Gods/The Zone, Federation II, AberMUG and Bloodstone) are run on a commercial
|
||
basis. The UK leads the world in this technology, despite the constraints of
|
||
high communications charges (even using PSS, it costs over 5 times more per
|
||
hour to call MUD2 than the game itself charges for playing).
|
||
|
||
This, then, is the state of the "industry" in the UK. However, there
|
||
are two almost disjoint streams to the development of MUAs, the other one being
|
||
based in academia.
|
||
|
||
1.6 Brief History (Academia).
|
||
|
||
With the publicity of the mid-1980's and the advent of JANet (Joint
|
||
Academic Network - free inter-university networking), students at other
|
||
universities continued to play MUD1 at Essex (along with other games written
|
||
using the same shell, MIST being the main one). These students also wrote
|
||
their own MUD1-like games. The first, AberMUD, was programmed at Aberystwyth,
|
||
and made available to other sites over JANet and InterNet. This in turned
|
||
spawned other MUAs based on it (TinyMUD, LPMUD), which were distributed freely
|
||
to (mainly Unix) sites around the network. There are now some fifty sites
|
||
running versions of these games, and the sources are available free to anyone
|
||
who wants them. There is a thriving NewsNet section dedicated to these games
|
||
(which are called "MUDs" by everyone), and new sites are coming on stream all
|
||
the time. They're mainly in the USA, but can be found in many other countries
|
||
as well. Only one game is run commercially, an incarnation of AberMUD called
|
||
AberMUG, which was mentioned earlier; a version of TinyMUD has appeared
|
||
alongside Gods, but as a test and without any publicity.
|
||
|
||
It can thus be seen that at present there are two almost completely
|
||
disjoint MUA camps. Few people in one group are aware of people in the other.
|
||
At present, the best games are the top-notch UK professional MUAs, but with the
|
||
huge number of US academics presently engaged in MUA activity, it is only a
|
||
matter of time before players over there start writing their own versions and
|
||
marketing them commercially. Unless the UK can maintain the lead that history
|
||
has given it, these American MUAs will doubtless come to dominate the scene
|
||
over the coming years.
|
||
|
||
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'
|
||
|
||
The breadth of a MUA is the extent to which it is able to deal with
|
||
things the players want to do. If a game has trees and an axe, then it is
|
||
reasonable to assume that players will attempt to fell the trees. Likewise, if
|
||
it has water then players will try to swim, and if it has a spade they will try
|
||
to dig. They will also try to write, sing, throw, sleep, and perform similar
|
||
"reasonable" actions. The more commands a game is able to cope with, the
|
||
greater its breadth. Giving a stock "I don't understand that" or "You can't do
|
||
that" response shows a lack of robustness. Games with the greatest breadth
|
||
cover eventualities most players would never consider, such as trying to open a
|
||
door with a skeleton, trying to read a "guardian" mobile as if it were a
|
||
newspaper, or hitting a sack and expecting to fall asleep.
|
||
|
||
'Depth'
|
||
|
||
Depth expresses a sense of the level of detail to which a MUA descends;
|
||
it is sometimes called 'sophistication'. It is a dependent upon the physics of
|
||
the world which the MUA manages. Games with good depth generally treat objects
|
||
in a way which approximates the real world. Games with bad depth will omit
|
||
certain concepts, or misimplement them. Dropping a glass object on a hard
|
||
surface "should" break it (unless there's a game-related reason why not, eg.
|
||
it's magic); dropping it on a soft surface "shouldn't" break it. Placing a
|
||
small box inside a sack "should" be allowed; placing it inside a sack which the
|
||
box itself contains "shouldn't" be allowed.
|
||
|
||
'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'
|
||
|
||
The size of a MUA is easy to gauge in terms of raw data: it is the
|
||
number of rooms (or locations) that the MUA contains. This can be deceptive: a
|
||
MUA consisting of a 100 by 100 grid can claim to have 10,000 rooms, however if
|
||
it did then it would need a a large number of players to populate it - even 50
|
||
players wouldn't meet each other often enough to promote the interaction that
|
||
makes MUAs such fun to play. In reality, point-based MUAs actually have an
|
||
interaction radius that makes "nearby" players able to see and hear one
|
||
another. On a 100 by 100 grid, an interaction radius of 5 would bring the
|
||
effective number of rooms down from 10,000 to around 400.
|
||
|
||
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'
|
||
|
||
The format of commands acceptable to a MUA is important, as it is the
|
||
only means by which players can describe what they wish to do in the game. The
|
||
part of the MUA which converts input into a form that the game can execute is
|
||
the parser. The absolute minimum requirement is that <verb>, <verb> <object>
|
||
and <verb> <object> <preposition> <instrument> are catered for.
|
||
|
||
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'
|
||
|
||
A powerful reason for playing a MUA is the quality and quantity of the
|
||
other players. Indeed, for some MUAs that's the only reason to play them - the
|
||
games are otherwise void of redeeming features.
|
||
|
||
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'
|
||
|
||
Many MUAs make a big thing out of being role-playing games. Strictly
|
||
speaking, such a game is one where players choose a personality other than
|
||
their own, and try to behave in character all the time. Theoretically, then
|
||
the more freedom players have to define their personae, the better suited a
|
||
game is for role-play. However, in practice the term is often used to refer to
|
||
games where there are strictures on what a player may or may not do - enforced
|
||
role-play. Thus, games with character classes, alignments, skill levels and so
|
||
on are usually understood to be role-playing in nature. In MUAs where there is
|
||
freedom to act however one chooses, "I was only role-playing" is more often
|
||
heard as an excuse to justify antisocial behaviour that the player regrets, eg.
|
||
viciously attacking someone else.
|
||
|
||
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'
|
||
|
||
Wiz powers are those command which (normally only privileged) players
|
||
are able to use on other players, and against which there is no defence. Such
|
||
powers are important for two reasons: the desirability of earning the right to
|
||
wield them is an important early driving force for mortals; they allow wizzes
|
||
to mould the game to their own personality, enriching it and helping it to
|
||
evolve.
|
||
|
||
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'
|
||
|
||
The length of time a MUA has been around can reveal a great deal about
|
||
it. First, it obviously works, and is likely to be relatively free of bugs. It
|
||
is therefore stable. However, unless it is frequently updated with new features
|
||
and puzzles, it also runs the risk of being stale. Furthermore, if it has a
|
||
comparatively fixed-size user base then it can saturate the market, ie.
|
||
everyone who is going to try it has now done so. Old games also tend to be
|
||
unable to cope with the latest advances in MUA technology, and become
|
||
fossilised.
|
||
|
||
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'
|
||
|
||
A defining characteristic for a MUA is its gameplay. What's the overall
|
||
goal, and how do you reach it? Is there a hierarchy of player levels? Do
|
||
personae gain powers as they advance? Is there fighting - and what happens to
|
||
losers? Do the environment and command set promote socialising, combat,
|
||
puzzle-solving or puzzle-designing?
|
||
|
||
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'
|
||
|
||
Finally, in judging a MUA there is the crucially important but
|
||
frustratingly intangible quality of atmosphere. The scenario, the room and
|
||
object descriptions, the events that occur, the things the players say, all add
|
||
up to a background feeling that dictates the mood of the game.
|
||
|
||
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.
|
||
|
||
3. Reviewing Strategy.
|
||
|
||
3.1 Review Format.
|
||
|
||
The meat of this report is a series of reviews of MUAs currently active
|
||
in the UK. Each review commences with a header giving facts concerning the
|
||
game under consideration - its name, its authors, its commercial status, and
|
||
how to access it.
|
||
|
||
Following the header are historical notes, presenting background
|
||
information on the game, and a brief description of its setting. After that
|
||
comes the main body of the review, where the game is discussed in some detail.
|
||
|
||
Although the reviews have been written as objectively as is reasonably
|
||
possible, naturally some subjectivity will inevitably creep in. To counteract
|
||
this eventuality, brief quotes from reviews in magazines and from players will
|
||
also be given (if available). All the quotes are unsolicited.
|
||
|
||
In order that some impression may be given of the overall importance of
|
||
the game in the IMPCG industry, the review header also includes a grading which
|
||
is purely subjective. Games will be rated as being in either the first,
|
||
second, or third rank; first rank is most important. This grading is based on
|
||
an assessment of the impact which the game has had on the MUA-playing
|
||
community. It therefore does not follow that the "best" games are necessarily
|
||
of a higher rank than lesser ones.
|
||
|
||
After the reviews of UK games, there follow reviews of MUAs from the
|
||
rest of the world. The same approach is taken for these as for UK games. A
|
||
handful are commercial, and these appear first; the rest are on academic
|
||
machines, and for these no pricing structure is given (they are all free).
|
||
Their importance is relative to other games in the same category.
|
||
|
||
3.2 Accuracy.
|
||
|
||
Although every attempt has been made to be accurate in the reviews,
|
||
they are not guaranteed correct. This is because information supplied by the
|
||
game designers is often out-of-date, over-optimistic, or contains outright
|
||
lies. Likewise, many semi-professional reviewers in magazines have little or
|
||
no idea what they should be (or, indeed, are) looking for, and will give
|
||
anything good or bland reviews so as to elicit future advertising revenue from
|
||
the flattered game author.
|
||
|
||
Since some of the information stated in the reviews in this report come
|
||
from such sources, it is possible that they contain errors. Where possible,
|
||
however, facts have been verified independently. Opinions expressed in the
|
||
review, however, while primarily the review author's, are grounded in either
|
||
personal experience or statements made by a number of players or reviewers.
|
||
|
||
Some of the later quotes that are given in this report are solicited,
|
||
but as the result of general questions (eg. "How do you think MUAs should be
|
||
made more widely available") rather than specific ones ("What do you think
|
||
about Shades' lack of containers?). Most quotes, however, are from public
|
||
access sources that anyone can read, such as bulletin boards, NewsNet, magazine
|
||
articles and publicity material. They therefore appear here without the
|
||
permission - or indeed the knowledge - of their originator, who may regard them
|
||
as too out of context to reflect their intended meaning.
|
||
|
||
3.3 Locations.
|
||
|
||
Included in each review is an indication of how the game can be
|
||
accessed. Some games run on the same system as others, and their location is
|
||
indicated by specifying the name of the appropriate system. Most games operate
|
||
at 1200/75 baud, 8 bits, 1 stop bit, no parity, but a good many can handle
|
||
other baud rates too.
|
||
|
||
For some of the academic MUAs there are many copies of the games
|
||
sprinkled across the networks. All these have their own local name to
|
||
distinguish them from other systems running the same software. The reviews of
|
||
these games concern the general software, however local versions are listed
|
||
along with the address at which they can be reached. As a guide to the
|
||
countries in which these lie, consult the last section of the address:
|
||
.au Australia
|
||
.ca Canada
|
||
.dk Denmark
|
||
.fi Finland
|
||
.nl Netherlands
|
||
.se Sweden
|
||
.uk United Kingdom
|
||
Anything else is assumed to be America (the .edu selector means "educational
|
||
establishment").
|
||
|
||
Systems supporting more than one MUA are:
|
||
|
||
Name: CompuNet
|
||
Phone: Pre-game registration required, call (081) 997 2591 voice
|
||
MUAs: Federation II, Realm
|
||
Comment:
|
||
Long-running but troubled network, originally backed by Commodore and
|
||
carrying MUD1. After staff buy-outs, its future now seems more secure. Still
|
||
caters primarily for users with Commodore hardware. Users pay to play.
|
||
|
||
Name: CompuServe
|
||
Phone: Pre-game registration required, call (0800) 289378
|
||
MUAs: British Legends, Island of Kesmai, Sniper, Megawars 1,
|
||
Megawars 3, You Guessed It!
|
||
Comment:
|
||
Largest user base of any commercial network in the world (around
|
||
1,000,000 users). Very expensive by UK standards. Recently began a UK
|
||
publicity drive.
|
||
|
||
Name: Essex University
|
||
Phone: PSS A2206411411
|
||
MUAs: MIST, Rock.
|
||
Comment:
|
||
Site of the original MUD1 game and many other MUAs using MUD1's
|
||
interpreter (Valley, Crud, Blud, Uni). About to lose all its MUAs because the
|
||
hardware upon which they run will shortly be scrapped.
|
||
|
||
Name: InterNet
|
||
Phone: Not available
|
||
MUAs: TinyMUD, AberMUD, LPMUD, UberMUD, TinyMUCK, TinyMOO, many more.
|
||
Comment:
|
||
An international network of (mainly Unix) computers primarily used by
|
||
research institutions (Universities and large companies) for electronic mail.
|
||
It carries daily updates of public messages on a wide range of topics,
|
||
rec.games.mud being the one of main interest to MUA players. Free to users.
|
||
|
||
Name: IO World of Adventure (IOWA)
|
||
Phone: (0883) 744044 and 744164.
|
||
MUAs: MirrorWorld, Parody, Quest, Empyrion, Chaos World of Wizards.
|
||
Comment:
|
||
Made an attempt this year to run commercially, but its players deserted
|
||
it and it had to back down. Free at present, and a popular place to meet and
|
||
chat. A local call from London.
|
||
|
||
Name: JANet
|
||
Phone: Not available
|
||
MUAs: AberMUD, TinyMUD, MIST.
|
||
Comment:
|
||
The main UK network for research institutions. Linked to InterNet.
|
||
Free to users.
|
||
|
||
Name: Lap of the Gods
|
||
Phone: (081) 994 9199
|
||
MUAs: Gods, The Zone, Future Life, TinyMUD.
|
||
Comment:
|
||
Long-standing system, has its own particular clientele. Users pay to
|
||
play.
|
||
|
||
Name: Prestel
|
||
Phone: Consult BT for your local number
|
||
MUAs: Shades, Trash.
|
||
Comment:
|
||
Large user base, and prices to match. A local phone call from almost
|
||
anywhere in the UK. Shades and Trash can be played for free on a development
|
||
machine at (0342) 810905, but be prepared for sudden surprises, eg. text in
|
||
french.
|
||
|
||
Name: Synergy
|
||
Phone: (081) 968 0333
|
||
MUAs: Avalon, The Spy.
|
||
Comment:
|
||
New system, having started this year. Small user base at present. Users
|
||
pay to play.
|
||
|
||
3.4 Genealogy.
|
||
|
||
This diagram shows the family tree of MUAs (where parenthood is known).
|
||
Children are listed alphabetically rather than in order of appearance, because
|
||
time of birth is difficult to establish for most of the games.
|
||
|
||
MUD1
|
||
|
|
||
+-------AMP
|
||
|
|
||
+-------Federation II
|
||
|
|
||
+-------Gods
|
||
| |
|
||
| +-------Future Life
|
||
|
|
||
+-------MirrorWorld
|
||
| |
|
||
| +-------Empyrion
|
||
| |
|
||
| +-------Mosaic
|
||
| | |
|
||
| | +-------Avalon
|
||
| |
|
||
| +-------Parody
|
||
| | |
|
||
| | +-------Prodigy
|
||
| |
|
||
| +-------Quest
|
||
|
|
||
+-------MIST
|
||
| |
|
||
| +-------AberMUD
|
||
| |
|
||
| +-------LPMUD
|
||
| | |
|
||
| | +-------DUM II
|
||
| |
|
||
| +-------TinyMUD
|
||
| | +-------Cthulhu
|
||
| | |
|
||
| | +-------Midgaard
|
||
| | |
|
||
| | +-------SMUG
|
||
| | |
|
||
| | +-------TinyMUCK
|
||
| | | |
|
||
| | | +-------TinyMOO
|
||
| | |
|
||
| | +-------TinyMUSH
|
||
| | |
|
||
| | +-------UberMUD
|
||
| |
|
||
| +-------YAMA
|
||
+-------MUD2
|
||
|
|
||
+-------Rock
|
||
|
|
||
+-------Shades
|
||
| |
|
||
| +-------Bloodstone
|
||
| |
|
||
| +-------Sector 7
|
||
| |
|
||
| +-------Trash
|
||
| |
|
||
| +-------Zone
|
||
| |
|
||
| +-------Void
|
||
|
|
||
+-------VaxMUD
|
||
|
|
||
+-------Wanderland
|
||
|
||
4. Reviews - UK.
|
||
|
||
4.1 Federation II.
|
||
|
||
Name: Federation II
|
||
Importance: 1
|
||
Author(s): Alan Lenton ("Bella")
|
||
Location: CompuNet
|
||
Pricing Structure: L1.50/hour plus
|
||
L12 flat quarterly fee
|
||
|
||
Brief Description:
|
||
SF, interplanetary trading/exploration game.
|
||
|
||
Historical Notes:
|
||
The Multi-User Galaxy Game project was begun in 1985 by CompuNet as a
|
||
SF alternative to MUD1, which then ran on the system. When the other
|
||
programmer left CompuNet, Lenton rewrote the game from scratch as Federation
|
||
II. It was officially launched on CompuNet in 1989; reported also to run on
|
||
MicroLink, and on any other commercial system willing to take it.
|
||
|
||
Review:
|
||
Federation II (known as Fed to its players) is a departure from the
|
||
conventional form of MUA. Rather than being based around the accumulation of
|
||
context-independent points, it is instead concerned with money (game-money -
|
||
'Imperial Groats' - rather than real money), which, unusually, can be given
|
||
away to other players. The game-play is dominated by economics rather than by
|
||
fighting skills or puzzle-solving abilities (there are no puzzles in Federation
|
||
II).
|
||
|
||
Federation II's setting, the solar system of the future, is wide in
|
||
scope but lacking in descriptive atmosphere. Referred to as 'dataspace' by its
|
||
author, it consists of the Earth plus six other planets/moons. Despite this,
|
||
the actual number of rooms it contains is not large, and movement in space is
|
||
with standard compass points rather than being directionally based on
|
||
pitch/yaw/roll. Most surprisingly (except from a programmer's point of view),
|
||
the planets are stationary.
|
||
|
||
There are 17 player levels, although most experienced players stop at
|
||
level 9. As well as pure monetary qualifications, other conditions need to be
|
||
satisfied in order to reach the next level. These are intended to ensure that
|
||
players don't try to run before they can walk, and include such things as
|
||
having undertaken a certain number of trading contracts, and owning a warehouse
|
||
('whorehouse' in game parlance) on every planet.
|
||
|
||
There are no wizzes in Federation II. Game management problems are
|
||
dealt with by the six richest players in the game, which ordinarily would lead
|
||
to even worse management problems; however, the real power is wielded by the
|
||
game's author, Alan Lenton, who used to be a MUD1 arch-wizard and is one of the
|
||
most experienced MUA managers around. Consequently, Federation II runs
|
||
smoothly.
|
||
|
||
The game is insensitive in some respects - it promotes the consumption
|
||
of alcohol by having its social focus at a bar named "Chez Diesel" on Mars, and
|
||
quaffing drinks will increase players' stamina; this might offend some people.
|
||
On the whole, though, there is little of the overt use of non-violent contact
|
||
commands ("kiss", "hug" etc.) seen on some other games. This is partly because
|
||
of Lenton's managerial skills, and partly because Federation II attracts a
|
||
higher proportion of female players than any other UK MUA.
|
||
|
||
Federation II lacks both depth and breadth - it has only 96 distinct
|
||
commands. The overall aim of the game (reaching level 17) is virtually
|
||
unattainable, so it is treated mainly as a social forum rather than as a "real"
|
||
game. There is little interaction required by the game mechanics, and fights
|
||
are infrequent (but see later concerning insularity). The 33 objects in the
|
||
game are exclusively for giving to one of the 51 mobiles in exchange for
|
||
points, or consuming so as to increase one's stamina. They are not used for
|
||
solving puzzles.
|
||
|
||
Beginners choose their name and gender, then distribute 140 units
|
||
between strength, stamina, dexterity and intelligence attributes. Intelligence
|
||
as an attribute is unusual in MUAs - most games assume the intelligence of the
|
||
persona equates with that of the player commanding it. In Federation II
|
||
intelligence determines the power of the ship-board computer a persona can use.
|
||
|
||
Players proceed by buying spaceships (usually with a loan), equipping
|
||
them (hull size, armour, shielding, drives, weapons, tractor beams, computers,
|
||
power plants), then purchasing commodities (24 are technical/industrial, 16 are
|
||
agricultural, 10 are leisure) from one planet and moving them to another where
|
||
they're needed (there are periodic announcements of contracts that are to be
|
||
undertaken). Players competing for the same contract race to get there first.
|
||
Completing contracts gives players money, which they use to improve their
|
||
ships, start their own companies, build factories and buy warehouses.
|
||
|
||
Federation II has two novelties not present in other MUAs. One is a
|
||
bounty system, where players can place reward money on their enemies in order
|
||
to induce someone to attack them; the other is an insurance system, whereby
|
||
players pay a certain premium and in the event of their untimely death they are
|
||
resurrected at their previous level. These two features tend to work against
|
||
each other, and the insurance facility in particular means that players rarely
|
||
lose their status once it is gained.
|
||
|
||
Players have the ability to describe themselves ("buy clothes");
|
||
ordinarily, this would be perilous to any coherence of descriptive power in the
|
||
game, but since Federation II is deficient in that area anyway it doesn't
|
||
really make much difference. Atmosphere, as perceived by the players (not as
|
||
found on planets' surfaces), is engendered entirely by those players.
|
||
Regrettably, the highest-level players form a clique that is very choosy about
|
||
who can join, and they can make life very unpleasant for any upstarts they
|
||
dislike. This makes the game very insular, a charge repeated many times by
|
||
ex-players and professional reviewers.
|
||
|
||
When combat does take place it is non-automatic, and there are many
|
||
weapon-control commands. Experienced players will invariably win, except
|
||
against hordes of novices (in which case they will later kill them
|
||
individually, having themselves been resurrected on an insurance policy).
|
||
Players are only allowed one persona per account ID, but can have several
|
||
account IDs.
|
||
|
||
Federation II does not have resets, and there is no automatic save to
|
||
disc of players' scores. Thus, if the game crashes then points gained after a
|
||
player's last explicit "save" command are lost.
|
||
|
||
Federation II is written entirely in C, is compiled directly (rather
|
||
than working from a definition language), and it therefore runs very quickly
|
||
but could never be used to implement any other scenario. Why is it of the first
|
||
rank? It takes a courageous new approach to the standard MUD1 style of
|
||
fantasy-based, combat-oriented, puzzle-solving world - it can run alongside
|
||
such a MUA without poaching any players; it is portable, and available on
|
||
several networks; it has a publicity director (Clement Chambers) and will thus
|
||
continue to be in the news; it is continually being updated and improved
|
||
(Lenton works on it full time); its author is one of the most experienced in
|
||
the field.
|
||
|
||
Summary:
|
||
Federation II is a game with a pedigree, but of modest size, poor
|
||
breadth, shallow depth and little atmosphere. Nevertheless, its players are
|
||
enthusiastic, its support team dedicated, and its future rosy.
|
||
|
||
Quotes:
|
||
|
||
"Federation II is a wonderful blend of space-trading game and
|
||
adventure."
|
||
Popular Computing Weekly [magazine]
|
||
|
||
"It sets you free from reality."
|
||
Trancer [player]
|
||
|
||
"Reality is boring."
|
||
Topcat [player]
|
||
|
||
"We all want an alter-ego, and Fed releases it."
|
||
Penelope [player]
|
||
|
||
"I found the other players very helpful and quite willing to give
|
||
vital information to help me on my way."
|
||
Popular Computing [magazine]
|
||
|
||
"It boasts quite the best manual of any game I've seen."
|
||
Popular Computing Weekly [magazine]
|
||
|
||
"Britain's most advanced multi-user game"
|
||
CompuNet [promotional material]
|
||
|
||
"I feel proud an honoured to offer people this game. It's like
|
||
partying without risk to the body. I'm giving them value for
|
||
money, so they come back for more."
|
||
Clement Chambers [marketing manager]
|
||
|
||
|
||
4.2 Gods.
|
||
|
||
Name: Gods
|
||
Importance: 1
|
||
Author(s): Ben Laurie ("Tiger Tiger")
|
||
Location: Lap of the Gods
|
||
Pricing Structure: L0.575/hour or
|
||
L11.50/month flat fee
|
||
|
||
Brief Description:
|
||
Advanced MUD1 clone, fantasy world.
|
||
|
||
Historical Notes:
|
||
Although the present system went live in October 1988, Gods began in
|
||
1985 as a non-commercial MUA; its author was inspired by MUD1 to write his own
|
||
game, and was among the first people to do so. Gods was Shades' only rival to
|
||
be the Prestel Micronet MUA.
|
||
|
||
Review:
|
||
The dominant concept in Gods, which permeates every facet of it, is
|
||
that of object creation. Instead of becoming a wiz when one gains the
|
||
appropriate experience points, one becomes a 'god'. Gods have the ability to
|
||
alter the game at will, but doing so costs them points. When mortals cash in
|
||
treasure for points, they take it to the temple of their favoured god. This
|
||
will add to that god's points, as well as to their own. Thus, popular and
|
||
respected gods will be able to make more changes to the game, and ones that are
|
||
unpopular will lose the ability.
|
||
|
||
The idea is attractive, but fundamentally flawed. Gods can use their
|
||
powers to do anything they like, without any interference from the equivalent
|
||
of arch-wizzes. Unfortunately, what they like to do is prevent people they
|
||
dislike from becoming gods. Although theoretically a seller's market ("which
|
||
god shall I give these points to?"), it's actually a buyer's market ("give
|
||
those to me"). There are two reasons for this: treasure is worth more if the
|
||
receiving god is present when it is offered at that god's temple; gods who see
|
||
mortals giving treasure to non-present gods have sufficient powers that they
|
||
can readily persuade such mortals that it would be in their best interests to
|
||
deposit their treasure elsewhere. Thus, unless there are several gods playing
|
||
for most of the time, the treasure dedicated to each god will tend to be
|
||
proportional to the period the god spends in the game. If a god needs more
|
||
points to create something, it's just a question of sitting around in the game
|
||
for long enough to get them.
|
||
|
||
This dominance of the idea that gods can create things is a shame,
|
||
because otherwise Gods is a very well thought-out game, wide in its extent and
|
||
with imposing depth to its world. Despite being first-generation, it has
|
||
nevertheless stood the test of time, and its definition language is one of the
|
||
clearest and most functional around. It is based on the notion of 'objects',
|
||
which are items that have 'properties'. Properties are either 'mundane' (they
|
||
return a simple value) or 'esoteric' (they run some code to return a value).
|
||
Commands are implemented as properties of objects, thus making Gods one of the
|
||
earliest object-oriented programming languages and pre-dating much of the work
|
||
presently going on in the TinyMUD field.
|
||
|
||
Gods operate by changing objects' properties, but this is not yet fully
|
||
implemented, nor is it likely to be in the near future. They can alter mundane
|
||
properties easily, but esoteric properties are out of bounds. This is because
|
||
they require programming skills, and there is no guarantee that they will be
|
||
safe. Problems of unwanted interactions between independently-created objects
|
||
are expected, and a facility to test/debug objects is necessary. It is
|
||
interesting to note that these are issues which have always concerned Gods
|
||
experts, but their importance is only now being recognised in the TinyMUD
|
||
world.
|
||
|
||
Nevertheless, it is a pity that the central vision of Gods is still
|
||
some way away even after all these years, and that what the game presently
|
||
boasts as its major player-winning feature is actually no better than what is
|
||
available as just one riff in MUD2. Gods' over-emphasis on object creation
|
||
distracts attention from the many really quite splendid other features that it
|
||
has. Its parser is good, it has a built-in class hierarchy of objects (although
|
||
"get all" doesn't work), and there's a neat counting feature for similar object
|
||
(eg. "You pick up thirty-one assorted rabbits."). The game is atmospheric - its
|
||
large (2,000 rooms), North African seaport setting is rooted in historical fact
|
||
(although elements from different periods are disconcertingly juxtaposed; this
|
||
may be deliberate). Puzzles can vary with time depending on whether it is
|
||
night or day, and commands that you use frequently can develop different
|
||
affectations. Gods has the reputation of being a difficult, challenging game.
|
||
|
||
One of Gods' recent innovations is its treatment of fights. Some
|
||
players like fighting, some don't, so Gods has two classes: fighters and non-
|
||
fighters. Non-fighters cannot be attacked, receive no points for killing, but
|
||
don't die if killed. Fighters can be attacked, do receive points for killing,
|
||
and lose them for dying. Whether this will work in the long run is something
|
||
which remains to be seen, though - the non-fighters would appear to be able to
|
||
annoy and dispose of the fighters without taking any personal risk, and it may
|
||
be that unimaginative non-fighters may find themselves at high levels without
|
||
really having much knowledge of the game at all.
|
||
|
||
As well as a points value, treasure also has a monetary (alms) value.
|
||
There is a commercial system in Gods which can be played as a game without
|
||
reference to the deities. Money can be used to buy certain objects, for
|
||
gambling in a slot machine (slot machines are not uncommon in money-oriented
|
||
MUAs), and for buying drinks at a bar to regain stamina. As with Federation II,
|
||
this "alcohol is good for you" attitude could offend some people, and Gods may
|
||
attract another form of objection by its explicit use of "black magic" as a
|
||
form of spell use which can be practised. That said, critics of this sort are
|
||
likely to complain about the very name of the game anyway, irrespective of
|
||
other considerations.
|
||
|
||
Gods tries to maintain an aura of mystique by keeping information from
|
||
players until they gain experience. Thus, a newcomer (of 'scum' level) is only
|
||
told how many points are required to reach levels 1 to 4, and has no idea how
|
||
many levels there are altogether. Similarly, only those spells which can be
|
||
used are listed. This works as an incentive to go up levels, but can be rather
|
||
worrying when you first start to play. Another way in which Gods strives to
|
||
provide atmosphere is by folding objects into room descriptions. This looks
|
||
good, but newcomers find that they can't always tell what is gettable and what
|
||
isn't.
|
||
|
||
Rather than limiting the number of objects a player can carry, or
|
||
letting players carry as much as they like, Gods has a halfway solution which
|
||
is perhaps more realistic. The more objects carried, the greater is the chance
|
||
of dropping one. Thus, with your arms full of treasure you can only travel a
|
||
short distance before something falls to the ground. Travelling light, you can
|
||
play for hours and not drop a thing.
|
||
|
||
Gods runs on an 80386 processor under Xenix. The Lap of the Gods
|
||
system to which it is connected consists of specialist multiplexer hardware and
|
||
associated software, collectively known as The Butler. This has recently been
|
||
upgraded so as to provide on-line help facilities, but the information it
|
||
displays is rather hurriedly put together. This is reminiscent of the whole
|
||
system - every feature imaginable can be expressed in one way or another, but
|
||
somehow it's never used quite as fruitfully as it could be.
|
||
|
||
Day-to-day running of the Gods system is now by one of the game's gods,
|
||
Heptaparaparshinokh. It appears to have no major managerial problems, perhaps
|
||
due to the fact that it is, in part, an experiment on the way deities behave
|
||
without higher deities above them. There is a guest facility for beginners,
|
||
with a built-in tour available.
|
||
|
||
Gods has a client written for it, Hear-Gods, which consists of normal
|
||
terminal software for the Atari ST with the addition of sampled sound-effects.
|
||
|
||
A version of Gods runs in Germany.
|
||
|
||
Summary:
|
||
A lone pioneer of object-creating MUAs, Gods is well written and
|
||
abounds in detail. It is old, yet still fresh, and has worn well. However,
|
||
its overall premiss, though seductive in theory, is unproven in practice. Had
|
||
it been written as a conventional MUA instead of a slightly eccentric one, it
|
||
might have had much wider appeal and taken its place at the forefront of MUA
|
||
development. As it is, Gods' story is one of missed opportunity, and its
|
||
considerable potential is still to be realised.
|
||
|
||
Quotes:
|
||
|
||
"Certainly a game I would recommend to anyone."
|
||
ACE [magazine]
|
||
|
||
"You will find a coliseum and a set of dry docks close by each
|
||
other, but this doesn't seem unusual in the game."
|
||
Comms Plus! [magazine]
|
||
|
||
"The system of scoring is complicated."
|
||
ACE [magazine]
|
||
|
||
"With the current generation of modems, I personally feel that
|
||
objects should be readily apparent to players."
|
||
Comms Plus! [magazine]
|
||
|
||
"Really, we can't explain what the games are like - you'll have to
|
||
try them"
|
||
Lap of the Gods [promotional material]
|
||
|
||
|
||
4.3 MirrorWorld.
|
||
|
||
Name: MirrorWorld
|
||
Importance: 1
|
||
Author(s): Pip Cordrey ("Pippin"),
|
||
Nat Billington ("Natso"),
|
||
Lorenzo Wood ("Penfold"),
|
||
Patrick Bossert ("Zoot"),
|
||
Tim Rogers ("Grobble"),
|
||
Piers de Lavison ("Inziladun")
|
||
Location: IOWA
|
||
Pricing Structure: free
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone, Tolkienesque.
|
||
|
||
Historical Notes:
|
||
Pip Cordrey used to run a BBS called 'Labbs', which had a section
|
||
devoted to MUD1 in its early days. Six people from St. Paul's School worked
|
||
on that section, and Cordrey organised them into a team to develop a MUA that
|
||
would run on a home computer. The system was named MirrorWorld because it had
|
||
rolling resets (as in the film "Westworld"). It went live in 1986. The St.
|
||
Paul's group are now all MirrorWorld arch-wizzes.
|
||
|
||
Review:
|
||
MirrorWorld (MW to its players) is a venerable yet thriving MUA. Its
|
||
stated aim is for players "to score points by killing monsters and other
|
||
players, finding and selling treasure, and doing clever things". Its
|
||
conventional setting is well described, and it has a strong, magical
|
||
atmosphere.
|
||
|
||
The game is easy to enter, and provides guest facilities. The new user
|
||
is well catered for with on-line help, but the authors seem preoccupied by the
|
||
expense of telephone calls to the game, and the newcomer is somewhat bombarded
|
||
with dire warnings of how costly it is to play.
|
||
|
||
Another of the things with which MirrorWorld is obsessed out of all
|
||
proportion to its importance is the concept of rolling resets (or 'autosets',
|
||
as they are called in the game). MirrorWorld was among the first MUAs to
|
||
incorporate rolling resets, and the authors consider it their invention. The
|
||
main reason for having rolling resets is to give a seamless scenario which
|
||
doesn't have its atmosphere ruined by intrusive resets; however, MirrorWorld's
|
||
alternative is to have a little man in a white coat appear to reset puzzles,
|
||
which, although a cute idea, doesn't fit in well with the fantasy milieu. The
|
||
downside of rolling resets is that they're difficult to implement for hard
|
||
puzzles, and this betrays a hint as to the deeper nature of the game (or rather
|
||
the lack of it).
|
||
|
||
From the outset, MirrorWorld was intended to run on a home
|
||
microcomputer (rather than the mainframe that hosted MUD1), and it partially
|
||
succeeded: the main computer is a BBC Master 128, but it has a 4mb RAMdisc and
|
||
custom-built multiplexer added on. This modest CPU perhaps explains the
|
||
overriding feeling that pervades all of MirrorWorld - its (spasmodically
|
||
elegant) simplicity.
|
||
|
||
Everything about MirrorWorld is simple. The parser is so basic that it
|
||
merely looks at words in the order they come, not even 'parsing' at all in the
|
||
computational linguistic sense. It has only a dozen or so spells, and they are
|
||
defined poorly or not at all - "blind", in particular, can only be implemented
|
||
in an astonishingly inadequate way (teleportation to a special room).
|
||
|
||
There's a fragment of originality in the way that spells are
|
||
time-based, so that lower-level players have a longer delay between casting a
|
||
spell and its taking effect than do higher-level players. Unfortunately,
|
||
people coming in using fast comms links have a similar advantage... The
|
||
"nullify" spell is unique to MirrorWorld and its sisters, as it interrupts an
|
||
opponent's spell if it fires during that spell's delay period. Otherwise,
|
||
though, MirrorWorld's spells are depressingly ordinary.
|
||
|
||
The problem that MirrorWorld faces is its implementation. Along with
|
||
most of the other IOWA games, it is written in a database definition language
|
||
called 'Slate'. That Slate is sufficiently powerful to be used to define
|
||
several disparate databases is to its credit, however it is a comparatively
|
||
feeble language, rooted in old ideas and methods, and resistant to change. For
|
||
example, when an "act" command was needed, Slate wasn't really up to the job,
|
||
and the resultant hack makes MirrorWorld the most impoverished major MUA in
|
||
this area.
|
||
|
||
Slate is a lot like a bad Basic. Variables cannot be declared
|
||
arbitrarily - only predefined system ones are usable. Its subroutines have no
|
||
parameterisation, and there is a confusion between commands, actions, and
|
||
actions tied to objects (in an object-oriented fashion that would be more
|
||
convincing if objects were arranged in an inheritance hierarchy). All this
|
||
makes use of Slate difficult, but not impossible. However, no amount of fancy
|
||
programming can get round the fact that too much is built into the Slate
|
||
interpreter, and not enough is in the hands of the database designer. Modern
|
||
features cannot be added to MirrorWorld without making alterations to the Slate
|
||
language, and thus to the compiler itself.
|
||
|
||
These criticisms of Slate aside, it must be said that the language does
|
||
work very well for simple MUAs, and that there are people willing to pay L3,000
|
||
to buy a complete Slate system so as to program their own MUAs in it.
|
||
|
||
Accepting that MirrorWorld is not really much of an intellectual's MUA,
|
||
it nonetheless has some nice, novel touches. There is an arena for fights,
|
||
where people go for mass combat and only one survivor is allowed to leave.
|
||
There is a gambling module, which is another concept the MirrorWorld team
|
||
implemented first, and which thus receives more publicity than it really
|
||
merits. Also, the persona file stores more details about a player's status than
|
||
is common, so eg. if your persona is crippled and you quit, it'll still be
|
||
crippled when you return.
|
||
|
||
On the managerial side, MirrorWorld functions well. There are written
|
||
and unwritten rules that the players must not transgress, which keeps everyone
|
||
peaceful but can occasionally stifle originality (today's best wizzes are often
|
||
yesterday's most misbehaving mortals; guidelines are a better solution than
|
||
cast-iron rules). MirrorWorld is overseen by Pip Cordrey, who has arch-wiz
|
||
status on Shades and is thus well qualified for the task. MirrorWorld is
|
||
regularly updated.
|
||
|
||
There are 12 levels for normal players, with an unusually large number
|
||
of points required to make wiz. Indeed, despite its age the game has under 20
|
||
wizzes in total. Wizzes can die in the game, which is something that is
|
||
impossible in other games (and difficult to justify in this one). Some of the
|
||
feminine forms of levels below wiz appear a little condescending, eg. male =
|
||
peasant, female = washer-woman; male = potent, female = bewitched.
|
||
|
||
Although relaxing and pleasant enough to play, MirrorWorld is not a
|
||
true heavyweight of MUAs. However, it has made an immense contribution to the
|
||
genre, has an experienced programming and design team behind it, and has
|
||
pioneered the concept of genuine choice between different MUAs on a single
|
||
system dedicated to such games. After a rough period in early 1990, when its
|
||
authors thought that it was better than it was and prematurely charged people
|
||
to play game (which lead to their rapid abandonment of the system), MirrorWorld
|
||
has bounced back and is again an entertaining place to spend an evening. Thanks
|
||
to the tireless efforts of Pip Cordrey in publicising IOWA (and MUAs in
|
||
general), it is likely to remain so for some considerable time.
|
||
|
||
Summary:
|
||
MirrorWorld is very shallow, has little breadth, and it possesses a
|
||
thoroughly awful parser; and yet, it isn't frustrating to play. Of average
|
||
size, its gameplay is good - especially for MUA novices - and its players
|
||
friendly. The atmosphere is well maintained, but, although it tries hard,
|
||
MirrorWorld is more a picturebook MUA than a meaty novel.
|
||
|
||
Quotes:
|
||
|
||
"MirrorWorld has that feel to it that just keeps you playing on and
|
||
on."
|
||
ACE [magazine]
|
||
|
||
"The feeling you get is that you have visited this place sometime
|
||
before."
|
||
Confidential [magazine]
|
||
|
||
"Used treasure is repositioned by an old man who wanders round the
|
||
game dropping things, which is a little less painful than being
|
||
thrown off every 45 - 60 minutes!"
|
||
ACE [magazine]
|
||
|
||
"[Resets] do nothing except drag you out of your fantasy world and
|
||
plop you right back in the real one."
|
||
Pip Cordrey [owner]
|
||
|
||
"Make sure that your phone bills contain no surprises."
|
||
Pip Cordrey [owner]
|
||
|
||
"Though some players are not quite as friendly as on some games, it
|
||
really is good."
|
||
ACE [magazine]
|
||
|
||
"On-line entertainment for the nineties"
|
||
IOWA [promotional material]
|
||
|
||
|
||
45MUSE Ltd Reviews - UK
|
||
|
||
|
||
"If you have offended against one of the rules, the thing that the
|
||
wizard or arch-wizard wants to hear is that you recognise that you
|
||
have broken the rules and will not do it again."
|
||
Pip Cordrey [owner]
|
||
|
||
"[Cordrey] has something that only a handful of other men have: his
|
||
own world."
|
||
Confidential [magazine]
|
||
|
||
|
||
4.4 MUD2.
|
||
|
||
Name: MUD2
|
||
Importance: 1
|
||
Author(s): Richard Bartle, Roy Trubshaw
|
||
Location: (081) 203 3033
|
||
PSS 23421920100441
|
||
Pricing Structure: L0.50/hour to L1/hour, depending on amount bought
|
||
up front
|
||
|
||
Brief Description:
|
||
Advanced MUD1 rewrite, fantasy world.
|
||
|
||
Historical Notes:
|
||
By 1985, MUD1 was becoming fossilised, so a completely new version was
|
||
written from scratch. Although MUD2 contains nearly all of MUD1 as a subset,
|
||
it is considerably larger. Originally intended to run on Micronet, this was
|
||
thwarted by BT politics, and MUD2 now runs on one of BT's Vax clusters
|
||
connected to Telecom Gold's network. BT and MUSE have both been trying to
|
||
escape from their mutual contract ever since. Warning: the principal author of
|
||
MUD2 is the author of this report; expect unrestrained enthusiasm.
|
||
|
||
Review:
|
||
The cutting edge of MUA technology. MUD2 is the most advanced MUA in
|
||
the world, with a big lead over its challengers (Gods and Avalon are probably
|
||
the next-best in programming terms). Although roughly the same age as Shades,
|
||
MUD2 is a second-generation MUA and was designed for portability and
|
||
endurability. Thus, there are versions of its interpreter in C and Pascal, and
|
||
it runs on a VAX under VMS, an Archimedes under Unix, and on both an Atari ST
|
||
and a VME-based piece of specialist hardware under OS9. The same database will
|
||
load on all these configurations.
|
||
|
||
In every aspect of MUA technology (except its parser, which, although
|
||
admirably capable of choosing implied objects, does not handle pronouns,
|
||
adjectives or adverbs), MUD2 excels. Its breadth and depth are unparalleled,
|
||
its atmosphere compelling, and its management sound.
|
||
|
||
In terms of detail, MUD2 (or simply MUD to most players) is the only
|
||
MUA that deals routinely with fluids (miscible or otherwise), heat, all
|
||
audio-visual effects, smells and consistency. If you drop an object from a
|
||
height through several vertically-placed rooms into running water, it will
|
||
consider impact damage, water damage, and will place the object either where it
|
||
landed or further downstream depending on whether it floats or not - players in
|
||
intervening rooms will see it pass. This form of world modelling adds a sense
|
||
of realism to MUD2 which most other games cannot even represent in their
|
||
definition languages, let alone emulate in practice.
|
||
|
||
The number of commands, spells and interactions MUD2 supports is also
|
||
unrivalled. Many of its nuances are found only occasionally by the more
|
||
enterprising players, and it has a dedicated band of enthusiasts whose main
|
||
preoccupation is simply exploring the range of command possibilities the game
|
||
might trap (eg. "play poker" for a poker object meant for stoking a fire, or
|
||
"stick pin in doll" using a rolling pin rather than a needlework pin).
|
||
|
||
MUD2's mobiles are the most sophisticated of any MUA. It has a large
|
||
number of them (over 160), and they are of many different types (some fly, some
|
||
swim, some regenerate, some can cast spells). They are also multi-functional:
|
||
for example, there is a sword that can be used for combat as expected, but it
|
||
also continually makes comments about its wielder, its own prowess, other
|
||
weapons, fights, and the weather. It will inform its owners when magic has been
|
||
cast against them, and cure them of ailments (especially if they deafen
|
||
themselves to avoid its endless chatter!).
|
||
|
||
Even mundane mobiles are very advanced. They incorporate expert systems
|
||
that enable them to fight (often better than the players): MUD2's thief knows
|
||
not only how to steal objects, but how to score points for them (it carries
|
||
them to a 'swamp' room and drops them there). Most mobiles know which weapons
|
||
to use, to drop useless objects when attacked, to attempt to steal useful
|
||
objects from opponents in a fight, when to flee, and when to offer a withdrawal
|
||
(MUD2, uniquely, has a mechanism that allows combatants to agree to stop
|
||
fighting without either losing points). Mobiles are also capable of planning
|
||
to achieve goals, eg. if they can't go west because there's a locked door in
|
||
the way, they should unlock it with the right key and then proceed (Bartle's
|
||
PhD concerned Artificial Intelligence planning techniques).
|
||
|
||
There are 11 levels in MUD2, which fall into two streams
|
||
(magical/non-magical) and two forms ('protected' and 'non-protected' personae).
|
||
Only magic-users who are not protected personae can reach wiz. The
|
||
distinction between fighters and magic-users is unusual, and although it does
|
||
add something to the game, MUD2 could survive quite adequately without it,
|
||
treating everyone as if they were magic-users. To switch from fighter to
|
||
magic-user, there's a special object (a "touchstone") that must be touched,
|
||
with a high chance of causing death at lower levels. Some players don't like
|
||
the idea, others look on it as a watershed that thrusts their play into a
|
||
different gear.
|
||
|
||
Protected personae are mainly people exploring who don't want to be
|
||
molested by other players. Conversion back to the normal stream is allowed at
|
||
any time, at a cost of two-thirds of the persona's score. This ensures that
|
||
people with no aspirations of reaching wiz can play in relative safety, but
|
||
that anyone seeking the top rank must run risks.
|
||
|
||
Another safeguard that ensures unsuitable people don't "sneak" to wiz
|
||
is a system of 'tasks'. These are eight quests, any seven of which a persona
|
||
must solve if it is to become a wiz. Some require co-operation with other
|
||
players, some test knowledge of the game, some test fighting, and some are
|
||
important puzzles; most are a combination. When players makes wiz in MUD2, it
|
||
can therefore be guaranteed that they have had a broad education in the game.
|
||
|
||
Wiz powers in MUD2 are considerable. As well as object, mobile and room
|
||
creation (by fleshing out "blanks"), wizzes can attach to mobiles and personae
|
||
(and thus play as several beings at once), there is a full complement of proof
|
||
commands, and multiple snoops are possible. There are four levels of
|
||
invisibility, so wizzes and arch-wizzes can choose to whom they are visible.
|
||
Wizzes have the ability to alter the manner in which players are described, and
|
||
the messages given when arriving, departing or using magic. As these powers
|
||
are creative in aspect, they are not granted to mortals (because otherwise the
|
||
game's atmosphere could be spoiled).
|
||
|
||
Among MUD2s other features are: a command that draws birds-eye view
|
||
maps; a safe start location where people can enter the game for a chat and to
|
||
see who's playing without risking assault; many-on-many fights; a wide range of
|
||
spells with their effects properly handled (so if you're blinded and walk into
|
||
a room where dripping water can be heard, you'll be given that part of the room
|
||
description but not the rest); and delayed-effect actions.
|
||
|
||
To new players, MUD2 can seem imposing. This is usually because its
|
||
sophistication, though concealed from newcomers in part, is nonetheless
|
||
imposingly evident; however, the game's reputation also has an effect. To ease
|
||
the way, a pair of excellent handbooks are provided that answer many of the
|
||
questions that enter newcomers' minds (but which reviewers don't always bother
|
||
to read...). The game itself has special novice-level treasure that other
|
||
players are discouraged (by its negative value) from picking up, and which is
|
||
therefore often in play even when a reset is due. Room descriptions are
|
||
friendly in areas frequented by novices, and get increasingly forbidding the
|
||
further away one travels; MUD2's prose is generally regarded as the finest of
|
||
any MUA's. There is a tour facility, that enables prospective players to be
|
||
shown round various areas of the game with a running commentary (and which
|
||
takes account for what's currently in the rooms being visited).
|
||
|
||
Fighting in MUD2 is of the automatic variety, with spells, potions and
|
||
(breakable) weapons available for use. Death results in persona deletion,
|
||
irrespective of who started the fight; although this is regarded as unfair by
|
||
many inexperienced players, those who have played for longer accept that it is
|
||
the best approach to adopt - in terms of game management, it's essential. MUD2
|
||
is managed by its principal author, the most experienced of all MUA managers.
|
||
At present, MUD2 is top heavy with arch-wizzes, though; this is because several
|
||
were appointed in preparation for an impending move to Prestel which was (as
|
||
usual) cancelled by BT.
|
||
|
||
There is a full classification system in MUD2, which readily accepts
|
||
commands such as "get food" (to pick up anything that might be edible). Unlike
|
||
many of the first generation games, it allows multiple objects of the same
|
||
type, however since its parser is weak on adjectives that leads to objects with
|
||
names like "key21". This can be rather unatmospheric.
|
||
|
||
Because of the game's high puzzle-density and large number of objects,
|
||
it resets every 105 minutes; this is despite its average size (around 800
|
||
rooms).
|
||
|
||
MUD2 is programmed in a special MUA programming language called MUDDLE.
|
||
This is the key to its success, since it gives complete control to the MUA
|
||
designer without hardwiring essential functions into its interpreter.
|
||
Object-oriented in concept, but reading like a hierarchical version of Prolog,
|
||
MUDDLE's versatility should ensure that MUD2 maintains its lead position in the
|
||
MUA world for some time yet.
|
||
|
||
Summary:
|
||
MUD2 is well designed, has superb depth, is wide-ranging in its scope,
|
||
and is easily modifiable. Its age belies its advanced features, particularly
|
||
its mobiles and the facilities provided for its wizzes. Its atmosphere is
|
||
carefully maintained by powerful room descriptions, and its gameplay is well
|
||
thought-out. Only its parser is less than satisfactory. Clearly, MUD2 stands
|
||
head and shoulders above all other MUAs. However, it has enjoyed only modest
|
||
success compared to, say, Shades. This is almost entirely due to its being tied
|
||
to BT by an agreement that was rendered inappropriate within a year because of
|
||
reorganisations within that company.
|
||
|
||
Quotes:
|
||
|
||
"An adventure on a grand scale."
|
||
ACE [magazine]
|
||
|
||
"MUD was, and still is, the multi-user game that others are
|
||
measured by."
|
||
PC Plus [magazine]
|
||
|
||
"MUD is the first of a new generation of interactive games."
|
||
Daily Mail
|
||
|
||
"If you want a civilised entry into a game, try MUD, the Multi-User
|
||
Dungeon."
|
||
MUSE [promotional material]
|
||
|
||
"The game is very user-friendly."
|
||
Computer and Video Games [magazine]
|
||
|
||
"Where MUD scores is in the atmosphere of the world you have to
|
||
explore. It's not as communal as Shades, but ... it can become an
|
||
obsessive exercise in politics, co-operation and the exercise of
|
||
power."
|
||
ACE [magazine]
|
||
|
||
"The atmosphere can be slightly daunting for a first-time player,
|
||
but as a rule other MUDders are tolerant of newcomers and even
|
||
helpful if you meet trouble."
|
||
PC Plus [magazine]
|
||
|
||
"[In atmosphere] MUD is definitely better than Shades."
|
||
Acorn User [magazine]
|
||
|
||
"I prefer to play [MUAs] in "verbose", even if I don't bother to
|
||
read it all. It's handy for picking up the feel of the place. I
|
||
rarely read the whole description unless it's my first visit to
|
||
the room and I'm not in a hurry to get anywhere. I quite like the
|
||
"unverbose" mode that MUD has, no other game seems to have that
|
||
one."
|
||
Wabit [player]
|
||
|
||
"One of the best things about MUD is the style of the text. The
|
||
locative descriptions are long, well-written, and vividly
|
||
evocative."
|
||
PC Plus [magazine]
|
||
|
||
"Part of MUD's strength is the quality of the descriptions of each
|
||
location, which are excellent."
|
||
Acorn User [magazine]
|
||
|
||
"Deaths lurk around every corner."
|
||
Computer and Video Games [magazine]
|
||
|
||
"Due to various political shenanigans at BT, MUD2 never got to
|
||
Prestel."
|
||
GM [magazine]
|
||
|
||
"Shades versus MUD: how about blank objects, levels of
|
||
invisibility, far greater realism, atmosphere, better room
|
||
descriptions, greater flexibility with everything..."
|
||
Faramir [player]
|
||
|
||
"Just because we think MUD is a better game doesn't mean that all
|
||
of the existing Shades players will drop Shades and come a running
|
||
to MUD."
|
||
Wabit [player]
|
||
|
||
"Novices and guests don't like MUD. They can't find any treasure.
|
||
Shades is more exciting for a beginner."
|
||
Acorn User [magazine]
|
||
|
||
"I honestly think that MUD's main problem is a lack of players, due
|
||
to a lack of advertising and a general lack of anyone in charge
|
||
being that bothered by the lack of players."
|
||
Wabit [player]
|
||
|
||
"MUD has too many internal problems. The game itself is far
|
||
superior to anything else on the market, and with a little forward
|
||
thinking could still be the number one game. Although advertising
|
||
would have helped, I don't see that as being the culprit ... the
|
||
problems were actually caused by an internal political power
|
||
struggle, and as there wasn't anybody strong enough to put people
|
||
in their place, the struggle gained momentum."
|
||
Wabit [player]
|
||
|
||
"It's an adventure, sure, but it's far more."
|
||
Computer and Video Games [magazine]
|
||
|
||
"Some activities are, it must be said, a little unusual, but are in
|
||
keeping with the alternative comedy theme that pervades the game."
|
||
Atari ST User [magazine]
|
||
|
||
"MUD is expected to be one of the most popular innovations in home
|
||
computing."
|
||
The Times
|
||
|
||
"Despite its outward appearance as just another computerised
|
||
fantasy, MUD is a great deal more than that, and what it promises
|
||
is even more intriguing."
|
||
Computing [magazine]
|
||
|
||
"MUD's success has been little short of phenomenal."
|
||
Atari ST User [magazine]
|
||
|
||
"MUD has a devoted following (one regular player lives in Japan)
|
||
among whom some must certainly be counted micro-junkies. One
|
||
unemployed participant built up a L1,000 phone bill and got zapped
|
||
by British Telecom."
|
||
Mail on Sunday [magazine]
|
||
|
||
"If you buy your credits in bulk, it can be satisfyingly cheap to
|
||
play."
|
||
ACE [magazine]
|
||
|
||
"One player in Wales clocked up a telephone bill of L3,000 before
|
||
she was cut off."
|
||
The [Economist]
|
||
|
||
"MUD has been described as the greatest adventure in the world."
|
||
Computer and Video Games [magazine]
|
||
|
||
"MUD leaves other adventures for dead."
|
||
Personal Computer World [magazine]
|
||
|
||
"You haven't lived until you've died in MUD"
|
||
MUSE [slogan]
|
||
|
||
|
||
4.5 Shades.
|
||
|
||
Name: Shades
|
||
Importance: 1
|
||
Author(s): Neil Newell ("Hazeii")
|
||
Location: Prestel (Micronet)
|
||
Pricing Structure: L4.80/hour 8am - 6pm
|
||
L1.20/hour 6pm - 8am
|
||
L19.80/hour on (0898) 100890
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone.
|
||
|
||
Historical Notes:
|
||
Newell was a MUD1 player. Shades was written over Christmas 1985 when
|
||
MUD1 was unavailable, partly as a spoof. It was launched nine months later on
|
||
Micronet, in preference to MUD2 and Gods because of internal BT wranglings. It
|
||
has been highly successful on that service. Nowadays, it is billed as "the most
|
||
popular on-line multi-user adventure game in Europe", which, in terms of player
|
||
numbers, is absolutely correct.
|
||
|
||
Review:
|
||
Shades is very lucky. MUD2 was going to go on Micronet, but due to
|
||
rivalries between departments of BT (Prestel and what was then NIS), the deal
|
||
fell through. Micronet's much-vaunted Viewdata scrolling software was, for
|
||
example, originally programmed to MUSE's specifications for MUD2. Shades was
|
||
chosen as a substitute (ahead of Gods for technical reasons), and has remained
|
||
the premier MUA on Micronet ever since, challenged only by the jokey Trash
|
||
(which comes from the same stable). Most MUA authors - Newell included -
|
||
consider this form of protectionism absolutely disgraceful. Compared against
|
||
almost any other MUA, Shades looks decidedly inferior.
|
||
|
||
Because it is the only MUA accessible at local call telephone rates
|
||
from anywhere in the country, Shades has enjoyed tremendous success. It has
|
||
introduced many people to MUAs who might otherwise have been unaware of such
|
||
games, and for this reason alone it ranks very highly. It has been well
|
||
marketed, and has good technical support, but it is five years old now and
|
||
really shows its age. Because of the hard-coded way it is programmed, it is
|
||
fossilised in 1985. Its infrequent updatings (minor changes every six months,
|
||
of late) means it continues to shed old players while only attracting a trickle
|
||
of new ones: its user base has been saturated.
|
||
|
||
Technically speaking, Shades is actually pre-MUD1 in sophistication.
|
||
It has insufficient depth to handle even basic concepts like containers. Its
|
||
mobiles follow a set track, rather than moving with some randomness, and they
|
||
cannot contain/hold objects either; this means that at times the game works
|
||
counter-intuitively. For example, there is a "thief" mobile which steals
|
||
things, however he can't carry his booty so it just automatically appears in
|
||
his lair. If you see him steal an object, and you kill him before he leaves the
|
||
room, your treasure is still in his lair.
|
||
|
||
The game itself is not really all that bad, given its age. There are
|
||
over a thousand locations now (which is probably too many, since each game can
|
||
only handle eight players at once), and its database is the usual castles and
|
||
buried treasure fare. The aim is to collect treasure and drop it in one
|
||
location (the Mad King's room) for points. There are 14 levels, some of which
|
||
aren't immediately obvious as being gender equivalent (eg. male = gallant,
|
||
female = dauntless; male = soothsayer, female = spellbinder). This doesn't
|
||
appear to bother the players (who call themselves 'Shadists').
|
||
|
||
Persona attributes are strength, stamina, power and fight skill, which
|
||
is an unusual combination. All players start with identical statistics, but
|
||
they can change (stamina goes up to 230: again, uncommon). Only the latter
|
||
three attributes are used in combat, which plays a central role in the game.
|
||
Blows in fights are handled automatically, with power being the damage you do,
|
||
and chance to hit depending on the combatants' respective levels. Fight skill
|
||
defines the number of blows that occur per round of combat; it can rise and
|
||
fall depending on the outcome of the fight.
|
||
|
||
Shades has a problem with fights, after complaints from players lead to
|
||
a misguided (from a managerial perspective) alteration to the way fights work.
|
||
If you start a fight and are killed, you lose all your points; if you were
|
||
attacked and are killed, you only lose half your points. If the winner started
|
||
the fight, the reward is 6.25% of the loser's score; if the winner was the
|
||
player attacked, the figure is 25%. This, in a game where fighting is a key
|
||
element, is something of a surprise. It discourages inter-player fighting,
|
||
which in turn means that anyone can reach wiz merely by playing for hours on
|
||
end, whether they are 'suitable' in some sense or not. Once they have reached
|
||
a high level, they are unlikely to be attacked at all - other high-level
|
||
players will not attack because the rewards don't match the risks, and low-
|
||
level players won't because they'd lose the fight (incredibly, Shades doesn't
|
||
allow fights involving more than two players). There is a "berserk" command
|
||
which could balance this, as it allows low-level players to flee without losing
|
||
points (whereupon another can attack), however it is used infrequently because
|
||
it doesn't work all the time.
|
||
|
||
As if this isn't bad enough, Shades has another means of ensuring that
|
||
anyone can be a wiz if they really want to be: 'pacifists'. These are similar
|
||
to MUD2's protected personae, but have no maximum level and a quicker
|
||
advancement rate - only half that of non-pacifists. A pacifist can be
|
||
attacked, but loses no points for fleeing. Pacifists can't start fights.
|
||
Switching modes between pacifist and fighter zeroes your score.
|
||
|
||
Shades has many problems as a result of earlier managerial decisions.
|
||
Although the situation is better now, there are still mistakes (eg. offering
|
||
10,000 points for the best map of the game). Despite having a MirrorWorld
|
||
arch-wiz (Pippin) and a MUD2 arch-wiz (Lordant) on its books, Shades has always
|
||
been a place where, if you complain loudly enough and with enough people
|
||
supporting you, you'll get your way in the end. There are horror stories of
|
||
people deliberately working up secret personae, gathering a coterie of
|
||
impressionable admirers around them, then doing all they can to wreck the game
|
||
as a wiz and having their minions leap to their defence every time there's a
|
||
warning that they're out of line (receiving 50 letters telling you you're wrong
|
||
is often enough to make even the most hardened arch-wiz think twice). By the
|
||
time these trouble-makers have been ejected, they've worked up another persona
|
||
and can start their disruption again. In addition, they probably didn't pay any
|
||
money for what they did, having simply torn up their Micronet bill and waited
|
||
to be cut off (you can get around 5 or 6 months' play for free this way).
|
||
|
||
One of the problems is that the game lacks logging facilities, so
|
||
gathering evidence is always difficult. Another is that wizzes have feeble
|
||
powers compared to other MUAs, and can't always keep mortals under control.
|
||
However, since most mortals seem convinced that wizzes don't play fair, perhaps
|
||
it's just as well there isn't anything really dangerous they can do.
|
||
|
||
Shades still has some oddities despite its age: there are
|
||
mispunctuations ("moats bank" instead of "moat's bank", occasional American
|
||
spellings ("center"), and room descriptions giving wrong directions. This
|
||
latter point is extremely irritating, because Shades has no "exits" command
|
||
(unlike virtually every other MUA) and thus you have to rely on reading the
|
||
long descriptions of rooms to find out which directions you can move.
|
||
|
||
Atmosphere is player-driven. The players can be friendly at times,
|
||
although stroppy at others. The room descriptions are not particularly
|
||
evocative, and are constantly spoiled by out-of-place objects and events.
|
||
Using rooms as a form of providing help is a neat idea, but it feels odd
|
||
compared to the rest of the rooms (especially as there is a standard on-line
|
||
help feature built-in anyway). Not really obviously (and perhaps politically
|
||
unwise), the means chosen to give players back lost stamina is to touch a
|
||
"little girl" mobile.
|
||
|
||
The spells in Shades are the usual batch, but there is no "blind" and
|
||
no "deaf" (some room descriptions contain sound references that would still
|
||
appear audible to a deaf persona). The only original spell is "jaunt", which
|
||
enables the user to teleport to the location occupied by another player. Most
|
||
MUAs do not have such a spell, as it can be a most unfair way of stealing
|
||
treasure that someone else has worked on, and there are problems of consistency
|
||
that can occur when someone suddenly appears in a room (eg. it's a "falling off
|
||
a cliff" or a "you can only get here if you're carrying a cross" room).
|
||
Another point worth mentioning is that the more usual spell, "summon" (move
|
||
someone to your room, rather than vice versa), is available to novices in
|
||
Shades, whereas it is restricted to high-level players only in most MUAs.
|
||
Finally, the incantation "where treasure" will tell you the location of every
|
||
item of treasure in the game, thus (unfortunately) making novices aware of
|
||
every major room and object right from the start.
|
||
|
||
Shades uses the normal fixed-time reset method, albeit using a shorter
|
||
period than most MUAs (45 minutes - under half that of MUD2) since it gets
|
||
played out quicker. The more people there are playing, the more treasure is
|
||
worth (to compensate for its subsequent scarcity), but there is no time-based
|
||
scaling.
|
||
|
||
There are two widespread clients for Shades. Named Ripper and Shadist,
|
||
their principal function is as an aid to fighting in the game, however they can
|
||
perform simple i/o tasks too.
|
||
|
||
It is widely acknowledged that Shades is a good game for people new to
|
||
MUAs. It is easy to get into, there is lots of treasure lying around for
|
||
novices to find, and there are no difficult problems to solve. The scenario is
|
||
not threatening, and the players can be jolly, supportive and entertaining. For
|
||
people who want a game rather than a place to socialise, Shades has its
|
||
shortcomings, but it is by no means as awful as is often made out. It's a nice,
|
||
easy, friendly, non-taxing MUA. It might not be the best programmed, the most
|
||
challenging or the most innovative MUA, but its claims to be the most
|
||
successful of the first generation MUAs are not made without some considerable
|
||
justification.
|
||
|
||
Summary:
|
||
Shades is a very shallow MUA, its breadth is well below average, and
|
||
its parser is notably weak. It is old, and looks it. It is of slightly above
|
||
average size, but almost totally reliant on its players for what little
|
||
atmosphere it can be said to possess. The gameplay requires no imagination on
|
||
the part of its players, its wizzes are over-numerous, and by the standards of
|
||
other MUAs they're virtually impotent. Management is much improved of late,
|
||
but there are still legacies of the past that won't go away. Shades is popular
|
||
because it's the only MUA with local-call access nationwide. It's a good game
|
||
in that it's a MUA, but alongside other MUAs it looks very weak. It was in the
|
||
right place at the right time, has been exploited marvellously, but is now,
|
||
sadly, well past its sell-by date.
|
||
|
||
Quotes:
|
||
|
||
"Shades, already Europe's leading multi-user game, heralds the
|
||
introduction of a new generation of interactive entertainment."
|
||
Micronet [promotional material]
|
||
|
||
"There is nothing else like Shades."
|
||
Micronet [promotional material]
|
||
|
||
"Shades is still fun to play."
|
||
Comms Plus! [magazine]
|
||
|
||
"Shades seems to be the most popular MUG around at the moment if
|
||
you're judging by sheer weight of numbers, though it has something
|
||
of an advantage in being part of Micronet/Prestel."
|
||
ACE [magazine]
|
||
|
||
"Pity that there's no real alternative available for people to show
|
||
their disquiet. If something like Avalon was available at the
|
||
same call rates, I doubt you'd see most Shades players for
|
||
dust..."
|
||
Nigel Hardy [Sector 7 author]
|
||
|
||
"Shades is better at coping with this [resets] than MUD, since
|
||
there are eight games of Shades running on each Prestel computer."
|
||
Acorn User [magazine]
|
||
|
||
"She stood close to me, put her arms around my neck and whispered,
|
||
"It's not the treasure I want, silly boy. Take a look around." I
|
||
did. I couldn't believe my eyes! We were in the Bridal Suite!
|
||
There was a bed, the door was locked, and I was being cuddled
|
||
again."
|
||
Comms Plus! [magazine]
|
||
|
||
"I found that type-ahead didn't work properly."
|
||
Comms Plus! [magazine]
|
||
|
||
"The location descriptions are atmospheric, and also vital to
|
||
moving about the game as there is no "exits" command."
|
||
Comms Plus! [magazine]
|
||
|
||
"Shades has an emotional immediacy - MUD seems a somewhat austere
|
||
environment in which grand concepts are brought to grand conclusions."
|
||
PC Plus [magazine]
|
||
|
||
"Shades has a more light-hearted approach. It is a teddy bear
|
||
adventure. MUD manages to be rather serious until you meet some
|
||
practical joker: then the fun starts!"
|
||
Acorn User [magazine]
|
||
|
||
"Shades is a good place to start for the new player. It's friendly,
|
||
and fairly easy to get going."
|
||
ACE [magazine]
|
||
|
||
"First time users find it less daunting than MUD, while serious
|
||
adventurers may find it less enthralling."
|
||
PC Plus [magazine]
|
||
|
||
"If you are new to multi-user adventures, go for Shades. ... Once
|
||
you have mastered Shades, the dizzy heights of MUD wizardhood
|
||
still beckon."
|
||
Acorn User [magazine]
|
||
|
||
"Shades is very basic, having no real depth or imagination. What
|
||
little thought has gone into it has been wasted - who really wants
|
||
to play football in a fantasy game? The players themselves are
|
||
usually big whingers. They hate enthusiastic killers just as much
|
||
as they hate people who talk too much. However, where Shades wins
|
||
over MUD is how the game is actually managed. Ego seekers seem to
|
||
be pushed to one side, and everyone seems to know exactly where
|
||
they stand within the framework."
|
||
Wabit [player]
|
||
|
||
"Shades (and Trash) is left way behind in the technical fields
|
||
compared to (say) Avalon or Gods (I'll explain that: Avalon and
|
||
Gods have much better parsers, much better commands, and much
|
||
better things for immortals to do once they've made it). They
|
||
[Shades and Trash] were written when even single-user adventures
|
||
were in their infancy, and have stood the test of time remarkably
|
||
well. But now they look just a trifle run down and archaic."
|
||
Graeme [player]
|
||
|
||
"Shades has a more amateurish feel to it [than MUD2]."
|
||
Acorn User [magazine]
|
||
|
||
"The game itself is rubbish. It has no life or realism in it.
|
||
Role-playing is one thing, but that just wasn't believable. As for
|
||
the players, yes, they have got lots more [than MUD2]. The only
|
||
problem I found was that they didn't want to talk or interact more
|
||
than what they had to. Eventually I was kicked off by a wizard
|
||
for annoying too many people by chatting to them."
|
||
Wabit [player]
|
||
|
||
"Having all the players start out equal is a design principle.
|
||
Although it doesn't mean it can be achieved in practice, the mere
|
||
fact that the goal is unattainable doesn't mean we shouldn't
|
||
attempt to reduce the distance to it."
|
||
Neil Newell [author]
|
||
|
||
"My viewpoint is not that fighting is the lifeblood of the game -
|
||
it is an essential element, but just one facet of the whole
|
||
picture."
|
||
Neil Newell [author]
|
||
|
||
"The ultimate adventure multi-user game"
|
||
Micronet [slogan]
|
||
|
||
|
||
4.6 AberMUG.
|
||
|
||
Name: AberMUG
|
||
Importance: 2
|
||
Author(s): Alan Cox ("Anarchy"),
|
||
Jim Finnis, Leon Thrane,
|
||
Richard Acott, Ian Smith.
|
||
Location: (081) 863 6646
|
||
Pricing Structure: L6.50/month flat fee or
|
||
L65/year flat fee
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone.
|
||
|
||
Historical Notes:
|
||
Originally entitled AberMUD, a version was moved by Smith to Connect
|
||
(the IBM PC User Group conferencing system) in 1989. The name change was for
|
||
legal reasons, to avoid allegations that it was passing itself off as MUD.
|
||
|
||
Review, Summary and Quotes:
|
||
See AberMUD in the section on international MUAs.
|
||
AberMUG runs on a Compaq Deskpro 386/16 under SCO Xenix system V/386
|
||
2.3.1.
|
||
|
||
|
||
4.7 Avalon.
|
||
|
||
Name: Avalon
|
||
Importance: 2
|
||
Author(s): Yehuda Simmons ("Genesis"),
|
||
Daniel James ("Aldaron"),
|
||
Jon Baber ("Cornelius"),
|
||
Peter Evans ("Zaphod")
|
||
Location: Synergy
|
||
Pricing Structure: L0.25/hour or
|
||
L10/month flat fee or
|
||
L25/quarter flat fee or
|
||
L80/year flat fee or
|
||
L200 flat fee
|
||
|
||
Brief Description:
|
||
Arthurian/Odyssean, multi-skill, trading game.
|
||
|
||
Historical Notes:
|
||
Written by students in 1989. Originally on IOWA, but went independent
|
||
in 1990.
|
||
|
||
Review:
|
||
Avalon is a new MUA that has already attracted great attention in the
|
||
industry due to its departure from the traditional MUD1 mould. It is primarily
|
||
a role-playing system, where the game determines the skills available to
|
||
personae, rather than the players acquiring skills (eg. combat) themselves.
|
||
|
||
Indeed, skills are a very important feature of Avalon. The gameplay
|
||
works something like this: when players start, they are given a history of
|
||
training in eight listed skills. All told, there are over 30 such skills,
|
||
covering a wide range from perception to music, defence to riding. Personae may
|
||
have up to 17 skills each, although why 17 rather than some other figure isn't
|
||
made clear. Skills can be improved by use, and by learning them from other
|
||
players. By acquisition and use of skills, players may do things which earn
|
||
them money or gain them experience.
|
||
|
||
Experience is obtained by visiting new places, wandering around
|
||
exploring, and even by simply chatting. This contrasts with the usual MUA
|
||
scheme where points are obtained for finding treasure or performing specific
|
||
tasks. In Avalon, treasure may be sold for money - gold pieces - and used to
|
||
buy things. Almost anything can be bought, including houses, shops, taverns,
|
||
animals, weapons, food and drink. Personae may use certain skills to create
|
||
objects, eg. potions, which can be sold to other players for use on their
|
||
adventures.
|
||
|
||
It is easy to go up experience levels in Avalon, at least initially,
|
||
but it has many more levels than usual in MUAs so rising to a new level doesn't
|
||
mean much - it can happen just by talking to someone for long enough. There is
|
||
a MUD2-like task system to rise from the third-highest level ("ultimate") to
|
||
the second-highest ("demi-god") and highest ("god/goddess"). Avalon employs the
|
||
Gods system for its wizzes, with some modification in that gods/goddesses
|
||
cannot lose their powers once they have been obtained. Nevertheless, it is
|
||
still rather galling for many players to have to prostrate themselves in front
|
||
of other players if they are to advance in Avalon. The gods also earned an
|
||
early reputation for being heavy-handed and for ignoring new players.
|
||
|
||
The system of deities (of which their are currently eight) is
|
||
interwoven with that of skills. There are nine guilds, each of which is
|
||
devoted to a particular style of play, with primary and secondary associated
|
||
skills, a persona as head, and (usually) a deity as patron. Deities favour
|
||
different aspects of play, and players are encouraged to choose one as patron
|
||
that they may advance in their chosen skills more quickly, via the appropriate
|
||
guild.
|
||
|
||
There is some lack of forethought here in that to reach god level, a
|
||
persona must identify with and follow the tenets of some other god, and thus
|
||
when they become deified there will be two gods with roughly the same outlook,
|
||
so one of them must change so as not to be supernumerary. To change requires
|
||
alteration to Avalon itself, because at the moment it is built around a
|
||
balanced system of greek-like "god of the ..." constructs. After several
|
||
years, when perhaps twenty or thirty gods have accumulated, this will lead to
|
||
an inevitable fragmentation into a collection of over-specialised deities
|
||
without any having a wide enough brief to be attractive to players.
|
||
|
||
Game management is woven into the game, with a judicial system in place
|
||
allowing personae to deal with offenders. Whether this will function remains to
|
||
be seen - as with Federation II, most complaints will be about out-of-game
|
||
actions (carrier loss, program bugs) that will spoil the atmosphere if
|
||
discussed in a game context. Certainly, there have been problems: one of the
|
||
authors is rumoured to have got into an argument with a player and deleted the
|
||
entire persona file in a fit of temper.
|
||
|
||
Avalon is atmospheric, but the room descriptions show inexperience on
|
||
the part of their authors. The purple prose falls over itself to use every word
|
||
in the synonym library, and makes the mistake of telling players how they react
|
||
to the scene. This form of unnecessary embellishment extends into the rest of
|
||
the game, and can be very tiresome; for example, if you clap your hands it's
|
||
reported as being done "merrily" even if you did it in anger, or to call for
|
||
silence. The dialogue for learning new skills, although interesting at first,
|
||
is samey, hard-wired, and looks too automated. The text also needs some minor
|
||
polishing, eg. "a unworthy", "the principle currency".
|
||
|
||
Overall, the scenario feels patchy, with creatures from Tolkien
|
||
(dwarves, orcs) alongside cities from ancient Greece. There are a large number
|
||
of locations (1,600) compared to the small number of players it allows at once
|
||
(5 external lines). Some of this size may be explained by the fact that Avalon
|
||
incorporates some ideas from Mosaic, and thus has a collection of locations
|
||
arranged in grid fashion. This may also explain why you need a steed to travel
|
||
the distance between towns.
|
||
|
||
The magic (or magik) system is complex. Spells must be memorised, and
|
||
some require the chanting of appropriate words before they can be cast (using a
|
||
"chant" command - merely saying them won't work). A very bad move is that when
|
||
players are killed they don't start from scratch; instead, their spirit roams
|
||
the land shedding experience until another player reincarnates it. This
|
||
fosters co-operation and friendship, which is its intent, but it also means
|
||
personae are effectively unkillable, and that in the long run players are
|
||
pretty much guaranteed to make it to god if they have enough friends. Having
|
||
the game itself prevent unsuitable or troublemaking candidates from reaching
|
||
the top is one of the tenets of good game management.
|
||
|
||
Avalon has several innovatory features, such as a page-based "read"
|
||
command and a page/line-based "write", random-access style, and object creation
|
||
(within a tightly-controlled framework) by mortal personae. When you leave the
|
||
game, objects can be kept for when you restart (eg. that weapon you
|
||
commissioned from a smith), and you restart in the room from which you quit.
|
||
This means some objects can be kept unavailable for long periods if their owner
|
||
isn't playing. There are no resets. Shouts in Avalon get level-dependent (but
|
||
not gender-dependent) descriptions, which discourages newcomers from using this
|
||
method to communicate. Combat is non-automatic, which makes life hard for
|
||
people without macros or fast modems.
|
||
|
||
Avalon runs on an Archimedes, connected to modems via a multiplexer
|
||
programmed by Blane Bramble (Comms Plus! magazine's UK MUA reviewer). The
|
||
system crashes quite often, and has a reputation for never being up for very
|
||
long. The game itself uses a language called Hourglass, specially designed for
|
||
writing MUAs. It is highly flexible, although the authors' claims that "unlike
|
||
other multi-user game languages it allows the user complete freedom in the
|
||
nature of the system created" betrays a certain naivety; it may be true of
|
||
Slate, but it certainly does not apply to MUDDLE or some of the American
|
||
object-oriented definition languages now emerging.
|
||
|
||
To the beginner, Avalon is intimidating. This is no fault of the
|
||
players, more a consequence of the sheer amount of information presented. It
|
||
is almost as if reading a manual is necessary before play can begin.
|
||
Instructions on how to use simple commands, such as communication, are buried
|
||
deep in the help system. There are no automatic tours; newcomers have to rely
|
||
on a deity to show them around, which, of course, will thenceforth colour their
|
||
outlook in that god's favour.
|
||
|
||
Avalon actively promotes role-playing. It feels less of a MUA, more of
|
||
a single-player role-playing game such as the later ones in the Ultima series.
|
||
The other players are constrained by their skills, their patronage and the
|
||
requirement that they role-play, to such an extent that they can appear little
|
||
more than the mobiles which feature in SUAs. It is a worthy experiment,
|
||
nonetheless, and if Island of Kesmai can flourish under such limitations, so
|
||
can Avalon.
|
||
|
||
Summary:
|
||
Avalon is very deep and very broad, but not in the usual "physical"
|
||
sense applied to MUAs; instead, it is social aspects of play that it models.
|
||
There is a great amount of detail, but always the nagging thought that in the
|
||
main it's unnecessary, mere depth for depth's sake. The game would probably
|
||
function just as well were much of the system removed; the players would
|
||
certainly feel less like they were wearing straitjackets. In their keenness to
|
||
try anything and everything, the authors have expanded Avalon into a great
|
||
sprawl of ideas, some good, some bad, many unworkable, but all interesting. In
|
||
two or three years' time, it will probably be in the first rank of MUAs.
|
||
|
||
Quotes:
|
||
|
||
"Players may choose to worship the gods in the land, although quite
|
||
what good this will do depends on who you choose to worship."
|
||
Comms Plus! [magazine]
|
||
|
||
"The main thing that is different is the idea of skills, and being
|
||
able to learn different skills to different levels of competence.
|
||
This allows for every player to be different and an unknown
|
||
quantity."
|
||
Wabit [player]
|
||
|
||
"Implementation [of skills and object creation] is not quite how I
|
||
would like it to be, but it's a good start and a definite step in
|
||
the right direction."
|
||
Wabit [player]
|
||
|
||
"Most of the 'usual' role-playing skills will be implemented
|
||
(hiding, stealing, archery), as well as some more unusual ones
|
||
(juggling, tightrope walking)."
|
||
Comms Plus! [magazine]
|
||
|
||
"I really object to being told how I view the location. Besides,
|
||
it's stupid to have a description that states you "pause to survey
|
||
your surroundings" if you are legging it through the location, or
|
||
one where an old woman appears and disappears every time you do a
|
||
look... These little things really bug me!"
|
||
Wabit [player]
|
||
|
||
"A multi-user game's atmosphere is to a large extent formed by its
|
||
players, and Avalon wishes to encourage a tolerant and
|
||
constructive environment."
|
||
Hourglass Communications [promotional material]
|
||
|
||
"In five hours, no-one hardly said a word to me, despite the fact
|
||
that I tried on many occasions to chat."
|
||
Jhary [player]
|
||
|
||
"Avalon is not simply a multi-user game, it is a way of life, a
|
||
living world unlike anything that has existed before."
|
||
Hourglass Communications [promotional material]
|
||
|
||
|
||
4.8 Bloodstone.
|
||
|
||
Name: Bloodstone
|
||
Importance: 2
|
||
Author(s): Robert Muir, Andrew Pusey
|
||
Location: none
|
||
Pricing Structure: none
|
||
|
||
Brief Description:
|
||
Advanced MUD1 clone, fantasy setting.
|
||
|
||
Historical Notes:
|
||
Muir was originally a Shades player. With finance from Tony Cox, he
|
||
and Pusey designed a transputer-based MUA specialising in world modelling.
|
||
Named Bloodstone, it burst on the scene in 1989 in a flurry of advance
|
||
publicity, but wasn't launched for almost a year. It finally went on-line on
|
||
MicroLink, but disappeared after a few months with hardware, software and
|
||
contractual problems. The cost was L7/month flat fee (the equipment it ran on
|
||
cost over L20,000).
|
||
|
||
Review:
|
||
Bloodstone was the victim of its own arrogance. Its specifications
|
||
were so exciting that, had they been implemented in full, the authors would
|
||
have qualified for a Nobel Prize. It was to be vast, fast-moving, incredibly
|
||
detailed, and the MUA to end all MUAs. In the end, it was brought down by
|
||
implementation problems and the cold reality that profit from MUAs in the call-
|
||
charge dominated UK market is not great.
|
||
|
||
The driving motivation in Bloodstone, which worked in part, was
|
||
compositionality. Objects were made up of other objects, and these of others,
|
||
and so on until the author got bored. For example, human beings were made up
|
||
of 260 parts, including eyes, finger joints and so on, but excluding individual
|
||
hairs on the head. A rose bush was made up of roots and branches, with thorns
|
||
and flowers on the branches, the flowers being made up of a stamen and petals.
|
||
Although always present, such details were not always given, however: "some
|
||
flowers" or "many petals" would be described. In this respect, the game was
|
||
able to ensure that players weren't completely swamped with information.
|
||
|
||
Despite this level of detail, Bloodstone was intended to be set in a
|
||
continent with 12 separate countries, in which were towns and cities and 37
|
||
different races of creatures. All these would work independently, with players
|
||
being able to have jobs during the day and be family men at night. Female
|
||
personae could become pregnant and give birth nine months later to a child.
|
||
|
||
Mobiles were to have artificial intelligence (AI). Because of the way
|
||
bodies were made up of parts, it was possible to get eg. a broken arm in a
|
||
fight. A mobile might be able to figure out it needed a splint, and proceed to
|
||
make one. Getting this alone to work as a general principle would be worth a
|
||
PhD in AI...
|
||
|
||
There were initially 20 spells, including "polymorph" - change into a
|
||
different kind of creature. This, as a side effect, would allow communication
|
||
with other creatures of that kind (which seems unrealistic).
|
||
|
||
Everything was interlinked. If bricks were removed from a wall, it
|
||
might collapse, bringing the rest of the building down. Small-scale actions
|
||
could have large-scale effects. There are, however, well known problems in the
|
||
AI field of object representation concerning this kind of activity. Either the
|
||
programmer has to list explicitly all effects of players' actions (which is
|
||
difficult and tedious) or the game's interpreter can figure it all out
|
||
on-the-fly as it happens. This latter approach, where there are a set of
|
||
physical laws that are applied to everything that has moved after a command has
|
||
been executed, is workable but vulnerable; there can be long delays as effects
|
||
are propagated throughout the universe being modelled, and some effects may
|
||
take considerable time to dampen down and disappear. Pulling a petal off a
|
||
flower may seem innocuous, but if it makes you weigh just enough that the snow
|
||
bridge upon which you're standing collapses, and this in turn starts an
|
||
avalanche, there can be wide-scale devastation that is almost impossible to
|
||
sort out.
|
||
|
||
Bloodstone had a 25,000 word dictionary; this was quite a feat, but the
|
||
authors never made apparent which words were actually functional and which were
|
||
merely ignored. It is quite difficult to think of even 1,000 words that could
|
||
feasibly be of use in a MUA. Again, Bloodstone appeared to be going for
|
||
overkill in an effort to impress potential customers.
|
||
|
||
Originally, the game was intended to run on transputers, but apparently
|
||
these slowed it down. It finally ran on a custom-built 80386 machine running at
|
||
over 6 mips (but rather flakily).
|
||
|
||
Although there were plans for graphics-based clients on the Atari ST
|
||
and the Amiga, Bloodstone's normal display was rather poor. It didn't
|
||
word-wrap, and the text (built up from object descriptions) contained such
|
||
blunders as "a blood" and "it feels has a firm, warm texture".
|
||
|
||
Bloodstone was envisaged as a game of life, yet there lay its central
|
||
problem: it had no gameplay to speak of. It was a simulation to incredible
|
||
depth, but there wasn't really much that players could do, it was too
|
||
open-ended. Even given the extravagant claims its publicists made, it probably
|
||
could have been forgiven all but that.
|
||
|
||
Bloodstone was a grand concept, but doomed to failure. Its reliance on
|
||
compositionality ensured that it would be stuck in a morass of intricate inter-
|
||
relations between its components unless it sacrificed some of its depth (and
|
||
thus some of its claim to originality). Some application of AI techniques may
|
||
have alleviated the problem (eg. lazy evaluation - expand a rose object from a
|
||
template only when it is actually in use), but the best approach would probably
|
||
have been to represent objects at a higher level of abstraction. In the end,
|
||
depth is useless unless there's a reason for it. Bloodstone's depth didn't pass
|
||
this "so what?" test.
|
||
|
||
Bloodstone has been included in this review because although it is
|
||
currently down, it is not out, and it may return in the near future. Hopefully,
|
||
this time it will make less boastful claims, and advertise only what it does do
|
||
rather than what it could do given a team of thirty programmers and a Cray 2
|
||
for four years. It's a very nice idea, but the programmers set their sights too
|
||
high initially.
|
||
|
||
Summary:
|
||
Bloodstone is characterised by its almost unbelievable depth, which
|
||
dominates every aspect of it completely. It is known, however, by the conceit
|
||
of its advertising, the unlikeliness of its features ever being implemented,
|
||
and the contempt in which it held other MUAs.
|
||
|
||
Quotes:
|
||
|
||
"I see that Bloodstone has gone down the pan. And just as MicroLink
|
||
were about to 'start serious promotion'. Pity they didn't do that
|
||
when it started, or they may have been able to get more than 4
|
||
users on and brought in enough dosh to keep the thing alive."
|
||
Nigel Hardy [Sector 7 author]
|
||
|
||
"The game is revolutionary in that it is massive and has huge
|
||
expansion potential."
|
||
Popular Computing Weekly [magazine]
|
||
|
||
"If you pull a wing off a fly, that creature will be missing a wing
|
||
forever and will probably die."
|
||
Popular Computing Weekly [magazine]
|
||
|
||
"Mobiles are equipped with artificial intelligence and will
|
||
probably strap a broken arm into a sling."
|
||
Popular Computing Weekly [magazine]
|
||
|
||
"It looks set to take the lead in the multi-player game market."
|
||
Popular Computing Weekly [magazine]
|
||
|
||
"Reports from UK-wide testers were proving enthusiastic."
|
||
Comms Plus! [magazine]
|
||
|
||
"It combines all the necessary detail and commands to be able to
|
||
walk all over the opposition and should be sufficient to convert
|
||
players of Shades and MUD."
|
||
Popular Computing Weekly [magazine]
|
||
|
||
"One of the early gripes [with MicroLink] has been about the late
|
||
arrival of its multi-user games."
|
||
Comms Plus! [magazine]
|
||
|
||
"It puts everything else into the shade."
|
||
Derek Meakin [MicroLink chairman]
|
||
|
||
"We feel we have a powerful enough parser for anyone."
|
||
Robert Muir [author]
|
||
|
||
|
||
4.9 Empyrion.
|
||
|
||
Name: Empyrion
|
||
Importance: 2
|
||
Author(s): ?
|
||
Location: IOWA
|
||
Pricing Structure: free
|
||
|
||
Brief Description:
|
||
SF, multi-skill trading game.
|
||
|
||
Historical Notes:
|
||
Appeared on IOWA in 1990. Currently withdrawn from service.
|
||
|
||
Review:
|
||
Empyrion is another of the well-received new MUAs, a cross between
|
||
Avalon and Federation II. Its scenario is an underwater city of the future,
|
||
divided into districts called Hages. Each Hage is run by an administrator, a
|
||
position which may be occupied by a player. Administrators have a budget which
|
||
they can spend as they please. Players can leave the city (a crime under city
|
||
law) and explore the surface, which is in the grips of a sinister alien force.
|
||
From there, they can trade.
|
||
|
||
Trading gets players money, which they can spend on objects. Houses can
|
||
be commissioned, and are built over a period of time, so it's possible to go
|
||
and watch the construction engineers at their task. Like all IOWA games,
|
||
Empyrion has no sudden resets.
|
||
|
||
There is no conventional scoring system in Empyrion. Rather, it is
|
||
skills-based: players progress by acquiring and practising survival skills such
|
||
as gun combat, medicine, bribery and street-wiseliness. What they progress to
|
||
is not apparent; there are a collection of energy beings called "eternals" with
|
||
gamesmaster status, but how exactly one becomes an eternal - if indeed it is
|
||
even possible - is not clear.
|
||
|
||
Eternals are capable of shape-changing, and are worshipped as gods in
|
||
the city. They are able to create and alter rooms, objects, system messages and
|
||
puzzles on-line; little is built into the interpreter. In this sense, the game
|
||
is player-extensible, but only by selected players.
|
||
|
||
The city has a legal system run by the hage administrators and a group
|
||
called "the sandmen" (as in the movie Logan's Run). For breakers of city law
|
||
they can impose fines, brainwash out skills, or order executions. This is part
|
||
of playing Empyrion, and is not to be confused with game management - that's
|
||
handled externally.
|
||
|
||
As with Avalon, and increasingly in new MUAs, some objects can be
|
||
reserved for individual players and left in a safe place so that the next time
|
||
that player plays, the object is available. Despite its SF setting, Empyrion
|
||
does have a magic system, "the force" (as in the film Star Wars). Players
|
||
expend psi points using it and have to spend time "recharging" afterwards.
|
||
Because of its large scale, vehicles are commonplace in Empyrion to enable
|
||
players to move between places that distant from one another.
|
||
|
||
Empyrion runs on two machines, one for the game itself and one for
|
||
mobiles. The mobiles are therefore more akin to bots. They are written in
|
||
Prolog, and are supposedly able to learn.
|
||
|
||
Summary:
|
||
Empyrion is an interesting game combining many features shared by other
|
||
newish MUAs, but not indulging in them to excess. However, it is rarely
|
||
available at the moment.
|
||
|
||
Quotes:
|
||
|
||
"It certainly sounds good."
|
||
Comms Plus! [magazine]
|
||
|
||
"In Empyrion, practically everything is editable on-line by the
|
||
gamesmasters."
|
||
Confidential [magazine]
|
||
|
||
"Empyrion is a fascinating new game that should have Sci-Fi buffs
|
||
sitting on the edge of their chairs."
|
||
Confidential [magazine]
|
||
|
||
|
||
4.10 MIST.
|
||
|
||
Name: MIST
|
||
Importance: 2
|
||
Author(s): David Barham, Paul Goodjohn,
|
||
John Medhurst, Dave Morris,
|
||
Shaun Plumb, Paul Friday,
|
||
Michael Lawrie ("Lorry"),
|
||
Bret Giddings, Richard Thombs,
|
||
Adam Bird ("Orc"),
|
||
Simon Smith ("Boo")
|
||
Location: Essex University
|
||
Pricing Structure: free
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone.
|
||
|
||
Historical Notes:
|
||
Written using the Trubshaw and Bartle MUD1 interpreter, went live
|
||
Christmas 1987. Runs on Essex University's DECsystem-10 mainframe, but not for
|
||
much longer as the computer is shortly to be scrapped.
|
||
|
||
Review:
|
||
MIST is one of the several databases written by students for the MUD1
|
||
interpreter in its MUDDL language (NB: MUDDL is MUD1's definition language;
|
||
MUD2 uses a greatly different language, MUDDLE). MIST introduced many JANet
|
||
users to MUAs, and was worked on by a large number of students.
|
||
|
||
Unlike MUD1's original database, MIST uses the berserker option. This
|
||
makes for a fight-oriented game. Management is easy, however - whichever
|
||
student is in charge any particular year usually assumes draconian powers, and
|
||
it's not unprecedented to delete the entire persona file (which would not be an
|
||
option in a commercial game).
|
||
|
||
MIST is dated by its MUD1 interpreter and the weakness of the MUDDL
|
||
language. However, the age of the hardware upon which it runs is its final
|
||
executioner - Essex's DECsystem-10 will be switched off and melted down for
|
||
scrap sometime within the next few weeks.
|
||
|
||
|
||
Summary:
|
||
A large mish-mash of rooms by different authors bound together in an
|
||
heroic fantasy setting. A completely traditional, fun MUA.
|
||
|
||
Quotes:
|
||
|
||
"MIST doesn't have any rules as such, it's a pretty anarchistic
|
||
place as games of this type go."
|
||
Michael Lawrie [author]
|
||
|
||
"Rules for general behaviour are laid down by the wizards and you
|
||
would be well advised to follow them."
|
||
Michael Lawrie [author]
|
||
|
||
|
||
4.11 Mosaic.
|
||
|
||
Name: Mosaic
|
||
Importance: 2
|
||
Author(s): Pip Cordrey ("Pippin")
|
||
Location: none
|
||
Pricing Structure: none
|
||
|
||
Brief Description:
|
||
A MUA design methodology.
|
||
|
||
Historical Notes:
|
||
Originally known as Vector, Mosaic was first suggested several years
|
||
ago, but only in 1989 did it come to the fore after a talk by Cordrey at the
|
||
Adventure 89 convention. Some of its concepts are used in Avalon.
|
||
|
||
Review:
|
||
Mosaic is not a MUA itself; rather, it is an influential approach to
|
||
designing MUAs.
|
||
|
||
MUAs represent rooms as a network of nodes connected bidirectionally.
|
||
The central theme of Mosaic is that a better approach would be to use a
|
||
point-based co-ordinate system instead. What normal MUAs regard as a "room" in
|
||
Mosaic would be nothing more than a collection of points that share a common
|
||
name.
|
||
|
||
The primary advantages of a Mosaic system over normal MUAs are: room
|
||
descriptions can be generated automatically; interaction over distance is
|
||
possible; it is more realistic.
|
||
|
||
That viable room descriptions can be generated on-the-fly is not in
|
||
doubt. Work at Essex University established that "bookkeeping" information
|
||
(number of exits, large nearby buildings, views from windows) can be folded
|
||
into a piece of atmospheric text to produce readable complete descriptions.
|
||
However, this work was in a normal MUA environment, not in a point-based one.
|
||
A prototype of Mosaic ran into problems in that too much information was
|
||
provided to the players, with many objects visible some considerable distance
|
||
away. The solution it adopted was twofold: to provide a command whereby players
|
||
could restrict how far into the distance their "look" command proceeded; to
|
||
prioritise objects so that things like advancing dragons would be included in a
|
||
description and distant mud huts excluded. There was no command to set
|
||
priorities for each user, however, nor was there one to select the cut-off
|
||
point of priority totals above which no further information was given.
|
||
|
||
In Mosaic, the world is divided into 1m cubes. Each cube has a surface
|
||
type, eg. grassy plain, which determines how it is described. Objects can be
|
||
seen at any distance, but can be occluded: line-of-sight calculations and
|
||
adjustments for atmospheric conditions are done automatically. Descriptions
|
||
are player-relative, so players can not see what is immediately behind them
|
||
(there are objections to this aspect of "realism" - just because a player is
|
||
generally facing west, that shouldn't mean they can't keep glancing around and
|
||
picking up high-priority objects approaching from the east).
|
||
|
||
A big play is made of Mosaic's ability to reduce the amount of text
|
||
necessary for a MUA, however in some ways it increases it. Objects (which are
|
||
not made up of 1m cubes) need different descriptions depending on how far away
|
||
they are and the direction from which they're viewed; what looks like a house
|
||
from a distance may look like a pole from the side and look like a billboard
|
||
close up. Objects can also have different descriptions depending on the time
|
||
of day, whether they're inside or outside, and the lighting. So although Mosaic
|
||
requires less text for describing rooms, it needs more for objects.
|
||
Interestingly, there is no provision for describing objects on-the-fly based on
|
||
whatever properties they have.
|
||
|
||
Physical features in the game, eg. hills, can either be constructed
|
||
from unit blocks or calculated at run-time from (fractal?) planar functions.
|
||
Distant objects can be modelled by placing appropriate surfaces at the edge of
|
||
the game world, eg. the sun, clouds, and mountains.
|
||
|
||
Movement can be fine-tuned, so that a normal "north" command may move a
|
||
player 5m north, or 4m through marshland; a "run north" may be 10m and 8m
|
||
respectively, whereas "north very slowly" could be 1m in both cases. There is
|
||
great scope for combat in this system, since combatants can move around as they
|
||
fight, terrain advantage can be taken into account, and weapon length can play
|
||
a part - someone standing behind a bar holding a polearm would be unassailable
|
||
from even the most magic of swords. There would be no need to flee - players
|
||
would simply move away and hope their injuries weren't so great that they could
|
||
be caught again.
|
||
|
||
Cordrey's articles on the subject include some suggestions for player
|
||
properties. Although some of these are perhaps conceivably of use (height,
|
||
weight, build, weapon skills), others are rather eccentric (body temperature,
|
||
blood pressure, blood sugar level, endocrinic activity) and would simply get in
|
||
the way of playing the game. There are also suggestions for more accurate
|
||
physical modelling, such as handling gravity automatically, however at best
|
||
this would be a case of moving objects down until their z co-ordinate matched
|
||
that of a surface; questions of objects being overbalanced or knocked over by
|
||
having a new mass land on them are unlikely to be addressed because these are
|
||
currently research issues in AI robotics.
|
||
|
||
Mosaic, like MirrorWorld, is a one-concept system - everything revolves
|
||
around this 1m cube idea. In reality, though, it's less flexible than the
|
||
system employed by normal MUAs, since their nodes can be strung together in
|
||
arbitrary ways including a co-ordinate system, whereas Mosaic is held rigidly
|
||
to uniformally-sized blocks. Perhaps a better approach would be to overlay the
|
||
rooms in a normal MUA with a co-ordinate grid, thus gaining the best of both
|
||
worlds (Avalon, which has a Mosaic segment, may do this; a single-user version
|
||
of MUD1 released around 1987 certainly did).
|
||
|
||
Implementation of these ideas can need a good deal of computer power.
|
||
Line-of-sight calculations are required every time an object is moved, so its
|
||
new position may be reported to all players, and this can be very
|
||
cpu-intensive. The first implementation recalculated the entire database every
|
||
time an object was moved, to check for consistency, but this approach had to be
|
||
abandoned because it proved far too slow.
|
||
|
||
All in all, Mosaic is a neat idea but it's too restrictive and too slow
|
||
for MUA programmers' liking. However, in one respect it would be fantastically
|
||
successful - graphics. The co-ordinate system it envisages is precisely what
|
||
is required in a graphical MUA, and many of the problems that arise from
|
||
textual descriptions (eg. information overload) would disappear if the
|
||
information was represented visually. However, Cordrey is vehemently
|
||
anti-graphics, so no work has yet been done in this area.
|
||
|
||
Summary:
|
||
Mosaic is an idea with potential, and its employment in MUAs in
|
||
parallel with the traditional approach would be beneficial. However, until the
|
||
idea is taken up by MUA programmers other than the IOWA team, this is unlikely
|
||
to happen.
|
||
|
||
Quotes:
|
||
|
||
"You never know, we may change the face of tomorrow's adventuring."
|
||
Pip Cordrey [author]
|
||
|
||
"Not only should this form of system make games more realistic, but
|
||
it also means that games (especially combat) should become more
|
||
tactical."
|
||
Comms Plus! [magazine]
|
||
|
||
"The real advantage is that it is no longer necessary to sit
|
||
scratching ones head dreaming up room descriptions, the system
|
||
will do it for you. What is more, these descriptions will be
|
||
accurate."
|
||
Pip Cordrey [author]
|
||
|
||
"Mosaic really is a progression from the early free style, free
|
||
space tabletop game."
|
||
Pip Cordrey [author]
|
||
|
||
"In current MUGs, if two players both decide to get the same
|
||
object, the one who enters the command first gets it. With Mosaic,
|
||
the system can determine the distance to the object (and possibly
|
||
how quickly the player can cover the distance), and delay the
|
||
action accordingly.
|
||
Comms Plus! [magazine]
|
||
|
||
|
||
4.12 Prodigy.
|
||
|
||
Name: Prodigy
|
||
Importance: 2
|
||
Author(s): Blane Bramble ("Geolin")
|
||
Location: IOWA
|
||
Pricing Structure: free
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone, Ancient Britain setting.
|
||
|
||
Historical Notes:
|
||
Originally entitled Parody, but very recently rewritten from scratch
|
||
and renamed Prodigy (coinciding with the loss of Parody through hardware
|
||
failure).
|
||
|
||
Review:
|
||
Parody was a run-of-the-mill MUA set in "Wesarg", a mythical part of
|
||
pre-Christian Britain. Written in Slate, it was subject to all the limitations
|
||
of that language, and Blane Bramble, its author, decided to rewrite it as
|
||
Prodigy using a language of his own design. Although this will eventually make
|
||
the game much better, most of it doesn't yet work. Worse, the original Parody
|
||
game had to be taken away because of hardware problems, so at present there is
|
||
no MUA available containing the complete Parody universe.
|
||
|
||
In Prodigy, players choose a character class for their persona, one of
|
||
warrior, rogue, priest or mage (standard AD&D classes). There is no difference
|
||
at the top level for each class, which equates with wiz; players need 3,072,000
|
||
points to reach wiz, though - the highest yet seen in a MUA and probably
|
||
attributable to the "pinball scoreboard effect" of scaling all point values by
|
||
a large number so as to give the impression that players are doing better than
|
||
they actually are.
|
||
|
||
Experience points are gained by solving puzzles, or by finding objects
|
||
and selling them to a trader (ie. back to the game). Experience points can,
|
||
unusually for MUAs, be spent, either in the anachronistic casino (playing a
|
||
card game based on baccarat) or on spells. Later, experience points may also
|
||
be exchanged for goods in shops, eg. food. The ability to swap experience for
|
||
spells, though, gives a more interesting trade-off: players who do it will not
|
||
go up levels as quickly (because they spend some of their experience points),
|
||
however they may survive longer in the long term.
|
||
|
||
The magic system is not fully implemented, but the spells Prodigy has
|
||
at the moment are mainly combat-oriented, with no "blind" or "deafen" spells
|
||
(a hang-over from the original Slate implementation). However, it does have
|
||
its own unique spell, "charm", which stops its victim (usually the person who
|
||
cast it) from being attacked by mobiles for six seconds.
|
||
|
||
When finished, Prodigy will have 160 extra locations, more puzzles, and
|
||
more objects; Bramble has delegated editorial control to one of the players.
|
||
The database definition language it employs is under wraps, but although it is
|
||
better than Slate it clearly has its problems: everything is stored in memory,
|
||
which can quickly run out, and which has to be backed up to disc every so
|
||
often, causing long pauses while it happens. Furthermore, its implementation
|
||
is not all it should be - adding any data to memory slows the game down due to
|
||
its having more information to search. As is normal with a new implementation,
|
||
Prodigy is shaky at the moment and prone to bugs and crashes. Its spelling and
|
||
punctuation are in need of being proof-read.
|
||
|
||
Fights are novel in that players can use two weapons at once, but they
|
||
are ultimately fruitless activities because the worse that can happen if you
|
||
lose is a loss of 25% of your points. This makes attacking powerful players
|
||
unattractive - if you plan an ambush and beat them, they're still pretty well
|
||
as powerful and can thrash you on their own terms as often as they like at a
|
||
later date. That said, fights are complicated by weapons having different
|
||
properties: attack, defence, parry, speed and damage. They also have an aura
|
||
(ie. alignment), which if different to the player's own will cause a
|
||
degradation in performance. It is therefore essential in Prodigy to choose the
|
||
weapon that best fits your needs - more realistic than most MUAs.
|
||
|
||
Prodigy has parser capable of accepting adjectives on the object (eg.
|
||
"get tabby cat"), and it has a pronoun ("me"). It will auto-abbreviate names,
|
||
which are unique in the first three letters (Avalon does a similar thing to
|
||
four letters), so "Geolin" can be shortened to "Geo" in all cases. This would,
|
||
however, appear to limit quite drastically the number of readable persona names
|
||
Prodigy can accept.
|
||
|
||
Uncommonly among non-academic MUAs, Prodigy has its own in-built
|
||
mail/notes system as part of its command set. Almost invariably in other MUAs,
|
||
this function is carried out by an external program, being an activity not
|
||
conducive to maintaining atmosphere. Nevertheless, it does appear handy, and
|
||
may find its way into other MUAs after a while.
|
||
|
||
Summary:
|
||
Prodigy is an average MUA, pleasant enough but nothing special. It will
|
||
increase in popularity as it is fleshed out, particularly because its author is
|
||
the MUA correspondent for Comms Plus! magazine.
|
||
|
||
Quotes:
|
||
|
||
"Parody is a fascinating game to play."
|
||
Pip Cordrey [owner]
|
||
|
||
"The quickest way to get to Mage is to ignore spells completely, IF
|
||
you can survive without them!"
|
||
Pip Cordrey [owner]
|
||
|
||
"The story line is a strong one, and the senior players are
|
||
attentive and available."
|
||
Pip Cordrey [owner]
|
||
|
||
"'Oh good,' I hear you say. 'Maybe we'll see some serious
|
||
additions to the game with someone else writing.' But no - having
|
||
seen one of her puzzles it seems the game will continue in a
|
||
similar vein to its currently confused setting."
|
||
Blane Bramble [author]
|
||
|
||
"Memory is fairly limited on the current machine, and if the memory
|
||
limit is reached the game will probably flame-out (crash and
|
||
burn)."
|
||
Blane Bramble [author]
|
||
|
||
"If you are keen on fantasy and AD&D then you should investigate
|
||
this game."
|
||
Pip Cordrey [owner]
|
||
|
||
|
||
4.13 Quest.
|
||
|
||
Name: Quest
|
||
Importance: 2
|
||
Author(s): Phil Harling ("Amstar"),
|
||
Marcus Tyler-Moore ("Totty"),
|
||
Ady Parker ("Apollo"),
|
||
Ian Cumbers ("Legal"),
|
||
Pip Cordrey ("Pippin")
|
||
Location: IOWA
|
||
Pricing Structure: free
|
||
|
||
Brief Description:
|
||
|
||
|
||
Historical Notes:
|
||
Originally entitled Quest 1, written in 1986 by Harling, then in his
|
||
early teens. Rewritten in 1987 for an Amstrad 6128, and again for an SBS PC
|
||
clone. In this latest incarnation, it was ported to IOWA.
|
||
|
||
Review:
|
||
Quest is a game permanently in a state of never-progressing
|
||
development. It has around 300 rooms with more promised, and has had since
|
||
1988. Their descriptions are brief (often only one line), and there are
|
||
numerous incorrect spellings. Object descriptions are of a length that other
|
||
MUAs would use as their name, and they are folded together (eg. "You can see a
|
||
soggy snowball and a magic mushroom"). This all combines to make the game
|
||
rather unatmospheric.
|
||
|
||
The gameplay is clearly an attempt to rationalise the idea of rolling
|
||
resets. Instead of a man in a white coat, Quest is run by a computer-
|
||
generated wizard called Taliesin. He creates and recreates the world,
|
||
recycling treasure by placing it back in play. Points are scored by dropping
|
||
objects down a bottomless pit, or, for higher-level players, giving them to
|
||
Taliesin's apprentice. This mobile is supposed to be a comic figure, and will
|
||
either pass the treasure on to Taliesin for reprocessing, drop it, or give it
|
||
back to the player.
|
||
|
||
Quest claims to be the first MUA with gambling, since it has a system
|
||
where players can bet points on the results of gladiatorial combat in an
|
||
amphitheatre (although they can't themselves participate). When players do
|
||
fight, whoever is defeated will lose half their points if they were attacked,
|
||
or all their points if they started it.
|
||
|
||
As with most MUAs, players can die silly deaths in Quest, eg. by
|
||
falling from a great height. The standard practice in this event is to quit the
|
||
player from the game and to fine them a small percentage of their points
|
||
(possibly 0%). Quest makes them lose the number of points since they last did
|
||
an explicit "save" command, since it has no automatic saving of score. This
|
||
can irritate players, who object to having to type "save" every so often while
|
||
they are exploring.
|
||
|
||
Players in Quest can pick up objects, mobiles and each other. This
|
||
latter feature is generally regarded as inadvisable in MUAs except when
|
||
undertaken by wizzes, since it effectively renders a player captive and
|
||
immobile. Nevertheless, in Quest it is thought to be a pretty nifty trick.
|
||
|
||
It is possible to send messages from Quest to players in MirrorWorld.
|
||
However, given the overall shoddiness of Quest, prospective players will
|
||
probably be in MirrorWorld anyway...
|
||
|
||
Summary:
|
||
A shallow, narrow MUA that seems virtually abandoned by its programming
|
||
team. Were it given more attention it could be one of the better Slate games,
|
||
but as it is it's fossilised in a state of neglect.
|
||
|
||
Quotes:
|
||
|
||
"There are some nice touches to the game."
|
||
ACE [magazine]
|
||
|
||
"Along similar lines to MirrorWorld, the game has managed to
|
||
introduce ideas of its own, and so has avoided the problem of
|
||
being thought a MirrorWorld clone."
|
||
Comms Plus! [magazine]
|
||
|
||
"It certainly is a step onward from the original game he [Harling]
|
||
wrote, including some very imaginative features."
|
||
Pip Cordrey [owner]
|
||
|
||
"The thing that is most unique is that it has a strong storyline
|
||
that makes the whole universe plausible."
|
||
Confidential [magazine]
|
||
|
||
|
||
4.14 Realm.
|
||
|
||
Name: Realm
|
||
Importance: 2
|
||
Author(s): Martin Hardcastle
|
||
Location: CompuNet
|
||
Pricing Structure: L1.50/hour
|
||
|
||
Brief Description:
|
||
MUD1 clone, Tolkienesque.
|
||
|
||
Historical Notes:
|
||
Launched with a fanfare in late 1989, but little publicity since then.
|
||
Its 17-year-old author took two years to write it.
|
||
|
||
Review:
|
||
Realm is set in a fantasy world like that of Middle Earth, where a once
|
||
prosperous population has been devastated by natural disaster and overrun by
|
||
evil creatures. Players are humans, elves, dwarves etc., whose task is to amass
|
||
points in the usual treasure-finding/puzzle-solving/monster-killing fashion
|
||
until they reach the wiz level ("Immortal").
|
||
|
||
The game has a reputation for good, atmospheric descriptions, a usable
|
||
MUD2-style hierarchy of object classes, and a superbly detailed combat system.
|
||
Unfortunately, there is no guest account and you need to be a subscriber to
|
||
CompuNet to play it.
|
||
|
||
Realm runs on a 1mb Atari ST.
|
||
|
||
|
||
Summary:
|
||
A good, traditional MUA, but without the backing it properly deserves
|
||
and somewhat overpriced.
|
||
|
||
Quotes:
|
||
|
||
"For my money, one of the best multi-user games."
|
||
Comms Plus! [magazine]
|
||
|
||
"Realm is just the sort of game I'd hoped to see on CompuNet one
|
||
day. A true, traditional MUG in the style of MUD and Shades."
|
||
Alan Wright [player]
|
||
|
||
"I liked it because it is very fair to slow, stupid beginners like
|
||
myself."
|
||
Alan Wright [player]
|
||
|
||
"A world where magic works and heroes are as common as the monsters
|
||
they slay."
|
||
Martin Hardcastle [author]
|
||
|
||
|
||
4.15 Trash.
|
||
|
||
Name: Trash
|
||
Importance: 2
|
||
Author(s): Matthew Ward ("Ambushbug")
|
||
Location: Prestel
|
||
Pricing Structure: L4.80/hour 8am - 6pm
|
||
L1.20/hour 6pm - 8am
|
||
L19.80/hour on (0898) 100890
|
||
|
||
Brief Description:
|
||
Non-standard MUD1 clone, "humorous" setting.
|
||
|
||
Historical Notes:
|
||
With Shades' success, Neil Newell set up a company (Third Millenium
|
||
Systems) to design and market MUAs. The first product to appear was Trash,
|
||
written in 1989 using Newell's MUGICK language. Despite being on
|
||
Prestel/Micronet, it has not been a hit.
|
||
|
||
Review:
|
||
Trash was deliberately written to be funny. MUAs are meant to be
|
||
entertaining, so Trash goes all out to amuse with "wacky" descriptions and
|
||
"weird" premisses. Unfortunately, it tries too hard, and most of it really
|
||
isn't all that amusing.
|
||
|
||
The objective is to collect trash (as opposed to treasure) and dump it
|
||
in an atomic furnace. For this, the players receive credits which can be spent
|
||
on restoring stamina, buying things, or on psionic powers. Psionic powers are
|
||
intended to be an encouragement to role-players, so ones playing evil personae
|
||
might concentrate on increasing their telekinesis or pyrokinesis psionics,
|
||
whereas good personae might focus on a power like faith healing.
|
||
|
||
Although this may appear to be a standard MUA with just the names
|
||
changed (psionics=magic, trash=treasure, atomic furnace=swamp), there is
|
||
actually a fairly interesting structure lying beneath it. Players go up levels
|
||
not by accumulating credits, but by increasing their "promotional prospects".
|
||
By solving puzzles in the game, a player's promotional prospects are raised a
|
||
few percentage points. When the total reaches 100%, the player goes up an
|
||
experience level - there are 12 in all, the top being 'Lord/Lady'. Although
|
||
credits can be used to increase your chances of survival, they aren't intrinsic
|
||
to rising levels.
|
||
|
||
Because of this puzzle-centred outlook, and the fact that higher-level
|
||
players get no reward for solving easy puzzles, Trash should attract the more
|
||
serious players who like ordinary SUAs, rather than just pure MUA addicts.
|
||
However, its self-conscious humour tends to drive such people away.
|
||
Nevertheless, Trash does have a larger number of puzzles than is common in
|
||
MUAs, and ensures that players need to have solved virtually all of them before
|
||
they reach the top level.
|
||
|
||
The game does have some background information to justify why players
|
||
are performing their trash-seeking tasks, concerning endotropic levels of
|
||
small dimensions within the multiverse. These "small dimensions" are actually
|
||
pocket MUAs in the overall Trash scenario, and have a theme running through
|
||
them. Some are generic, eg. "Heavy Citadel of Metal" and "the Pyramid of
|
||
Tutan", but others poke fun at specific targets: "Shades of a land" spoofs
|
||
Shades; "Cabbages and Caves" does AD&D; "Off-Centre Earth" is Lord of the Rings
|
||
and "Starship Wantarise" is Star Trek.
|
||
|
||
So why hasn't Trash been as successful as expected? Part of the reason
|
||
is its gameplay - not everyone is an adventure fan, and if there's no
|
||
alternative to problem-solving then they won't play. However, the main reason
|
||
is its setting - the forced atmosphere of crazy (ie. unfunny) humour grates
|
||
after a few minutes, and the strange logic of the game is too much of a
|
||
departure from reality for many players to consider fair. It may seem a good
|
||
joke for players to get a spaceship from a spaceship tree, but it's not really
|
||
the first thing you'd look for if you wanted to undertake interstellar travel.
|
||
|
||
Trash runs an an IBM AT.
|
||
|
||
Summary:
|
||
A good, puzzle-oriented MUA with an interesting alternative to
|
||
convention experience points, totally ruined by an inappropriate scenario.
|
||
|
||
Quotes:
|
||
|
||
"With a name like that, no-one can prosecute it under the Trades
|
||
Descriptions Act."
|
||
[Traditional]
|
||
|
||
"The whole game is puzzle oriented, and takes one step closer to
|
||
being an adventure game for multiple players. Here, the
|
||
distinction between a MUG and a MUA becomes more pronounced."
|
||
Ace [magazine]
|
||
|
||
"The puzzles range from easy to incredibly annoyingly difficult."
|
||
Confidential [magazine]
|
||
|
||
"Trash is one of the strangest multi-user games around, combining
|
||
fire-breathing cabbages and inflatable hovercars with Matthew
|
||
'Ambushbug' War's own inimitable style and humour."
|
||
Third Millenium Systems [promotional material]
|
||
|
||
"Where else could you grow your own spaceship, meet fire-breathing
|
||
cabbages, teach machinery to hum in tune, cause pink blancmange to
|
||
rain from the sky, clamber through a giant statue and drive around
|
||
in an inflatable hovercar - while clearing up rubbish!?"
|
||
Third Millenium Systems [promotional material]
|
||
|
||
"Couple the puzzles with large doses of humour and you get a game
|
||
that's both satisfying and highly enjoyable."
|
||
ACE [magazine]
|
||
|
||
"Anything and everything may happen in the game, and though there
|
||
is always a certain logic in the background it may not be easy to
|
||
find."
|
||
Confidential [magazine]
|
||
|
||
"Trash has been MUGICK's first big challenge, and I'm very pleased
|
||
with the results. Matt has really made MUGICK do some very strange
|
||
things indeed!"
|
||
Neil Newell MUGICK [author]
|
||
|
||
|
||
4.16 Void.
|
||
|
||
Name: Void
|
||
Importance: 2
|
||
Author(s): Clive Lindus ("Dirk")
|
||
Location: (0903) 700737
|
||
Pricing Structure: free
|
||
|
||
Brief Description:
|
||
Non-standard MUD1 clone, multi-setting.
|
||
|
||
Historical Notes:
|
||
Lindus was a player of Zone, who became disillusioned with it and
|
||
decided to write his own alternative. Void was premiered two years later at the
|
||
Adventure 89 convention, and was launched in 1990.
|
||
|
||
Review:
|
||
Void, like Trash, is a multi-setting game. Its linking scenario is that
|
||
reality rifts are being caused by the construction of an intergalactic
|
||
throughway, and that players can fall through these rifts into parallel worlds.
|
||
At present, Void consists of 450 rooms split into 9 environments (with another
|
||
due shortly) including a fairground, a school, an ice palace, Dodge City in the
|
||
wild west, and Narnia. This idea of connecting popular milieux together in one
|
||
consistent system has gained currency in face-to-face role-playing, and will
|
||
probably become one of the next fads in MUAs, too.
|
||
|
||
Everything in Void is there as an aid to role-playing. It is not
|
||
really a game, since there is no real goal; instead, it is a framework to
|
||
promote imaginative interaction between players. There is, for example, no
|
||
combat, and thus the speed at which players progress through its twelve levels
|
||
is dependent directly on the amount of time they invest in accumulating points.
|
||
Alignment is explicit, either good or evil, and is not monitored by the game
|
||
(Avalon, on the other hand, determines alignment by what players do, not by
|
||
what they say they'll do).
|
||
|
||
The emphasis on role-play is a pity in one way, because Void actually
|
||
has quite a good game system underlying it. Players' stamina decreases with
|
||
time, and is replenished by food and drink. Magical power, on the other hand,
|
||
increases over time and is reduced by the use of spells. Spells for each player
|
||
are kept in that player's personal spellbook, and even at the highest level
|
||
(arch angel or demon lady/lord, depending on alignment) not all spells are
|
||
available. Thus, other players are unknowns - a rather attractive and realistic
|
||
idea. One-off spells can be obtained by reading appropriate scrolls.
|
||
|
||
Points are of two types, magical and social. The former correspond
|
||
with points in other MUAs, the latter are just things that players get a few of
|
||
each week to give to their friends - there is no gameplay reason for having
|
||
them. Magical points are obtained in Gods-like fashion by offering them to the
|
||
ruler (ie. creator - usually an ex-Zone player) of the world you're in at the
|
||
time, at some appropriate location.
|
||
|
||
Void has more depth than you'd expect - it can handle smells, for
|
||
example - but it is selective in that interaction between players is handled in
|
||
a far more detailed fashion than the rest of the game. It has, for example, a
|
||
modern switch facility, so that a string containing, say, "/Fred" will expand
|
||
to "Fred" for everyone except Fred, in which case it expands to "you". This can
|
||
be used to good effect in emotion commands, eg. "Growl at /Fred".
|
||
|
||
The reason for this degree of attention to inter-persona messaging is
|
||
because it is Void's raison d'etre - the whole point of playing is to role-play
|
||
in imaginative ways with other players. Some of it is sexual, but on the whole
|
||
it is good-natured and fun, rather than the sometimes sordid behaviour which
|
||
goes on in Zone. A side effect is that some desirable commands usually left
|
||
out of MUAs are present in Void for effect - "dress" and "undress" are there,
|
||
which means "wear" is also present and is distinct from "get". Cash is part of
|
||
the game, and can be spent on various services, such as the "ogram" (sending a
|
||
message to another player by means of a transient messenger, eg. a kissogram).
|
||
Perhaps surprisingly, perhaps not, Void has a larger proportion of female
|
||
players than most MUAs.
|
||
|
||
There is some humour written explicitly into the game, which can be
|
||
intrusive. Players can create their own prefixes, although there's no problem
|
||
with that because virtually anything they choose can be fitted into the
|
||
scenario, and even misspellings only add to the general feeling of fun.
|
||
|
||
Player names can be abbreviated to minimum uniqueness, although there
|
||
are problems when this conflicts with command names, and when other players
|
||
enter whose entire name is someone else's minimum. Void's players form a
|
||
small, tight-knit yet gregarious community, however, and if people do mess it
|
||
around they can usually be persuaded in friendly fashion to be a little more
|
||
thoughtful. Whether that would be possible with a larger user base seems
|
||
unlikely, though.
|
||
|
||
There is a bulletin-board in Void that can be accessed from within the
|
||
game. Normally, this would be too dangerous for players to use - while they're
|
||
in the BB, their persona could be being attacked. However, since Void has no
|
||
fights, it's safe to have one there.
|
||
|
||
Void has an unfriendly rivalry with Avalon, which it sees as poaching
|
||
its players - the game was deserted for a time when Avalon came out, and is
|
||
only now recovering due to Avalon's fragility. Some of Avalon's programmers
|
||
and gods are regarded as particularly arrogant by Void stalwarts.
|
||
|
||
Void is hard-coded in Pascal, with text and object/room definitions
|
||
written externally in a simple database definition language. It has just four
|
||
external lines, and runs on two IBM ATs.
|
||
|
||
Summary:
|
||
Void is really little more than a virtual reality to encourage
|
||
role-playing, often of the flirtatious type but by no means restricted to that.
|
||
With some concessions to gameplay and a few puzzles, it could really get to be
|
||
quite good, however its author, Clive Lindus, seems happy with what he has - a
|
||
light piece of variety with a warm nose.
|
||
|
||
Quotes:
|
||
|
||
"The availability of different realms is an interesting alternative
|
||
to offering several different games."
|
||
Comms Plus! [magazine]
|
||
|
||
"There are quite a few touches of humour in the game."
|
||
Comms Plus! [magazine]
|
||
|
||
"I like it! Wonderfully inventive and atmospheric."
|
||
Lizandith [player]
|
||
|
||
"The main idea of the game is enjoyment, and how you achieve this
|
||
(as long as it doesn't stop someone else enjoying themselves) is
|
||
up to you."
|
||
Void [promotional material]
|
||
|
||
"I try to take a back seat and let players get on with
|
||
role-playing. The best way is for me to play as well. I think all
|
||
this "I'm the coder" rubbish puts people off."
|
||
Clive Lindus [author]
|
||
|
||
"This game is truly run for the players: no charge to play, and
|
||
relying on players' ideas to improve it. Before you worry about
|
||
Avalon, spare a thought for Void - I think it deserves its fair
|
||
quota of players as well."
|
||
Clive Lindus [author]
|
||
|
||
|
||
4.17 Zone.
|
||
|
||
Name: Zone
|
||
Importance: 2
|
||
Author(s): Chris Butterworth ("Gandalf")
|
||
Location: Lap of the Gods
|
||
Pricing Structure: L0.575/hour or
|
||
L11.50/month flat fee
|
||
|
||
Brief Description:
|
||
Non-standard MUD1 clone, debauchery setting.
|
||
|
||
Historical Notes:
|
||
Butterworth was playing Shades when another player suggested that
|
||
someone should write an adult MUA. Zone was finished in 1987, and went live
|
||
independently (with only two external lines). In 1988, it moved to the Lap of
|
||
the Gods system.
|
||
|
||
Review:
|
||
Zone is short for Erogenous Zone. It is a MUA deliberately written to
|
||
be "adult" and controversial, and succeeds admirably in both areas:
|
||
over-reaction by BT to the threats of self-styled "moral guardians" could
|
||
eventually lead not only to the removal of Zone from the telephone network, but
|
||
also of every other MUA. Zone could then use its notoriety to flourish abroad,
|
||
but most other MUAs would simply die. That Zone will best succeed in the long
|
||
run by annoying the anti-pornographic lobby and getting banned perhaps
|
||
explains its stalwart refusal to make all but the most token gestures towards
|
||
ensuring that people aren't offended.
|
||
|
||
In Zone's case, at least originally, it was intended to be
|
||
controversial only in that it was thought-provoking; more cynical approaches to
|
||
generate publicity by explicit lewdness had been suggested, however - most
|
||
notoriously CompuNet's now-abandoned After Midnight project. Zone has given way
|
||
to pressure to a minor extent in that it now asks players to state their age,
|
||
and won't let them play if they say they're under 18; however, it has no way of
|
||
verifying that people are telling the truth, and there have been suggestions
|
||
that the question could really be intended as more of a gimmick to entice new
|
||
players than as a demonstration of Lap of the Gods' responsibility.
|
||
|
||
The game itself (and it is a game) is set in an old mansion, its
|
||
grounds, and a temple (dedicated to Sappho, a Greek poetess whose behaviour
|
||
gave rise to the word "lesbian"). Compared to other MUAs, Zone has a small
|
||
database and few items of treasure. Points can be scored by taking objects to
|
||
the temple altar and offering them to Sappho, but the main way for players to
|
||
increase their score is to do just that - score with the other players.
|
||
|
||
Zone has a command "make love to ... ". Players have to get into the
|
||
right mood first by use of "cuddle" and "kiss" type commands, and the process
|
||
can be speeded up by consuming alcohol. Points are awarded depending on
|
||
location, participants, deflowering virgins, and who issued the "make love"
|
||
command. If a persona is being made love to and doesn't want to be (ie. is
|
||
being raped), there is a "stop" command - but it costs points to use.
|
||
|
||
Lovemaking uses up stamina, which can be recovered by consuming food
|
||
and drink. Alcohol intake can have advantageous effects, but too much will
|
||
cause disorientation, and, beyond that, death. MUD2 has a more complete
|
||
treatment of alcoholic beverages (and, since it deals with liquids properly,
|
||
allows drinks to be diluted), but there is no advantage gained by drinking in
|
||
that game. In Zone, it's practically mandatory.
|
||
|
||
There are twelve levels, the top being master/mistress. There are
|
||
arch-wizzes for game management purposes, although since mortals can do pretty
|
||
well everything except swear in Zone their position isn't very taxing. A nice
|
||
touch is that the game leaves its own messages of congratulations on the Zone
|
||
bulletin-board when someone reaches master or mistress. Although there is no
|
||
combat in Zone, players can lose points by seducing or being seduced by a
|
||
player of a much lower level. From a gameplay viewpoint, then, lovemaking is
|
||
Zone's equivalent of combat.
|
||
|
||
Although Zone is a MUA in the traditional sense, these aspects of it
|
||
have been neglected in favour of its role-playing side. New objects are added
|
||
occasionally, but as props rather than as tools or treasure. For example,
|
||
kittens are a recent addition to Zone, but there's no way to score points from
|
||
them. Other objects have shared a similar fate. This is a shame, because,
|
||
like Void, Zone has some nice touches. Its parser is capable of distinguishing
|
||
between "drink cocktail" (meaning all objects present of class cocktail) and
|
||
"drink a cocktail" (meaning just one cocktail). Furthermore, it doesn't execute
|
||
all the bindings at once: there's a time delay. Thus, if you "drop all" and
|
||
then move after two objects have been dropped, the remainder of the "drop all"
|
||
will be abandoned.
|
||
|
||
Although shallow in areas of gameplay, Zone provides many facility
|
||
which can promote role-playing by the players. As well as "dance with ... ",
|
||
"dress", "undress" and "hold hands with ... " commands, Zone has the latest
|
||
switch feature in its strings (as in Void, but with possessives handled too).
|
||
Magic is also like Void's, with spells costing magical power, and magical power
|
||
replenishing with time. It has two first-level spells, "where" and "summon";
|
||
"summon" doesn't work on mobiles as they follow set paths when they move, and
|
||
would therefore become lost if derailed.
|
||
|
||
Atmosphere is therefore all there is in Zone. The players, and the way
|
||
they choose to interact, are the only reason for playing it - as a game, it's
|
||
very thin. However, that makes it very vulnerable: 1990 has seen many of Zone's
|
||
customers departing for Void. They can't be lured back, because this kind of
|
||
sexual role-playing is virtually database-independent, and Void has a major
|
||
advantage over Zone in that it's free. The only way that Zone can survive in
|
||
the long term is by having more publicity than Void (eg. switching to the
|
||
Playboy bulletin-board), or by dropping its charges.
|
||
|
||
Zone is written in SuperBasic and runs on a Thor (a Sinclair QL clone
|
||
with 3<>" discs).
|
||
|
||
Summary:
|
||
There is definitely a market for games like Zone, and a well-written
|
||
MUA along those lines could attract a large number of players. However, the
|
||
large networks won't touch it because of the moral backlash of so doing, which
|
||
could be expected from almost every pressure group in the country - religious,
|
||
social, political, academic, whatever. Whether this is fair on Zone is not for
|
||
this review to determine, however it would certainly be a gross error to tar
|
||
all MUAs with the same brush.
|
||
|
||
Quotes:
|
||
|
||
"In Zone, the idea is to make love, not war."
|
||
Lap of the Gods [promotional material]
|
||
|
||
"It is friendly in the Zone - make no mistake about it. The nature
|
||
of the game dictates that all players interact to a great degree
|
||
after all!"
|
||
Ace [magazine]
|
||
|
||
"I talked to a teenage girl who said that she had never been
|
||
pressurised into participating in anything in Zone."
|
||
Comms Plus! [magazine]
|
||
|
||
"Fi [a female Federation II player] wasn't very impressed with
|
||
Zone's being oriented around sex, rather than its being a
|
||
side-line as it is in some other games. We wondered if perhaps
|
||
young people came away from Zone with inappropriate ideas about
|
||
relationships?"
|
||
Comms Plus! [magazine]
|
||
|
||
"In the first 6 hours of being on-line, the game had a player
|
||
logged in for 5.75 hours. ... Over the next month, the players
|
||
proved that even a game with 65 rooms and a trivial amount of
|
||
treasure could be popular."
|
||
Chris Butterworth [author]
|
||
|
||
"Since some people are a little touchy about the subject of making
|
||
love, you must be 18 or over to play this (and not touchy)."
|
||
Lap of the Gods [promotional material]
|
||
|
||
"(Almost) in the words of one famous MUG - 'You haven't lived until
|
||
you've screwed in Zone'!"
|
||
Jhary [player]
|
||
|
||
"[It is an offence to send] by means of a public telecommunications
|
||
system a message, or other matter, that is grossly offensive or of
|
||
an indecent, obscene or menacing character."
|
||
[Section 43.1(a), Telecom Act 1984]
|
||
|
||
"British Telecom is concerned about the use to which a network is
|
||
put but it is not the guardian of the nation's morals."
|
||
BT spokesman [quoted in Popular Computing Weekly magazine]
|
||
|
||
"The whole process is a product of the state of arousal of the
|
||
players, how drunk they are, and the state of their undress."
|
||
Ace [magazine]
|
||
|
||
"We are certainly going to go down this [on-line pornography]
|
||
route when we have cleared some of the other things off the lines.
|
||
At the moment, the government is just washing its hands of this
|
||
sort of thing."
|
||
Terry Lewis [MP for Worsley]
|
||
|
||
"The game is ADULTS ONLY, as it involves large amounts of drinking
|
||
and sex - which can make for quite funny games. A bit weird to get
|
||
used to..."
|
||
Comms Plus! [magazine]
|
||
|
||
"It is NOT a dating agency, and anyone using it as such faces ...
|
||
legal action."
|
||
Lap of the Gods [promotional material]
|
||
|
||
"On-line porn is freely available to youngsters."
|
||
Headline in Popular Computing Weekly [magazine]
|
||
|
||
|
||
4.18 Chaos World of Wizards.
|
||
|
||
Name: Chaos World of Wizards
|
||
Importance: 3
|
||
Author(s): Pip Cordrey ("Pippin"),
|
||
Nat Billington ("Natso"),
|
||
Lorenzo Wood ("Penfold"),
|
||
Phil Harling ("Amstar"),
|
||
? ("Esoniq"),
|
||
? ("Birax")
|
||
Location: IOWA
|
||
Pricing Structure: free
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone with facilities for all players to create rooms and
|
||
objects.
|
||
|
||
Historical Notes:
|
||
Went live on IOWA in mid-1990.
|
||
|
||
Review:
|
||
Chaos World of Wizards (or Chaos for short) is what Pip Cordrey terms a
|
||
MUPEG - a 'multi-user player-extensible game'. By that, he means it is a
|
||
normal MUA except that the players have the ability to create their own rooms
|
||
and objects. Although this is the main type of MUA available on the academic
|
||
networks, few games in the UK industry work that way. As usual for games on
|
||
IOWA, a claim is made that the idea originated there, and that those games
|
||
which do provide facilities for players to add rooms are taking on board IOWA's
|
||
suggestions. In actuality, the notion is not new: the second version of MUD1
|
||
had it back in 1979.
|
||
|
||
Chaos is in its early stages at the moment, and is therefore fragile
|
||
and incomplete; however, even when it is finished it is likely to be very
|
||
shallow and not especially broad. A manual for its design language is promised,
|
||
but at present the only information available is the rather limited help coded
|
||
into the MUA itself. This shows that rooms and objects have two buffers, for
|
||
long and short descriptions. One buffer is selected, and text is appended to
|
||
it a line at a time. A "clear" command will empty a buffer, but there are no
|
||
other editing commands. When both buffers are full, the player can either
|
||
"makerm" or "makeobj". Judging by the small number of commands listed, it seems
|
||
that the on-line definition language works by currying object types into the
|
||
commands, eg. "killrm" works on rooms but not objects. This implies that the
|
||
system makes a fundamental distinction between rooms and objects, and thus is
|
||
both inflexible and limited in the long run.
|
||
|
||
Given that this is the central feature of Chaos, it is surprisingly
|
||
weak. The only property of an object that can be set is its value, and
|
||
therefore the only use objects can have at present is as treasure. There are
|
||
no instructions on how to link rooms together, but there is a "rmexit" command
|
||
mentioned which may do it. All these features, and many more, are present in
|
||
MUD2; the two ways that Chaos differs are that objects are created permanently,
|
||
and that anyone can create them, even novices.
|
||
|
||
Because the game is in its infancy, much of the hype surrounding it is
|
||
of the "eventually, you'll be able to..." kind. Some of these claims are
|
||
reasonable, but others show a deep misunderstanding of how people play MUAs.
|
||
Chaos is envisaged as combining the object-creation part of a MUA with the
|
||
actual playing of the game. Thus, players can fight one another
|
||
conventionally, but will have to create any weapons themselves. They can create
|
||
spells to use against one another, and design counter-spells for defence.
|
||
Unfortunately, all this is idealistic nonsense: either the spells or weapons
|
||
will all be of maximum devastation, or there will be a limited number of
|
||
predefined types which players can combine in strictly determined ways. The
|
||
suggestion that players will willingly create low-damage weapons so that they
|
||
can role-play with them better is ludicrous - some players may do that, but it
|
||
only takes one not to and the whole game is compromised.
|
||
|
||
Cordrey sees the game as evolving, unlike TinyMUD, by introducing a
|
||
form of meta-combat where players can destroy or take control of one another's
|
||
creations. This seems a suitably grand thing to do, but it reduces the MUA to a
|
||
simple strategy game in a godlike setting. It also makes the game very
|
||
difficult for newcomers who wish to build their own rooms yet are powerless
|
||
against the might of long-standing players. People will also find it difficult
|
||
to play the game like a normal MUA if such large-scale events are happening all
|
||
the time, especially if they can't take part in them at that level.
|
||
|
||
There is no requirement that Chaos rooms are all from the same milieu,
|
||
so SF worlds can coexist with fantasy ones. This is attractive, but not when
|
||
objects from those worlds cross over - a SF weapon against a roman shortsword
|
||
would be no contest, for example. Some of the other suggestions, eg. that
|
||
players should create room complexes and then play in them normally, are also
|
||
naive - the urge to cheat is too strong. Besides, if people wanted to do that
|
||
then they'd be better served by a SUA-design program, of which many are on the
|
||
market.
|
||
|
||
Finally, Chaos is promised a means by which players will be able to
|
||
create mobiles, program them, and give them their own personalities. Like
|
||
spell-creation, this involves writing program code, and that involves either
|
||
highly advanced exception-handling or completely infallible programmers.
|
||
Unfortunately, neither solution is likely to be available.
|
||
|
||
Chaos World of Wizards runs on a Sun workstation.
|
||
|
||
Summary:
|
||
Allowing complete novices to create rooms is a dubious enough activity
|
||
at the best of times. The way Chaos hopes to merge such activities with those
|
||
of normal MUA-playing dooms it to failure. Its ideas are attractive, but fly in
|
||
the face of reality. Some good will come out of it, for example talented
|
||
writers will probably emerge; however, without violent changes to its basic
|
||
premisses, Chaos will burn itself out after a couple of years of intensive use.
|
||
|
||
Quotes:
|
||
|
||
"As well as a peaceful distraction from the mayhem of playing a
|
||
'real' MUG, Chaos should be an interesting long-term project as
|
||
the game unfolds in the way the players themselves wish."
|
||
Comms Plus! [magazine]
|
||
|
||
"One of the problems with MUPEGs is that they become disjointed and
|
||
dog-eared if not adequately controlled. Some of the games now have
|
||
a committee which authorises players to link their particular
|
||
development area with the body of the game."
|
||
Pip Cordrey [owner]
|
||
|
||
"If this [acquiring other players' creations] is well implemented
|
||
it could make Chaos extremely interesting as alliances shift and
|
||
diplomacy replaces treasure-hunting."
|
||
Comms Plus! [magazine]
|
||
|
||
"Since I first introduced the idea and later wrote about it in
|
||
Confidential, a number of traditional MUGs have adopted some of
|
||
the ideas and are introducing MUPEG-like features."
|
||
Pip Cordrey [owner]
|
||
|
||
|
||
4.19 Rock.
|
||
|
||
Name: Rock
|
||
Importance: 2
|
||
Author(s): Phil Fox
|
||
Location: Essex University
|
||
Pricing Structure: free
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone in a Fraggle Rock setting.
|
||
|
||
Historical Notes:
|
||
The first game written for the MUD1 interpreter by someone who didn't
|
||
work on MUD1 itself, around 1983.
|
||
|
||
|
||
Review:
|
||
Rock is 100 rooms of fantasy set in the Fraggle Rock milieu. It
|
||
includes most things present in the TV series, along with some rather inventive
|
||
weaponry that stretched MUDDL to its limits (eg. an electric drill you make
|
||
yourself out of various components found lying around).
|
||
|
||
Rock was lost for several years, but was discovered on some ancient
|
||
back-up tapes and reconstructed.
|
||
|
||
For further details on MUDDL, see the review of MIST.
|
||
|
||
Summary:
|
||
Small, quirky and surprisingly violent game in a fun (but unlicensed)
|
||
setting.
|
||
|
||
Quotes:
|
||
|
||
"Rock is based on ITV's Fraggle Rock, and is generally regarded to
|
||
be impossibly deadly!"
|
||
Micro Adventurer [magazine]
|
||
|
||
"Even at Essex University, different types of MUD have sprung into
|
||
existence, with Rock being the first 'unofficial' MUD."
|
||
An Introduction to MUD [book]
|
||
|
||
|
||
4.20 Sector 7.
|
||
|
||
Name: Sector 7
|
||
Importance: 3
|
||
Author(s): Nigel Hardy ("Quinch")
|
||
Location: (081) 952 5128
|
||
Pricing Structure: free
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone, cyberpunk setting.
|
||
|
||
Historical Notes:
|
||
Demonstrated at Adventure 89 as Dark City, it was originally an
|
||
experiment in MUA-writing. It presently runs on the author's bulletin-board,
|
||
but as a SUA as the system has only one external line.
|
||
|
||
Review:
|
||
Sector 7 was written in the three weeks prior to the Adventure 89
|
||
convention. Its atmospheric cyberpunk setting gained it many admirers, despite
|
||
the fact that at the time it had no fighting, no mobiles, no way to progress,
|
||
and few puzzles.
|
||
|
||
The main purpose of writing the game was to learn how it could be done.
|
||
Hardy had no wiz experience in any games, and used Shades as a model.
|
||
Nevertheless, Sector 7 has some features beyond Shades' capabilities, including
|
||
on-line editing of objects and rooms.
|
||
|
||
Sector 7 is written in GFA Basic and runs on a 1mb Atari ST with a 40mb
|
||
hard disc, multiplexed by an IBM PC.
|
||
|
||
Summary:
|
||
A shallow, narrow, simple game that convincingly demonstrates both how
|
||
easy a basic model MUA is to write, and the enormous potential of a cyberpunk
|
||
setting.
|
||
|
||
Quotes:
|
||
|
||
"It was originally written as an exercise for myself, to see if I
|
||
could do it; the feedback at Adventure 89 where I demoed it was
|
||
enough to keep me working on getting it going."
|
||
Nigel Hardy [author]
|
||
|
||
"It can be used as a simple introduction to MUGs which won't cost
|
||
much."
|
||
Nigel hardy [author]
|
||
|
||
|
||
4.21 Other MUAs.
|
||
|
||
The MUAs presented in this subsection exist, but little is known about
|
||
them - a flier, a message on a bulletin-board, a magazine article. They are
|
||
included here in case they reappear in the near future. None were available for
|
||
playtesting at the time of this report's writing.
|
||
|
||
Only those parts of the review header which can be filled in are given.
|
||
All are of the third rank in importance.
|
||
|
||
|
||
Name: AMP
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone.
|
||
|
||
Historical Notes:
|
||
One of the first (if not the first) MUAs written by a MUD1 player.
|
||
Last seen at Adventure 89, but probably still running happily somewhere.
|
||
|
||
Review:
|
||
AMP's present location is unknown, and there is no publicity material
|
||
concerning it.
|
||
|
||
AMP pioneered the use of shape as a property of objects to determine
|
||
whether they fit inside containers.
|
||
|
||
Summary:
|
||
Friendly (if dated) MUA with good depth.
|
||
|
||
|
||
Name: Daemon Adventure
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone, multi-setting.
|
||
|
||
Historical Notes:
|
||
Only known appearance - Adventure 89.
|
||
|
||
Review:
|
||
The flier for Daemon Adventure describes it as one of a series of MUAs,
|
||
based on 10 different play areas combined together to form a games world with
|
||
over 2,000 locations. These include Arthurian, Egyptian, Western and
|
||
Futuristic areas. Thus, it is similar to Trash and Void in combining several
|
||
milieux into one. That said, it concentrates heavily on magic, quests, and
|
||
(presumably setting-independent) combat.
|
||
|
||
Great play is made of the fact that the game has many mobiles, and that
|
||
these are programmed to perform tasks. Some are friendly, others are not, and
|
||
they may even fight one another. None of this is new to second-generation MUAs,
|
||
so it hints at Daemon Adventure's having been written by a player of Shades,
|
||
MirrorWorld or similar.
|
||
|
||
There are no resets in the game, and the persona file keeps location
|
||
and inventory details; although standard practice in SUAs, this rarely works in
|
||
a MUA, as it removes objects from play and thus renders some puzzles
|
||
unsolvable. How areas are reclaimed once played out is not explained.
|
||
|
||
Daemon Adventure boasts a fast response time and "the latest in
|
||
multi-user software techniques", allowing it to support 50 players at once.
|
||
|
||
Summary:
|
||
Many of Daemon Adventure's claimed features are probably vapourware.
|
||
However, if they are fully implemented the game may prove successful. Some
|
||
aspects of the game will need to be thought through more deeply, however -
|
||
overall, there is a decided aura of "group of enthusiastic amateurs" about the
|
||
project.
|
||
|
||
Quotes:
|
||
|
||
"The multi-user, multi-world, multi-game environment."
|
||
QuestRole [promotional material]
|
||
|
||
|
||
Name: Future Life
|
||
Author(s): Dave Mager ("Slime")
|
||
Location: Lap of the Gods
|
||
Pricing Structure: L0.575/hour or
|
||
L11.50/month flat fee
|
||
|
||
Brief Description:
|
||
SF setting.
|
||
|
||
Historical Notes:
|
||
Appeared late 1990.
|
||
|
||
Review:
|
||
There has been no publicity surrounding Future Life. It appears to be
|
||
in alpha-test at the moment, and is therefore unplayable by outsiders.
|
||
|
||
Quotes:
|
||
|
||
"Future Life is a game written by Slime, which nobody (least of all
|
||
Slime) knows much about yet."
|
||
Lap of the Gods [promotional material]
|
||
|
||
|
||
Name: Imperium
|
||
Location: Red Star BBS
|
||
Pricing Structure: free
|
||
|
||
Brief Description:
|
||
SF MUA.
|
||
|
||
Review:
|
||
Imperium is advertised on several bulletin-boards, but its host system
|
||
has not been up for several weeks, and no information about it is available
|
||
other than the fact it exists.
|
||
|
||
|
||
Name: Mage
|
||
Author(s): D. Harris ("Brangdon")
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone.
|
||
|
||
Historical Notes:
|
||
Only known appearance - Adventure 88.
|
||
|
||
Review:
|
||
Mage is a MUA with a strong plotline - protecting a remote city from
|
||
monsters in the absence of its missing, magic-wielding feudal lord (the
|
||
"mage"). It consciously draws on ideas from face-to-face fantasy role-playing
|
||
games, and so includes skills, money and magical artefacts.
|
||
|
||
The eventual goal of players is to find out what happened to the
|
||
missing mage. This is uncharacteristic of MUAs - it would seem that once one
|
||
person has learned the secret, the game should be effectively over for
|
||
everyone. Even if it involves elevation to a higher plane (ie. a wiz level),
|
||
keeping the secret will inevitably prove impossible.
|
||
|
||
Mage is written in C and runs on an unmodified AT clone.
|
||
|
||
Summary:
|
||
Mage appears to be a single-user role-playing game at heart.
|
||
Nevertheless, it is interestingly different enough to be worth a look if it
|
||
ever does make a public appearance.
|
||
|
||
Quotes:
|
||
|
||
"The very best may undertake the greatest challenge - to discover
|
||
exactly what has happened to the missing mage."
|
||
Mage [promotional material]
|
||
|
||
Name: MUG
|
||
Location: Red Star BBS
|
||
Pricing Structure: free
|
||
|
||
Review:
|
||
MUG runs alongside Imperium. See the review of Imperium for more
|
||
details.
|
||
|
||
|
||
Name: Spacers
|
||
Author(s): Pip Cordrey ("Pippin")
|
||
|
||
Brief Description:
|
||
MUD1 clone, SF setting.
|
||
|
||
Historical Notes:
|
||
First mooted in 1989, but yet to be implemented.
|
||
|
||
Review:
|
||
Spacers a forthcoming game on the IOWA system. It started off as an
|
||
attempt to rationalise the idea of rolling resets, and grew (but not very far)
|
||
from there. Its setting is a space station which has fallen into disrepair and
|
||
become inhabited by Mad Max vagrants and hostile aliens. Players are rewarded
|
||
for mending the broken hardware, or replacing it with parts from a store-room;
|
||
after a while, whatever has been repaired breaks down again, thus giving the
|
||
rolling reset. Points are also obtained for eliminating aliens.
|
||
|
||
Summary:
|
||
An interesting alternative to normal treasure-collecting games:
|
||
instead of moving objects from all over the place to a central location, it
|
||
involves moving objects from a central location to all over the place. A neat
|
||
conceptualisation of rolling resets, but it doesn't appear to address the main
|
||
problem of such systems - they aren't adept at handling complex puzzles. If
|
||
it's not written in Slate, it should be worth a look.
|
||
|
||
Quotes:
|
||
|
||
"Although still in its infancy, the game will add another dimension
|
||
to the growing world of Pip Cordrey."
|
||
Confidential [magazine]
|
||
|
||
"Since the station is in a constant state of breakdown, it is no
|
||
surprise when the same equipment repeatedly malfunctions, and the
|
||
story holds together very well."
|
||
Pip Cordrey [author]
|
||
|
||
|
||
Name: Strata
|
||
Author(s): Nic Alderton
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone, SF setting.
|
||
|
||
Historical Notes:
|
||
Only known appearance - Adventure 89.
|
||
|
||
Review:
|
||
Strata is another MUA built on promises. Its main thrust is size: it is
|
||
envisaged as having 8,000 locations with full descriptions, including sounds
|
||
and smells. To this end, Alderton has been soliciting for location authors, and
|
||
has managed to secure some fairly big names in the MUA world (although none of
|
||
them have experience in writing their own MUAs). 8,000 rooms is sufficiently
|
||
large to make mapping virtually impossible, and the descriptions will vary
|
||
through completely different styles; the game is likely to seem as if it is a
|
||
SUA rather than a MUA.
|
||
|
||
Mobiles are intended to have AI capabilities, but Alderton is rather
|
||
offhand about this, and appears to labour under the misapprehension that a
|
||
command along the lines of "ask <mobile> about <object>" is enough to ensure
|
||
success in that area.
|
||
|
||
Full sensory abilities are hoped-for in Strata, including scent, taste
|
||
and audibility for all objects. Along with many of the other features
|
||
announced in the Adventure 89 flier, these are only impressive to players of
|
||
first-generation MUAs - MUD2, for example, has them already, and has had for
|
||
some time.
|
||
|
||
An interesting suggestion is the inclusion of pseudo-mobiles - messages
|
||
appearing on the screen appearing to indicate the presence of mobiles passing
|
||
through, but actually just there to give an impression of a bustling, crowded
|
||
environment.
|
||
|
||
Strata has a distinction between money and score (similar to that of
|
||
Empyrion - indeed, it is possible that Strata actually is Empyrion under an
|
||
earlier name). Money is used to buy things, but only by obtaining enlightenment
|
||
points can progress to the top level (entitled 'Etheral') be made.
|
||
|
||
Resets in Strata are of the rolling variety: Alderton sought advice
|
||
from the authors of MirrorWorld, Zone and Gods before embarking on his project.
|
||
The game has humour explicit in its descriptions, which makes them fun the
|
||
first time you read them but aggravating after the umpteenth. However, with a
|
||
projected 8,000 rooms it is unlikely that rooms will be visited all that often
|
||
anyway...
|
||
|
||
Strata runs on an Atari ST with a 32 megabyte hard disc.
|
||
|
||
Summary:
|
||
If it delivers all the features it promises, Strata will be a good,
|
||
modern MUA. Concentrating on having a huge number of rooms, however, is a bad
|
||
move. Hopefully, the author will realise that before he launches 8 novels'
|
||
worth of locations on an unsuspecting world.
|
||
|
||
Quotes:
|
||
|
||
"I hope, when all is working, to have roughly 8,000 locations with
|
||
full descriptions including smell and listen. I have noticed
|
||
people try to comfort me when I tell them this, but I'm not insane
|
||
(!). It is technically possible..."
|
||
Nic Alderton [author]
|
||
|
||
|
||
Name: Wanderland
|
||
Author(s): Ted Greene ("Wanda")
|
||
|
||
Brief Description:
|
||
Standard, MUD1 clone.
|
||
|
||
Historical Notes:
|
||
One of the first MUD1 lookalikes, Wanderland is a long-standing MUA
|
||
which either moved or disappeared sometime last year.
|
||
|
||
Review:
|
||
Wanderland is a traditional MUA with around 1,500 hundred locations in
|
||
its fantasy setting. Treasure is easy to find, and is scored for by placing it
|
||
in the Reclaimed Land. Strangely, 524,288 points are required to make wiz.
|
||
The game runs on a DEC computer, most probably a PDP 11.
|
||
|
||
Summary:
|
||
A game with a pleasant atmosphere, much-loved by its players.
|
||
|
||
Quotes:
|
||
|
||
"It's a pity there aren't a few more players around, although MUGs
|
||
do tend to go through periods of popularity. Even so, perhaps I'll
|
||
make Wanderland the site of my third witch."
|
||
ACE [magazine]
|
||
|
||
|
||
Name: Warlord
|
||
Author(s): Neil Newell ("Hazeii")
|
||
|
||
Brief Description:
|
||
Combat-oriented MUA.
|
||
|
||
Historical Notes:
|
||
Only known appearance - Adventure 89.
|
||
|
||
Review:
|
||
Warlord is a MUA where the only means of advancing levels is fighting.
|
||
There is a monetary system overlaid on top, so that players can buy weapons,
|
||
armour and related services.
|
||
|
||
A problem with Shades (Warlord comes from the Shades stable) is that
|
||
players with fast modems have an advantage over ones playing at slower baud
|
||
rates. This is something of a preoccupation with the author, and hence Warlord
|
||
is designed to reduce any such advantage to a minimum. How this is done exactly
|
||
isn't clear from the flier, however.
|
||
|
||
The top level of the game is 'warlord'.
|
||
|
||
Summary:
|
||
The main thrill killer players get in a MUA is in attacking players who
|
||
don't want to fight. Since fighting is, by definition, part and parcel of
|
||
Warlord, it probably won't have staying power except among arcade-game lovers.
|
||
|
||
Quotes:
|
||
|
||
"The fighting tends to be fast and furious."
|
||
Third Millenium Systems [promotional material]
|
||
|
||
"Preparation, skill and anticipation are all vitally important if a
|
||
player is to attempt to achieve the role of The Warlord."
|
||
Third Millenium Systems [promotional material]
|
||
|
||
5. Reviews - Rest of the World.
|
||
|
||
5.1 British Legends.
|
||
|
||
Name: British Legends
|
||
Importance: 3
|
||
Author(s): Roy Trubshaw, Richard Bartle
|
||
Location: CompuServe
|
||
Pricing Structure: $12.50/hour plus
|
||
$9.40/hour for UK players
|
||
|
||
Brief Description:
|
||
Archetypal MUA.
|
||
|
||
Historical Notes:
|
||
The original MUD1 MUA, with modifications for the American market.
|
||
Launched on CompuServe in mid-1987, but the core of it dates back to early
|
||
1980. The name-change was because CompuServe thought "MUD" sounded
|
||
unattractive.
|
||
|
||
Review:
|
||
British Legends (or simply BL) is the American name for MUD1, the very
|
||
first MUA and the one from which nearly all others are descended. Despite its
|
||
age, BL still compares well against many other MUAs, especially those available
|
||
in the USA. Almost every feature present in MUAs, from wizzes to mobiles and
|
||
most of the vocabulary, comes from this game (although, technically speaking,
|
||
BL is MUD version 3B, a late modification of version 3A; it is 3A, or Essex
|
||
MUD, which is properly considered as the root of other MUAs).
|
||
|
||
Although it is now dated, BL is still fun to play, continues to attract
|
||
new players, and is well managed. Its atmosphere is good, and its players
|
||
generally responsible (40% are female - the highest published ratio of any
|
||
MUA).
|
||
|
||
The MUDDL interpreter that underlies BL is hardwired for a fantasy
|
||
style world, and is limited in the complexity of commands it allows to be
|
||
defined. Objects, rooms, mobiles and players are all stored using different
|
||
internal formats, which makes the writing of generic routines difficult. Room
|
||
descriptions take no account of whether the player is able to detect the
|
||
sensations listed, so it's possible to "hear" sounds when you're deafened and
|
||
not hear them when you're blinded. However, the system is still capable of
|
||
being expanded in certain directions - the "act" command, for example, was
|
||
taken from MUD2.
|
||
|
||
Despite its simplicity, BL's parser is remarkably robust and
|
||
user-friendly - better than MUD2's, in fact. The game's depth is average,
|
||
although its breadth still beats that of most MUAs (on account of its age -
|
||
over the years, just about everything has been tried in it).
|
||
|
||
Perhaps the worst thing about BL is the fact that there is a 7-second
|
||
delay between the processing of commands. This condition was imposed by
|
||
CompuServe - BL works asynchronously, and is thus normally one of the fastest
|
||
MUAs, even though the DECsystem 10/20 hardware upon which it runs is hopelessly
|
||
out of date now. In the UK, a 7-second delay in a commercial game would be
|
||
intolerable - 4 seconds is about the limit - yet since CompuServe impose
|
||
similar constraints on all their multi-player games, the USA market is
|
||
presently conditioned to accept such artificial limitations.
|
||
|
||
Due to its age and the size of the CompuServe user base, BL is the
|
||
single most-played MUA in the world.
|
||
|
||
Summary:
|
||
Evergreen MUA which started off the whole industry. It looks its age
|
||
when compared to the newer commercial MUAs, but is still surprisingly
|
||
sophisticated in places. A classic.
|
||
|
||
Quotes:
|
||
|
||
"The initial attitude of the Americans was to be politely skeptical
|
||
that any games software from the UK could be worthy of their
|
||
attention. But once they saw the program running on their system
|
||
they could hardly believe their eyes. So far as I know, this is
|
||
the first British program ever to be taken by CompuServe."
|
||
Simon Dally [MUSE managing director]
|
||
|
||
"British Legends is better suited to the occasional user [than is
|
||
Gemstone], with its simpler entrance requirements and a universe
|
||
small enough to enable most players to get around adequately by
|
||
memory."
|
||
PC Magazine
|
||
|
||
"The kinder, gentler [than Gemstone] British Legends makes a quick
|
||
command summary available, along with some rather general hints."
|
||
PC Magazine
|
||
|
||
"Solving a puzzle for the first time is the most exciting part of
|
||
the game."
|
||
Ron Fitzherbert [player]
|
||
|
||
"Adding a multi-user environment to the basic adventure game adds a
|
||
whole new dimension."
|
||
The Guardian
|
||
|
||
"The first time I found myself in the swamp, a character called
|
||
Monkey came up to talk and scared me so much that I immediately
|
||
quit the game. I didn't know it was another person. I thought it
|
||
was a monster about to destroy me!"
|
||
John Starr [player]
|
||
|
||
"Todd Carter is 22, a computer addict from Miami who was left blind
|
||
by a gunshot wound in high school. On CompuServe, he called
|
||
himself Blinddog when he played an adventure game called "British
|
||
Legends". He was so hooked on the game that he dropped about
|
||
$8,000 in on-line charges playing it."
|
||
The Miami Herald
|
||
|
||
"Not only are the wizards and witches helpful to novices, but many
|
||
mortals also can show a kind word or gesture. Make friends!"
|
||
CompuServe [promotional material]
|
||
|
||
"British Legends is the most-played multi-user adventure game in
|
||
the world."
|
||
The Observer
|
||
|
||
|
||
5.2 Gemstone III.
|
||
|
||
Name: Gemstone III
|
||
Importance: 2
|
||
Author(s): ? (Simutronics Corp.)
|
||
Location: GEnie
|
||
Pricing Structure: $35/hour 8am - 6pm
|
||
$5/hour 6pm - 8am
|
||
(no UK access point)
|
||
|
||
Brief Description:
|
||
Multi-user adventure game, fantasy setting.
|
||
|
||
Historical Notes:
|
||
One of the few MUAs developed independently of MUD1.
|
||
|
||
Review:
|
||
Like MUD1, Gemstone III was inspired by SUAs. However, despite this
|
||
separation from the mainstream of MUA development, Gemstone III is nevertheless
|
||
uncannily similar in many areas, particularly in its basic "search for
|
||
treasure, get points, go up levels and become a wizard" attitude; levels and
|
||
wizdom were never a part of early SUAs.
|
||
|
||
Gemstone III is primarily a role-playing game, which makes it popular
|
||
among Americans. To this end, it requires that people beginning the game flesh
|
||
out their persona by choosing between various personality characteristics,
|
||
races, occupations, and many other details right down to eye colour. Few of
|
||
these have any real bearing on gameplay, but they do make new players think
|
||
they're getting value for money.
|
||
|
||
The game has a 25,000 word manual, which must be downloaded and read
|
||
because there is no on-line help while playing. This, and the barrage of
|
||
persona-defining questions at the beginning, combine to make Gemstone III very
|
||
daunting for all new players except those in whom a thick rulebook induces
|
||
excitement.
|
||
|
||
There are many rooms in Gemstone III, including streets and shops. As
|
||
with the rest of the game, it seems that size is regarded as the most important
|
||
facet, and that detail must be provided whatever the cost and no matter how
|
||
irrelevant it is. It's the classic role-playing problem: whether to provide a
|
||
loose framework in which players can develop personae their own way, or a tight
|
||
one where players' options are limited by strictures imposed by the game
|
||
dependent on the role they have chosen. MUD1's descendents tend to favour the
|
||
freedom of the former; Gemstone III comes down heavily in favour of the latter,
|
||
and in this respect is more akin to Island of Kesmai.
|
||
|
||
Summary:
|
||
An interesting MUA, but one which requires a certain doggedness on the
|
||
part of its players to stay the course. Not a game for dabblers, socialisers or
|
||
fun-seekers.
|
||
|
||
Quotes:
|
||
|
||
"Gemstone is the one for people who want to escape reality and
|
||
really get into playing a role in an incredibly complex world."
|
||
PC Magazine
|
||
|
||
"The sheer number of options involved in getting started can be so
|
||
intimidating that a simplified setup process is also provided."
|
||
PC Magazine
|
||
|
||
"In my roamings through Gemstone, I never saw the same place twice.
|
||
Drawing a map is definitely necessary to navigate effectively."
|
||
PC Magazine
|
||
|
||
|
||
5.3 Other Commercial MUAs.
|
||
|
||
As in the last subsection of the section on UK MUAs, the MUAs presented
|
||
here are known to exist; however so little information is available concerning
|
||
them that no detailed reviews or summaries are given.
|
||
|
||
|
||
Name: Kyrandia
|
||
Location: Galacticomm Bulletin Boards
|
||
|
||
Brief Description:
|
||
A basic multi-user adventure game.
|
||
Notes:
|
||
Bundled with the Galacticomm Bulletin Board system. These are
|
||
expandable MSDOS machines intended for commercial, multi-user conferencing and
|
||
the like.
|
||
|
||
Quotes:
|
||
|
||
"A version of Kyrandia is reachable via US Minitel at "ALLA". I've
|
||
yet to meet anybody in it, so usage seems light. And at
|
||
$0.20/minute, exploring the world is very expensive."
|
||
John Nagle [player]
|
||
|
||
|
||
Name: Quest for Magic
|
||
Location: Galacticomm Bulletin Boards
|
||
|
||
Brief Description:
|
||
A basic multi-user adventure game.
|
||
Notes:
|
||
See Kyrandia.
|
||
|
||
Quotes:
|
||
|
||
"A multi-user, interactive text adventure game."
|
||
Galacticomm [promotional material]
|
||
|
||
|
||
Name: Scepter
|
||
Author(s): Alan Klietz
|
||
Location: none
|
||
|
||
Brief Description:
|
||
A multi-user adventure game, fantasy setting.
|
||
Notes:
|
||
A game called Milieu was written in the early 1980's under Multi-Pascal
|
||
for a CDC Cyber used by high-school students in Minnesota for educational
|
||
purposes. Klietz ported it to an IBM XT in 1983, and renamed it Scepter of
|
||
Goth. Klietz later wrote a MUA called Screenplay, which incorporated building,
|
||
using an interpreted command language reputedly more powerful than those
|
||
available on the InterNet today.
|
||
|
||
Scepter was influenced by AD&D-style role-playing, and incorporated
|
||
many of the ideas concerning character classes and skills presently gaining
|
||
popularity in commercial UK MUAs like Avalon. Combat was blow-by-blow, and
|
||
multiple identical objects were numbered (the same approach taken by MUD2).
|
||
|
||
Scepter was sold to a company called InterPlay in Virginia, which
|
||
licensed out the software but was liquidated after its executives were charged
|
||
with tax evasion. The game was sold off to creditors, and is no longer
|
||
available.
|
||
|
||
Although many players loved the game, Scepter earned a reputation for
|
||
enforcing artificial friendliness among its players, with ruthless consequences
|
||
for "troublemakers". Thus, all sparks of originality were snuffed out, but the
|
||
game worked well for people who didn't "misbehave".
|
||
|
||
Quotes:
|
||
|
||
"Scepter had the best atmosphere of any multi-user game I've
|
||
player."
|
||
Bill Wisner [player]
|
||
|
||
"In Scepter, you just offer an item for sale several times to get
|
||
an idea of the price, then sell it when you hit the maximum again.
|
||
Nobody I knew in Scepter ever bartered. They just took the first
|
||
offer. They had better things to do with their time."
|
||
Andrew Thomas [player]
|
||
|
||
|
||
5.4 AberMUD.
|
||
|
||
Name: AberMUD
|
||
Importance: 1
|
||
Author(s): Alan Cox ("Anarchy"),
|
||
Jim Finnis, Leon Thrane,
|
||
Richard Acott, Rich Salz,
|
||
Brian Preble ("Rassilon")
|
||
Location: InterNet
|
||
ArkMUD engr.uark.edu
|
||
ButlerMUD butler.tds.kth.se
|
||
HackeMUD bass.vsect.chalmers.se
|
||
IlliniMUD speedy.cs.uiuc.edu
|
||
TempleMUD monet.ocis.temple.edu
|
||
The Underground mole,ai.mit.edu
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone.
|
||
|
||
Historical Notes:
|
||
Cox was a player of MUD1 who wrote AberMUD while a student at the
|
||
University of Wales, Aberystwyth. The code was made generally available, and
|
||
was enhanced and added to by several people, most notably Salz; Preble is the
|
||
present AberMUG co-ordinator. A commercial version of the game has been
|
||
running on Connect since 1989.
|
||
|
||
Review:
|
||
AberMUD was written in 1987 in B for a Honeywell L66 mainframe under
|
||
GCOS3/TSS. Its first scenario was not a serious effort; its second scenario is
|
||
the one in present use.
|
||
|
||
In 1988, AberMUD was ported to Unix and converted to C. Version 3.7.14
|
||
was distributed on JANet and InterNet, and regular updates by the original
|
||
authors continued until version 3.9.8. The present version is 3.12.5, but
|
||
version 3.9.8 spawned a rogue 4.9.8 clone which, among other things, has combat
|
||
messages ripped out of MUD1. This is the version which became most popular on
|
||
InterNet. Despite its poor design and implementation (eg. communication via
|
||
shared files), AberMUD became the first widely-available MUA on InterNet, and
|
||
most of the games presently being written by academics are descended from it.
|
||
|
||
The game itself is not particularly special, being a poor MUD1
|
||
lookalike in the Shades mould. There are 10 levels, scaled slightly lower than
|
||
is common, and with fights scoring relatively higher than treasure. Treasure is
|
||
converted into points by dropping it in a sacrificial pit in a church, ie. as
|
||
MUD1's swamp.
|
||
|
||
There is no "sleep" command to restore stamina after a fight; instead,
|
||
stamina is recovered automatically over time. This is something MUD1 did not
|
||
have; although MUD2 does, AberMUD's rate of stamina replenishment is much
|
||
quicker.
|
||
|
||
AberMUD lacks polish, despite its commercial standing and its erstwhile
|
||
popularity (now waning, as it's regarded as a CPU hogger). There are missing
|
||
full stops, spurious full stops, inconsistencies in uses of commas, and the
|
||
room descriptions are convoluted and ambiguous. Objects and rooms are placed
|
||
together without reference to description clashes, eg. snow on the ground, rain
|
||
in the air and a rainbow in the sky, all at the same time.
|
||
|
||
Abbreviations in AberMUD are not catered for very well - the common "l"
|
||
("look") and "x" ("exits") commands are missing, for example. The game is also
|
||
deficient in other commands - no "act" or equivalent, and apparently only
|
||
cardinal directions plus "up" and "down". The game needs to be reset
|
||
occasionally, but doesn't do so automatically: an explicit "reset" command is
|
||
necessary.
|
||
|
||
Although fights play a big part in AberMUD, they are not well
|
||
implemented, initially being of "the ghoul hits you" variety. This may explain
|
||
why many of the game's descendents eschew fighting altogether.
|
||
|
||
Summary:
|
||
A simple MUA that makes other InterNet MUA-writers think they have
|
||
less to do to become world class than is actually the case.
|
||
|
||
Quotes:
|
||
|
||
"The main reason for writing it was because the system manager said
|
||
it wasn't possible on the Honeywell."
|
||
Alan Cox [author]
|
||
|
||
"It now seems to have found a home at St. Olaf University, where a
|
||
few dedicated hackers are keeping it alive despite its general
|
||
grunginess."
|
||
Bill Wisner [player]
|
||
|
||
"The combat text has been greatly improved. ... InterNet versions
|
||
now offer more MUD-like multi-line messages."
|
||
Comms Plus! [magazine]
|
||
|
||
"I do have one fairly major quibble, and that is the lack of
|
||
information and help text within the game."
|
||
Comms Plus! [magazine]
|
||
|
||
"AberMUD has a sort of similar concept to LPMUD (kill the monsters
|
||
and such until you become a wizard), but that's about the end of
|
||
the surface similarity. LPMUD is designed to be easily extended
|
||
from within the game. Once you become a wizard, you work on
|
||
developing new sections of the game, and a list is kept of which
|
||
wizards' sections are most popular. AberMUD can only be modified
|
||
by changing the source data files and recompiling, and even then
|
||
is far from easy (I know, I've done it...)."
|
||
Jim Seidman [player]
|
||
Most of these MUDs have been eliminated in the US because of the
|
||
network traffic they cause."
|
||
Philip Cutone III [player]
|
||
|
||
"The best version on the InterNet was in Sweden, and people in the
|
||
US would play it but put up with the link problems which would
|
||
regularly disconnect them."
|
||
Comms Plus! [magazine]
|
||
|
||
"A problem with AberMUD, and to some extent LPMUD, is that people
|
||
with slower links are severely penalised. Especially on some
|
||
AberMUDs where the wizards require everyone to go back to the
|
||
church before resetting, people with slow links have no chance."
|
||
Jim Seidman [player]
|
||
|
||
"AberMUG is a fairly 'standard' game in its setting and in its
|
||
general feel, so existing MUGgers should feel at home - although I
|
||
did find the absence of several abbreviations to be annoying."
|
||
Comms Plus! [magazine]
|
||
|
||
"I wasn't too amused at the way people seem to have lost the
|
||
original AberMUD license, broken it in several places, and even
|
||
included copyright material from other games systems (MUD1) in
|
||
it."
|
||
Alan Cox [author]
|
||
|
||
"AberMUG is a multi-user adventure game in the traditional mould."
|
||
Connect [promotional material]
|
||
|
||
|
||
5.5 LPMUD.
|
||
|
||
Name: LPMUD
|
||
Importance: 1
|
||
Author(s): Lars Pensjo
|
||
Location: InterNet
|
||
BATMAN batman.hut.fi
|
||
Boiling MUD frey.nu.oz.au
|
||
ClubMUD milton.u.washington.edu
|
||
Crossroads civeng.ua.oz.au
|
||
Darker Realms worf.tamu.edu
|
||
Dartmouth LP melchior.dartmouth.edu
|
||
DEATHMUD gauss.nmsu.edu
|
||
DeepTrouble MUD krikand.iesd.auc.dk
|
||
End of the Line ucrmath.ucr.edu
|
||
GENESIS milou.cd.chalmers.se
|
||
GhostMUD beowulf.acc.stolaf.edu
|
||
NannyMUD nanny.lysator.liu.se
|
||
NLD MUD chaos.utexas.edu
|
||
Phoenix galjas.cs.vu.nl
|
||
Sanctuary j.ms.uky.edu
|
||
Small Systems calvin.nmsu.edu
|
||
Sun MUD einstein.mpccl.ksu.edu
|
||
Thieve's World uokmax.ecn.uoknor.edu
|
||
Third World hardy.u.washington.edu
|
||
UCSB-GEOG LPMUD sherlock.geog.ucsb.edu
|
||
U Maine LPMUD mud.umcs.maine.edu
|
||
Vision watnxt2.ucr.edu
|
||
WARHAMMER MUD watnxt3.ucr.edu
|
||
World of Mizar mizar.dosc.uu.se
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone with object creation.
|
||
|
||
Historical Notes:
|
||
Pensjo obtained the source for AberMUD, didn't like it, so wrote his
|
||
own MUA instead at Gothenburg in Sweden. It was distributed to other Unix sites
|
||
across InterNet. Late 1989, some American players modified the code themselves
|
||
(despite regular updates and technical support by Pensjo), and the two LPMUDs
|
||
diverged. Several attempts to reconcile the European and American sources is
|
||
now under way, such as one being programmed by Duncan Howard (a former MUD1
|
||
arch-wiz).
|
||
|
||
Review:
|
||
LPMUD (named after its author) is one of the more popular MUAs on
|
||
InterNet, certainly in terms of the number of sites that run it. Although
|
||
immediately descended from AberMUD, copies of MUD1 were sent to Sweden in the
|
||
early 80's, prompting some activity in the MUA area by the locals; there was a
|
||
project possibly already under way at Linkoping to develop a MUA called
|
||
Asgaard, which eventually petered out but left a body of programmers with
|
||
experience in MUAs. It seems likely that the lessons and ideas that emerged
|
||
from this effort may have had an indirect influence on Pensjo.
|
||
|
||
LPMUD plays as a good MUD1 clone until wiz level is reached. At that
|
||
point, it allows players to create their own permanent rooms, objects, mobiles
|
||
and (even) commands. The game's interpreter will accept input in a C-like,
|
||
object-oriented language called LPC, and will save all creations across resets
|
||
(unlike MUD2). It was the first InterNet MUA with this facility built in
|
||
(although there is a good measure of cross-fertilisation with TinyMUD), and is
|
||
thus often credited with inventing the idea; actually, most good first-attempt
|
||
interpreters can handle it (second-attempt interpreters generally take their
|
||
input preprocessed by a database compiler, for speed).
|
||
|
||
Because each LPMUD has rooms created by its players, the different
|
||
sites on InterNet will all be different; a common core of rooms is linked to a
|
||
network of new ones. However, room complexes are often copied between different
|
||
LPMUDs, so the difference is not as great as it might be.
|
||
|
||
Resets in LPMUD are rolling. Initially, one object was reset every 3
|
||
seconds, but this meant that the more objects that were added, the longer the
|
||
period between resets. Now, objects are only reset in a room when a player
|
||
enters that room - a form of lazy evaluation. This works well, but it has the
|
||
disadvantage of only working for very simple puzzles that involve objects'
|
||
changing locations, rather than their changing other properties.
|
||
|
||
In LPMUDs, it's only a question of time before a player makes wiz. The
|
||
only penalty for death is being subjected to a time-consuming sequence where
|
||
the deceased is taken to a room and meets Death incarnate. Higher-level
|
||
players even get a scar from this that they can show to their friends. Recently
|
||
a quest system (similar to MUD2 tasks) has been added to make sure players know
|
||
something about the game before reaching wiz, but performing such quests is not
|
||
particularly dangerous to personae.
|
||
|
||
LPMUD has experimental bots programmed in LPC and running internal to
|
||
the game. These are therefore more properly referred to as mobiles, but this
|
||
term has not found favour in InterNet MUAs since most of them don't cater for
|
||
such sophisticated objects. LPMUD has a client, LPTalk.
|
||
|
||
Versions of the European LPMUD are distributed regularly, and improving
|
||
the system is an ongoing project programmed by Pensjo. There are some features
|
||
which need changes to the LPMUD interpreter before they'll work, for example
|
||
players' properties are hard-coded and transient ones cannot be saved to disc.
|
||
However, with its excellent support and dedicated players, LPMUD will doubtless
|
||
be around for some considerable time yet. Despite this, most LPMUDs are based
|
||
in Europe - American systems managers seem less ready to tolerate CPU-intensive
|
||
MUAs than their European counterparts, and prefer light users like TinyMUD and
|
||
its descendents.
|
||
|
||
Summary:
|
||
An average MUA with object creation added on top. Not as prone to
|
||
criticism as the freer creation-based games (if, indeed, games they are) like
|
||
TinyMUD, but still causing the usual problems of atmosphere, editorial control
|
||
and overall ownership that would dog a commercial version of the software.
|
||
|
||
Quotes:
|
||
|
||
"Only wizards can create new objects and rooms. By limiting
|
||
creation like this, the feeling of chaos that one is prone to
|
||
encounter on Tiny-type games is reduced."
|
||
Comms Plus! [magazine]
|
||
|
||
"LPMUD: Lots of programming available. Mainly an adventure setup
|
||
where you are trying to advance in level by solving puzzles and
|
||
killing wandering monsters. This gives users a 'carrot' to chase
|
||
(becoming a wizard) and could keep them in the game easier."
|
||
Glenn Crocker [player]
|
||
|
||
"One of the advantages that I see with LPMUD is that objects are
|
||
continually being reset. There is one object reset every 3 seconds
|
||
or so, so that an object will come back every 15 minutes or so.
|
||
Therefore, a lot of people have the chance to explore and see
|
||
things."
|
||
Jim Seidman [player]
|
||
|
||
"Some rooms have been taken from AberMUD, but the game is
|
||
user-extendable."
|
||
Comms Plus! [magazine]
|
||
|
||
"The bad news about LPMUD is that the programming language is very
|
||
C-like, and that comes back to the problem of whether your players
|
||
know C... They might not be willing to learn a language just for
|
||
the game. Of course, the same applies to TinyMUCK."
|
||
Jim Seidman [player]
|
||
|
||
"This [extensibility] introduced a considerable level of depth into
|
||
the choices open to wizards, and brought some new problems too."
|
||
Bill Wisner [player]
|
||
|
||
"On LP there is massive amounts of building, because after making
|
||
wizard the whole point of the game is to have most people visit
|
||
your area. So, wizards build their areas to attract people, and if
|
||
a wizard has crappy building, nobody visits. Therefore, the
|
||
wizard is forced to make his building that much better."
|
||
Patrick Wetmore [player]
|
||
|
||
"Strangely enough, the LPMUDs are closer to what the original
|
||
TinyMUDs were: people wandering around, exploring. Eventually,
|
||
people start building their own domains for people to explore.
|
||
Granted, only wizards can build, but in a way that's good, since
|
||
it really stops the casual builder who builds two or three items
|
||
then wanders off never to build again."
|
||
Martin Terman [player]
|
||
|
||
"Semi-recently, quests were added as a feature of LPMUD. A certain
|
||
number (or all) of the quests must be solved before advancing to
|
||
wizardry. Most quests involve puzzle-solving and exploring (and
|
||
most have some hack and slash involved too). Suddenly, LPMUD did
|
||
not guarantee wizardry just by serving your tour of duty as a
|
||
player - thinking was involved."
|
||
Darin Johnson [player]
|
||
|
||
"The rate of new wizards on Genesis [the first LPMUD] is ten per
|
||
week, and Genesis is already crowded (186 of level 20 and
|
||
above...)."
|
||
Bertil Jonell [player]
|
||
|
||
"LPs are something worth checking. Think: 3,000+ rooms, 30+
|
||
players, running 24 hours - and not arousing the [system owners']
|
||
administration. These provide some challenge to the player - not
|
||
to mention wizards and gods, it's just a pity their efforts mainly
|
||
are used in building new rooms, not to make interesting events for
|
||
players."
|
||
Esa Kankaanpaa [player]
|
||
|
||
|
||
5.6 TinyMUD.
|
||
|
||
Name: TinyMUD
|
||
Importance: 1
|
||
Author(s): Jim Aspnes
|
||
Location: InterNet
|
||
DragonMUD naucse.cse.nau.edu
|
||
Eden unicorn.wwu.edu
|
||
FantaMUD sage.cc.purdue.edu
|
||
Islandia II apex.yorku.ca
|
||
MuseumMUD fuzine.mt.cs.cmu.edu
|
||
TinyMUD Classic planck.physics.purdue.edu
|
||
TinyWorld banyan.ssc.gov
|
||
|
||
Brief Description:
|
||
Object creation and inter-player communication.
|
||
|
||
Historical Notes:
|
||
TinyMUD was prompted by a 1989 discussion on InterNet, and drew on
|
||
LPMUD to abstract an idealised notion of what made MUAs important. It rapidly
|
||
spread across InterNet, due mainly to its small size and low CPU requirements.
|
||
Aspnes' own TinyMUD was closed down when he grew tired of it.
|
||
|
||
Review:
|
||
The MUD in TinyMUD stands for "Multi-User Dimension." There is some
|
||
debate as to whether the system is a game. It was certainly written as a game,
|
||
with the idea that players collect 'pennies' which they then spend on building
|
||
new rooms. Pennies were either left lying around, or obtained by dropping
|
||
objects in a pit. Combat is possible, just, but it's generally discouraged for
|
||
fear of frightening off players. Everything else is very, very basic - even
|
||
gender pronoun substitution wasn't handled in the original.
|
||
|
||
This adventuring aspect of TinyMUD rapidly disappeared. Objects were
|
||
created with huge values, and soon players could get as many pennies as they
|
||
wanted. This meant they spent all their time either building rooms or
|
||
socialising with other players. The key point about TinyMUD is that anyone can
|
||
build rooms. All they need to connect their creations to the rest of the room
|
||
network is the co-operation of an existing player who doesn't mind linking a
|
||
free exit with one in the new complex. Whether this is topographically correct
|
||
is immaterial, as is the quality or quantity of rooms so joined together.
|
||
|
||
TinyMUD's creative capacities are strictly limited to only basic
|
||
objects, rooms and exits. Complex actions cannot be defined, only room-related
|
||
puzzles (eg. hidden doors, missing keys, mazes). Programmers found this
|
||
frustrating, which is why the TinyMUD sources were rapidly torn apart and put
|
||
back together with more powerful facilities at builders' disposal, eg. in
|
||
TinyMUCK and TinyMUSH.
|
||
|
||
There are wizzes in TinyMUDs, of a sort. Really, they're little better
|
||
than sysops, although they do have some authority over building and can remove
|
||
or modify rooms. Game management is very difficult, however, since anyone,
|
||
friend or foe, has full powers to add new rooms whether they have the slightest
|
||
idea of what they're doing or not. This ensures that the only atmosphere a game
|
||
possesses is that due to its players, and that any pretensions of consistency
|
||
or depth swiftly disappear. Sadly, most people are not good room-describers
|
||
(in the same way that most people aren't good novellists), and thus, although
|
||
the quantity of rooms in a TinyMUD can be fantastically large, the quality is
|
||
generally very low.
|
||
|
||
TinyMUD has several clients written for it - most of which work with
|
||
all its descendents - and half a dozen or so bots. Some of these bots are
|
||
tightly coupled to the program, able to dispense pennies etc., and thus are
|
||
prone to causing crashes.
|
||
|
||
Ardent TinyMUD players see their game as the pinnacle of achievement
|
||
for MUAs. At the bottom end of the evolutionary scale are CB chatline
|
||
programs; next come systems with rooms, allowing local conversations and some
|
||
degree of privacy; higher up, basic commands like "who" and "look" are present;
|
||
higher still are games, with objects, more sophisticated commands, and rooms
|
||
linked together so that they can be perceived as a complete structure; most
|
||
sophisticated of all are the systems that allow the user to create rooms,
|
||
objects, and complete scenarios "limited only by the imagination of the
|
||
builder".
|
||
|
||
This evolutionary view of things completely misses the point: in order
|
||
for room-creation to be worth anything, there has to be a user: commodities are
|
||
valueless if they cannot be sold. TinyMUDs have no-one using the products of
|
||
creation, and are therefore little more than chatlines with rooms as
|
||
conversation pieces. They're no more games than would be an illustrated
|
||
on-line discussion of amateur artists' latest masterpieces. TinyMUDs are indeed
|
||
limited only by the imagination of the builder - with heavy emphasis on the
|
||
word "limited".
|
||
|
||
TinyMUDs have a short lifespan, and operate like slash-and-burn
|
||
agriculture: once a site has been farmed by a TinyMUD, thousands of players
|
||
have been either hooked on TinyMUDs or put off all MUAs forever. The addicts
|
||
will choose another site elsewhere, the rest are effectively lost.
|
||
|
||
As an example, consider two related TinyMUDs, Islandia and BloodMUD.
|
||
They had the same seed, but grew in opposite directions. The fact that they
|
||
are both regarded as "classic" TinyMUDs gives testimony to the ephemerality of
|
||
such MUAs on InterNet.
|
||
|
||
Islandia began as recently as January 1990. By its close in November
|
||
1990, it was regarded as a "tradition" among TinyMUD users. It had as its core
|
||
a 1000-object (ie. rooms, exits and portable objects) database called
|
||
TinyBASE. This was put on general release to make the task of starting up a
|
||
TinyMUD from scratch easier.
|
||
|
||
Islandia started at Berkeley, but was moved to different sites as it
|
||
increased in size. It was constantly added to, and grew to be huge. In the
|
||
month of October, it had 1,503 players (from a total of 3,271) and 14,900 rooms
|
||
- a phenomenal size for a MUA. However, of those 14,900 rooms, only 7,503 were
|
||
used that month...
|
||
|
||
Islandia was a friendly place, with friendly people, and famed for its
|
||
many beautifully designed rooms. Its maintainers scoured the database removing
|
||
useless or incomplete creations, trying to keep it to a manageable size and
|
||
reasonably consistent. However, they finally decided to take the system down
|
||
simply because, despite their efforts, it had grown too large; besides, they
|
||
were wearying of trying to trim the database in the face of its relentless
|
||
growth towards full capacity.
|
||
|
||
The maintainers also felt that the game was too old. People were using
|
||
the system as a means to annoy others, which was taken as a sign of decay.
|
||
Since TinyMUDs offer no facilities for game management, this fate eventually
|
||
befalls all such programs, except in the case where being nasty is the whole
|
||
point of playing.
|
||
|
||
Such was indeed the case with BloodMUD. The TinyBASE database was taken
|
||
as a starting point, and developed along themes of blood, violence and sleaze.
|
||
Rooms were deliberately corrupted by other players, with special attention
|
||
giving to vandalising TinyBASE. BloodMUD was a reaction to the "nice"
|
||
atmosphere that pervaded Islandia - and was a lot more fun to play. It finally
|
||
disappeared when the database was accidentally deleted, but by then it had sunk
|
||
into depravity.
|
||
|
||
By giving game-writing powers to anyone and everyone, it was hoped that
|
||
TinyMUD would be a means of promoting individual expression and group
|
||
interaction. It was a brave attempt, but it didn't work. Instead, TinyMUD has
|
||
probably done more harm than good, at least in the short term, with many
|
||
American academics growing up holding narrow views of what constitutes a MUA.
|
||
On a commercial network, a game like TinyMUD would rapidly burn up as soon as
|
||
it acquired a modest user base.
|
||
|
||
Summary:
|
||
TinyMUD is not so much a MUA as a forum for conversation where
|
||
participants have pinned short pieces of prose on the wall for the benefit of
|
||
anyone with the inclination to read them. If this kind of MUA gets a strong
|
||
hold in the USA, it could set the industry back several years.
|
||
|
||
Quotes:
|
||
|
||
"TinyMUD isn't a MUD in the classical sense of the term; it isn't a
|
||
game. In TinyMUD, all people can really do is create things and
|
||
interact with others. It has built up a considerable following,
|
||
and today is perhaps the most popular MUD on the InterNet."
|
||
Bill Wisner [player]
|
||
|
||
"TinyMUD was written as a game. Jim Aspnes did not go 'Gee, I think
|
||
I will create a social environment that will replace reality and
|
||
have dozens of kids fail out of school because they are so
|
||
addicted by this game.'"
|
||
Edwin Huang [player]
|
||
|
||
"The *primary* value of TinyMUD is as an experiment in
|
||
computer-mediated social interaction."
|
||
Michael Mauldin [Julia author]
|
||
|
||
"TinyMUD: mainly social. Little programming available in objects,
|
||
false exits and fail messages being the main programmability.
|
||
It's simple, but could get boring."
|
||
Glenn Crocker [player]
|
||
|
||
"Combat, adventuring, levels etc. are not part of this game. It is
|
||
possible that you could add these features to the game, seeing as
|
||
the whole TinyM* series is notably more flexible (and consequently
|
||
less well defined as a gaming system) than any other I've seen."
|
||
Duncan Howard [MUD1 arch-wiz]
|
||
|
||
"One thing which draws people to TinyMUD is the dynamic room/object
|
||
creation, but AberMUD would *never* allow *everyone* to create
|
||
things. There is also a problem that AberMUD is a *much* more
|
||
complex program than I think TinyMUD will ever get to. Dynamic
|
||
room creation in an object-oriented type game is very hard to
|
||
implement because the game requires many more flags and such than
|
||
TinyMUD."
|
||
Michael Barthelemy [player]
|
||
|
||
"With many people allowed to build freely, you get problems with
|
||
non-finished parts of the world and parts that are totally
|
||
different in character from the rest of the game. Walking from a
|
||
fantasy castle to an SF setting or finding a large joystick in the
|
||
centre of the castle may be fun the first couple of times, but it
|
||
kills the atmosphere."
|
||
Jorgen Holmberg [player]
|
||
|
||
"I have personally received pages from people who're sorry that
|
||
Islandia has to go and would like us to keep it going."
|
||
Conrad Wong [Islandia maintainer]
|
||
|
||
"BloodMUD was a fun place, near anarchy, as close as one could get.
|
||
People did horrible things and generally broke MUD taboos whenever
|
||
possible. It was not a MUD for socialisation or exquisite
|
||
building, it was a MUD for being nasty and killing. ... In short,
|
||
it was an excellent place."
|
||
Martin Terman [player]
|
||
|
||
"I put the kill command in when I was still assuming ... it would
|
||
be difficult to detect disconnects. It was called 'kill' as a joke
|
||
- and I assumed that putting a 100p charge on it would keep people
|
||
from using it very often."
|
||
Jim Aspnes [author]
|
||
|
||
"Eventually they [TinyMUDs] are going to get too big for their
|
||
servers, no matter how large they already are. ... Smaller MUDs
|
||
are at the low part of the exponential growth curve, and have a
|
||
great deal more life ahead."
|
||
Conrad Wong [Islandia maintainer]
|
||
|
||
"If you have a big MUD with 10,000 rooms and things enough to keep
|
||
you happy 'til doomsday, the players won't look for them. After
|
||
the initial fun wears off, they stop playing and start chatting,
|
||
never to play again."
|
||
Jorgen Holmberg [player]
|
||
|
||
"Nobody pays attention to building on Tiny*s, except for newbies
|
||
occasionally, but they're lowly peons and soon grow out of it
|
||
anyway. So nobody builds there."
|
||
Patrick Wetmore [player]
|
||
|
||
"I came across a room with an intriguing name. When I looked, I saw
|
||
"dir1 dir2 dir3 dir4 dir5". After typing "dir1" I was then
|
||
presented with another list of about 35 names (trying the other
|
||
directions, I was presented with similar sized lists of different
|
||
names). I picked one name and typed it in, and was suddenly taken
|
||
into someone's domain. The size of each domain was limited only
|
||
by the owner's imagination and the number of pennies they had
|
||
available. When it dawned on me that each room behind the numbered
|
||
portals were actually links to created kingdoms and the like, the
|
||
sheer enormity of the game took my breath away."
|
||
Comms Plus! [magazine]
|
||
|
||
|
||
5.7 TinyMUCK.
|
||
|
||
Name: TinyMUCK
|
||
Importance: 2
|
||
Author(s): Stephen White,
|
||
"Lachesis"
|
||
Location: InterNet
|
||
Brigadoon dante.cs.uiuc.edu
|
||
CAMUCK flounder.berkeley.edu
|
||
FurryMUCK hobbes.catt.ncsu.edu
|
||
MbongoMUCK mbongo.ucsd.edu
|
||
MedMUCK thesis2.hsch.utexas.edu
|
||
Pegasus l_cae05.icaen.uiowa.edu
|
||
QuartzPARADISE quartz.rutgers.edu
|
||
TinyHORNS bashful.cc.utexas.edu
|
||
|
||
Brief Description:
|
||
TinyMUD with better building.
|
||
|
||
Historical Notes:
|
||
Version 1.0 was written by White, however he has left the project and
|
||
there is now a programming team developing the system, headed by "Lachesis".
|
||
|
||
Review:
|
||
TinyMUCK is a version of TinyMUD that has been drastically modified to
|
||
make building more powerful and controllable. Players need to have the "mucker"
|
||
bit set by a wizard, which enables them to "muck about" with the game. Thus,
|
||
visitors and casual players are denied the ability to wreak havoc (although if
|
||
they really want to, there's little to stop them once granted the mucker bit).
|
||
TinyMUCK is very popular, and people starting up their own MUA these days
|
||
usually choose it in preference to TinyMUD.
|
||
|
||
The big difference between TinyMUCK and TinyMUD is programmability.
|
||
TinyMUD provides users with very basic creation facilities, but TinyMUCK has
|
||
its own interpreted programming language, TinyMUF ("Multi-User Forth"). This is
|
||
flexible and powerful, but has a reputation of being difficult to use.
|
||
|
||
TinyMUF (or just MUF) is basically the same as Forth, with a few new
|
||
library routines. It has three types of constant: integer, string and database
|
||
reference (an index into the database that is unique to every game object). The
|
||
language is stack-based, with library routines that operate on the stack (eg. +
|
||
pops off two elements, and pushes back their sum). Variables are static, and
|
||
there are functions to set and fetch them; variables' names (addresses) need to
|
||
be dereferenced to obtain the values they hold. MUF has a limited "if-then"
|
||
construct, but no "if-then-else". The game-specific library routines do things
|
||
like print a string on someone's screen. There is some protection offered to
|
||
players' creations in that "important" properties of objects cannot be modified
|
||
except by their creator.
|
||
|
||
To make programming easier, there is an on-line, line-oriented editor
|
||
built in. Source code is stored, which means tried-and-tested creations can be
|
||
moved easily to other TinyMUCKs. MUF programs tend to be longer than in most
|
||
MUAs - a simple slot machine (gambling pennies) is, for example, around 150
|
||
lines long. TinyMUCK can read TinyMUD databases, but not vice-versa.
|
||
|
||
TinyMUCK comes with plenty of documentation, and compared to other
|
||
building-oriented MUAs on InterNet looks rather attractive. It works, and it
|
||
can perform many powerful tricks. Its problem is that the people doing the
|
||
building have little experience of a thorough, well-written MUA. The best
|
||
example of this comes from TinyMUCK's own advertisement on InterNet: under the
|
||
headline "Can *your* MUD do this?" was a short transcript of a TinyMUCK session
|
||
where the player created a "camera" object, took a "photograph" of another
|
||
object with it, and then "projected" back the image. This is genuinely
|
||
impressive, except the photograph was of a red rose "with the fragrance of
|
||
spring". This lack of attention to detail ensures that unless there is strict
|
||
quality-control from above, any MUA which allows arbitrary, unchecked additions
|
||
to its database is going to suffer severe problems maintaining overall depth.
|
||
|
||
Summary:
|
||
TinyMUCK is a decided improvement on TinyMUD, but it's really just one
|
||
short step on the long road back to LPMUD-like MUAs. The sooner programmers of
|
||
TinyMUD derivatives realise this, the better.
|
||
|
||
Quotes:
|
||
|
||
"Why wait for 'more powerful' MUDs when you can have all this?"
|
||
TinyMUCK 2.0 [promotional material]
|
||
|
||
"TinyMUCK 2.0 is better documented than any other MUD in public
|
||
distribution."
|
||
TinyMUCK 2.0 [promotional material]
|
||
|
||
|
||
5.8 TinyMUSH.
|
||
|
||
Name: TinyMUSH
|
||
Importance: 2
|
||
Author(s): Larry Foard
|
||
Location: InterNet
|
||
Sanctuary valkyrie.ecn.uoknor.edu
|
||
TinyCWRU solarium.scl.cwru.edu
|
||
TinyMUSH sigh.berkeley.edu
|
||
TinyTIM grape.ecs.clarkson.edu
|
||
ToonMUSH uokmax.ecn.uoknor.edu
|
||
TwinPeaks corona.ecn.uoknor.edu
|
||
|
||
Brief Description:
|
||
TinyMUD with modifications.
|
||
|
||
Historical Notes:
|
||
Another approach by the Berkeley group to making TinyMUD usable.
|
||
|
||
Review:
|
||
TinyMUSH is an enhancement to TinyMUD that is easier for beginners to
|
||
use than is TinyMUCK, but which irritates trained programmers. It differs from
|
||
TinyMUD primarily in that it provides daemons that can be programmed to fire
|
||
when an event occurs. This is similar to an AI technique, production systems,
|
||
however in TinyMUSH the production rules are called V-functions. They are
|
||
short pieces of code that provide a means of storing, changing and displaying
|
||
information. Some fields are expected for all objects, such as what happens
|
||
when it is dropped, killed, or listened to.
|
||
|
||
Recognising that in enormous databases players rarely bump into each
|
||
other by accident, and that normal travel between rooms can involve a string of
|
||
thirty or more directions, TinyMUSH has more liberal teleportation rules than
|
||
TinyMUD, enabling players to materialise in other players' creations without
|
||
permission.
|
||
|
||
TinyMUSH does have one kind of object that may be of general
|
||
applicability in MUAs - the puppet. This is an item that can relay information
|
||
to players. Example uses in a fantasy setting would be a crystal ball or a
|
||
magic-user's familiar. Although some of the advanced UK MUAs have similar
|
||
objects, most do not.
|
||
|
||
TinyMUSH is a nice idea, and the notion that one small change can cause
|
||
great changes to occur elsewhere in the database is attractive. However,
|
||
programming this kind of system and controlling the interactions between
|
||
daemons is a nightmare even if there's only one programmer: with lots of people
|
||
programming objects, it will soon be virtually impossible for anyone to predict
|
||
the effects of actions or figure out the cause of some change. The problem goes
|
||
away if the changes that daemons can make are limited, but then so does all the
|
||
power.
|
||
|
||
A version of TinyMUSH runs on a public-access bulletin board in
|
||
Toronto.
|
||
|
||
Summary:
|
||
A worthy attempt, but, inevitably, destined for obscurity.
|
||
|
||
Quotes:
|
||
|
||
"When a user does X to Y, the MUSH can be programmed to fire off
|
||
all kinds of small 'programs'. I use quotes, because these aren't
|
||
so much programs as one-line attachments to object Y. Qualities
|
||
maybe."
|
||
Duncan Howard [MUD1 arch-wiz]
|
||
|
||
|
||
5.9 TinyMOO.
|
||
|
||
Name: TinyMOO
|
||
Importance: 3
|
||
Author(s): Stephen White
|
||
Location: Internet belch.berkeley.edu
|
||
|
||
Brief Description:
|
||
TinyMUD with better building.
|
||
|
||
Historical Notes:
|
||
MOO stands for "MUD, Object-Oriented". TinyMOO is an enhancement to
|
||
TinyMUD, written in 1990. White also wrote the original TinyMUCK.
|
||
|
||
Review:
|
||
The main difference between TinyMOO and TinyMUD is that it transfers
|
||
the power to create objects away from the system administrators and towards the
|
||
players who are builders.
|
||
|
||
Objects are implemented in a simple, C-like language, and can easily be
|
||
specialised (so that even non-programmers can create). This is achieved by a
|
||
class hierarchy and an inheritance (ie. object-oriented) approach.
|
||
|
||
TinyMOO is not yet distributed publicly.
|
||
|
||
Summary:
|
||
Another attempt to make TinyMUD safer, TinyMOO is basically a means of
|
||
allowing people to share a programming experience, chat a little, and do
|
||
nothing else.
|
||
|
||
Quotes:
|
||
|
||
"The current version is stable, however I'm in this bad habit of
|
||
tinkering and tinkering with it without releasing it."
|
||
Stephen White [author]
|
||
|
||
|
||
5.10 UberMUD.
|
||
|
||
Name: UberMUD
|
||
Importance: 3
|
||
Author(s): Marcus Ranum
|
||
("Jerry_Cornelius")
|
||
Location: none
|
||
|
||
Brief Description:
|
||
An experiment in MUA building language design.
|
||
|
||
Historical Notes:
|
||
Began as a project to improve on TinyMUD. It was written from scratch,
|
||
and generated a lot of interest - Ranum was willing to give every idea a
|
||
hearing. A mailing list was established to organise messages between interested
|
||
parties, and when UberMUD was completed the mailing list enlarged its brief and
|
||
stayed on. So far, most of the discussions on it still concern UberMUD,
|
||
however. The Uber part of its name comes from the German, as in Ubermensch.
|
||
|
||
Review:
|
||
UberMUD was conceived as an alternative to TinyMUD, with much improved
|
||
building facilities. It incorporated many ideas, some of which were clearly
|
||
ridiculous but others of which showed sufficient promise to be included in many
|
||
post-UberMUD InterNet MUAs. In particular, its system of protecting objects
|
||
from misuse by others (using a form of permission inheritance) looks like
|
||
making an impact.
|
||
|
||
The UberMUD language - U - was low-level, a cross between Forth and C
|
||
(Forth semantics, C syntax). There were no predefined data structures, as
|
||
everything was implemented directly in U, nothing hard-wired. Objects were
|
||
atomic entities to which properties could be attached; that meant that things
|
||
like inheritance had to be implemented in U (MUD2's MUDDLE language, which has
|
||
the same overall aims as U, has inheritance built in automatically: this helps
|
||
with function matching). U's only predetermined factor was the order in which
|
||
programming-language objects were searched to find code to execute: verb first,
|
||
noun second, player third.
|
||
|
||
Despite all the ideas that were included in UberMUD, some simple things
|
||
were left out (gender pronoun substitution being the most glaring omission).
|
||
It had the capacity to implement them, but no-one put them in. The mistake made
|
||
was to believe that by having a flexible implementation language that allows
|
||
pretty much anything to be phrased in it, everything necessary actually would
|
||
be phrased in it. Definition languages have to be either specific (ie. with
|
||
much assumed, but able to guide a new programmer in database design) or general
|
||
(ie. assuming nothing except that the programmer knows what is to be
|
||
programmed).
|
||
|
||
Nowadays, UberMUD is maintained as the focus for discussions on MUAs in
|
||
general, but it has signally failed thus far to widen the topic of discussion
|
||
beyond UberMUD itself.
|
||
|
||
|
||
Summary:
|
||
UberMUD is available as a teaching tool for people wishing to write
|
||
their own MUAs, but proved too cumbersome itself to use in practice.
|
||
|
||
Quotes:
|
||
|
||
"The author seems to have mostly lost interest now that the code is
|
||
finished. Today, the code is used more as an example of what can
|
||
be done with MUDs than an actual production system."
|
||
Bill Wisner [player]
|
||
|
||
"UberMUD has implemented the biggest advance of all. It requires
|
||
you to write the code on your local machine and upload it to the
|
||
game, thereby automatically saving a copy that can be uploaded
|
||
onto a second machine just as easily."
|
||
Lauren Burka [player]
|
||
|
||
"The Ubermud mailing list is now, more generally, called mudwiz. It
|
||
has expanded its mandate to include wizards from all MUDs, not
|
||
just Uber."
|
||
Clay Luther [mudwiz postmaster]
|
||
|
||
"I'm pretty much tired of working on it, and don't plan on doing
|
||
much more with it than I have (I wanted to prove it could be done,
|
||
mostly)."
|
||
Marcus Ranum [author]
|
||
|
||
|
||
5.11 Other InterNet MUAs.
|
||
|
||
The MUAs here are either one-off systems not on proper public release,
|
||
or vapourware. Suspected spoof MUAs (eg. CoreMUD) have been omitted.
|
||
|
||
|
||
Name: Cthulhu
|
||
Author(s): Bill Burdick, Mitch Adler,
|
||
Roy Riggs
|
||
|
||
Historical Notes:
|
||
The first version was written in Spring 1988 in C by Riggs. It was
|
||
essentially just a souped-up TinyMUD. In autumn 1988, the game was rewritten in
|
||
a version of object-oriented Lisp. Spring 1989 saw the first version of Mob,
|
||
the game's database definition language; this was based on Objective C, and was
|
||
scrapped. The second version of Mob came out Autumn 1989, based on Smalltalk
|
||
and written in Lisp. The game itself was written in Mob shortly afterwards; the
|
||
Mob interpreter was rewritten again in Spring 1990, using C. The game was
|
||
scheduled for release Summer 1990.
|
||
|
||
Review:
|
||
If Cthulhu, or whatever it is eventually called, delivers all it
|
||
promises it will roughly on a level with a slightly above average UK MUA.
|
||
Nevertheless, this is good going to say that the programming team has no access
|
||
to these games for ideas (except the rather obsolete AberMUD), and has
|
||
developed its system from scratch.
|
||
|
||
Cthulhu supposedly has intelligent mobiles, weapons, armour, clothing,
|
||
spells and glowing objects. There is some depth insofar as containers are
|
||
concerned, since they can have a rigid (box) or floppy (bag) shape, however
|
||
there is nothing similar to MUD2's transparency, for example, and the
|
||
containers have no lids. There is a powerful form of "attach" available,
|
||
although granting this to ordinary players is perhaps rather foolhardy on the
|
||
designers' part.
|
||
|
||
There is an on-line system for room building, with players having
|
||
control only over their own creations. This appears primarily to be because
|
||
such functions are de rigeur on InterNet MUAs these days.
|
||
|
||
The wish-list of things on the drawing board includes many
|
||
standard-issue features from the better UK MUAs. Using "look" to see in another
|
||
room, and printing text messages modulo a player's ability to sense what they
|
||
contain is nothing new in the MUA industry. Nevertheless, if such seemingly
|
||
"advanced" features gained a foothold on InterNet MUAs, it may hasten the day
|
||
when the vacuous TinyMUD-like MUAs are abandoned and more traditional games
|
||
replace them.
|
||
|
||
Summary:
|
||
Sounds good, but as yet unseen.
|
||
|
||
Quotes:
|
||
|
||
"We can't sell anything written on a Purdue machine. We haven't
|
||
been giving out any sources either. Basically, we are too
|
||
dissatisfied with the old stuff to release it to the public eye,
|
||
and none of the new stuff is finished yet."
|
||
Roy Riggs [author]
|
||
|
||
|
||
Name: DUM II
|
||
Author(s):
|
||
Location: InterNet
|
||
AdaDUM II legolas.cs.umu.se
|
||
|
||
Brief Description:
|
||
LPMUD-like MUA with no on-line building.
|
||
|
||
Notes:
|
||
DUM II is something of a reaction to the unrestricted, unchecked
|
||
building possible in TinyMUD and, to a lesser extent, LPMUD. All wizzes have
|
||
privileges to build, however they may only submit their designs to the game's
|
||
maintainers ("gods"). These people write any necessary code, make
|
||
modifications for consistency, and consult with the designer if they feel their
|
||
suggestions need significant change or are inappropriate. New areas are then
|
||
thoroughly playtested before being opened.
|
||
|
||
This form of editorial control is, perhaps, the best way to ensure that
|
||
room-building progresses naturally, and linearly over time. Its main
|
||
disadvantage is that the gods may not have the time required to deal with every
|
||
submission speedily or fairly, and they need to be skilled programmers. Some
|
||
players may also be tempted to take advantage of them.
|
||
|
||
Quotes:
|
||
|
||
"This [gods editing suggestions], and the fact that zones are not
|
||
opened until play-tested, makes the general quality of zones and
|
||
puzzles high."
|
||
Jorgen Holmberg [player]
|
||
|
||
|
||
Name: MIDgaard
|
||
Author(s): Andrew Plotkin
|
||
|
||
Brief Description:
|
||
A shell of a MUA, meant for complex building.
|
||
|
||
Historical Notes:
|
||
Finished in Spring 1990, due to go up in the Summer but so far nowhere
|
||
to be seen. Designed to be run as a commercial system.
|
||
|
||
Review:
|
||
MIDgaard is a basically empty game, like TinyMUD, with the intention
|
||
that players add to it themselves. It is object-oriented with an extensible
|
||
classification system, and its power lies in the ability of players to program
|
||
objects.
|
||
|
||
The game has nothing substantial built in - no spells, combat, persona
|
||
details or the like. This sort of thing is up to the game builders to
|
||
implement. The game is reported to have a tight security system that ensures
|
||
the zones people build are distinct from one another and cannot be spoiled by
|
||
other builders. This implies that objects created by one builder cannot be used
|
||
in someone else's zone, although any game running under those conditions would
|
||
be infuriating to play.
|
||
|
||
MIDgaard's authors are obviously pleased with their game, since they
|
||
hope to run it commercially (charging around $20/month flat fee - this is
|
||
comparable to commercial UK MUAs). Object creation, as it uses limited hardware
|
||
resources (disc space etc.), will be surcharged.
|
||
|
||
However, MIDgaard's rationale is fundamentally flawed. The authors
|
||
think that because they have a game which compares well with TinyMUD, it will
|
||
attract players in the real world. However, as has been noted elsewhere, room
|
||
building is not really an interesting or fruitful thing for people to do -
|
||
TinyMUD's success is entirely down to the fact that it allows people to
|
||
communicate over a distance while being less of a CPU hog than systems that do
|
||
it a whole lot better. If MIDgaard's programmers think they can sell a simple
|
||
chatline under the guise of its being a game, they are in for a tragic
|
||
surprise.
|
||
|
||
Summary:
|
||
Over-rated, and also behind the times.
|
||
|
||
Quotes:
|
||
|
||
"Since the maintainers of MIDgaard will be employed by MIDgaard, we
|
||
will have great motivation to keep things running smoothly, and
|
||
make interesting stuff."
|
||
Andrew Plotkin [author]
|
||
|
||
|
||
Name: PennMUD
|
||
Author(s): Charles Hannum ("MycroftXXX"),
|
||
Michael Barthelemy ("Edheler"),
|
||
David Singh ("Cyric"),
|
||
Al Catalfamo ("Satan"),
|
||
and 10 others
|
||
|
||
Brief Description:
|
||
On-line AD&D.
|
||
|
||
Historical Notes:
|
||
PennMUD took the InterNet world by storm in Spring 1990, when its
|
||
incredible design was announced. After a flurry of scepticism, which PennMUD's
|
||
promoters answered in disparaging tones that alienated them from the rest of
|
||
the InterNet MUA community, they took umbrage and clamped up. Nothing has been
|
||
heard of them since, except that the authors are no longer at the university
|
||
(Pennsylvania).
|
||
|
||
Review:
|
||
Take the AD&D handbooks, enumerate all the ideas without considering
|
||
their implementation, and you'll end up with a fair approximation to PennMUD
|
||
(also called NeXTMUD on occasion). Detail was everything (but, for the most
|
||
part, unnecessary).
|
||
|
||
There were to be 7 basic character classes, 6 different races, 9 basic
|
||
statistics, an unspecified number of languages, spells with verbal and physical
|
||
components, a game divided into "days" of 4 hours real-time duration,
|
||
encumbrance affecting speed of movement, a currency with exchange rates for
|
||
different coin types, a barter system, wet/dry and temperature factors for
|
||
rooms, rolling resets, objects saved when you quit (with periodic persona file
|
||
searches to return "special" objects that stayed out of play too long),
|
||
vehicles, and several towns. Object creation was to be available, by extending
|
||
the level system beyond god (ie. wiz). And this list just scratches the
|
||
surface.
|
||
|
||
Not all proposals were completely unimplementable or totally
|
||
undesirable, but most were. One neat idea that may work in existing MUAs is
|
||
limiting the number of objects that can be seen in a dark room depending on the
|
||
intensity of the persona's light source.
|
||
|
||
PennMUD combined all the worst things from MUAs with the worst things
|
||
from games like Island of Kesmai. Fortunately, its specification team was so
|
||
ambitious that it will be many years before anything as complex as PennMUD
|
||
becomes publicly available. By then, traditional MUAs will hopefully have a
|
||
strong enough toehold that when large, multinational games companies enter the
|
||
field they will not ignore the hidden-depth, freestyle MUAs in favour of the
|
||
explicit-bells-and-whistles role-playing monsters.
|
||
|
||
Summary:
|
||
Archetypal vapourware. All impossible design, and no substance
|
||
whatsoever. The worst is, even if it had been written it wouldn't have been
|
||
much fun to play due to the fearsome constraints it would have imposed in the
|
||
name of role-playing.
|
||
|
||
Quotes:
|
||
|
||
"We are still working on the god/demigod commands and do not have a
|
||
list made up as of yet. If you can think of any commands that you
|
||
would like to see implemented at these levels, please note me on
|
||
them with a full description of the command."
|
||
Michael Barthelemy [project designer]
|
||
|
||
"To keep the game moving, you might consider dilating time for rest
|
||
and movement commands. The amount of realism that is lost is not
|
||
nearly as important as the amount of boredom that is alleviated."
|
||
Andrew Thomas [would-be player]
|
||
|
||
|
||
Name: SMUG
|
||
Author(s): Jim Aspnes
|
||
|
||
Notes:
|
||
SMUG (Small Multi-User Game) was written by Aspnes as a would-be
|
||
successor to his own TinyMUD. The primary goal was to include a programming
|
||
language that ran at a high speed, but which was safely accessible to all
|
||
players. The language includes an inheritance hierarchy, but has fewer tools
|
||
in general than either TinyMUCK or LPMUD.
|
||
The project ground to a halt in mid-1990, so Aspnes recently made the
|
||
sources available as ideas material for other MUA writers.
|
||
|
||
Quotes:
|
||
|
||
"A secondary goal was to show that you didn't have to have 15,000
|
||
lines of code to do this."
|
||
Jim Aspnes author
|
||
|
||
|
||
Name: VAXMUD
|
||
|
||
Brief Description:
|
||
Standard MUD1 clone.
|
||
|
||
Historical Notes:
|
||
Written in 1987 by students at Strathclyde University, and distributed
|
||
in binary form only. It is still being added to.
|
||
|
||
Notes:
|
||
VAXMUD is written in Fortran, and runs only on VAX VMS systems. The
|
||
scenario it comes with is hard to customise, and the fact that source code is
|
||
unavailable makes it doubly unpopular.
|
||
The game saves objects carried when a player quits, a practice which in
|
||
general can lead to games being tied up for some considerable time.
|
||
|
||
|
||
Name: YAMA
|
||
Author(s): Alan Cox ("Anarchy")
|
||
|
||
Brief Description:
|
||
A program for writing MUAs.
|
||
|
||
Historical Notes:
|
||
Alan Cox's latest project, based on his experience in writing AberMUD.
|
||
|
||
Notes:
|
||
YAMA is intended to be used for writing MUAs, and in that sense it is
|
||
more properly described as a database definition language plus interpreter than
|
||
a game itself. It was written to be fast, efficient and powerful. It is also
|
||
reputedly difficult to learn. It is player-extensible, however its
|
||
programmability in this respect is not as good as, say, LPMUD.
|
||
YAMA is presently in beta-test.
|
||
|
||
Quotes:
|
||
|
||
"It has been aptly described as an assembly language for MUDs."
|
||
Bill Wisner [playtester]
|
||
|
||
"It is a game in the spirit of the original MUD; TinyMUD players
|
||
need not apply."
|
||
Bill Wisner [playtester]
|
||
|
||
6. Reviews - Non-MUAs.
|
||
|
||
Name: Air Warrior
|
||
Location: GEnie
|
||
Pricing Structure: $35/hour 8am - 6pm
|
||
$5/hour 6pm - 8am
|
||
(no UK access point)
|
||
|
||
Brief Description:
|
||
Multi-player flight simulator.
|
||
|
||
Historical Notes:
|
||
Written by the Kesmai Corporation, who also wrote Island of Kesmai and
|
||
Megawars III.
|
||
|
||
Review:
|
||
Flight simulators are usually best-sellers for single-user computer
|
||
games. Air Warrior is a normal flight simulator with a comms package built in,
|
||
a client program of the most sophisticated kind yet developed. Why the Kesmai
|
||
Corporation haven't done something similar for their other multi-player games
|
||
is a complete mystery.
|
||
|
||
All the work is done by the user's home machine. Information is passed
|
||
from the host computer, and is assimilated into the user's machine's database;
|
||
the display is updated accordingly. Commands are processed and passed back up
|
||
the line to the host. The user's computer is therefore acting as a front-end
|
||
for the game; furthermore, it is smart in that it generates its display itself
|
||
- sending complete screen images down the telephone line in real-time is not
|
||
yet possible, given the narrow bandwidth of present-day telephone networks.
|
||
Indeed, even if it were possible it might not be desirable - Air Warrior has an
|
||
off-line practice mode built in, which would be impossible to use in a system
|
||
that obtained all its graphics from a host machine.
|
||
|
||
The terminal software necessary to play Air Warrior is available for
|
||
the Macintosh, Amiga, Atari ST and IBM PC. Fancy instrument displays can be
|
||
downloaded from an on-line database, or designed by the user.
|
||
|
||
Summary:
|
||
State-of-the-art IMPCG. The game itself isn't particularly brilliant,
|
||
but the graphics are stunning and there's nothing else quite like it - yet.
|
||
|
||
Quotes:
|
||
|
||
"Where conventional multi-user games like MUD or Micronet's Shades
|
||
can only portray their game-world using text messages, Air Warrior
|
||
gives you all the animated 3D graphics and sound you'd expect from
|
||
any single-player flight sim."
|
||
ACE [magazine]
|
||
|
||
"The first thing you need to realise about aerial combat is that
|
||
the main objective is to survive. Shooting down enemies is just
|
||
icing on the cake."
|
||
Cap'n Trips [player]
|
||
|
||
"One thing's for sure: US gamers are taking to the game in their
|
||
droves, joining GEnie and possibly even buying modems just so they
|
||
can play it. Let's hope it - or something similar - reaches
|
||
Britain soon!"
|
||
ACE [magazine]
|
||
|
||
|
||
Name: Astroid
|
||
Location: Minitel
|
||
|
||
Brief Description:
|
||
Multi-player on-line arcade game.
|
||
|
||
Review:
|
||
Astroid (formerly Astro) marks Third Millenium Systems' entry into the
|
||
non-MUA interactive computer game market (they also produce Shades and Trash).
|
||
Unlike all other commercial games of this type except Air Warrior, it was
|
||
written specifically to be used with client software. Players thus get quality
|
||
graphics and sound effects if they have the appropriate disc and an IBM PC or
|
||
an Atari ST.
|
||
|
||
The player's screen is a pilot's eye view of the cockpit and the
|
||
universe. This looks like a flight simulator, but isn't - all action takes
|
||
place within two-dimensional planes.
|
||
|
||
The game itself is a standard arcade-style shoot-em-up with exploration
|
||
and mineral mining thrown in. There is ship-to-ship communication that allows
|
||
players to talk to one another, but Astroid's fast pace leaves little time for
|
||
such pleasantries.
|
||
|
||
Summary:
|
||
A definite step in the right direction, but it'll be a long time before
|
||
such games are widely available in the UK.
|
||
|
||
Quotes:
|
||
|
||
"Astroid is the most sophisticated game of its kind today, and in
|
||
its underlying architecture we see a glimpse of the potential
|
||
offered by developing network and terminal technologies for
|
||
interactive entertainment."
|
||
Mike Brown [Third Millenium Systems]
|
||
|
||
|
||
Name: BattleTech
|
||
Location: Chicago BattleTech Centre
|
||
|
||
Brief Description:
|
||
Very high-technology arcade game.
|
||
|
||
Historical Notes:
|
||
Based on the BattleTech inter-robot role-playing game.
|
||
|
||
Review:
|
||
BattleTech is unlike all the other games described in this report.
|
||
Rather than being played over the telephone lines, players interact over an
|
||
ethernet LAN. Each sits at a console in a cockpit, and they battle in real-time
|
||
over a simulated 10 miles by 10 miles landscape in assorted weather conditions.
|
||
Although the system is not quite complete, and is LAN-based, the point is that
|
||
all it does could be implemented equally well over a sufficiently wide-band
|
||
telephone network.
|
||
|
||
The BattleTech console has six audio speakers, one of which is for
|
||
inter-player communication. There is a microphone, a numeric keypad for
|
||
punching in missile co-ordinates and a joystick for aimed laser fire. Movement
|
||
is via a hand-held throttle and two foot pedals. Visually, there is one primary
|
||
screen, several secondary screens, and numerous illuminated instruments.
|
||
|
||
Players work in teams, up to four a side. There's only one BattleTech
|
||
centre at the moment, but others are planned.
|
||
|
||
Summary:
|
||
IMPCGs will only have come of age when products like BattleTech are
|
||
available to home users over the telephone network.
|
||
|
||
Quotes:
|
||
|
||
"It drives like a tank."
|
||
Ross Babcock [technical director]
|
||
|
||
"This is the game of futuristic mechanised combat we all know and
|
||
love - but this time it's for real!"
|
||
GMI [magazine]
|
||
|
||
|
||
6.1 Fantasy Sports.
|
||
|
||
Name: Football/Hockey/Baseball
|
||
Location: CompuServe,
|
||
USA Today Sports Center
|
||
|
||
Brief Description:
|
||
Simulations of sports leagues.
|
||
|
||
Review:
|
||
There are several Fantasy Sports available on US networks, but as they
|
||
are all basically the same idea their reviews have been combined.
|
||
|
||
Fantasy Sports' players take control of a sports team and guide it
|
||
through a season of matches against other players. Team members can be
|
||
transferred and new members drafted, paid for using game money. Team selection
|
||
is made before each match, and the games are played to coincide with matches in
|
||
the real world.
|
||
|
||
Participating in Fantasy Sports takes little time - a few minutes a
|
||
day. The overall goal is to win the league title, and there is usually a
|
||
real-life prize associated with it - a stay at a baseball training camp, for
|
||
example.
|
||
|
||
Fantasy Sports are usually uncomplicated, and they are not properly
|
||
interactive. They do, however, generate a lot of discussion among players, and
|
||
were the games displayed graphically they would attract an even wider audience.
|
||
|
||
Summary:
|
||
Multi-user, but not really interactive. When interactive versions do
|
||
come out in the USA, someone there will make themselves an awful lot of money.
|
||
|
||
Quotes:
|
||
|
||
"The most exciting part was when I won the BERRA National League
|
||
Championship in 1987. Unfortunately, I wasn't able to defend my
|
||
title in 1988; I came in fourth. Other than that, it's exciting
|
||
when one of your pitchers throws a two-hit shutout, or when your
|
||
catcher hits two home runs and six RBIs in one game, and you know
|
||
that your team has been helped in the overall standings as a
|
||
result."
|
||
Bill Gallagher [player]
|
||
|
||
"When Boomer Esiason limps off the field with a sprained ankle or
|
||
Greg Swindell develops arm trouble, the Fantasy Sports owner has
|
||
to find a way to bolster his team and continue to compete.
|
||
Replacing Esiason or Swindell may mean gambling on an unproven
|
||
rookie, signing a free-agent or putting together a trade for a
|
||
seasoned veteran."
|
||
CompuServe [magazine]
|
||
|
||
|
||
6.2 Island of Kesmai.
|
||
|
||
Name: Island of Kesmai
|
||
Location: CompuServe
|
||
Pricing Structure: $12.50/hour plus
|
||
$9.40/hour for UK players
|
||
|
||
Brief Description:
|
||
First-generation graphics game.
|
||
|
||
Review:
|
||
Island of Kesmai (or IOK) is Compuserve's best-selling game - its
|
||
popularity exceeds that of British Legends, which came on-line later.
|
||
|
||
IOK is primarily a role-playing game. Beginners have to select from
|
||
various character classes and races (each of which have their advantages and
|
||
disadvantages), and they are assigned 6 property values (strength,
|
||
intelligence, dexterity, wisdom, stamina and constitution). The parallels with
|
||
AD&D are clear.
|
||
|
||
IOK is in many ways like a conventional MUA. Players move by typing in
|
||
directions, and there are commands to pick up, drop, examine and throw objects.
|
||
There is little breadth, true, and hardly any depth, but it does have
|
||
complexity enough to merit a 160+ page manual. Subtle differences between
|
||
character classes, and a range of effects dependent on players' statistics, do
|
||
give an impression of realism.
|
||
|
||
The main point about IOK, however, is its display. Rather than textual
|
||
room descriptions, IOK gives a bird's eye view of the area local to the player.
|
||
The game is grid-based, and players see a 6 by 6 matrix drawn using pairs of
|
||
ASCII characters. This may be incomplete, since areas not in line-of-sight are
|
||
not drawn.
|
||
|
||
The display is crude. Common features have their own symbols (eg.
|
||
walls are [], fire is **), but mobiles (critters) and players are simply listed
|
||
as letters, with a key to decode them printed alongside the map; this is
|
||
necessary because players can occupy the same square, and thus couldn't be
|
||
drawn graphically. There is some informational content in mobiles' names, eg.
|
||
!Nocha is of neutral alignment, +Nocha would be evil (and likely to attack).
|
||
|
||
There are client programs available which make playing IOK easier, and
|
||
which tart up the display. However, at present there is no software on general
|
||
release that produces quality graphics (an Amiga terminal driver has been made
|
||
available just this month, but so far only 6 people have downloaded it). This
|
||
is something which must surely come soon - if IOK were given Dungeon Master
|
||
graphics, for example, it would be almost irresistible. The game is structured
|
||
specifically for automatically-generated graphical displays, and it's amazing
|
||
that nothing beyond crude ASCII is used.
|
||
|
||
The atmosphere in IOK is enforced friendliness. Attacking other
|
||
players, while possible, produces howls of outrage and the attacker will become
|
||
a pariah. Communication over distance is not possible, so even if there are 50
|
||
people playing you can only talk to those in the same "room" as you.
|
||
|
||
Players in IOK progress by finding money, and using it to buy equipment
|
||
or training. There is no overall goal - the players just try to keep alive.
|
||
However, since some people have been playing for years, they can build up
|
||
incredibly powerful personae, and it is unlikely that they will ever die. Even
|
||
if they do, they will be resurrected automatically unless killed by a
|
||
flesh-eating mobile. In order to keep these long-term players from getting
|
||
bored, the game is continually added to, with new sections of increasingly
|
||
dangerous monsters and bigger rewards. This does have the effect of keeping
|
||
high-level players interested, but it makes the game even more daunting for
|
||
newcomers. Because of this, IOK has two games - basic and advanced.
|
||
|
||
The game does have resets, but they are over a long period of time - 60
|
||
days or so. Individual objects and puzzles can be reset on their own -
|
||
necessary, as players take them with them when they quit.
|
||
|
||
In many ways, IOK is like Rogue or Hack. It has a similar display,
|
||
similar commands, slightly more depth (mobiles that speak gibberish, mobiles
|
||
that can only be damaged by weapons made of a certain material), and is
|
||
multi-player. Nevertheless, even Hack is compulsive, and as IOK is
|
||
multi-player that makes it doubly so.
|
||
|
||
IOK appeals to people who like complex (yet often arbitrary)
|
||
interactions between objects, lots of detailed rules, and no descriptive text.
|
||
Were a large games company to muscle in on the play-by-modem scene, this is the
|
||
kind of game they'd probably go for. In the long term, it's a bad move because
|
||
IOK makes many mistakes - it can't go on expanding indefinitely, for example.
|
||
However, with a good client it could be very impressive for a few years, and
|
||
that would certainly be enough to make a large amount of money.
|
||
|
||
Summary:
|
||
Basically, Island of Kesmai is an average, role-playing style MUA, with
|
||
a crude graphical interface and not a great deal else. However, it is tuned to
|
||
perfection, and when a proper client is written it should be very impressive.
|
||
|
||
Quotes:
|
||
|
||
"In 2.5 years of playing, I've never been on-line when there
|
||
weren't at least 3 other players, and there are usually 10-60
|
||
players."
|
||
Dragon [magazine]
|
||
|
||
"When you become involved in Island of Kesmai, you find yourself
|
||
thinking of it not so much as a game but as a place."
|
||
Randy Eichman [player]
|
||
|
||
"Expect your first dragon-slaying outing to take a few hours. Your
|
||
adventure could end in glory or in a dragon's stomach, but chances
|
||
are you'll have a great time either way."
|
||
CompuServe [magazine]
|
||
|
||
"Kesmai's creators have fashioned a revolutionary experience."
|
||
Dragon [magazine]
|
||
|
||
|
||
|
||
Name: MegaWars III
|
||
Location: CompuServe
|
||
Pricing Structure: $12.50/hour plus
|
||
$9.40/hour for UK players
|
||
|
||
Brief Description:
|
||
Multi-player space warfare game
|
||
|
||
Historical Notes:
|
||
Written by the Island of Kesmai team, MegaWars III is a greatly
|
||
enhanced version of MegaWars I.
|
||
|
||
Review:
|
||
MegaWars III is, at heart, a multi-player version of the old Star Trek
|
||
game that was popular on mainframe computers in the late 1970s. More detail
|
||
have been added, with an economic system, troop landings, planets, gas giants
|
||
(for fuel), and an overall goal - to become emperor of the galaxy.
|
||
|
||
Resets are several weeks apart. Players colonise planets, raise
|
||
revenue, build more ships, and spread throughout the galaxy. Unlike Prestel's
|
||
StarNet, the game runs in real time and orders are not "batched"; even
|
||
experienced players must spend several hours a day playing if they are to stand
|
||
any chance of becoming emperor. For this reason, players usually join teams, so
|
||
that other team members can protect their growing empire while they're away.
|
||
|
||
The screen display is a simple ASCII bird's eye view. It's only really
|
||
essential for ship-to-ship combat, so can be turned off at other times. Its
|
||
size is adjustable, up to 32 by 32 squares. Again, there is no client software
|
||
for users, so any ideas of sprite-driven missiles racing across the screen and
|
||
exploding in vibrant colour must be dismissed: all you get on MegaWars III is
|
||
an exclamation mark if you're lucky.
|
||
|
||
CompuServe also have a very basic cut-down space combat game called
|
||
SpaceWAR. Unlike MegaWars III, however, it does not feature inter-player
|
||
communication, just high-speed combat.
|
||
|
||
Summary:
|
||
MegaWars III is basically a simple core, with lots of added detail that
|
||
significantly changes the gameplay. As with most cursor-addressing games, its
|
||
appeal would be greatly improved if it had specialist client software that
|
||
dealt with proper graphics, instead of relying on ANSI escape codes.
|
||
|
||
|
||
Name: NetHack
|
||
Location: InterNet
|
||
|
||
Brief Description:
|
||
Multi-player Hack.
|
||
|
||
Historical Notes:
|
||
Hack is a development of Rogue, a single-player game where the player
|
||
wanders around a computer-generated dungeon slaying monsters and casting
|
||
spells. NetHack is the multi-player version of Hack.
|
||
|
||
Review:
|
||
NetHack is one of a series of games developed from Rogue, and shares
|
||
many of the latter's features. Players are given an overhead view of their
|
||
dungeon level, and move around using arrow keys. Players are supposed to
|
||
co-operate in their attempts to find the lower reaches of the dungeon. There
|
||
is no direct communication between players within the game - it works best when
|
||
played by two people on adjacent terminals.
|
||
|
||
Work is beginning on the USA academic MUA circuit aimed at combining
|
||
NetHack with standard MUAs, eg. LPMUD. This should produce something along the
|
||
lines of Island of Kesmai, but with more traditional MUA features rather than
|
||
IOK's detailed role-playing orientation.
|
||
|
||
There are already two NetHack lookalikes with a MUA flavour. Myth was
|
||
written by Per Abrahamsen in Denmark using C++, and incorporates many classes
|
||
useful for such games; it is, however, rather primitive. Strathclyde
|
||
University has VAXMUF (Multi-User Fight), with 100 levels, 100 spells and using
|
||
ASCII graphics. Neither of these is as widespread as NetHack.
|
||
|
||
Other InterNet games based on Rogue are Larn, Moria and Omega, and
|
||
multi-player versions of these may be forthcoming in the near future.
|
||
Galacticomm bulletin boards already carry an ANSI-graphics game called
|
||
Androids!.
|
||
|
||
Summary:
|
||
Although there probably are people willing to pay to play NetHack, the
|
||
real developments will come when the game is merged with existing MUA
|
||
technology and is given a proper server.
|
||
|
||
Quotes:
|
||
|
||
"I tried linking up a TinyMUD to Hack. One was in ANSI C and the
|
||
other was in C. Although it did some really impressive stuff, it
|
||
failed as a 'good attempt' to get them to link up - but I believe
|
||
it is possible to do it."
|
||
Ashgon [player]
|
||
|
||
|
||
6.3 Sniper!
|
||
|
||
Name: Sniper!
|
||
Author(s): Steve Estvanik ("Yngvi")
|
||
Location: CompuServe
|
||
$12.50/hour plus
|
||
$9.40/hour for UK players
|
||
|
||
Brief Description:
|
||
Man-to-man World War II combat game.
|
||
|
||
Historical Notes:
|
||
Based on the TSR boardgame.
|
||
|
||
Review:
|
||
In Sniper!, players control not individuals, but a squad of
|
||
individuals, each with their own strengths and weaknesses. This is a growing
|
||
trend in single-user role-playing games. The player takes on the position of
|
||
the squad's commanding officer.
|
||
|
||
The game uses IOK-like cursor addressing to draw a 10 by 60 map on the
|
||
players' screens, however the game is difficult to play without having first
|
||
downloaded a copy of the full-sized map, of which the screen display is only a
|
||
part.
|
||
|
||
The game has a levels system: ranking points are given for each
|
||
engagement, and when a certain number have been achieved the player is
|
||
promoted. Whether a brigadier general would actually be involved in man-to-man
|
||
combat isn't at issue...
|
||
|
||
Sniper! is a two-player game. Players can play against the computer or
|
||
against themselves, or even watch other people play; however, they will
|
||
normally play against someone else. Missions can be either patrol, infiltrate
|
||
or specific, and can take place in different areas (Sicily, Normandy,
|
||
Ardennes), each with its own map. A game will normally last between 20 to 45
|
||
minutes for players of similar rank, but if there's a big disparity then it
|
||
could all be over in 10 minutes.
|
||
|
||
Being a two-player game drastically reduces the amount of socialisation
|
||
that can take place. There is a saloon bar for friendly discussion, but little
|
||
to do in the game itself. Sniper! is not for role-players. Unlike
|
||
modem-to-modem games, it does actually run on CompuServe's computers, and
|
||
therefore can only be played there. It's not merely a place for players to make
|
||
contact and then call each other separately; if it were, it wouldn't be as
|
||
lucrative as it is at present.
|
||
|
||
Like IOK, Sniper! does not have graphical client software. Since most
|
||
American players use either an IBM PC or a Macintosh, this is inexcusable. The
|
||
display it does have can be in colour, but it is composed of single ASCII
|
||
characters; it is even more difficult to decipher than IOK's.
|
||
|
||
Sniper! has a reputation for intricacy and complexity. As with IOK,
|
||
experienced players like being able to talk about fine, subtle details. It is
|
||
certainly possible to play Sniper! without being aware of all the rules, but
|
||
unlike normal MUAs there is little fun to be gained in discovering them:
|
||
they're all available explicitly, and just have to be read and learned. Battle
|
||
tactics are the "exploratory" side to the game.
|
||
|
||
Summary:
|
||
An adaptation of a boardgame that takes out all the tedious
|
||
manual-reading during play and replaces it with tedious manual-reading before
|
||
play. A good game for seriously minded wargamers.
|
||
|
||
Quotes:
|
||
|
||
"Some people enjoy role-playing and use the radio to send insults
|
||
or jibes when they hit, or complain when they miss."
|
||
Steve Estvanik [author]
|
||
|
||
"You have to think on your feet. While you're in the game, it's a
|
||
real battle. Things happen, and you have to react. It's like a
|
||
game of high-speed chess."
|
||
Peter Soehnlen [player]
|
||
|
||
|
||
6.4 The Spy.
|
||
|
||
Name: The Spy
|
||
Author(s): Blane Bramble
|
||
Location: IOWA and/or Synergy
|
||
Pricing Structure: free
|
||
|
||
Brief Description:
|
||
First-generation graphics game.
|
||
|
||
Review:
|
||
A budding IOK-style game. Players are espionage agents armed with a gun
|
||
and some grenades, who wander around a maze attempting to dispose of one
|
||
another. Since there are no puzzles, playing The Spy alone is, at the moment,
|
||
pointless.
|
||
|
||
The graphics used are simple ASCII characters, with screen addressing
|
||
via VT52 codes. As with IOK, line noise can badly trash a screen. Also as with
|
||
IOK, The Spy would benefit enormously from a client program that took the
|
||
simple ASCII and turned it into a proper, high-quality pictorial display.
|
||
|
||
Summary:
|
||
A new game: playable, but badly in need of more MUA-like features.
|
||
Probably going nowhere itself, but it may spark someone to attempt something
|
||
more sophisticated, along IOK lines.
|
||
|
||
Quotes:
|
||
|
||
"The idea is to provide a multi-user game with a semi-graphical
|
||
user interface (similar to that found in the games Hack, Moria,
|
||
Omega and so on)."
|
||
Blane Bramble [author]
|
||
|
||
Name: You Guessed It!
|
||
Location: CompuServe
|
||
Pricing Structure: $15.50/hour plus
|
||
$9.40/hour for UK players
|
||
|
||
Brief Description:
|
||
Multi-player trivia quiz game.
|
||
|
||
Historical Notes:
|
||
Based on a US TV programme vaguely similar to Family Fortunes.
|
||
|
||
Review:
|
||
You Guessed It! (or YGI for short) is a simple multi-player quiz game
|
||
with a now sadly diminished following on CompuServe. Players are asked a series
|
||
of questions in turn by the program, and score points for 'correct' answers;
|
||
the quotes are because the questions are based on the most popular answer given
|
||
by 100 people surveyed in the mid-west, and are not always factually correct,
|
||
eg. "Name a famous Italian opera" was answered "Carmen" by more people than
|
||
was any other opera. Players can challenge the survey results, in which case a
|
||
majority vote by all players is required for the new answer to be accepted.
|
||
|
||
Players can win bonus points for some answers, and these can be added
|
||
up and turned into real cash; for legal reasons only US citizens aged 18 and
|
||
over may do this, however. To pay for the prizes, there's a $3/hour surcharge
|
||
on YGI contestants.
|
||
|
||
YGI's main problem is sterility. At the moment, its database contains
|
||
around 2,000 questions, and some players have seen them all and recorded the
|
||
answers. New questions involve taking surveys, which is expensive, although
|
||
2,000 is still rather measily.
|
||
|
||
The main reason people play YGI is nothing to do with the game itself,
|
||
though. It has a lobby area, where players go to wait for a game to start, and
|
||
they chat to one another there. Forming friendships in this way is the real
|
||
reason people play. YGI is therefore really little more than a chatline.
|
||
|
||
The past few years have seen a decline in YGI, as it has lost players
|
||
to British Legends, which provides better communication facilities with the
|
||
bonus of role-playing - something YGI's socialisers enjoy.
|
||
|
||
Summary:
|
||
YGI is an innocuous quiz program that was successful for reasons its
|
||
authors had not considered: the game itself was merely a focal point to draw
|
||
like-minded people together, and it had no staying power of its own in the
|
||
face of opposition from a fully-fledged MUA. YGI is now reduced to cult status.
|
||
|
||
Quotes:
|
||
|
||
"Will you have fun? Will you learn more about your friends on
|
||
CompuServe? Will you discover the Meaning of Human Existence? -
|
||
You guessed it!"
|
||
You Guessed It! [promotional material]
|
||
|
||
7. Discussion.
|
||
|
||
7.1 Organisation.
|
||
|
||
This section contains a selection of representative quotes on a variety
|
||
of MUA-related subjects. Some of the quotes presented are solicited, unlike
|
||
those in previous sections; most, however, are taken without permission from
|
||
public sources such as magazine articles, bulletin boards, and InterNet's
|
||
rec.games.mud list.
|
||
|
||
Between quotes are connecting paragraphs advancing the main points. At
|
||
the end of each subsection is a summary.
|
||
|
||
7.2 Why Do People Play?
|
||
|
||
The first and most obvious reason people play MUAs is because it's fun
|
||
to do so. In some cases, 'fun' is perhaps too weak a word, however:
|
||
|
||
"There was little doubt that playing MUD was exciting and
|
||
stimulating. After one long evening interview, wishing to
|
||
experience the game first hand, I agreed to join a player as he
|
||
prepared to access Essex. Not all who wished to play could, as it
|
||
was strictly on a 'first come, first served' basis, and as the
|
||
methods of access were no straightforward much of the excitement
|
||
seemed to hinge upon whether one could gain entry. While waiting
|
||
to see if his efforts had been successful, the interviewee thrust
|
||
his wrist to me to feel his racing pulse. He did not get in, but
|
||
stated that he always got an 'adrenalin high' before and during
|
||
play."
|
||
Margaret Shotton
|
||
[Computer Addiction? A study of computer dependency]
|
||
|
||
Many MUA players feel this kind of a buzz playing the game -
|
||
particularly killers, ie. those who attack other personae with intent to cause
|
||
them harm. The 'thrill' of the hunt can be so strong that it doesn't always
|
||
matter who wins the eventual fight - and in many ways, if the killer is taking
|
||
a risk then it can be an even greater attraction (like gambling). Similarly,
|
||
role-players can enjoy deceiving other people into believing things that aren't
|
||
true, although realising that someone has attempted to trick you is rarely as
|
||
exciting as avoiding persona death in a fight.
|
||
|
||
Contrast the heart-pounding excitement of the above MUD1 player with
|
||
the faint enthusiasm of a TinyMUD veteran:
|
||
|
||
"Why do I MUD? Same reason you use the phone. And it's a lot
|
||
cheaper."
|
||
Bryant Durrell [Islandia founder]
|
||
|
||
Here, it's mere convenience that determines why Durrell plays.
|
||
TinyMUDs have little or no puzzles, exploration is seldom rewarding, so they
|
||
settle down into chatlines. Players who met when the game first started, and
|
||
were learning to build rooms together, struck bonds of friendship. However,
|
||
when the futility of that activity sinks in, they just sit around talking. New
|
||
players don't get the same initial fun, so don't play for very long, and older
|
||
players are lost through general attrition. Eventually, the game/chatline is
|
||
deserted.
|
||
|
||
(The reason it's cheaper, incidentally, is because Durrell uses
|
||
InterNet, so the costs are borne by others).
|
||
|
||
So it seems there is a distinction between a MUA that models reality in
|
||
some way and one that merely provides chatline facilities, with the former
|
||
having more staying power than the latter because the emotional talons with
|
||
which it holds its players are stronger. Why is this so, though? Why should
|
||
interaction that occurs in a computer-moderated fantasy world be any more
|
||
gripping than straight CB-style interaction?
|
||
|
||
"I remember the first time I was killed in MUD - it was deliberate.
|
||
I was in tears. I really knew what it was like to be dead, the
|
||
simulation was so real."
|
||
An interviewee (male)
|
||
[Computer Addiction? A study of computer dependency]
|
||
|
||
The reason is that a good MUA can be believable. If it works the same
|
||
way as the real world, then the players use the same mind-set as if they were
|
||
in the real world, and hence emotional response to events in the MUA world are
|
||
as if they were affecting the player directly in the real world. In a chatline,
|
||
nothing happens; people don't interact, they merely communicate. Whatever,
|
||
there must certainly be some other players - a SUA may be lifelike, but it's
|
||
essentially private. For a world to seem truly real, it must be a shared
|
||
experience.
|
||
|
||
"One thing is for sure, and that is that the multi-user feature is
|
||
very important."
|
||
Lars Pensjo [LPMUD author]
|
||
|
||
If, however, MUA worlds can seem to the players like they are real,
|
||
should events that take place in these worlds be treated as if they were
|
||
real-world events? Or are they distinct? Should players shrug off what happens
|
||
to them? What if they can't?
|
||
|
||
"MUDs are games. Deal with it."
|
||
Clay Webster [player]
|
||
|
||
This is a popular view: people who are unable to switch off when they
|
||
leave a MUA ought to learn to do so, because the bottom line is that a MUA is
|
||
just a game, and haranguing people about what they did in the game is as
|
||
pointless as haranguing authors about what happened in books they wrote. This
|
||
viewpoint is held mostly by people who have never played a MUA, have played but
|
||
never let themselves become emotionally absorbed by it, or who play killer
|
||
personae in order to get a kick out of annoying someone who doesn't hold the
|
||
"MUAs are games" viewpoint.
|
||
|
||
Surely, though, things which wield this kind of emotional power over
|
||
people can't be mere games? The passions roused in (traditional) MUAs have the
|
||
kind of fire to them normally reserved for religious or political evangelism.
|
||
People aren't so much playing the MUA as living it.
|
||
|
||
"Ready for the shocker? Reality is a game. It has rules (physics),
|
||
players (life forms), and many goals. ... I won't deny that MUDs
|
||
are games, but if that is so then reality can also be considered a
|
||
game."
|
||
Ray Cromwell [TinyMUD player]
|
||
|
||
This argument is intended to show by reducto ad absurdum that MUAs (or
|
||
at least TinyMUDs) aren't really games, because if they were then everything is
|
||
a game. However, perhaps it be applied in reverse: if real life is as much a
|
||
game as is a MUA, perhaps MUAs are as much a reality as real life?
|
||
|
||
"My MUD philosophy is that it's more than just a game, it's a
|
||
virtual reality."
|
||
Bruce Woodcock [TinyMUD player]
|
||
|
||
Correct. Although the popular conception of virtual reality is a mass
|
||
of electronic headsets and cybergloves containing Tomorrow's World presenters,
|
||
MUAs are precisely the same thing, only instead of the images being generated
|
||
by a computer they're created by the imagination of each individual player.
|
||
|
||
The 'virtual' in 'virtual reality' is used in the same sense as
|
||
'virtual image' in optics: the appearance of a real reality is there, but it
|
||
actually doesn't exist. However, if it truly doesn't exist, then nothing that
|
||
occurs in it really happens either, and therefore it should have no effect on
|
||
the real world (which, we assume, does exist).
|
||
|
||
"All repeat after me: IT'S ONLY A GAME!"
|
||
Anton Rang [TinyTalk author]
|
||
|
||
The crucial point is that the virtual reality does exist; not in the
|
||
same way as real life, but as a conceptualisation which can have an effect on
|
||
people in real life.
|
||
|
||
"I'm hesitant to label it 'just a game'. Sure it looks like a game.
|
||
It uses a text-adventure metaphor for social interaction.
|
||
However, that geeky phrase doesn't even *begin* to convey the
|
||
complexities of 'what mud is'."
|
||
Stephen White [TinyMUCK author]
|
||
|
||
When a player like Shotton's interviewee controls a persona in a MUA
|
||
and becomes absorbed to such an extent that he is oblivious to the real world,
|
||
concentrating only on the virtual reality, then the player and his persona
|
||
fuse; he 'becomes' his persona in that MUA. As far as the player is concerned,
|
||
things are happening not to the persona but to he himself. He can do things
|
||
that are impossible in the real world, and be whoever he wants to be. That's
|
||
the attraction.
|
||
|
||
Of course, a sudden change back to real life is going to be jarring.
|
||
The emotions felt by the player as he lived in the virtual reality cannot be
|
||
shaken off when he leaves that reality any more than real life emotions can be
|
||
dismissed at the drop of a hat. No wonder Shotton's interviewee cried when his
|
||
persona - ie. he himself - was killed in MUD1.
|
||
|
||
MUAs are not merely chatlines with games screwed on top; rather, they
|
||
are a whole that is greater than the sum of these two parts. Of course, a good
|
||
deal of their insidious attraction is that they can lure not just people who
|
||
want a virtual reality buzz, but ones who simply like games and ones who simply
|
||
like chatlines. People who just like talking can do that in a MUA if they want
|
||
to. TinyMUD has a very weak 'learn what to do' game about it when it is first
|
||
installed at a site, and then it rapidly degenerates into a chatline; however,
|
||
even then it has enough of a virtual world about it to have prompted this
|
||
recent posting on InterNet:
|
||
|
||
"I was thinking about things today, and realised that I was
|
||
spending more than 8 hours a day MUDding, skipping classes and
|
||
ignoring homework in favour of all the socialisation of the MUDs.
|
||
It also hit me that I was going to flunk out of college if I
|
||
didn't stop it. I'm addicted bad. Real bad. ... To all of you who
|
||
insist that MUD is a game, I disagree. MUD is a socialisation tool
|
||
that just happens to allow you to go adventuring and solve
|
||
puzzles. Problem is, that I over-used it, to the exclusion of a
|
||
real life."
|
||
Garth Minette [ex-TinyMUD player]
|
||
|
||
MUAs are very addictive. Chatlines can be addictive, and games can be
|
||
addictive, but neither compares remotely with what a MUA can do to people. It
|
||
happens in all MUAs:
|
||
|
||
"The burnout player has a very clear profile - he is a very active
|
||
player who cannot be missed when he is in the game, he is chatty
|
||
and likeable, a fighter (but not very good), and he sparkles,
|
||
bubbles, burbles and froths all over chat. Above all, he wants to
|
||
be involved with everything. The symptoms are very obvious from
|
||
the outset: long hours of play every day may gradually move into
|
||
peak time, followed by a furious activity towards the end of the
|
||
first quarter, with a 'well I might as well be hanged for stealing
|
||
a sheep as a lamb' attitude just before the bill arrives. Then the
|
||
painful farewell to friends and enemies moments before dad
|
||
consigns the modem to the dustbin. Then, silence forever. He is
|
||
never seen again. Burnout."
|
||
Pip Cordrey [IOWA owner]
|
||
|
||
Apart from the predictable grouse about telephone charges, Cordrey has
|
||
a genuine point here. People who like the world offered by a MUA more than
|
||
they do the real world will often spend a lot of time there. If they are
|
||
obliged to pay for their time after having played, and are aware that they
|
||
can't, they'll play as much as they can before being cut off. This will
|
||
increase their addiction even more, and when the phone is finally disconnect
|
||
then the sudden wrench from the MUA can be devastating. Players have described
|
||
it as 'cold Turkey'.
|
||
|
||
"MUDs are addictive, as we who play them are well aware. Gibson and
|
||
the rest were right about the addictive possibilities of
|
||
cyberspace. They were just wrong about the magnitude."
|
||
Bryant Durrell [Islandia founder]
|
||
|
||
The intersection between game and chatline which is so addictive is a
|
||
form of role-playing. The term is appropriate, however note:
|
||
|
||
"Role-playing games have attracted some criticism; US religious
|
||
fundamentalists have managed to conflate them with satanism and
|
||
other evils - such as psychiatry."
|
||
Computer Weekly [magazine]
|
||
|
||
That's why these days, in discussing their relationship to their
|
||
persona, smart American MUA players stay on the virtual reality bandwagon.
|
||
|
||
"In my case, Sir Bruce Sterling is mostly me. His words are
|
||
generally my words in that situation, his actions often the ones I
|
||
would take. But there are slight differences. I can do things in
|
||
MUDs I can't in real life, which allows options I don't have in
|
||
real life. And when I kill in virtual reality, it doesn't mean I'd
|
||
actually kill under the same circumstances in real life, since
|
||
no-one *really* dies or even ceases to exist on MUDs if they are
|
||
killed."
|
||
Bruce Woodcock [player]
|
||
|
||
Why is role-playing seductive? Its principal attraction is that it
|
||
allows players to be someone else, to take on an assumed identity. They can be
|
||
themselves, but when things go wrong they don't feel so bad about it. Anonymity
|
||
is the key.
|
||
|
||
"Considering my MUD persona - and I only have one, which probably
|
||
says a lot in itself - there are a lot of similarities. I
|
||
definitely hide behind the anonymity, but share a large number of
|
||
traits (not all good) with my MUD personality."
|
||
Mike Prudence [player]
|
||
|
||
Anonymity also enables players to take on completely different roles,
|
||
behaving outrageously, safe in the knowledge that they can't be hurt in the
|
||
real world.
|
||
|
||
"Interaction can mean anything from kissing to killing or
|
||
stealing."
|
||
The Economist
|
||
|
||
Often, this involves sexual manipulation - sometimes subtle, but not
|
||
always:
|
||
|
||
"The hozer: 'Yo, babe! I got this amazing ten-inch love muscle.
|
||
Wanna date? Lie down and spread your legs.' Hozers are usually
|
||
college freshmen with no social skills who can't get sex any other
|
||
way. They tend to skew the male/female ratio on MUDs even further
|
||
by causing all female characters in the vicinity to change to male
|
||
or gender-neutral characters."
|
||
Lauren Burka [TinyMUD player]
|
||
|
||
The ability to live out sexual fantasies in a MUA does attract certain
|
||
people, especially to games set up precisely for that purpose (eg. Zone). This
|
||
can cause managerial problems if it is uninvited. Something common in all MUAs,
|
||
though, is cross-gender playing. Most male players play female personae
|
||
(usually admitting that they are really male if questioned) and many female
|
||
players play male personae (usually not admitting it if asked). Sometimes,
|
||
males playing females will attempt to get themselves picked up by players they
|
||
think are male:
|
||
|
||
"The slut: 'Hey, does anyone here want a blow-job?' The slut comes
|
||
in all different shapes and sizes, but her description always
|
||
includes mention of her luscious lips and prominent nipples. 95%
|
||
of all sluts are played by male players. Most of these used to be
|
||
hozers."
|
||
Lauren Burka [TinyMUD player]
|
||
|
||
Rarely will this totally brazen technique fool anyone, but an
|
||
accomplished role-player can build up amazingly detailed on-line relationships
|
||
over time. Quite what the fun in this involves is hard to say - it's probably
|
||
to do with enjoying manipulation other people, although the challenge of
|
||
role-playing may be a significant factor. Certainly, it can lead to tragic
|
||
cases where a player falls in love with a persona played by someone of their
|
||
own gender (almost invariably they're both male - females don't appear to
|
||
indulge in this kind of thing with quite the same dedication). Most MUAs will
|
||
have that happen to them at some time in their history unless they're very well
|
||
managed.
|
||
|
||
Male players in some games have developed a defence against the
|
||
possibility that the female persona that they are talking to is actually male:
|
||
|
||
"If you see a persona with a female name, it's really a male. If
|
||
they come up and talk all feminine and giggle, it's still a male.
|
||
If they phone you, meet you in a park, chat for two hours about
|
||
MUD and produce logs of their games, it's still a male playing the
|
||
persona. If you actually see them sitting down, playing the game,
|
||
behaving just like they do when you've snooped them, then they
|
||
might be the real thing but the chances are they're not. You can't
|
||
be too careful!"
|
||
Richard Bartle [Comms Plus!]
|
||
|
||
Except in games with a near-even male/female ratio, many women adopt
|
||
the same attitude:
|
||
|
||
"Perhaps it's because women are so scarce on the computers that
|
||
some men haven't realised that they don't have to talk any
|
||
differently to us. I know that some women conceal their gender
|
||
from those who think that just because someone says that they are
|
||
female, this is an invitation to be harassed. This loss of
|
||
freedom seems to be a high price to pay to get respect."
|
||
Paola Kathuria [Comms Plus!]
|
||
|
||
The 'freedom' Kathuria is talking about is that of being able to be
|
||
yourself. Many new female players will be scared off by male players trying to
|
||
chat them up all the time, and will not play as male personae because they
|
||
object to being forced into a role by the attitudes of others.
|
||
|
||
For those women who play openly as females, a barrage of pick-up lines
|
||
can be expected (not normally meant to be offensive, just very numerous because
|
||
there are many more males per female player). Once this has died down, women
|
||
can play pretty much the same way as men. By then, however, male players will
|
||
often have formed a visual impression of them that might not fit physical
|
||
reality.
|
||
|
||
"In my experience, unless I have got to know someone well enough to
|
||
call them a (platonic) friend, after face-to-face meetings things
|
||
are never the same back on the talkers. I have therefore developed
|
||
a rule of not meeting people while I am getting to know them and
|
||
instead just relish wanting to meet them. I am inclined to think
|
||
that if I were male there would be no problem. I put this down to
|
||
my hunch that when men meet women on a computer the way women are
|
||
imagined to look like tends to be more like an ideal than someone
|
||
who may be skinny or fat, spotty, six feet tall or four feet
|
||
short. I know that when I started to meet people I had a real
|
||
shock when I found out they wore glasses or had a beard."
|
||
Paola Kathuria [Comms Plus!]
|
||
|
||
This reluctance to meet people face-to-face is quite sad in a way,
|
||
because whereas more men than women get immediate pleasure from role-playing,
|
||
more women than men find that their true enjoyment manifests itself in the way
|
||
in which friendships and companionship can form between players over time.
|
||
|
||
"The biggest attraction for me would have to be the people here. I
|
||
have developed many friendships that I will cherish for years to
|
||
come."
|
||
Stargazer [BL player]
|
||
|
||
In two games at least (Shades and British Legends), players have
|
||
married people whom they first met in the game. If female players don't want to
|
||
go to face-to-face meetings for fear of shattering their friends' illusions of
|
||
them, it can detract from their overall enjoyment of the MUA. Long-standing MUA
|
||
players who may have jealously guarded their anonymity initially will often
|
||
gladly turn up at face-to-face meetings to renew their friendships.
|
||
|
||
"One of the most interesting features of the MUG phenomenon is
|
||
their social aspect, not just in the game but outside as well.
|
||
Every game holds social gatherings, and at these events all the
|
||
players get together and enjoy meeting the people behind the
|
||
personae. It's always amazing to see people who were battling each
|
||
other in cold fury the previous evening sitting down together over
|
||
a pint discussing tactics."
|
||
Pip Cordrey [Confidential]
|
||
|
||
To summarise, then: chatlines can be addictive, games can be addictive;
|
||
combining the two should therefore be addictive, and yes, MUAs do attract
|
||
people who like chatlines and people who like games. However, MUAs can exert an
|
||
influence over a large number of these players out of all proportion to that of
|
||
either a chatline or game alone. MUAs have an emotional hold over their
|
||
players which stems from the players' ability to project themselves onto their
|
||
game personae, feeling as if the things which happen to the game personae are
|
||
happening directly to the players themselves.
|
||
|
||
When persona and player fuse, as they do in a good MUA, events are
|
||
given an impact far beyond that of the mere words that convey them. The game's
|
||
virtual reality becomes (temporarily) the player's reality. Players can do
|
||
things and have things done to them that are impossible in real life; they can
|
||
experience feelings and imbue feelings in others that real life denies them.
|
||
It's the belief that things are happening to you, not to a game persona, that
|
||
makes MUAs unique.
|
||
|
||
This must be understood by the reader. The really exceptional thing
|
||
about interactive, multi-user computer games of the MUA variety is not that
|
||
you're chatting to someone miles away (although that can be fun), and it's not
|
||
that you're competing against a real human instead of a machine (although that
|
||
can also be fun); it's that you're existing in another world. That's the root
|
||
of their appeal.
|
||
|
||
"You get very excited with adventure games. Your adrenalin goes up
|
||
and you get very tense. It's fascinating that you forget you are
|
||
hunched over a computer and that others are - you feel you are all
|
||
together in the magic land of MUD. It's a further extension from
|
||
reading a book. It's totally engrossing - the mind is focused on
|
||
one thing and you don't notice anything else."
|
||
An interviewee (female)
|
||
[Computer Addiction? A study of computer dependency]
|
||
|
||
|
||
7.3 Why Do People Not Play?
|
||
|
||
If MUAs are as entertaining as has just been claimed, why do some
|
||
people start playing them and then give up shortly afterwards?
|
||
|
||
New players are the lifeblood of MUAs, as they are needed to replenish
|
||
the older players who stop playing for personal or financial reasons. They also
|
||
stop a game from becoming sterile. Hence, most MUAs make some effort to keep
|
||
new players for long enough to get them hooked.
|
||
|
||
One of the things commonly cited as a reason for not playing a MUA is
|
||
that it is too daunting. There is a class of person that finds huge amounts of
|
||
pre-game reading a real appetiser for the game, and who by the time they've
|
||
read all the documentation will be raring to go. Many people do not like it,
|
||
however. They want simple, basic instructions, and they don't want to be told
|
||
just how much they'll need to know to play the game in earnest - it's just too
|
||
awesome.
|
||
|
||
The best way to achieve this is by means of on-line help. Players can
|
||
ask for assistance on specific game-related topics, and the game will give them
|
||
details. Purists argue that this spoils the atmosphere, but it's necessary if
|
||
players are to learn gradually rather than be put off by an initial flood of
|
||
facts.
|
||
|
||
"Virtual reality is not hurt by being able to find out how the
|
||
virtual reality is mapped to the real reality at any time. It's
|
||
very unrealistic not to be able to whisper to someone because I
|
||
forgot the command and the help command is not global. Sheesh."
|
||
Lee Brintle [player]
|
||
|
||
However, the crucial factor in ensnaring new players into a game is how
|
||
the other players react. New players are often confused in their first session,
|
||
and longer-standing players can help enlighten them.
|
||
|
||
"If you give people a little guidance, they'll all pull in the same
|
||
direction, rather than one zillion different directions."
|
||
Mike Prudence [TinyMUCK player]
|
||
|
||
Unfortunately, the behaviour of other players is as potent in its
|
||
ability to scare off newcomers as it is to welcome them. In male-heavy games,
|
||
women have special difficulties as outlined earlier. However, everyone suffers
|
||
verbal abuse from time to time from anonymous personae. Older players will
|
||
dismiss it without comment, but newcomers (and especially journalists looking
|
||
for a story) are often shocked, and can easily be driven away (which is, of
|
||
course, exactly what their abuser intended).
|
||
|
||
"One of the most annoying things is when I'm sitting in a public
|
||
(or private) place and someone comes by and starts swearing and
|
||
insulting me and everyone else in there."
|
||
Gregory Blake [player]
|
||
|
||
Proper game management, especially the ability of arch-wizzes to find
|
||
out to which account any persona belongs, can do a great deal to stop these
|
||
practices. However, they'll always be open to misuse by people using guest
|
||
accounts, where no link between a persona and a real person can be determined.
|
||
|
||
Swearing and sexual innuendo can creep into any public service with a
|
||
chatline component - 'sleaze' is the term used to refer to it. Due to
|
||
mismanagement in some MUAs, eg. Shades, an attitude has set in that this is
|
||
somehow inevitable, and that when anyone plays a MUA the result is a
|
||
transformation comparable with that of Dr Jekyll's to Mr Hyde. Since this can
|
||
be used as an argument against allowing MUAs at all, it is important that it be
|
||
recognised as fallacious.
|
||
|
||
"Computer interaction seems to make people nastier and more
|
||
obnoxious. It doesn't: it merely gives the rude and ignorant more
|
||
efficient and anonymous means to display their rudeness and
|
||
ignorance."
|
||
Lauren Burka [TinyMUD player]
|
||
|
||
In other words, MUAs don't make people behave badly; all they do is
|
||
enable people who want to behave badly to do so. In a properly organised MUA,
|
||
bad behaviour by an individual will occur at most twice: the first time, if
|
||
they appear to have thought it was OK to do what they did, they'll perhaps be
|
||
let off with a stern warning; the second time, they're ejected. Games that
|
||
allow wrongdoers to return have a harder time of maintaining discipline. That
|
||
said, when people play MUAs their emotions are often difficult to contain, so
|
||
when disputes do break out they can escalate rapidly.
|
||
|
||
Note that sleaze is not limited to MUAs, and that BT is very sensitive
|
||
about it:
|
||
|
||
"Should you receive offensive or abusive material over any of our
|
||
data transmission services or feel that material on a database is
|
||
offensive and you wish to complain, please register your complaint
|
||
in one of the following ways. ..."
|
||
W. R. Broadhead
|
||
[head of BT MNS Customer Service Unit,
|
||
in a letter to PSS customers]
|
||
|
||
It is impossible to deal with sleaze so long as narrow-minded
|
||
individuals have access to a system and know they cannot be traced. Automated
|
||
censorship is presently impossible - computers would throw out words like
|
||
'Scunthorpe', and if they didn't then players would use them as swearwords.
|
||
|
||
To summarise: new players will lose interest if they find a game looks
|
||
too complicated to play, or if it is too sleazy for them. More experienced
|
||
players will leave if sleaze gets really bad, but otherwise have a higher
|
||
tolerance of it. Good game management can reduce the amount of sleaze, in the
|
||
same way as good Home Office policing can reduce the amount of sleaze on ham
|
||
radio. However, it can't ever be removed 100%. You can discourage people from
|
||
breaking a code of acceptable behaviour (eg. by throwing them out), but you
|
||
can't actually stop them from breaking it.
|
||
|
||
"If you think about it, you will realise that a game is just a
|
||
coded collection of rules. With a multi-user adventure these
|
||
rules are complex, and defy being entirely coded. So some
|
||
externally applied rules have to exist. The purpose of rules in
|
||
the game is to ensure that the game is fair and enjoyable to all
|
||
players."
|
||
Pip Cordrey [IOWA owner]
|
||
|
||
|
||
7.4 Why Do People Stop Playing?
|
||
|
||
MUAs do lose long-standing players. Sometimes it's because the games
|
||
are boring, or no longer games (as with TinyMUD and derivatives). Other times,
|
||
the players or their circumstances change: they get older, change job, die,
|
||
move house, marry, have children.
|
||
|
||
However, in the UK at least, the main reason that people stop playing
|
||
is because telephone charges are too high. The evidence for this is
|
||
overwhelming - almost every professional article on the subject complains about
|
||
the cost.
|
||
|
||
"The main obstacle to MUD, and similar programs, gaining a wider
|
||
airing is the cost of making a telephone call."
|
||
Popular Computing Weekly [magazine]
|
||
|
||
|
||
"The problem area with this way to play is the cost and speed at
|
||
which it operates. Current costs are prohibitive."
|
||
New Computer Express [magazine]
|
||
|
||
|
||
"These games are expensive to play, habit forming, and rapidly
|
||
becoming big business."
|
||
PC Plus [magazine]
|
||
|
||
|
||
"No MUG is free when it comes to your telephone bill!"
|
||
GM [magazine]
|
||
|
||
|
||
"Maybe the forthcoming changes to BT might lead to a more
|
||
enlightened attitude to telephone charges for this type of
|
||
service. For the home user, however, MUD playing will be limited
|
||
to the rich or the resourceful."
|
||
The Times
|
||
|
||
The service BT provides is held in contempt by everyone in the
|
||
commercial comms field. Usage patterns for MUAs are very different to those of
|
||
voice users, with players commonly sitting down for several hours at a stretch
|
||
playing a game. During that time they are, of course, occupying slots on the
|
||
same exchanges that normal telephone users are paying full-price to use,
|
||
however since they have no choice in the matter it can hardly be said to be
|
||
their fault. Even the absolute minimum price for a local telephone call in the
|
||
UK works out at 5.06p per 240 seconds, ie. L0.759/hour; for a long-distance
|
||
call, it's 5.06p per 38 seconds, ie. L4.794/hour. An evening of playing even a
|
||
free MUA would cost the players anything between L2 and L14 each. Even for
|
||
commercial games, the bulk of the money players pay ends up in BT's coffers.
|
||
|
||
BT is very complacent about all this; after all, it's making money by
|
||
doing nothing, so why bother? Indeed, since there are some people who
|
||
apparently spout sleaze in these games, perhaps it would be better in the long
|
||
run if they were all shut down? Less hassle for all concerned...
|
||
|
||
BT could make a lot more money from MUAs if it dropped its prices. One
|
||
large phone bill will drive a person off a MUA, whereas they are likely to
|
||
accept smaller ones over a much longer period. L300 for one quarter nets BT
|
||
L300; L75 per quarter for two years nets BT L600. People don't play less when
|
||
the price goes up, they either continue to play or just stop. It's an issue
|
||
for Market Research to determine the exact trade-off point for maximum income,
|
||
but it's definitely below 75p/hour.
|
||
|
||
Another important point is that although BT makes money from MUAs,
|
||
they're commercially unattractive to games companies. Players are prepared to
|
||
pay only a certain amount per hour to play, but if BT takes the lion's share of
|
||
that then there's little profit for the MUA authors. This means companies that
|
||
specialise in computer games prefer to invest their energies elsewhere, and so
|
||
the number of commercial MUAs is small. The more games there are, the more
|
||
players, and therefore the more income due to BT overall.
|
||
|
||
BT does provide alternative services for its users. Most of these
|
||
suffer from the fact that they are distance-dependent: most telephone numbers
|
||
may be local to London, but MUAs often hold a special appeal to people in
|
||
remote areas, for whom a long-distance call is 5 or 6 times as much. Present
|
||
facilities and their disadvantages are as follows:
|
||
|
||
- PSS
|
||
Allows inexpensive data transfer compared to direct dial over a modem
|
||
long-distance, but is still a local call plus a high premium of several
|
||
pounds per hour (depending on the amount of data sent).
|
||
|
||
- 0800 numbers
|
||
Players don't get big phone bills, they get big bills from the MUA owners,
|
||
who in turn get the big phone bills. If they are charged up front to use
|
||
the service, this can be beneficial - people don't get any nasty surprises.
|
||
Unattractive to MUA owners because it's distance-dependent, and local
|
||
callers subsidise distance callers. If, however, all calls to the number
|
||
cost the MUA owners the same, and that amount was equal to or less than the
|
||
price of a local call, it would be a very satisfactory option - especially
|
||
if the MUA providers could claim back the VAT on their phone bills.
|
||
|
||
- 0345 numbers
|
||
These are numbers that are a local phone call from anywhere in the country.
|
||
They're a cross between 0800 calls and normal calls - long-distance calls
|
||
are subsidised by the owner of the 0345 number. If local call rate from
|
||
pretty well everywhere in the country could be guaranteed, with no hidden
|
||
charges, this would be a reasonable second-best option.
|
||
|
||
- 0898 numbers
|
||
These are the premium call-rate numbers, where users pay enormous amounts
|
||
per minute and BT gives some of the resulting money to the 0898 number
|
||
owner. This would work well for MUAs if the prices weren't so incredibly
|
||
high - L19.80/hour. Bring it down to L1 or L1.50 an hour and it would be
|
||
more reasonable. Players would get even larger phone bills to pay all at
|
||
once, however, and thus may be even more inclined to give up their gaming.
|
||
|
||
- Midnight Lines
|
||
Midnight lines allow their owner to pay a flat fee per quarter and make
|
||
unlimited phone calls any distance in the UK, so long as they do so between
|
||
midnight and 6am. Best used as a call-back system, where players dial the
|
||
game, give their password, log off, and the game calls them back on its
|
||
midnight line; this way, only the game needs the midnight lines, not the
|
||
players. The problem with these lines is that only the most hardened of
|
||
players will stay up so late before they can start to play.
|
||
|
||
Given that BT's options are limited by its charter, there probably
|
||
isn't much scope for altering these services or providing similar ones. As far
|
||
as MUA players are concerned, the best solution is to have a service like the
|
||
0800 numbers where calls can be made from any distance and don't appear on the
|
||
users' phone bill. Different prices for different times of day are a reasonable
|
||
thing for BT to ask, but they should always be the same as or less than a local
|
||
phone call. The MUA provider would sell players 'credits', take these away from
|
||
their total at a certain rate depending on the time of day, and ask for more
|
||
when they ran out. In this way, players can see precisely how much the game is
|
||
costing them, can budget in advance, and have no nasty shocks when their phone
|
||
bills arrive:
|
||
|
||
"In general, I think paying for credits in advance is definitely
|
||
better than running up a bill. It allows players to budget, and
|
||
avoids the problems a lot of new players could encounter of a huge
|
||
bill arriving after the first month or so, which puts them off
|
||
playing and therefore loses the game a customer."
|
||
Phil Purle [MUD2 player]
|
||
|
||
From the MUA providers' point of view, the best solution is a service
|
||
like the 0898 numbers. This is because they'll get more people playing during
|
||
the day using their companies' resources; also, BT does all the billing.
|
||
However, the 0800-lookalike solution is probably fairer.
|
||
|
||
A third alternative is for BT to charge the MUA providers a flat fee
|
||
for a number that can be dialled by anyone without costing them anything - a
|
||
sort of 0800/midnight/land line. This may be subject to time-of-day
|
||
restrictions, perhaps only working at cheap-rate times. Provided the cost of
|
||
doing this wasn't too large, it would benefit both the player (free calls to
|
||
the MUA in the evening) and the MUA (daytime calls from users on their company
|
||
phones). However, as a service it's perhaps a little complicated to operate.
|
||
|
||
All this assumes use of the existing telephone network. There are
|
||
likely to be problems, however, in that providing new services primarily for
|
||
transmitting and receiving data doesn't ensure that they will be used for those
|
||
purposes. For example, if a company bought a data 0800 number that only cost
|
||
it local call access outside business hours, there is nothing to prevent its
|
||
being used for voice communication. It could, of course, be made a condition of
|
||
having such a line that there should always be a modem on the end, but this may
|
||
prove expensive to police.
|
||
|
||
Although at this stage there is probably insufficient evidence to tempt
|
||
all but the most progressive of companies into setting up a data-oriented
|
||
network, nevertheless that's probably the best way to proceed. Certainly it
|
||
will be needed in the future, it's just a question of how long BT or their
|
||
competitors (such as they are) wait before implementing it (or realising that
|
||
they'll even need it - mind you, Finland has it already, and it's free). Local
|
||
phone calls to a special data node will doubtless be with us for some time to
|
||
come, but a national packet-switched data network that people don't require a
|
||
special account to use will come eventually. All they'd have to do is dial the
|
||
appropriate code for the data network followed by the number of the recipient,
|
||
and instead of being charged on a time basis they'd be charged on a data
|
||
transmitted/received basis. If CompuServe can knock up a system that gives
|
||
local call access to their mainframes from pretty well anywhere in the USA, BT
|
||
can surely manage something in Britain.
|
||
|
||
Of course, if BT is ever allowed to run its services on a subscription
|
||
basis like cable TV, other avenues are open:
|
||
|
||
"I do feel that you're best off following the example of US TV or
|
||
radio - don't charge the end-user if at all possible, and pull in
|
||
the revenue someplace else."
|
||
Bryant Durrell [Islandia founder]
|
||
|
||
Summarising this, then, there are several options available for people
|
||
who wish to use IMPCGs. A very important consideration is the cost: if at all
|
||
possible, it should be standard countrywide, irrespective of distance; also, it
|
||
should be no more expensive than a local phone call - otherwise, why would
|
||
people a local call away bother with it?
|
||
|
||
MUAs are played most frequently in non-business hours, which may give
|
||
some leeway in implementing changes to existing approaches. Of these, the most
|
||
favoured are where all the cost is borne by the information provider, either as
|
||
a flat fee per line or time-dependent as at present.
|
||
|
||
Ideally, data communications should have their own network which
|
||
charges on a data sent/received basis rather than for time used. Voice sends
|
||
lots of data over a short period, but on-line services send smaller amounts
|
||
over a longer period, and furthermore can be carried more efficiently if their
|
||
computer-oriented nature is known. This, a datanet would achieve.
|
||
|
||
"The quality of networked services in the UK is very poor, and I do
|
||
not wish the work that we have done up to this point to be swamped
|
||
by poorly managed highly commercial services."
|
||
Pip Cordrey [IOWA owner]
|
||
|
||
|
||
7.5 What Does the Future Hold?
|
||
|
||
"With the software industry definitely looking for new ideas to
|
||
keep home computer users interested, the multi-user game is
|
||
strongly tipped as being a hot item."
|
||
Datamation [magazine]
|
||
|
||
"At a time when the microcomputer software industry is entering a
|
||
period of crisis - the number of new ideas for computer games is
|
||
painfully small - the idea of multi-user games has been put
|
||
forward as the next big area for development."
|
||
Computing [magazine]
|
||
|
||
MUAs are fun, rewarding to play, and compulsive. From a software
|
||
author's point of view, they're a dream: the software is not made public, so
|
||
there is no danger of piracy; people pay for them continually, they don't just
|
||
make a one-off payment; larger computers acting as a host mean that more
|
||
sophisticated games can be written than work on home micros. A pity BT takes
|
||
such a huge percentage of the revenue. Nevertheless, MUAs are definitely the
|
||
future.
|
||
|
||
But what exactly is that future? The present trend in MUA design is for
|
||
games that allow players to add rooms etc. to it themselves. For many reasons,
|
||
this approach is unlikely to be successful commercially - quality, security and
|
||
the UK copyright laws are the main objections. However, that is not to say that
|
||
new alternatives should not be examined; too many MUAs these days are formula
|
||
issues that use the old, tried-and-trusted approaches.
|
||
|
||
"The main thing hampering game development is the fact that the
|
||
people writing them are content to produce yet another Shades
|
||
clone. It seems that whilst there is a lot of enthusiasm for
|
||
writing your own games, nobody is willing to be a bit adventurous
|
||
and try and make things a little more complex."
|
||
Wabit [player]
|
||
|
||
To seasoned players, the older MUAs look very dated. If members of the
|
||
general public were given a wider access to these games, then after a while
|
||
they'd come to feel the same way too. Unless work starts soon on the "next
|
||
wave" of MUAs, there'll be nothing there to take their place.
|
||
|
||
"Hopefully, they will be replaced by new games, but who is going to
|
||
write them? And who is going to back them? BT don't need to
|
||
replace Shades, it still brings in the money..."
|
||
Wabit [player]
|
||
|
||
The authors are there, but the backers aren't. Even CompuServe doesn't
|
||
commission games, it merely deigns to permit them on its network. Prestel will
|
||
allow companies access to its user base, but at L6,500 per entry point plus
|
||
L260 per channel, both sums charged annually, there are few takers.
|
||
Unfortunately, BT is too big an organisation for this to make much difference
|
||
to it, and its charter means that cross-subsidisation is not allowed; thus,
|
||
Prestel couldn't let new services join it for free in the knowledge that this
|
||
would generate income for the telephone division, because Prestel itself would
|
||
have to pay for the connection and would get nothing (or comparatively little)
|
||
in return.
|
||
|
||
MUA authors and carriers generally agree on the next big step in MUAs:
|
||
|
||
"I see it splitting several ways. There'll be the continuing
|
||
MUD/Shades type games, there'll be an increase in on-line
|
||
chat/conferencing systems concentrating on the 'social' side of
|
||
MUGs as they are, and there'll be the hard-edged commercial
|
||
things, probably graphical games."
|
||
Nigel Hardy [Comms Plus!]
|
||
|
||
Graphics are seen as being the key to bringing MUAs to a wider
|
||
audience; sound, too, if possible. Viewdata, sadly, is nowhere near good
|
||
enough, despite Prestel's doggedness.
|
||
|
||
"To market MUDs successfully, the interface between host and client
|
||
must be improved. It is a small percentage of the buying public
|
||
that will suffer through typing and reading to enjoy a few hours'
|
||
escapism. If someone were to combine the ease of watching
|
||
television with the interactivity of MUDs and make it available to
|
||
the world at large, they would soon put the passive networks (NBC,
|
||
ABC, BBC, ITV etc.) out of business."
|
||
Duncan Howard [author of An Introduction to MUD]
|
||
|
||
Graphical MUAs are possible right now, it's just that no MUA author has
|
||
the financial clout to do anything about it. The approach is not to send
|
||
photographic images down the line, but instead to provide these on disc or
|
||
multimedia systems at the user end. The MUA host merely transmits a few control
|
||
codes that say "Print background 219, with a tree at co-ordinates (314, 16),
|
||
and Eric at (210, 101) with a face using identikit image 12/11/23/1/92." This
|
||
doesn't need ISDN telephone links, and it's the way games like Air Warrior
|
||
work.
|
||
|
||
"Graphical MUGs won't work until the BT monopoly is broken and 15
|
||
year olds can afford to play shoot-em-and-run type games over the
|
||
phone."
|
||
Graeme [Ripper author]
|
||
|
||
IMPCGs in the future will, in general, be one of the following types:
|
||
|
||
- Arcade style.
|
||
These will appeal to people who like blasting aliens. However, blasting
|
||
aliens is a lonesome thing, and players will not take kindly to being
|
||
blasted by other people. When teenagers play such games over the phone,
|
||
it'll be because that's a way the computer companies have figured they can
|
||
make more money out of it. Making people pay as they play is always going
|
||
to be more lucrative than making them pay once only.
|
||
|
||
- Strategy.
|
||
These are mainly going to be two-player games between 'older' players of a
|
||
generation that came too early for AD&D. People enjoy playing things like
|
||
chess by post, and will enjoy playing such games by phone. They are
|
||
unlikely to come in their hordes, however; this is a niche market. Networks
|
||
will only be necessary as a place to meet opponents before playing direct-
|
||
dial.
|
||
|
||
- Simulators.
|
||
The players take sides in a competitive environment of fast action and/or
|
||
skill. This covers everything from flight simulators to rock climbing.
|
||
Doubtless there will be people who want to play golf against a real human
|
||
being in a laserdisc rendition of the US Masters course, but whether
|
||
they'll keep coming back for more or grow tired when the novelty wears off
|
||
(or they keep losing) is uncertain.
|
||
|
||
- Chatlines.
|
||
Not really games, but such a socially useful tool that despite the sleaze
|
||
factor they'll eventually conquer all. They'll appeal to people who are
|
||
prudish about playing games but who don't mind a little gossip.
|
||
|
||
- MUAs.
|
||
Chatlines plus games. Unbeatable, except for people who "don't like
|
||
dragons and suchlike", ie. are too old or set in their ways. With graphics
|
||
and sound, they'll be absolutely sensational.
|
||
|
||
There is going to be an enormous market for IMPCGs. Although the UK has
|
||
a significant lead in MUAs, it'll disappear in a couple of years once the US
|
||
academics get working on it in earnest, unless the UK industry is given
|
||
support. If not, it'll be brushed aside by the US and Japanese giants,
|
||
particularly purveyors of arcade games and simulators who have suddenly become
|
||
aware of "virtual reality" and may implement such systems leap-frogging
|
||
present-day MUAs completely.
|
||
|
||
There is a demand for these simulator games, unquestionably. However,
|
||
the danger is that they will constitute all the games on offer. There's a
|
||
common misunderstanding among company people discussing playing games over the
|
||
phone: they think that the reason people do it is because they relish the
|
||
challenge of taking on a real human being in a test of skill. They don't.
|
||
People may have that idea initially, but any long-standing MUA player will tell
|
||
you that it's not really this that keeps people playing. To some extent it's
|
||
the social aspect of the game that holds the key, but the real juice is the
|
||
virtual reality.
|
||
|
||
To summarise: single-player games that are modified merely by giving
|
||
them more players will probably have some considerable appeal. This will be
|
||
enough to satisfy their backers. However, shared virtual reality is where the
|
||
big bucks lie hidden, and the first company to make a top-notch graphical MUA
|
||
available to a large user base will clean up.
|
||
|
||
"Business users pay for the system and we have to look after them,
|
||
but we get a lot of satisfaction from the home users who come on
|
||
the system in the evenings. They are the lifeblood - no, the SOUL
|
||
of MicroLink"
|
||
Derek Meakin [MicroLink chairman]
|
||
|
||
|
||
7.6 Conclusion.
|
||
|
||
BT has been lucky enough to have the leading technology for IMPCGs take
|
||
root in its front garden. It can nurture this young shoot until it is strong,
|
||
then plant its seeds elsewhere, or it can dig it up and wait a few years until
|
||
someone else sells one at the garden centre.
|
||
|
||
BT can watch or participate - preferably the latter.
|
||
|
||
|
||
"For adult educators and researchers, text-based virtual realities
|
||
offer an opportunity to enter a synthetic society either as
|
||
observers of the sociology (and sociopathy) of a predominantly
|
||
adolescent culture, or as mission-oriented contributors to the
|
||
informal education and enrichment of the young people populating
|
||
the ethereal world of Cyberion City."
|
||
Barry Kort [BBN scientist]
|