Back to index

The copyright situation for this article is unclear. It does not belong to the author of this site. Please see the copyright notice. If you have information about the copyright contact me!

Taking Muds to the Next Level

by Nolan Darilek

During the past ten years, the field of graphical games has been transformed greatly. Initial classics such as Doom and other old favorites have been phased out by the likes of Quake III., Unreal and HalfLife. These games have made many individual contributions to the field of 3-D gaming, and the art has changed dramatically during the past few years.
Ooooh Crumbs DM!

A secret agent working on saving the mud from the evil empire.

Yet, the art of text-based gaming seems to remain primarily unchanged. While games implement their own in-house features, often these features remain within the games for which they were developed. Furthermore, many debates have concerned the implementation of these features, and many implementations exist. Take, for example, the age-old issue of ranged combat. While many implementations can be created, no one will be content with a single standard, as the current mud architecture presents difficult limits to surpass.

I am not writing this article to debate the merits of implementing specific mud systems in specific manners. Instead, I wish to propose several interesting concepts by which the mud architecture can be extended such that there is no longer a question concerning how to implement some of the more popular systems which many game designers want. If the very architecture atop which a game is built is modified to be as dynamic and rich as possible, then the implementation details of many systems and game mechanics may fall neatly into place. What I am proposing though is no mere patch to existing systems. Rather, these proposals will require a new server platform atop which to be based. I have begun such a project, but as is the case with many programmers, I cannot offer a time frame for its completion. My hopes are that these ideas will inspire others as they have inspired me, and that perhaps other developers will adopt these concepts in future endeavors. I will summarize these ideas below, and will elaborate on each in future articles.

Coordinate-based and real-time mechanics are a necessity for many dynamic systems. Room-based mechanics are extremely arbitrary, as they do not present enough data to extrapolate the size and area covered by a location. As such, any system which needs to rely on distances, such as ranged combat or vehicles, cannot be implemented without creating the possibility for flawed mechanics. If, for example, one room is described as a large area while another is described as smaller, it makes no sense for vehicles and ranged combat to behave the same in both rooms. While solutions to this problem may exist, they only serve to increase the abstraction in an already abstract system.

Coordinate-based mechanics can serve to eliminate the room-based environment which dominates the arena of text-based games. By defining area boundaries in terms of maps, and attaching descriptions and dimensions to these maps, it is possible to retain the basic, vividly-described feel of a room-based game while enhancing it to include a true coordinate system with real-time movement.

Muds are often populated by non-player characters (NPCs). These NPCs often fall into two categories: targets and assistants. Targets include monsters, city guards, etc. while assistants consist of shopkeepers, priests and healers. However, the potential exists to create large groups of NPCs which act in support of or in opposition to each other. Furthermore, a limited set of verbal actions could easily be performed between PCs and NPCs, or between individual NPCs, thus allowing others to influence the goals of NPCs by hiring them for jobs, trading with them or requesting information. While such a system could certainly become powerful with the addition of new goals and strategies, it would not be possible for an NPC to accomplish every possible action. For these situations, a dynamic casting system could notify a set of administrators that an NPC is being interacted with beyond its coded capabilities. The administrator could then transfer control to the NPC and control it just as if it were a normal character. In this manner, random NPCs could quite easily be incorporated into plots, perhaps eventually being designated as player characters.

In order to truly support intelligent agents, a mechanism must exist through which changes in the environment are communicated. In some cases simple strings are used, and NPCs are coded to listen for the arrival of specific patterns. This is a poor mechanism by which to drive an agents actions, since it is prone to abuse. Similarly, a mechanism must exist for an environment to change ones perceptions based on certain factors. For example, a rainstorm would seem much different when viewed from a forest than from a city street. Similarly, the time of day could also effect ones perceptions of an event.

An event-based system must be developed to accomplish this. In the proposed system, a hierarchical event structure is used to signify all changes in the environment. All changes, from new weather patterns to character speech, are encapsulated within an event object. In certain cases, such as character speech, the event may travel directly from the environment to the client, unchanged. Yet in other cases, the environment may modify an events context before rethrowing it. If, for example, a builder wishes to make speech echo within a cavern, he would merely modify all speech events thrown to the caverns location to appear echoed. NPCs could then scan for specific events, such as weather changes, and base their actions on reliable data directly from the server. If a user attempts to emit a weather change message, however, other agents would recognize it as an emit event rather than one which signifies a weather change, and the agent would not act as if any changes had occurred.

Next month, my article will elaborate on the considerations which must be made to account for a map-based system. I will try to elaborate on the various aspects of my idea in the order which this article has presented them, yet this may not be the best order in which to convey them. Feel free to email me with any questions or criticisms concerning these thoughts. I can be reached at