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.

PROJECT 1: ISDN as LAN.
Estimated time: 9 man-months.
Equipment: Four or more micro's.

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.

PROJECT 2: Dumb Terminal to Front End.
Estimated time: 12 man-months.
Equipment: Three or more micro's.

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.

PROJECT 3: One-way Text/Sound.
Estimated time: 6 man-months.
Equipment: two or more micro's.

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.

PROJECT 4: Two-way Text/Sound.
Estimated time: 12 man-months.
Equipment Three or more micro's

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.

PROJECT 5: Host Bypass.
Estimated time: 18 man-months.
Equipment: Three or more micro's.

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.

PROJECT 6: Feasibility Study.
Estimated time: 6 man-months.
Equipment: None.

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.

PROJECT 7: Developuent Tools.
Estimated time: 9 man-months.
Equipment: Two or more micro's.

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.