SECTION 1: Abstract.

A new form of computer-based leisure activity, the
MUD, is described, and its future impact on the computer
games industry discussed. The existing prototype system,
although it performs well, is, however, subject to a
communications bottleneck. This both limits the number of
users with which the system can cope and reduces the amount
of descriptive complexity available to the designers/authors
of programs written for the MUD environment. An examination
of the next generation of communications hardware outlines
new facilities which will be available, and which are
appropriate to removing this bottleneck. Several profitable
research topics are outlined, with reference to implementing
a MUD on such hardware.

SECTION 2: The MUD system.

SUBSECTION 2.0: Introduction.

MUD stands for "Multi-User Dungeon", and, on the
face of it, it is a computer game program. Indeed, its early
origins in the department of Computer Science, Essex
University, were solely leisure-oriented. However, it has
outgrown the game-only application domain, and is now in a
position to offer a useful collection of man-machine
interface facilities for a wide range of subject areas.

However, it is as a game that MUD is best known, and
is likely to make its greatest impact. Also, it is mainly
the computer leisure industry which has been attracted to
MUD so far and most of the potential of the program has
been explored in that area. Hence, I shall discuss the
program from a games-centred viewpoint, although I may from
time to draw upon other application areas in order to
make a point.

MUD is a coming together of many different kinds of
program, but primarily it is an adventure game. Computer games
tend to come in one of three categories: the arcade game, the
flight simulator and the adventure game. Examples of arcade games
include Pac Man, Space Invaders, Missile Command, Defender and Star Wars.
Flight simulators embrace
simulators for racing cars, WWII aeroplanes, space ships, and
even JCB diggers. Adventure games are typified by programs
such as Zork. Collosal Cave, The Hobbit, Lords of Midnight,
and Valhalla. Whereas arcade games have reached a plateau in
their development, and simulators never were very popular
anyway, adventure games are beginning to sell more and more,
as they continue to increase in sophistication.

In an adventure game, the player takes on the role
of a character in an imaginary world, a world which is
maintained by the program. The player issues commands in
some subset of English, which the program interprets as
changes to be made on the database it uses to represent the
world. These can include moving around the tokens which
represent the player (eg "go west" , "quit") or other objects
("get spoon", "drop bag"); changing the properties of
objects ("burn curtain", "kill dragon", "open door"); and
queries to the program ("score", "where dwarf", "look").
Each adventure game is typically divided into a number of
'rooms'. which make up a world model, and the player
explores these rooms attempting to 'win' the game. The game
is won usually by obtaining a certain number of 'points'
(which are awarded for deeds carried out and treasures found
during the course of play), or by fulfilling some quest
(killing the evil magician, rescuing the princess,
discovering the murderer, or whatever). Because adventure
games can be very complex, and can require a good deal of
thought and inference to win (especially if they are of a
high quality), they appeal to a good many older players than
the conventional kind of computer game does.

There are, however, several fundemental flaws in
adventure games as they stand at the moment. Some are
related to the kind of audience they enjoy: computer games
are bought mainly by teenagers, although adventure games cut
right across the age groups. Part of the reason adventures
are now selling so well is because by introducing some
graphics capability, they appeal more to the younger age-group;
hence, they are drawing people away from the traditional
"man versus random-number generator" type of
arcade game, into the domain of fully-fledged adventure
games. Graphics enhancements to adventure games are only
short-term measure, however, because most micro's cannot
handle too many high-resolution graphics frames before
either running out of memory or becoming incredibly slow as
they access the disc. The best adventure games are all text-based,
and the usual comparison is that graphics adventures are like
watching films, text adventures are like reading a book.
Eventually, games will be provided with pictures from
laserdiscs, although the price of such equipment is likely
to remain out of the reach of most players for quite some
considerable time, and some alternative way of providing
high-quaiity pictures may have to be sought.

The other main disadvantage with adventure games is
that playing them is essentially a solitary occupation.
While this has its benefits, in the same way that watching a film
or reading a book is a rewarding solo affair, sitting
for hours on end crouched over a terminal oblivious to one's
surroundings is inherently antisocial. Eventually the
players either become bored, or withdraw into themselves and
have a virtual obsession with the computer ("hackers"). This
does not happen to people who play the board games which
inspired adventures, namely Dungeons and Dragons, Runequest.
Traveller, Chivalry and Sorcery, and the like. The reason
for this is that sucn, games involve other players, whereas
adventures do not.

This phenomenon is well-known among adventure-writers.
In a recent edition of "Kaleidoscope" on Radio 4
(llth January, 1985), prominent adventure authors made these
very points. The solution which was proposed was to have
games where several people would play in the same simulated
environment. MUD is the only such game at the moment.

MUD is, at the present moment, a computer game
running on the Essex University DecSystem-10. Due to the
altruism of the University Computing Service, the game has
been made available to players external to the University at
times when the mainframe has spare capacity, which is
presently only at nights. The game is open between the hours
of midnight and seven in the morning, and is restricted to
12 players at a time, because of a limiton the number of
incoming PSS calls (although up to 4 in addition may use the
"slow", 300-baud lines). MUD attracts around 40 different
people a night, half of which form a 'hard core' who play at
least 4 times a week. Around 50 hours an evening are spent
in the game, and some 3000 or so people have played it since
its inception in 1980, clocking up a total of over 25000
hours of play. I have received over 350 letters from the
general public enquiring about MUD, and asking how to access
it, aithough for most of them the expense of obtaining a
modem and/or PSS account has proven too much.

1984 saw growing publicity in the outside world for
MUD. Articles on MUD have appeared in virtually all the
well-known computing hobby magazines, many of the
professional publications, and even a few pieces have been
printed in daily newspapers. All of these have been
extremely favourable. In addition, MUD has been featured on
both local and national radio, and has been demonstrated
live on TV. The reason for this success is down to the
enthusiasm of the players, many of whom have been directly
responsible for the publicity by penning articles
themselves. Some have an almost evangelical fervour for the
game, because, to be subjective for a moment, the game
appears to be an order of magnitude more fun to play than
any other computer game of any kind. Demonstrations for
disbelievers can be arranged!

Another disadvantage with conventional adventure
games is that when they are finished. they almost instantly
lose their appeal. If the princess has been rescued,
Professor Moriarty brought to justice, the jewels returned
to their rightful owner, or the kingdom saved, then the game
is complete. From then onwards, it merely gathers dust until
the player wishes to "trade" it with a friend for some other
program... MUD, ln general, does not have this effect on
people. When the game is 'completed', ie. they reach a
threshold number of points, the players carry on. In some
cases, they are still playing several years after they
nominally completed the game. Even enormous telephone bills,
in the region of 1000 pounds per quarter for the hard-core
adventurers, often leaves them undaunted. Well over half the
people who have completed the game still regularily play it
when they can.

MUD provides several additional facilities for
players, apart from those one would expect of an adventure
game. It includes as standard a sophisticated
teleconferencing system, where several players may be
involved in a conversation at once. The ability to 'snoop'
on other users, which means that all output on their screen
is reported simultaneously on your own, has long been an
integral part of play. The game ls managed by the players
themselves; the ones who have 'completed' the game are given
special privileges, which they use (among other things) to
stop anyone from spoiling play for the rest by misbehaving.

A MUD, then (the term can be used generically), has
the potential to be a very exciting new product in the
computer games marketplace. MUD should also be a natural
first choice of game to run on networKs. It has already had
considerable impact in the computing press, and looks set to
herald a new era in games software technology.

SUBSECTION 2.1: Human-Centred programs.

Although I have been talking of MUD as a game-only
product, it is a generalisation of many present systems
which lie on the interface between human beings and computer
programs. Its 'room' structure, for example, is an abstract
version of the 'menu', found so often in business
applications. In theoretical terms, it is an implementation
of a state-to-state diagram, where the user starts off
one program state, and, by application of suitable operators
(commands), moves to another. These 'states'correspond
to MUD rooms, and whether they are used to represent physical
entities such as real or imaginary rooms, or more abstract
concepts such as "the next question on the questionnaire"
is immaterial. If an application domain can be characterised
in terms of discrete focal points which contain enough
nformation to make a choice as to which point to visit
next, these can be mapped onto states/ooms. Many
man-machine interface (MMI) domains fall into this category.

The main point to note about this class of program
is that it is human-centred. Unlike menu-driven or icon-driven
systems, where the user selects from a set of
possible alternatives, in a MUD the input language is more
like English. Users can attempt to describe what they wish
to do in words they themselves understand. This is
particularily useful for cases where the user is not sure
about what to do next, as actions which they understand may
be attempted in order to build up some composite command. So
if the program was being used as an operating system command
decoder, then rather than provide a menu with "queue" as an
option, it would indeed accept a request to "queue" a file,
but would also accept variants such as "give file to
printer" or "copy my file onto paper". As the users grow in
expertise, so the commands available to them will become
better understood. and they wiil eventually use "to queue"
as the act of requesting a file be printed by the
lineprinter. Because all the commands were already there
anyway. no special 'user profiles' need be maintained to
record an individual's commonly-used icons, or any similar
subset of commands. This is what is known as "adaptive,
intelligent dialogue".

Although, obviously, full English comprehension is
way beyond this, or any other kind of program, it will
attempt to understand what the user says in order to give a
more finely-tuned error message. The built-in communication
facilities are, of course, capable of transmitting any text
to all between users, not just that which the system can
parse. The language used at present for commands to the
system is English, but there is no reason why any other
ASCII-based language cannot be used, say French, Spanish or
German.

MUD, therefore, is general enough to cover a wide
range of applications. It can, for example, be used to aid
cabbies "on the knowledge", biology students exploring the
human body ("You are passing along the hepatic portal vein
Before you looms a large liver.") or to hold a business
meeting ("Hello Ms. Smith, your meeting is in room 3 in 5
minutes."). What gives it this power is its special MUD
definition language (MUDDLE). By using this, any number of
MUDs may be created which have the same interpreter but
different databases. Hence the above three MUDs could all
run on the same interpreter, but with wildly differing
environments. Admittedly, the present version of the program
is heavily biased in favour of adventure games, but there is
no reason why other environments should not be possible.
There are four MUD databases at the moment: MUD itself; an
adjacent environment called VALLEY; a version of ITV's
Fraggle Rock; and a program with just one room, meant only
for private conversations.

So although MUD is first and foremost an adventure
game, its database may be from any other suitable domain. It
can be honed for specialist applications - "if you say 'no'
in room 54 ('have you ever been unwell?') then go to room 87
('what previous work experience have you had?')".
Furthermore, since the interpreter need only be written once
for any target machine, any new database will run on all
machines which have a MUDDLE interpreter, with no extra work
(unless they're too small, of course).

MUD, then, constitutes a programmable man-machine
interface. It is general enough to cover a wide range
of applications, yet provides a powerful set of core routines
which may be used in any of them (MUDDLE primitives).
Whether used for leisure-time activities or in business,
MUD-like systems could play a key role in the future.
Although able to carry out processing without direct
commands from the user, it's fair to say they're not so much
"user-friendly" (for that implies that the machine is still
calling the shots) as "user-centred", in that the system is
completely subserviant to the needs of the users. If those
needs involve maintaining and controlling other, non-human
agents within the environment, then that, too, can be
accommodated.

SUBSECTION 2.2: Academic Relevance.

MUDs can be thought of as a focal point of many
aspects of Artificial Intelligence (AI) work. Unfortunately,
due to the fact that it is still considered very much a
game, this kind of program has not yet taken off in the AI
world.

The relevance of MUDs to AI could easily fill a book
(indeed, I am in the process of writing one!). There are
three main areas in which MUDs can play a significant part,
namely Natural Language, Knowledge Representation, and
Planning/Expert Systems. This is in addition to the MMI
interest expressed in the previous section, but with which I
am not so familiar.

Natural Language is the field of AI devoted to
making computers "understand", in some sense, an input in a
language spoken by human beings. This has long been the
subject of intense research, and MUDs are an ideal
application domain. There are two places where Natural
Language comes into play in a MUD: command input, and
communication with computer-generated players. The first is
obvious, since in order to issue commands to the program
some input protocol must be observed. If the language chosen
is close to English, it will be easier for the human user to
formulate instructions to be obeyed. The second is more
devious, and potentially the more interesting. Natural
Language front ends to database systems have existed for
some time, but there has until now been few attempts to have
human beings conversing with computer-controlled 'software
robots' in an environment they both share. Indeed, the very
notion of a player conversing with another player and not
being able to decide whether it is a human being or a
program-controlled process forms the basis of the 'Turing
Test', the original method designed to determine whether a
machine could be said to have "intelligence" or not. I
hasten to add that it it unlikely that MUD would pass the
Turing Test! Also, in the present prototypical MUD, such
human/computer dialogue is not implemented. It is, however,
a good avenue for future research. There is no shortage of
volunteers to try out the system, either...

Knowledge Representation (KR) is central to most
aspects of AI. Many different KR regimes have been proposed,
but always on relatively trivial domains. MUDDLE, the MUD
database definition language, presents a fine opportunity to
test out many KR techniques in the flesh. The present system
is 'frame' based, because this interfaces best with the
requirements of the natural language front-end (which uses a
'case' grammar). However, more appropriate representational
methods may well be worth investigating, and given a
worthwhile, non-trivial application domain such as a MUD,
such work could yield useful, concrete results.

Planning, including Expert Systems technology, is
essential to 'drive' the computer-controlled players round
the game. It's no use asking one of these agents how to get
to a cave if it is incapable of figuring the route out.
Similarily, when not involved in conversation, the agents
should be able to pursue their own goals, which in an
adventure game may mean finding treasures in the same way as
normal players are expected to do. In effect, they act as
expert systems to play the game (or take part in whatever
simulation is under way - invading bacteria in the biology
model, say, or other motorists in the taxi domain). Certain
conditions imposed by the necessity that these computerised
agents behave in some respects like human players have
already fed back into the AI planning arena, and there are
techniques under development as a direct consequence of MUD
which are capable of handling situations that existing
planners cannot cope with ('cross-level' plans).

Because MUDs use programmable databases, more
appropriate application domains can be selected if it turns
out 'fun' games remain a non-respectable academically for
much longer. The whole idea of a MUD as a framework for
general MMI architectures also needs to be pursued. Research
in these aspects is still in its infancy, but well worth
continuing from an academic point of view.

Certain aspects of MUD play have attracted attention
from other, non-computing disciplines. In particular,
applications in EFL (English as a foreign language) training
have come to light. The sociological aspects of the ongoing
MUD game, in which players invest many hours every night,
has also aroused interest; for example, in some ways the
hierarchy of experience 'levels' in the game mirrors the
caste system in other cultures (particularly that of the
Asian Indians). I have no intention personally of following
up such research, however...

MUDs, then, are beginning to act as a focal point
for many fields of AI. At the moment, however, they are
barely started, and although the interest is there it is
unlikely that they will ever rise to great prominence; this
is likely to be for commercial reasons (they will soon be
big business), rather than academic ones. Also, a pedigree
with a games program at the root does not auger well for any
AI system at present, as the subject is trying to shed its
image of a discipline not to be taken too seriously.
However, tht MUDs are well worth investigation from a
purely academic standpoint can certainly not be denied.

SUBSECTION 2.3: Immediate Prospects for MUD.

The current version of MUD, which runs at Essex
University, is in the process of being made a commercial
concern. It already runs on Commodore's CompuNet, although
that is due to a fortunate choice on their behalf to use the
same hardware as MUD already uses. The program is about to
be rewritten to run stand-alone, to be accessed from the
public telephone network, and it is this system, and its
comparison with the original version, which I shall be
discussing in this section. Hence, most of what follows is a
description of what advances the forthcoming MUD has over
the original, and a demonstration that the project is
feasible using existing technology. It is also very much
adventure-game oriented, as this is the main area in which
expertise lies, and it has a proven track record of
commerciai viability.

The new version of MUD, the Mark 2, has several
advantages over the Mark 1, primary among which is that it
does not require a large, industrial-power, timesharing
mainframe computer to run on. Because of this, it is far
cheaper to purchase or rent the hardware necessary for the
system to function. The basic Mark 2 architecture is a local
area network (LAN) of microcomputers, each of which has
associated with it a modem. The users contact the system via
some public network, for example the telephone lines, and
are assigned one of the micro's. This then acts as a front-end
for the MUD, and their own machine is nothing more than
a dumb terminal. The micro' performs all the mundane parsing
work required for the user's input, which uses a lot of
processing power if carried out serially, but which in this
system will be undertaken by all the machines in parallel,
each handling its respective user's commands. Also on the
network is a database machine, which takes the tokenised
commands from the users over the LAN, and carries out the
update on the world model. It then reports to the relevant
front-end micro' any changes, and this machine transforms
them into text and transmits it over the connecting media to
the user to which it is assigned. This architecture has
other advantages, too, apart from its relative
inexpensiveness.

As it is modular, the initial configuration (which
is set up when the Mark 2 is first opened to the public) may
have as small or as large a number of machines as desired.
There's no need in this system to obtain a powerful
mainframe computer capable of handling up to 70 users, if,
for the first two months, there is only likely to be a
maximum of around 30. Similarily, if 100 people are
regularly trying to play and there are only 70 slots for
them, it is simple to upgrade the Mark 2 hardware merely by
buying in more microcomputers, whereas for the Mark 1 system
the immensely prohibitive cost of purchasing a higher-powered
mainframe would have to be borne. Buying in another
mainframe the same size would allow two MUDs to run, but not
one MUD with all the players in it.

Another major advantage of the Mark 2 hardware is
that it is much cheaper to maintain. It does not need
permanent operator supervision, and no special environment.
Furthermore, it is far less expensive to insure the
equipment, and it needs no external maintenance. Even
minicomputers, such as VAXes, need regular, monthly check-ups
by engineering staff provided by the suppliers.

The Mark 2 is to be written in an adaptation of
MUDDLE, which is in effect a brand-new programming language
designed to make it easy to write Adventures, particularily
multi-user ones such as MUD. This is potentially the
greatest asset of the Mark 2, because it heralds all manner
of other significant advances over existing and planned-for
programs. For example, the time required to write a MUD once
the first one has been developed is far shorter than with
the Mark 1, because the majority of the work needed to be
performed has already been done. The language is much
simpler, so that it is easier to describe the new 'worlds'.
No programming skill at all is required, which means that
bona-fide authors may be tempted to use the system to define
their own universes (for sufficient commercial reward!).

Because much of the work in the Mark 2 is done in
the adventure-definition ianguage, any computer system which
has an interpreter for the language will be able to run all
the MUDs written in that language. This is the case for the
Mark 1, except that the interpreter has several very large
built-in procedures which really ought to be part of the
database rather than the interpreter. Also, it has several
superseded parts, which may be safely removed once their
full effects have been traced throughout the program.
Because of the portability of the MUDDLE code, to move the
Mark 2 onto a different range of machines all that is needed
is to write the interpreter for the target system. It will
then be able to run ALL the software written in the
language, ie. all the previously-defined MUDs, automatically.
The language has been designed to keep the interpreter down
to as small a size as possible, and much of this program
will be in a readily-transportable language already (C or
PASCAL); only a few machine-dependent routines will have to
be rewritten if a new hardware configuration is required.

Because the interpreter for the Mark 2's definition
language is modular, it may be readily expanded when new
technology becoles available. In particular, if a graphics
capability is required, it should be relatively easy to add
the reievant graphics packages to the system. Laser discs
for fibre-optic carrier media, digitised networks for
voice-and-data, and high-speed connections between different MUDs,
are all more futuristic possibilities which may be slotted
into the present system when the technology becomes more
commonplace. A great deal of work will be required, however,
if this is to become a reality, because the implementation
of those modules themselves is likelyto be a very difficult
exercise, and nost probably would benefit from some research
itself.

Since the Mark 2 will run on any machine which has
an interpreter, and the interpreter is not too large to run
on micro's (as was the case for the Mark 1), it is possible
to write Mark 2 interpreters for the home micro' market.
These will in theory be able to run the larger MUDs, as
single-user dungeons (SUDs), but in practise they will
probably have smaller sections of the main game, because
they will not have the storage required for the entire
database. Some of the packages present in the multi-user
versions will not be necessary for the SUDs, for example the
communications software, whereas other modules, such as
graphics handlers, will probably be substituted in their
stead. Interpreters for each home micro' need only be
written once, and they will then run any of the SUDs written
for the other personal computers, assuming they are not too
large.

Another place where the Mark 2 scores heavily over
the Mark 1 is the efficiency of its implementation. By this
I mean that the program will use structures and algorithms
better suited to handle the needs of MUDs. The Mark 1 was
purely for research purposes, and the lessons learned in
implementing it will make it that much easier to do the Mark
2 . Although the Mark I does not run slowly, that is partly
because it is run at nights on a fairly powerfol mainframe.
The Mark 2 implementation takes full advantage of existing
hardware and software packages to build a parallel-processing
network. Much of the work which would slow down
the game is mundane symbol manipulation which isn't multi-user
at all. The multi-user part can be hiked off onto a
separate machine. This will speed up the response time no
end. Also, because the system is linked to the user via a
modem, these can be replaced were faster external lines to
become available (or if the game were linked onto an
existing network, such as PRESTEL). Even at full throttle,
the user will notice hardly any delay in obtaining a
response from the game, because additional players do not
add significantly to the load on the "shared" database
management machine (the only possible source of a bottleneck
within the LAN). The main cause for concern is the speed of
communications between the user's home microcomputer and the
MUD system, and it is this factor more than anything else
which limits the potential of MUDs.

With the proposed architecture, far larger databases
may be written. The present MUD runs out of space at about
40O rooms, given 70K to utilise . The new system will have
some 15 times that amount of memory. With hard discs already
used (to save the text messages. and for accounting
records), any extra locations may be stored directly on
them. In theory, there is no limit to the number of
locations in a game, although in practice few players would
want to start a MUD if they knew they were unlikely ever to
hope to finish. Also, beyond a certain size it is necessary
to introduce different start locations to avoid congestion,
determined by the "physical" layout of the world in the
database, rather than any technological considerations of
the LAN.

It is no great trouble to add on things to the game
incrementally. So, if a small database was used initially,
later additions could be made at leisure. Also, because of
the nature of the adventure definition language of the Mark
2, the addition of new rooms does not increase the number of
actions exponentially, a big problem in the Mark 1. In
there, adding a new room and its associated objects involves
increasingly more work, due to the interactions with already
existing objects. For example, adding a new object which has
a naked flame (a match, say) means that all the existing
combustible objects have to be covered in case the user
attempts to burn them with it. In the Mark 2, this problem
is avoided by a hierarchy of object types, enabling already-written
code to handle most interactions.

The Mark 2 has much more sophisticated
representational techniques upon which it can draw, culled
from the science of Artificial Intelligence. These provide
it with greater descriptive power, and hence more complex
entities can be made available than ever before in adventure
games. As I mentioned earlier, this is the chief academic
interest in the system, because of its great flexibility. If
more complex entities can be represented in the game, it
follows that far greater detail can be given. Due to the
amount of common store available, the descriptions will be
richer and more comprehensive - they may even be edited by
a professional author for greater eloquence. The amount of
detail can vary, for example in one game a "ship" might be a
single object which can be manipulated as a whole; in
another, it might be made up of more objects, for example a
hull, mast, and sails - you may even be able to get into
different rooms contained within it. The level of detail
depends on the application, and is always at the discretion
of the person or team designing the database.

Present adventure games have a very poor Natural
Language front-end. They don't understand many perfectly
reasonable English-like sentences. One of the powerful
features of the Mark 2 will be a complex Natural Language
parser, capable of understanding virtually anything the
players would care to say. Since the system is modular, this
part of the program can be taken out and replaced by one for
a different language, eg. French, if needs be. The parser for
the Natural Language interface has already been developed
for the Mark 2, and is capable of delimiting sentences as
complex as "after four seconds, using the small knife which
is not silver stab three times the old wizard beneath the
tree, then pick up some of his shiny coins but not any
copper ones and slip them in the casket".

It will be far easier to access the Mark 2, because
people will be able to dial direct using their own 'phone.
Whether special data lines will be needed to make it run at
speed remains to be seen, but the extra communicational
costs borne by PSS users who play the Mark 1 will certainly
not be necessary for the Mark 2. In the mid term, with
access points all over the country, a large percentage of
the population will be able to play at local 'phone rates,
if not in Britain then certainly in America. The alternative
is to open the game to the cable TV companies, but the
forthcoming digital network capabilities proposed by British
Telecom make the use of telephone access a better
proposition in the long term.

The Mark 1 is not a very reliable program, but then
it was never meant to be. It crashes quite often for this
reason or that, the most popular being is hardware failure,
Which for a centralised system means that no-one can play.
In the Mark 2, the software will be more of a product than
a program, and will be built with reliablity in mind.
Resistance to crashes due to the players, such as
communication failure, will be built-in - it may very well
come automatically with a judicious choice of modem. If any
of the networked machines crash, then only one user is
affected, and only their call is lost. The line can then be
removed so that no-one else is given it until the machine is
repaired (or a backup substituted). The only major problems
are when a "shared" machine, ie. the main database-handling
one or the file server, fails. Then the whole system will be
out until it can be fixed. This can be avoided by using
either a standard hardware, such that one of the other
micro's can be used instead, or by always having a back-up
machine ready to be used in the event of a breakdown.

Unlike most computer games, there is no chance that
the Mark 2 will be pirated by unscrupulous individuals.
Since it will only be running on one system, no external
agent will be able to take the software for their own use,
unless permitted them through a franchise. This is an
advance on the case for normal adventure games, but for any
other MUD-like game the same would be true. Similarily,
no-one would wish to give one of their personae (ie. the roles
they play in the game) to another player, because if that
persona were killed then it would be they wno suffered. If
these personas were tied to network accounts, then, it would
be an added reason for people to protect their passwords;
folk would be reluctant to distribute their password to
their associates if it ruined months of work building up a
persona to a high level in the game. Free dissemination of
passwords is the primary source of security violations in
computing installations.

An important feature of the Mark 2 is that the
operating company will be in a position to employ people to
play the game and keep it under control. This would mean a
person tking on the role which SUE the witch played in the
Essex version, until her recent departure (due to several
consecutive phenomenally large telephone bills). With some
high-level stabilising influence, the Mark 2 will be more
fun to play than the Mark 1, since people won't get so
incensed when they're the victim of some high-powered
character's whim; it'11 be more "just", in a sense. Also,
the intrusion of unwelcome outsiders, perhaps players owing
their allegience to a competitor. who wish to distrupt the
game or advertise the rival product, will be reduced if
there is a permanent watchdog to ensure that the game is not
spoiled.

The greatest difference between the Mark 2 and Mark
1 versions of MUD is that the new one will have a far
greater user base. What makes MUD fun is other people, and
the more people who play the greater the fun will be. A
large user base is the Mark 2's most important asset. A
speedy implementation of the Mark 2 is therefore under way,
before advantage of this seller's market is taken by another
organisation.

It should now be fairly obvious that the next
version of MUD is feasible, both on the playing side, and on
the software and hardware sides. There are, however, several
problems which have not been fully addressed in the Mark 2,
which will need solutions in the long term if MUDs are ever
to become major computer-based leisure systems.

SECTION 3: Present Problems.

SUBSECTION 3.0: Hardware.

It is undeniable that if they are to operate with
many players at once, MUDs need a great deal of both
processor power and memory. The configuration of machines
outlined in the previous section have their advantages, but
they are still not a very good solution to the problem of
running a commercial MUD. A great deal of free processor
power, that available in the userls own micro', is being
squandered by their being used solely as dumb terminals, the
main work being carried out by the micro's at the host end
('host' meaning the system which the player is contacting,
and which runs the MUD software).

This has disadvantages; in particular, the
communication between user and MUD system can be greatly
reduced, and hence speeded up, by tokenising the user's
command before transmission to the main system. Output from
the modems can then be multiplexed into a smaller number of
front-end machines, or perhaps to only one, the database
driver itself.

The architecture described was chosen for a number
of reasons. At the moment, there is no off-the-shelf product
which would enable modems to be multiplexed into a
relatively inexpensive machine. Even a 16-bit processor,
which is the architectur envisaged for the database serving
part of the system, would have difficulty timesharing up to
100, say, lines by itself. Also, the great variety of
micro's owned at the present by members of the public would
mean that much of the communications software and the
command parsing mechanisms would have to be written for
several different kinds of machine, and bought over the
counter by prospective players. Finally, providing software
for users to access the MUD would be a gift to competing
outfits who could use it as their own front-end software.
This would mean any company which had invested effort in
writing the software in the first place was effectively
wasting its time, as others would be able to utilise the
programs without any payment. Their only chance of recouping
this loss would be in the price paid by the public to buy
the MUD/comms software.

Once the system was operating, a great deal of the
equipment could be made up on boards and racked, although
again, many companies are understandably reluctant to sell
their machines in bits and pieces. Also, time pressures mean
that the companies which make the first moves in
MUD-oriented networks will snatch a lead that the late-comers
will find hard to catch up, so spending time constructing
specialist hardware is probably out of the question for most
companies working on MUD-like products at the moment.
Eventually it may be possible to buy an off-the-shelf black
box, containing all the sophisticated electronics you need
to run 2 MUDs under one casing, but not for some considerable
time I should imaglne!

Other problems arise because of the general
inavailability of cheap, buyable hardware for large, stand-a1one
programs. There are not many LANs on the market for
inexpensive micro's, and those that do exist commonly do not
allow machines of a different type to operate from them, ie.
they are machine-dependent. The Sinclair networks for
spectrums (spectra?) and QLs, and the ECONET and TORCHNET
for BBC's, operate more or less on this principle. For more
powerful general-purpose LANs, such as ETHERNET, it is often
the case that the coupler which links micro' to cable costs
more than the micro' itself, and, in addition, none of the
operating software required is available. To mix processor
types is next to impossible on inexpensive LANs unless you
write the software yourself, and the only way out seems to
be to use a micro' with a second CPU (ACORN do a Natsemi
32016 for the BBC, and TORCH have a Motorola 68000 board
available). For anything else, a good deal of tedious
machine coding needs to be written. These LANs aren't
particularly wide band, either. Development tools for
software on any micro' aren't ever anything particularly
special, and being forced to program in BASIC is enough to
put any programmers worth their salt off a system. Even the
peripherals advertised, such as printers and file servers,
generally need extra work on the software side to funtion
properly. This lack of support for serious LAN users by the
microcomputer manufacturers is yet another annoying facet of
trying to implement a large system with a small amount of
capital.

The above bardware difficulties are mere
obstructions, however, and can be side-stepped with the
investment of only a little extra cash. Under-utilisation of
the available computing power is a deficiency, for example,
but it does not matter if extra power is brought in on the
host system side; in the example configuration for MUD
cited, this is in the form of a LAN of micro's. There are
hardware difficulties beyond this kind of solution, however,
dominated by the media used to connect the user with the MUD
system.

SUBSECTION 3.1: Communications.

The way to reach the largest number of subscribers
is via the public telephole system, which in this country is
owned and maintained by British Telecom. Unfortunately, this
system was designed decades ago to handle voice-only
communications. It is not suitable for high-speed data
transmission, of the kind which would be required for a MUD.
The best speed it can manage is 1200/75 baud, which
represents just about the bottom line in acceptability as
far as playing MUDs gaes. The game at Essex University is
played both internally (at 9600 baud) and externally (at
1200 or 300 baud), and the difference is quite astonishing.
It makes for a much better game if things can be transmitted
and displayed on the screen just as soon as they happen (for
MUD is, obviously, a real-time program). At 300 baud it is
so slow that players spend most of their time reading
messages sent by other players, only occasionally adding one
themselves. MUD itself generates text messages, some of
which can come so quickly that the program runs out of
buffer space before they can be printed by the players, even
if they are running at 1200 baud.

It is out of the question to use the existing MUD to
send graphical information to the users' terminals, even if
they were all using the same equipment and could display it
as it came. Beyond 9600 baud, most micro's couldn't cope
anyway, but since the telephone network doesn't give them a
chance to try, this is only really an academic point.

This speed deficiency is out of the hands of the
people running a MUD. The alternatives they have are: to try
some other, faster carrier medium (for example cable TV);
try some country with a better telephone network (the USA);
or to wait and trust that the network in this country is
improved within the forseeable future.

Cable TV companies which would allow MUDs on their
lines are hard to come by, as most owners have bought their
franchises with a definite purpose in mind. Even the
companies which wish to offer games will probably make quite
a killing anyway on the products they are promoting, and
will not wish to bother themselves with unproven, esoteric
ideas like MUD appears to them to be. Also, viable cable
networks are quite a way off in this country, and even
abroad they don't reach the kind of audience which would
immediately relate to a MUD.

Professional databases have a long and chequered
history in the USA, but have now stabilised. The massive
DIALOG, THE SOURCE and CONPUSERVE networks are indeed
impressive to behold looked at from a UK base. Also, they
are willing to tack on any fringe systems which approach
them, provided that these do not violate the integrity of
the system as a whole. Any product which will increase the
range of services to their users will be considered.
Although DIALOG probably has the wrong kind of user group,
the other two systems mentioned, and the numerous localised
databases, may be good places to initiate a MUD.
Alternatively, a system like the above, except using the US
'phone network, might be a good idea.

Another problem with the present telephone network
in the UK is that the number of lines required for people to
play is roughly one per player. MUDs involving thousands of
players simultaneously are not out of the realms of
possibility, but they would need a similar number of
telephone lines. One line could not be used and 'time-shared',
because the exchanges cannot manage that. It is the
BT exchange, rather than any on-site one, which takes apart
the signals onto different lines. Again, because the number
of incoming calls allowed is out of the hands of the company
running the MUD, it is a lengthy business to arrange for any
increase in the number of incoming calls which can be
handled. Also, these lines cost a rental, which many small
companies might not be able to afford.

Another alternative is to stay with the existing UK
telephone system and hook onto a favoured network. All the
front-end communications software will then already be
available, and many of the problems presented to anyone
wishing to initiate a MUD would be already out of the way.
For a network such as PRESTEL, this would definitely be an
advantage, because if high-speed data transfer were to
become a reality in the near future, PRESTEL would probably
be the first network to benefit However, there are
disadvantages to this, and indeed to connecting to any
network owned by another company, headed by the usual
problem of cost. I'll go into this in more detail later on.

Because the current communications system is so
ingrained into the conciousness of network operators in this
country, many technologically feasible improvements to the
networks of the future have not yet been considered. Even
using cable networks bi-directionally, rather than for
simply downloading software, is a relatively novel idea for
many cable-owning companies. High-speed transfer of visual
images is easily within the limits of fibre-optic based
cable networks and wide band digital electronic nets.
Perhaps a study should be commissioned into the possible
uses of future communications technology, so that when it
becomes available the projects to utilise it will already
exist. I should certalnly like to see MUDs high on such a
list of products.

SUBSECTION 3.2: Methods of Payment.

MUDs can generate large amounts of income. If people
are prepared to pay up to £3.50 an hour to play (as they do
on CompuNet), this kind of game has definitely got a future .
Last quarter there were several telephone bills among the
Essex University MUD players in the range 900-1000 pounds,
and the largest ever received was over 2000 (immediately
after a l000 pound one had been paid). The continuing
precarious existence of the 'midnight line' facility for BT
means that these costs can be reduced to 100 pounds a
quarter, but still that's a substantial amount of money for
someone to pay.

It is probably fair to say that, given more social
hours, the present velsion of MUD would attract a large
number of players even with PSS costs making the going rate
about £2.50 an hour. It is likely that if these costs were
halved, many people would over spend three times as long in
the game, and thus increase the income by 50%.

However, none of the money people currently spend
playing MUD goes into the pockets of the designers.
Virtually all of it goes to the people who control or own
the network by which the players zccess the game. For the
Essex copy of MUD, that means BT; for the CompuNet one, it
means BT, CompuNet, and ADP. Hence there is no incentive for
people to design their own MUDs unless they own a network.

There is obviously a problem here! The solutions
outlined in the previous section have some bearing on the
issue, too. One of the reasons the USA is a prime target for
MUDs is that local telephone calls there are free. Also, the
telephone companies may be negotiable over possible large-volume,
long-term calls to the same destination. BT has
consistently refused to reduce telephone charges, even for
data-only transfer, and not even PRESTEL enjoys free
communication (although the 50p an hour or so demanded by
local 'phone call rates aren't too devastating).

To link to a network which is already running,
whether on the telephone system or some other data link, is
tempting (because of a ready-supplied user base, and
utilisation of their existing front-ends). Hiring time on a
network would cost money though, and perhaps-even involve a
royalty on income derived from use of the network. This
would present a heavy burden on the company operating the
MUD. As has been demonstrated with CompuNet, even when one
of the main reasons people initially connect up to the
network and pay their subscriptions to it is to play MUD (as
has been reported in the computer press), the MUD is still
seen as a product which uses the network for its own ends,
rather than a service which encourages people to use the
network in the first place. If a standard charge were levied
for time spent on the network, irrespective of the service
being used, then it would be far more satisfactory as far as
MUDs were concerned. As it is, charging is made along two
axes; for connect-time, and for a percentage of the income
obtained by the MUD operators. The reason for this is
because for many services, such as downloading programs, the
connect-time spent is relatively small, but it needs to be
charged to discourage people from typing up the network by
sitting around viewing free pages all day. However, it is
very significant for people who may spend hours in a game,
and the network owners therefore rake in far more money than
they should really be entitled to in relation to the effort
involved on their part.

To rationalise this is next to impossible, because
most of the charges are beyond the control of the MUD
operators. Ideally, there should be either free
communication with the game and the charge be levied for
time spent in it, or free play in the game and the money be
taken in by the network owners. The income should then be
split to an agreed percentage. I favour free communication,
because then "prizes" of extra time in the MUD can be given
by the MUD, as an incentive to spend more time playing.
There should certainly be more co-operation between MUD-running
companies and the appropriate network-owning
businesses; if people would play the game for over twice as
long as they do at present were the costs involved halved,
then both companies would benefit. It is definitely worth
the experiment, anyway.

I have assumed, here, that the best way to make
people pay for the game is per hour spent in it. This is not
necessarily the case. There is likely to be a registration
fee anyway, and it may be that making this be sufficiently
high as to permit unlimited free play for a length of time
could be the answer. Were it not for BT's midnight line,
several players would not be spending ANY money playing. As
it is, they play for 'free' after the initial payment, but
know the extent of their investment before they play. So it
could be that a greater income could be raised if the game
were based on a fixed charge for as much access within a
certain time as possible. This works well for things like
season tickets for public transport companies, where one
initial outlay will gain unlimited use for a set period.
Whether it would be a good way to run a MUD is a matter for
conjecture, however, since it is unlikely that BT would
change their charging strategies for such a small section of
their total user group. Cable TV companies may take a
different 1ine, however .

I suspect, though, that the best way to make money
is to charge on the hourly rate. The players would be given
a certain number of units free (effectively credit), and
these units would be worth time in the MUD, depending on the
time of day. At peak times they may be worth 30 minutes, at
other times perhaps an hour. Charging for time in the game
in this way means that playing a MUD is like buying a book,
but having to pay every time you read it. Put like that, it
sounds promising if you're the author of the book, although
not so encouraging if you are a prospective reader,
however...

SECTION 4: Future Possibilities.

SUBSECTION 4.0: ISDN-like Technology.

With the advent of new communications technology,
MUDs could really become a big success. The Integrated
Services Digital Network (ISDN) of BT looks the best
prospect for the implementation of MUDs in the long term, in
common with other related, enhanced services which
incorporate digital switching and data transference.

I shall restrict myself in this section to
describing the ISDN system, and use it as the model to hinge
discussions about the improvements which can be made to MUDs
in the future. Other high-speed, wide band data networks,
based on alternative technologies such as fibre-optic
cables, would benefit in an equivalent manner were they to
become a viable, usable media in the same way as ISDN is
scheduled to be.

ISDN essentially offers a 64 Kbit digital pipe
between users. Dotted around the country will be some 60
digital switching units, connected by a high-speed trunk
network. The wide bandwidth will be used for voice, data.
and anything else which can be putinto digital form, and
can be made available right down to the user's home. Users
can then hang virtually any piece of approved equipment they
like from the network, and have a 64 Kbit connection to any
other user via the ISDN. Or, indeed, users; ISDN allows
shared calls, which means more than two users can be
connected to one another simultaneously.

Although the availability of the full 64 Kbit
bandwidth down to the user end is intended primarily for
such applications as internal telephone networks for large
organisations (via a switchboard) it is obviously an
exciting prospect for home computer owners (or, indeed, any
computer owners!), because it permits very fast data
transference between installations The capability of
linking several users together at the same time is also
meant for other purposes, business teleconferencing for
example, but with computers on the relevant nodes instead of
people, it becomes a giant LAN, only some 4 times as fast!
This is a highly powerful idea, and if it can indeed be
proven to work could revolutionise communications,
effectively by having all comms systems use the same
network. Even LANs in schools, for example, could benefit in
using ISDN instead of local networks, provided the costs
were not too great, by initiating and maintaining permanent
conference calls from their machines; this would side-step
the need to buy and maintain their own LAN, because they
could use the ISDN for that purpose instead.

So the kind of technology which will become
available is a national network, operating at such a wide
bandwidth that it is possible to link any collection of
computers together in what amounts to a LAN. This is indeed
a very exciting prospect; what advantage can be taken of
such a major advance in the available technology from the
standpoint of the possible implementation of a MUD?

SUBSECTION 4.1: MUD on ISDN.

In this section I shall outline some of the ways in
which MUD software technology can utilise the ISDN system.
Of course, there are many related problems involved, both on
the practical and theoretical sides, which I shall make some
attempt to discuss. Some of the suggestions are obviously
flights of fancy, but most are realistic possibilities, with
a good chance of successful integration into the ISDN
scheme. A consideration of the ways a MUD could use the ISDN
hardware for its own ioplementation appears in the section
after this.

The main advantage of ISDN from the software point
of view is the amazing bandwidth available. MUD is text-only,
but using ISDN it would be comparatively easy to
download images from a fast-access permanent storage medium,
such as a laserdisc, onto the user's terminal. Provided that
this machine could handle it, the picture could be displayed
directly on the monitor. It would require a substantive
memory to maintain such an image on the screen, however,
although even this would not cost a fraction of the price of
an individual laserdisc system for each user.

For MUDs, the ability to download complex, detailed
images within a split second leapfrogs the conventional
graphics facilities employed by the normal kind of adventure
game. It greatly enhances the non-game respect MUD would be
able to command, especially in the educational world where
pictures of a high quality under interactive control would
be of immense value. "Business games", of the "John Cleese
learns how to calculate cash flows" genre would also adapt
well to the programmable screen.

Text/image mixing isn't, in theory, very difficult
because the image traffic goes one way, host to user.
Permitting the users to transmit digitised pictures of their
own within the MUD context is possible, but unlikely to be
of any use. MUD itself would not be able to handle them, as
they would only become meaningful if viewed by another human
being. So assuming one-way traffic, it shouldn't be too
difficult to arrange protocols to define whether incoming
bitstreams are for text or images. Writing a suitable
interface for a micro' attached to a video monitor, such
that the image can be displayed in a separate window, would
be a worthwhile activity, and have applications wider than
just MUDs.

The same can be said of voice communication, except
that this medium enjoys an immense advantage over the
transmission of photographs in that the equipment needed to
do it is cheap, and the network was especially constructed
with voice contact in mind. MUD could download sound effects
at great speed, in the same manner as it would digitised
images, and these could be switched even more easily over a
speaker or telephone handset for the user to hear. The
incorporation of protocols into MUD to decide whether to
display or audibly transmit incoming bitstreams is
is essentially the same kind of thing as the case for images,
and since the equipment on the receiver's end is guaranteed
to be present, this is probably the better project to
implement first. The main problem would seem to be having a
mass-storage system at the host end able to store and
randomly access a significal amount of digitised audio

Players would, however, have a ready-built hotline
to the MUD operators. If play in the game became affected by
the irregular behaviour of some of the players, a complaint
can be lodged there and then, and the problem rectified
within moments. This would free any "permanent presence" in
the game for other duties, rather than simply sitting in MUD
all the time making sure that nothing ado happened which
required attention.

The real difference between audio and visual
integration within a MUD is that whereas video is only
likely to be host to user, the greater audio traffic is
liable to be user to host (or user to user, possibly via the
host). This is a much more difficult affair, because if the
user can initiate either text or speech communication,or
possibly both at the same time, the MUD must be very careful
that it does not confuse the two signals. Such
disambiguating protocols are only necessary, however, if the
voice and data are both transmitted to the same host. As the
MUD system has no use for voice input save to retransmit it
to other users, the built-in ISDN audio signals processing
will be able to send it directly to the relevant people,
without going via the MUD host. This means that MUD would
have to interact closely with the ISDN supervisory modules
in order to switch in and out the appropriate recipients.

For example, if the player wishes to issue MUD
commands at the same time as talking to several other
players in the same MUD room, then MUD can inform ISDN which
other parties should be recipients of the information. If,
as the conversation proceeds, other players in the MUD enter
the same room, then MUD will inform ISDN to relay all
conversation going on in that room to that player - a
teleconference, in effect. If players leave, they will be
removed fron the conference and will no longer receive the
messages - MUD would have to tell ISDN to adjust the
relevant connections so that any messages sent to the group
no longer went to them. If one of the players in the MUD
gave the text command SHOUT, then any words they uttered
would be patched through to everyone. If they used some form
of one-to-one telepathic command, then they would employ
what amounts to a standard everyday kind of telephone link
between two individuals

It can be seen, then, that in order to make this
work a great deal of interaction between the MUD and the
ISDN system has to occur. Whether this would require
additional software in the ISDN exchanges in order to cope
with instructions, from a remote host, to alter the
destinations of messages of certain kinds originiating from
subgroups which share a teleconferencing line with the host,
I fear would require a deeper insight into the workings of
ISDN than I currently possess.

Apart from the possibility of carrying different
modes of information other than text to players in MUDs,
other possibilities are opened up by the impressive
communications specifications of the ISDN facility. Speed is
another obvious one - information can be transmitted faster
than the micro's can display it, which is the reverse of the
position pertaining at the moment. Because the data is
passed so quickly, a greater amount can be sent, which means
more detailed MUDs are possible. Although for adventure
games applications, there is an upper limit on the amount of
text players can read without getting bored (especially in a
real-time game like MUD), for less time-dependent
applications, such as in business or education, these
constraints are much less important; the addition of extra
information resulting from commands could only improve them.

The ISDN connections make the whole MUD system
behave as if it were on a giant LAN, and hence the usual LAN
facilities can be incorporated into the MUD. Detailed
communication between the MUD host and the home micro' will
be possible, and downloading of the latest communications
software appropriate to that make of machine is feasible
(although expensive if it needs to be written for a wide
range of machines). Certainly a roll-call of micro's every
few seconds should be implemented to check for hardware
failure. Other regular LAN-related services may also be
worth installing.

Perhaps the most appealing application of ISDN
technology to MUDs is that it will allow virtually any
number of players to participate at once. The current
limitations on the number of lines which the system can take
will vanish with ISDN. This, however, would need a different
architecture for the MUD, and certainly could not be done
with the network of micro's for whlch the Mark 2 has been
commissioned, acting as an ISDN local exchange to pipe the
incoming calls to particular front-end processors before
being passed to the database management machine. Once a
MUDDLE interpreter for this architecture had been written,
all the previous MUD software would run, of course, but the
putting together of the hardware isa non-trivial exercise,
and off-the-shelf products would certainly have to be
modified to cope. A 1000-player MUD is the size of game
which is envisaged eventually for this kind of set-up,
although the amount of work in designing a corresponding
10000-room MUD to cope wlth it all is rather overwhelming.

So MUDs as independent systems hooked onto a
national ISDN grid would be able to make full use of the
excellent facilities afforded by the wide band digital pipe
which it provides. However, it may be possible not only to
link the communicational needs of the MUD user community.
but also to use their processors to run part of the game
itself, making the ISDN work like a fully-fledged LAN among
MUD players. It is this, the hardware integration of the MUD
concept into a digital network, which is considered in the
next section.

SUBSECTION 4.2: MUD in ISDN.

If a configuration of machines running MUD were to
utilise the ISDN hardware as part of their organisation, the
ways in which they could achieve this can be classified by
proximity of the system to the user. With ISDN, the
communication between computers attached to the network
occurs at such great a speed that it is faster than it would
be were the machines on an average, present-day LAN.
Provided that the cost of continual use of the ISDN
connections does not prove too heavy, there is no reason,
then, that the LAN to which the host system's micro's are
attached shouldn't in fact be implented through ISDN. So
instead of the hardware layout I described earlier, with a
LAN of micro's linked to a central database management
computer, it would instead utilise the same basic machines
but tied together with ISDN links. This would mean the
inter-processor communication would be even quicker, and a
greater amount of data could be passed between the nodes on
the network without having to be compressed first (text, in
particular). This would release more processor power for
maintaining the game, and monitoring the players' use of the
game.

This system would still be "closed", however, in
that all the processing of information would be carried out on
machines run by the MUD operators. A more ambitious scheme
would be to use the micro's of the players to process the
game. This would mean that for all the popular makes of home
microcomputer some software package would have to be written
able to keep, edit and maintain a section of a MUD; hardware
is likely to become sufficiently cheap within the time scale
under consideration, however, and much of the essential
communications software could be put into ROM and interfaced
with the micro'. Probably, however, a small number of makes
of machine would evolve to take the lion's share of the user
group - MUD's players at the moment are 80% to 90% BBC
users. Software f or these dominant makes of machine could be
produced, and downloaded by the MUD host upon establishing
contact.

The home micro's could then play exactly the same
role as the LAN micro's in the Mark 2 version. They would
parse the individual's commands, and pass the tokenised
versions on to the database manager, which would update the
MUD world as a result of their command, and then report the
subsequent events back to the player.

The more interesting case is where the MUD database
itself is distributed across machines, and each player is
responsible for a small part. Either their home micro', or
the one to which they were assigned on the host system,
would process requests for information about particular
areas of the game (not necessarily sets of rooms; perhaps
information on some objects, or about who is connected to
the game). A great deal of communication between the
computers would be involved here, and perhaps 80% of the
micro's time may be spent talking directly to other micro's.
However, the load required to parse commands every few
seconds is comparatively small, and this interaction between
users' machines should not preclude their acting as a front-end.
It is very complicated to manage,though, and demands
high data rates between processors, a reason why it is not
to be implemented in the LAN of the Mark 2.

A great deal of care would have to be taken to
ensure the integrity of the system if the users' home
micro's were given any form of control of the game.
Sensitivity to crashes would naturally be increased, as it
is to be assumed that the users could pull the plug on their
computers at any time, without warning. Although this can be
reduced by a regular polling of machines, and the dumping of
their information to some central, permanent storage medium
so as to lose as little information as possible in the event
of failure, it assumes that all machines are "friendly".

In reality, computer users tend to relish breaking
into systems. In a MUD game, this would be seen as a semi-legitimate
form of cheating, the default attitude being that
if no-one stops you doing it, then you were allowed to do
it. In other app1ications of MUDs, however, corruption of
the service by individual users could cause serious damage,
particularly if weighty decisions relied upon the
information provided (in a business application of MUD,
running some kind of simulation, say). A great deal of work
is involved in making things dificult for the would-be
saboteur, and even attempts to read the memory in their
machines could be sidestepped by a wily user, supplying a
plausable, innocuous alternative version of what is in the
machine instead of what is really there. If the MUD were run
in competition with other comprnies' programs, then
deliberate fouling of the mechanism would be a real threat.
From a security point of view, putting this kind of power in
the user's hands is highly questionable, and not to be
recommended at all.

From a commercial standpoint, it is also a bad idea,
since downloading segments of the game is tantermount to
giving away company secrets. Rival systems can examine the
information with which they have been provided, and infer
the mechanisms at work within the MUD. They may also use
some of the software, such as that downloaded to carry out
the parsing, for their own MUD. This point I made earlier,
namely that the effort invested by the company which wrote
the software in the first instance has has offered
diminished returns.

So in the case for a hardware integration of MUD
with ISDN, the safest opportunity lines in using the ISDN
connections of a collection of micro's under the control of
the LAN needs really only be a star network, as all shared
informatiOn passes through the database machine; a binary
star may be required if a file server is incorporated,
though, which will probably be the case. Hence, the user is
kept away from controlling any information which may be
deliberately corrupted to damage the integrity of the MUD,
but the impressive communications afforded by the ISDN links
may still be utilised. If the users' machines are to be used
for any processing, then that should be restricted to the
parsing of commands which are then passed to the database
machine to interpret

SECTION 5: Research Suggestions.

SUBSECTION 5.0: Outline.

The remaining sections of this paper are devoted to
descriptions of possible projects which it would be
profitable to follow, involving MUD-related ideas and ISDN.
I have been deliberately vague in specifying the resources
required, for humans, equipment and time, because each
project can be covered in greater depth, and the preferred
result may be different ("products" take longer than
"programs"). Obviously, these projects are merely
suggestions, and were any of them to be carried out a great
deal more thought would have to be applied to decide just
what the objective is, and how best it should be attempted.

The estimated number of man-months to complete the
project assumes that the people working on the project are
familiar with it. If not, it may take some "settling in"
time to pick up the ideas. Also, the time taken is subject
to variations, for the reasons outlined in the previous
paragraph, and should therefore not be taken too literally.

The hardware requirements exclude ISDN equipment.
All the projects will obviously need some form of ISDN
connection, and hence it is to be assumed that whatever
projects are carried out, ISDN (or similar) harware and
software would be available.

I have deliberately omitted projects which do not
have a fair chance of achieving their objective, or for
which the result is unlikely to be of use. This includes,
for example, the use of the memories of home machines to
store part of the game, which although it is an interesting
exercise, is likely to be of little or no use.

The projects fall into three categories, and I
devote a section to each. The first is with reference to
utilising the ISDN hardware, the second is with respect to
the data which MUDs transmit via the network, and the third
is other ideas, which don't fit into either of the above
classes.

SUBSECTION 5.1: Hardware Use of ISDN.

The projects in this area centre around using the
ISDN grid as part of the hardware connecting the players to
the host, and are ordered such that each of the suggestions
utilises progressively more of ISDN's facilities than the
previous one.

PROJECT 0: Demonstrator.
Estimated time: 12 man-months.
Equipment: Four or more micro's, half of which are connected
via a LAN.

The idea of this project is that the proposed Mark 2
version of MUD is taken and implemented using the suggested
architecture, on an independent LAN. Four machines are
needed because at least two must be used to play the game,
and these are linked over ISDN to their counterparts on the
LAN. One of the LAN-based machines, which acts as a front-end
for the player, will also double up as the database manager.

This project makes minimal use of ISDN, except for
faster transfer of larger quantities of information. It is,
as its name suggests, a demonstrator project to show both
MUD and ISDN in action, in tandem. The communications
bottleneck which so restricts MUD at the present moment will
be gone, however, and this will make the system much more
powerful (although with only two players it would probably
cause little problem on the normal system, either!). The
system would have to be impressive to act as a demonstrator,
which is why it would take a year to complete. If a
commercial product were desired (and it is certainly
possible) an extra 6 months or so would be required to
enhance the databasee and make the game more fun to play. I
say 'game', here, but there are good reasons for putting the
product in a non-game domain, for example an educational
subject; primary among these is the reluctance of virtually
any non-progressive company to accept research proposals
which are oriented toward the leisure market. However, extra
time may be required to assess and implement a suitable
alternative domain if found.

Because of its modularity, the system requires only
four micro's, but may be extended to more if it is to be
used to impress people. Each 'home' microcomputer would be
linked via ISDN to the 'host' micro's, on the LAN. More
machines may be brought in to allow use by a correspondingly
larger number of people.

Of all the projects, this is the one I favour the
most because it is very flexible. It is also commercially
viable, and may be created using existing, inexpensive
hardware. The sophistication which it permits is such that
were a long-term project lasting several years to be
envisaged, those research interests which were mentioned in
an earlier section could be fully covered.

This project is similar to the previous one, except
that instead of linking the host micro's together via a LAN,
the ISDN network takes its place. Because the project is not
a demonstrator, less time need be spent in ensuring that the
game (or other application) which forms the scenario is up to
professional standards. A reasonably simple game may be
used, and the emphasis be instead on using the ISDN network
as a connecting service for the micro's at the host end.

This project requires more knowledge of ISDN than
the previous one, and much of the work is in the ISDN area,
trying to make it act like a LAN and providing primitive
functions for the MUD programmer to use in communication.
Hence, it requires a great deal of interaction between the
ISDN people and the MUD people, the one providing the
primitives required by the other. This is perhaps the better
project to assess the problems associated with running a MUD
on ISDN, but it is not as 'safe' as the earlier one. Also,
if the earlier project is embarked upon, then this one may
be regarded as a possible extension to it.

In this project, the 'home' micro's, which have
previously been merely dumb terminals, are now an active
part of the MUD. The extent of their power is restricted to
parsing the user's commands and passing these on to the
database manager, plus other duties such as formatting
output and the like. Ideally, to demonstrate the modularity
of the system, more than one make of micro' should be
involved, although this would involve more time to write the
software for the new brand.

Again, there is a strong correspondence between this
proiect and the first one,except that this time the LAN is
ISDN itself. More co-operation between the ISDN personnel
and the MUD designers is necessary, indeed there is little
which could be done in the way of implementing multi-player
games using this system unless ISDN had the correct
facilities to hand. The project may, of course, be extended
to a full demonstrator if more time is spent, or it could be
considered as a possible alternative architecture if either
of the first projects is to be extended. The modules may
also be used for programs other than MUDs.

SUBSECTION 5.2: Software Control of ISDN.

This collection of projects looks at ways of sending
increasingly more information to the players of the game
and mixing the types of data sent. They are all modules to a
full-blown MUD, and much of the main program need not be
written (only the communicational aspects of the game) . The
modules may be incorporated into any of the projects in the
previous section, if a larger-scale project is preferred.

This is the basic system for mixing test and sound.
A stream of data would be sent by the MUD to the user's
micro'. This would then decide, on the basis of the
protocols to be designed as part of the project, whether to
print the data as text or switch it through to the speaker
system to produce sound. If a more impressive configuration
is desired, then graphics could be used instead of, or in
addition to, sound, but there would be correspondingly
higher costs for the equipment involved, which would include
image digitisers and the like.

The module would be one-way, in that only the user
receives mixed-type data; the host system would receive
straight ASCII text. This is the simplest case for this kind
of MUD module, as the host would be able to transmit all in
one form, and then switch to the other, without confusion.
Full mixing, where the sound and text is transmitted in
near-simultainety, is only probable if users wish to
communicate with each other via the host system.

Here, the user wishes to converse with nother user
(hence the additional micro'), and does so by use of
switching commands to the module, which indicate to which
person the verbal output should be directed. Textual
commands should still go direct to the MUD. In this project,
the host system receives all spoken messages and itself
sends them to the appropriate people concerned. It does not
require sophisticated interaction with ISDN to order the
switching be carried out by ISDN exchanges. The problems
arise because of users mixing text and sounds, in addition
to the host so doing. This project necessarily subsumes the
previous project, ie. all functions which the previous system
could perform, so can this (and lots, lots more!). There is
no true software interaction between the MUD and the ISDN,
however, and all players are on the same conference lines,
the MUD host decides who receives what information.

Because of this, the system is still relatively
clearly partitioned, and the distinction between ISDN and
MUD is maintained. It would fit in well with any of the
architectures for MUDs depicted in tbe previous section. The
major part of the work is on the integration of the various
data modes via MUD-switched protocols. However, because MUD
would need to store the audio information in order to send
it to several possible destinations, a large-memory micro'
would probably be required for the database machine, which
makes it more expensive.

The most difficult way to pass messages around the
ISDN links is if the users transmit them themselves, without
going via the host. This would mean the workload of the MUD
system would be reduced, but it would also mean that a
fairly tight rein must be kept on what the users may and may
not say to each other. For example, allowing players to
contact any other player in the game may not be acceptable
within the scenario - if some of the other players are in
sound-proofed areas, on spaceships, say. So the MUD host
must be able to order ISDN to switch messages originating
from the players to only a certain subset of the other
players. Integrating text and audio modes for this purpose
will be quite difficult, even if ISDN has ready-built
protocols for distinguishing between the modes (which it
certainly ought to have).

This project incorporates the previous projects in
this section, hence the extra time required. It is possibly
a better idea, if such a period were available, to join two
projects out of each section, perhaps a demonstrator MUD
which used mixed text and sound, rather than spending time
sending certain classes of messages (audio ones) to
different destinations than other kinds (text ones), which
is the point of this project. Most of the work here is just
a hard slog. However,it is always an option to upgrade a
project once it has achieved early success. In particular,
this project may well be worth combining with the last
project in the hardware section, because if the entire MUD
is in effect a LAN already, a lot of the workload would be
shared, and hence the duplication of effort would be
reduced.

SUBSECTION 5.3: Other Projects.

Although this is not strictly a MUD-related project,
while working on the MUD/ISDN connection I have been
impressed by the sheer power that ISDN puts at the user's
disposal. I have presented several ideas for how MUD may
benefit from ISDN (and vice-versa), but there is no concrete
set of example proposals which may be looked upon for
inspiration. I have almost certainls omitted several other
reasonable ways by which ISDN could be employed in
constructing MUDs, but am unaware of the full capabilities
of the system and their common uses. A feasibility study, by
an independent outside organisation, which itemised the
advantages inherent in the ISDN system, and proposed
projects which may be developed to utilise those design
principles, would most certainly be very welcome.

In order to build more than one MUD type of system
within the ISDN specifications, it would make sense to
develop tools to make the work easier. In particular, tools
for mass storage/retrieval of visual or audio data would be
necessary if many MUDs were envisaged, and if all of them
required the ability to mix text and images/sounds. This
project is rather tentative, in that it is probably not
worth embarking upon until the full extent of the need for
tools is known, probably gleaned as a result of implementing
one of the projects in the previous section.

SECTION 6: Conclusion.

MUDs are very commercially viable, flexible, man-machine
interface systems. The ISDN kind of network provides a
marvellous opportunity to explore the ways by which MUDs
could develop in the future, and in return be exposed to the
demands of a real, user-oriented system. A collaboration
between research on MUDs and on ISDN would benefit all
parties, both in the immediate future, and, especially, in
the long term.