Table of ContentsContribute An Article

The subject of dynamic descriptions has been thrown around for many years, yet surprisingly few MUDs make use of them for describing their worlds, perhaps in part because of the many misconceptions about how they work  in particular, the mistaken assumption that "dynamic" is synonymous with "computer-generated", and that "computer-generated" means the computer writes the entire description from scratch.

In this article I describe the divide between static and dynamic, and between handwritten and computer-generated, and then show some examples of how I use computer-generated dynamic descriptions in my own project.

Handwritten static descriptions

This is the approach used by most MUDs for writing room and object descriptions, help files, and so on. Someone writes the description, and that's exactly how everyone else sees it.

Obviously this imposes some pretty severe limitations on the writer, as they need to produce descriptions that are appropriate to all viewers at all times, regardless of whether it's summer or winter, day or night, or the viewer is a giant or a halfling, sitting or standing, etc.

Some people try to work around these limitations by imposing strict rules and guidelines, such as not using the word "you" and requiring that all room descriptions be written in the third person, despite the rest of the MUD being written from the more-immersive second person perspective. This writing style is hardly ideal for an interactive game.

It's worth noting that, while many people defend the use of third-person in room descriptions, you don't see them applying the same rule elsewhere; nobody wants to see "a weapon is drawn" rather than "you draw your sword". Yet the use of static room descriptions is so prevalent and ingrained that many people take them for granted, and even defend their limitations without really considering the alternatives.

Computer-generated static descriptions

This approach is rare, because if you're going to the effort of generating descriptions anyway, then you might as well make them dynamic. However, it's occasionally used by MUDs with large wilderness areas, or to generate default "filler" descriptions that can later be replaced or modified by hand.

A common misconception is that the computer writes the descriptions from scratch, and that they will therefore be poorly written. In fact, the descriptions are usually assembled from randomly selected handwritten sentences or paragraphs, with further randomisation applied to certain words, in order to produce a large number of unique descriptions with much less effort than writing the same number of descriptions by hand.

However the end result is still static and will be the same for all viewers. Such descriptions can also become repetitive unless a sufficient amount of pre-written text is provided, so the staff will still need to invest a fair amount of work; a handwritten world grows in size the more effort you put into it, while a computer-generated world grows in detail the more effort you put into it.

Handwritten dynamic descriptions

These produce the best results, but also require the most work. Much like handwritten static descriptions, a real person has to write them, but the difference is that dynamic descriptions can include variables and conditional checks  for example, describing the snow crunching beneath the viewers’ boots as they walk, but only when it's actually winter, and when the viewer is currently walking, while wearing boots.

Some MUDs already offer separate static descriptions for day and night, but dynamic descriptions take the concept much further, allowing you to include whatever factors you consider appropriate for each particular description.

It should be stressed that dynamic descriptions are just a tool; you don't have to use them for every description. For example, you might choose to use them only for specific details that couldn't otherwise be included in a static description, such as sunlight reflecting off a statue (which should only occur during sunset), or translating the meaning of the words carved above an ancient goblin temple (which should only occur if the viewer can read ancient goblin script).

This approach is actually very common in most MUDs, but only for event messages. For example, DikuMUDs often write messages in the format $n draws $s $o, which might be displayed as "KaVir draws his sword". Technically, that's a very simple hand-written dynamic description, as are the customisable prompts offered by most modern MUDs. One could even argue that the use of customisable colour codes in room descriptions is also a form of dynamic description, although that's only really true from a technical perspective.

Computer-generated dynamic descriptions

Much like the computer-generated static descriptions, these are generally assembled from pieces of handwritten text. The difference is that these descriptions are usually generated on the fly and/or use some sort of markup language, so that they're customised for each viewer and each viewing.

It can sometimes be difficult to draw a line between a handwritten and computer-generated dynamic description, but the former is usually written for a specific thing (one particular creature, object, etc.), while the latter is applied to a whole category of things. For example, a handwritten dynamic description might apply to one specific room, while a computer-generated dynamic description might apply to millions of rooms (the actual output would obviously vary from room to room, but all the descriptions would be produced using the same system).

Describing locations

My MUD doesn't use rooms, so I lacked the obvious anchor for descriptions, and decided that the easiest approach would be to generate dynamic descriptions based on what the viewer could currently see. After trying various different techniques, I finally settled on generating a series of sections of text which could be combined to form the final description:

  • Section 1: Viewer's position (standing, walking, flying, etc.), season, and terrain.
  • Section 2: Time and terrain.
  • Section 3: Weather and terrain.
  • Section 4: Optional hand-written area description (season and day/night specific).
  • Section 5: Nearby landmarks at your level of elevation or higher (if available).

Each section usually consists of a single sentence, but can be longer  or may be combined with another section, if both are particularly short. For example, in the following description you can see that sections 2 and 3 have been merged together in the second sentence:

On the other hand, here’s a different example in which sections 1, 2, 3, and 4 each have their own sentence, but where there are no nearby landmarks visible for generating section 5:

As you may have noticed, the descriptions also mention that I’m walking and wearing boots. That’s the sort of thing you can’t assume in a static description, but because the descriptions are dynamic, they’re automatically adjusted based on the viewer. This solution allows you to use any and all information that the MUD might have available, because you no longer need to make assumptions about the viewer. You could even reference emotions, if the MUD tracks them (such as phobias chosen during character creation).

For example I might not be walking, and I might not have boots. Come to think of it, I might not even be human...

Describing creatures

Most MUDs offer a command for players to write their own static descriptions. I wanted to avoid that approach for a couple of reasons. Firstly, I don't run a roleplaying MUD, and most of my players would have left their descriptions blank, or filled them with quotes or ASCII art. Secondly, I wanted character descriptions to be accurate, consistent, and factor in worn equipment and current form (as shape changing is an important part of the game), which meant including “naked” descriptions for characters who weren’t wearing clothing.

As most characters are humanoid, that’s what I focused most of my attention on. Inspired by the approach I’d used for locations, I decided to split the description into six sections:

  • Section 1: Appearance (or face armour) and hair (or head armour).
  • Section 2: Body, arms and forearms equipment (or naked upper body).
  • Section 3: Waist, groin, legs, shins and feet equipment (or naked lower body).
  • Section 4: Height and physical grace.
  • Section 5: Held weapons and hand-worn armour.
  • Section 6: Sheathed weapons.

The first section describes your head (hair) and face (attractiveness), but only if those features are visible. You might wear a mask which covers just your face, a hat which covers just your head, or a helmet which covers both locations. You might wear a cloak with a hood, or an open helm with a visor that can be lowered. You might even wear a headband that goes around your head without actually concealing your hair.

The second and third sections cover the upper body (including arms and hands) and lower body (including legs and feet) respectively, and can be combined in certain situations  for example, when wearing a dress or robe, or when naked. They also need to factor in different layers, because although you can’t see a vest under a shirt, you can see a shirt under a breastplate, because the breastplate covers only the torso while the shirt also covers the arms. There are also certain pieces of armour (such as bracers and greaves) which don’t cover their location entirely, so if you wore a breastplate and bracers over a chainmail shirt, then all three would be visible.

I ended up defining torso and groin as the “naked” locations, so that if your torso is uncovered you’re described as being naked from the waist up, while an uncovered groin describes you as being naked from the waist down, and if both are uncovered then you’re simply described as being naked. Other locations are noted as exceptions, for example you might be naked “except for a pair of boots”. The naked descriptions then factor in tattoos, physical build, and so on, in order to generate something appropriate.

Another nice side effect of generating the descriptions is that I can automatically change the perspective when you look at yourself.

The actual features (attractiveness, skin, eyes and hair) are configured by the player using a simple “appearance” command. The command offers different options for different forms, although some of them share the same data; if you have black hair in human form, and shape change into a wolf, you’ll also have black fur.

However, other forms required their own solutions. It was particularly challenging trying to describe a vaguely humanoid-shaped mist that can also wear equipment.

Not all of the forms are so clearly defined. In particular, demons are able to fully customise their appearance by collecting and applying different “warps” to their body:

This solution has also proven to be a very quick and effective way of generating monster descriptions, as I can simply assign them the appropriate traits and the MUD does the rest. I’ve used it for describing a wide range of creatures, and in one case I even used it to populate randomly-generated dungeons with randomly-generated monsters. Because the warps actually change your body shape (activating specialised movement and combat abilities), the descriptions are actual descriptive text, not just cosmetic flavour.

For the short descriptions you see when interacting with a creature, I generally use handwritten or computer-generated static descriptions, but in a former MUD project (in which I also used an introduction system) I used computer-generated dynamic descriptions for PCs which factored in both appearance and equipment being carried, so you might see a “tall, dark-haired man wielding a pair of knives”.

Describing objects

I don’t actually generate descriptive flavour text when someone looks at an object, as the goal is simply to provide an overview of the item type and its attributes; however, I do use a number of other dynamic elements.

The short descriptions you see when interacting with an object are computer-generated dynamic descriptions, allowing the descriptions to be updated on the fly to indicate whether a sword is notched, blood-stained, rusty, and so on. This doesn’t just look cool, it also provides useful information about the item: a rusty weapon is easier to damage, wet armour provides better protection against heat damage (but leaves the wearer more vulnerable to electrical damage), and so on. This is the sort of attention to detail that can help bring the game alive, and make it feel more immersive, as you wade knee-deep into a pond and see that all your uncovered equipment below knee level has become wet.

This is also a good example of the way in which objects interact with creatures and the world. Consider what happens when a wet character assumes an elemental form of fire, and then equips themselves with two items with different melting points:

Describing help files

Hand-written dynamic descriptions are a highly effective way to present help files, allowing you to include hints and examples tailored specifically to the individual and highlight information that might be of interest to a particular viewer.

Now consider how the same technique could be applied to the help file for a quest:

The status has been colour-coded to indicate that I’ve already completed the quest, while the flavour text itself is tailored towards a vampire  because the viewer is a vampire. If that same help file were viewed by a dragon, for example, then they’d see the following:

The technique is particularly effective when applied to help files for abilities, as it allows the viewer to see at a glance exactly what requirements they need to fulfill.

Although the informative text within help files usually needs to be handwritten, there are other areas where you can make use of computer-generated output. For example, if the player requests a help file that doesn’t exist, you could use a soundex algorithm to search for a similar-sounding keyword.

The soundex algorithm isn’t always very helpful on its own, as it matches by sound rather than meaning, but I’ve found it works well in combination with a text search  even if the requested keyword lacks its own help file, it might still be mentioned within other help files.

Another useful technique, particularly for the benefit of commonly asked questions, is to select help files based on combinations of keyword and trigger them from a public channel.

The above help file is linked to the sequence “how |i|you| |open|pick| |lock|chest|chests|”, which means it’s a match if the text contains “how”, either “I” or “you”, either “open” or “pick”, and either “lock”, “chest”, or “chests”. The tokens must be in sequence, and any other tokens are ignored. Here’s another, this time for “how |i|you| |lower|raise|open|close| |visor|eyes|”.

Describing combat

Most MUDs already have dynamic combat messages, but don't take the concept very far. Usually they include little more than the name and gender of the attacker and target, and a message based on how much damage they inflicted. The descriptions can be made much more interesting if they also factor in body shapes:

That looks like a fairly regular combat message, but what happens if you shoot lightning at something that doesn’t have a head?

A guardhouse doesn’t have a head, but it certainly has a wall  and in this case it also has a custom death message based on the damage type (exploding from the lightning). The same concept can be extended to any number of opponents, producing appropriate cosmetics for whatever body shape they might have:

Even the random treasure drops have appropriate descriptions (in this case a chest floating from the wreckage), to explain how a pirate ship “creature” is able to drop loot.

The “display” command

Having implemented a system for generating dynamic descriptions, it was a simple matter to add a “display” command that allows players to interface with the system directly.

Combined with a simple alias system, this allows players to create their own shortcuts for displaying any information they might need. It's particularly useful for blind players, enabling them to access specific information without having to suffer the spam of a prompt or filtering the necessary data from a score sheet.

Active descriptions

One last technique I’d like to touch on is that of active descriptions: instead of the descriptions always appearing in bursts, this approach generates a continuous flow of information as the character moves around. Conceptually it isn’t really any different from the way most MUDs already handle weather and day/night messages, it’s just been extended to cover a wider range of messages.

Sending too much data can overload the player and feel like spam, but if handled with care this technique can provide the user with a form of ongoing narrative of their progress. It’s particularly effective for blind players, as it’s faster to parse than big blocks of text.


When using handwritten static descriptions, you can typically expect a well-written world to require about 30-60 minutes work per room, taking into account extra descriptions, object and monster descriptions, proofreading, etc. The Mud Connector defines a medium-sized world as 3000-8000 rooms, so even if you treated building as a 9-to-5 job, it would probably take you a couple of years of solid work to create a decent medium-sized world. If you’re using handwritten dynamic descriptions, then you can expect it to require even longer.

Even if you're able to invest that much time, you may decide there are other things you'd rather spend it on. Using computer-generated descriptions is one approach to freeing up that time. Any strategy for managing a project’s resources has its pros and cons, and there’s no universal “right” or “wrong” way of doing it. However, time is a finite resource, so if you want to create a playable MUD, then at some point you’ll have to make compromises.

KaVir (Richard Woolcock) is the owner of  God Wars II.


« issue « article article » issue »