Quests and adventuring have been common enough in many LP and Diku MUDs for some time. More recently TinyPlots have spread this idea to the role-playing TinyMUDs. However, there is still plenty of room for growth in the area of organised adventures, and it is one such possibility that I am outlining in this article. More particularly, my emphasis is on adventures with multiple participants.
MUDs, whilst being undeniably multi-player, suffer from a lack of concerted playing by many characters. Since a player can theoretically log in at any time while the MUD is running (and in most cases this is all day), and given that players have outside committments at varying hours, it is difficult to ensure that any set of characters will be logged on at any one time. Admittedly there are peak times, but even then there is no guarantee that a particular character will be present.
This leads to problems, particularly with respect to "quests" which require multiple characters. One obvious solution is for players interested in co-ordinating their playing times with others to contact those others and arrange a time in advance. While this is fine from the players' point of view, from the administrator's perspective it is not so helpful. Since most administrators wish to cater to as many of their players as possible, it is not a good idea to make many activities require more than one player; despite its multi-player nature, the solo player is usually not overlooked. This naturally limits what can be specifically designed only for groups of characters.
Another negative aspect of MUDs that stems from the multi-player aspect of the games is that there cannot be individual attention from administrators. Although the game mechanics and database are something of a substitute for the "game master" of traditional role-playing games, administrators should also fulfill a large part of the functions of that person, not only by creating new areas and objects for later use, but also by running NPCs and creating and changing the database in immediate reaction to events. Even with the best set of mechanics and laws of physics in a game, it is impossible to model the world of the MUD adequately without some outside `tweaking' at opportune moments. No computer yet can react to events so as to help a story or adventure along - it is a rare enough skill in people. Unfortunately, given that administrators are usually present in much smaller numbers than characters, this is not possible in the normal course of events. Most administrators, in any case, have too much else to do to bother with such functions without some definite purpose to them.
On the one hand, then, MUDs are a multi-player, interactive game, and on the other they are limited in the extent to which the environment can be adjusted to suit the story. There are, however, a number of approaches that can be taken in organising and running adventures for more than one player. To begin with the familiar, those few LP style quests which require multiple characters in order to be completed are coded into the rooms, objects and NPCs involved. The wizard, aside from the initial input coding the quest, does not become involved in the quest, particularly not during the course of characters performing it. This makes the quest inflexible, since all of the important parts are coded, and the wizard does not interact with the characters (through the objects, NPCs and rooms of the quest area) in order to react to the characters' actions.
By contrast TinyPlots are far more dynamic and interactive. The participants decide some details of the adventure ahead of time, while judges resolve conflicts between different groups and individuals. Much of the adventure is left to the players themselves to role-play. While this is a good thing, there is still not the interactivity between those involved in the adventure and those who can arbitrarily change the database.
A more radical solution, and one which presents a number of problems, is to make the MUD a specific adventure setting. This involves, for varying lengths of time, the `closure' of the MUD to all but certain predetermined characters. These characters then participate in an adventure previously designed and prepared for by the administrators. Such preparation may involve changes to any existing database in order to facilitate the running of the adventure. When the characters actually play the adventure, the administrators are always close at hand; they change the database in response to those actions of the characters which are not resolved by the game mechanics, role-play any non-player characters, and generally ensure that the adventure works.
As an extension of this idea, the entire MUD could be turned over simply to these customised adventures. The administrators, after designing the adventure, prepare the database, and then open to MUD up to the selected players. After the adventure has been run, the database is scrapped, until a new adventure is designed, with its own database. This would naturally result in a lot of downtime for the MUD, and it would be limited in the number of players it could cater for at any one time. An additional problem is that there might (depending on the characters used and the settings used) little continuity between adventures. This loss of the `campaign feel' is the greatest drawback to this type of MUDing, I feel. However, even this can be avoided, if the MUD is used by a consistent set of players; in this case, the administrators can run linked adventures, much like as in traditional role-playing games.
The first and most obvious problem with this solution is its closed nature; only the selected few may play during the adventure, and no one may be added during the adventure (unless this is also arranged outside of the game). Where an adventure involves a proportionally small number of characters, this is a nuisance to those not involved. It could also be seen as something of a waste of the resources of the MUD; as I stated above, most administrators would prefer to see many players on their MUD, rather than giving `special' treatment to a select few.
Of course, it is possible to run such a scheme without shutting other characters out of the MUD. This allows for perhaps more realism, although it does introduce many unaccountable elements into what would otherwise be a strictly controlled environment. This is far less of a departure from normal MUDing than closing the MUD, although because of the additional unknown factors, it is perhaps harder on the administrators running the adventure.
Quests: I use this term to describe any organised adventure, whether it is an LP-style quest or a TinyPlot, or something else again.
Select few: Of course, private MUDs do exist simply for the friends of the administrators; these are less common than open-access (even if registration-only) MUDs.