Table of ContentsContribute An Article

I’ve always wondered, “What’s the point of day and night, seasons, weather, and other cycles in a MUD?” Sure, I see the messages when the sun sets and rises. Maybe there are weather messages if your MUD has those. Maybe your character will be affected by those things, if of a race or class that is sensitive to them. Shouldn’t the way the world looks change in response to those, and other events as well?

I imagine most builders like the idea, but most would feel intimidated by how much work that would add. Most implementations rely on separate or appended descriptions for day, night, and seasons, or complex tagging that is difficult to understand and remember. That’s a huge burden on builders and it’s very inflexible. We’ve come up with a tagging system, similar to HTML or XML, that allows builders to change as little as a word or a phrase, and is very intuitive and easy to remember.

Seasons, time of day, and phases of the moon

Most MUDs already have day/night cycles, seasons, and moon phases. Implementing these tags is relatively easy for the developer. Simple tags make it easy for the builder, too.

Let's look at an example. The following room has phrases that change depending on the season. Notice that I wrote this so that only part of the sentence changes:

[ 1]  The cobbled road runs up to the city's thick wall, and a wide, arched
[ 2]  opening allows passage to the countryside west of town.
[ 3]  The road continues beyond the open portcullis, making its way across a rocky field
[ 4]  <winter>filled with patches of crusty snow.</winter>
[ 5]  <spring>dotted with hints of sprouting greenery.</spring>
[ 6]  <summer>with clumps of green and yellow grass.</summer>
[ 7]  <autumn>filled with clumps of browning grass.</autumn>

Exit states and nested tags

Exits are another easy tag to implement because almost all MUDs have them. Don't limit yourself to doorways, either. You could write a room script to close an exit for something like a rockslide, and allow the player to clear the path and open the exit. The room description would reflect this change in state.

Building on our example above, let's add a portcullis that players can open and close:

[ 1]  The cobbled road runs up to the city's thick wall, and a wide, arched
[ 2]  opening allows passage to the countryside west of town.
[ 3]  <open=west>
[ 4]    Beyond the open portcullis, the road makes its way across a rocky field
[ 5]    <winter>filled with patches of crusty snow.</winter>
[ 6]    <spring>dotted with hints of sprouting greenery.</spring>
[ 7]    <summer>with clumps of green and yellow grass.</summer>
[ 8]    <autumn>filled with clumps of browning grass.</autumn>
[ 9]  </open=west>
[10]  <closed=west>The opening is blocked by a lowered portcullis.</closed=west>

You can see that the seasonal tags are nested within the <open=west> tag. You'll want to allow unlimited nesting so your builders can do things like the example above.

Weather, “not” tags, and combining tags

Rather than invest time in a complicated weather back-end, we decided that weather would be very simple. The area has a setting for the chance of precipitation, and the MUD periodically changes the weather in each area based on this chance. That’s all our weather code has to do, because the dynamic tags take care of how weather looks in a room. Weather is tailored specifically for each area and room without complicated code in the back end. Builders can also choose to send area-wide messages using room scripts, adding to the ambiance in their area.

You might write something like this to reflect weather in a room:

[ 1]  <stormy>Dark clouds fill the sky and
[ 2]    <winter>the snow is so thick you can't see more than a few feet in front of your cold nose.</winter>
[ 3]    <spring|summer>light showers sprinkle across the mountain slopes.</spring|summer>
[ 4]    <autumn>snowflakes drift and dance in the crisp autumn air.</autumn>
[ 5]  </stormy>
[ 6]  <!stormy>The sky is clear and the mountain air is crisp and clean.</!stormy>

Notice that I combined the spring and summer tags using a pipe character. This helps to simplify room descriptions and make them easier for builders to read and maintain.

You’ll also notice that there is a stormy tag and a !stormy tag. We implemented “not” tags for all tags that made sense for it, such as day, night, and seasons.

Room flags

In addition to the tags for world or room conditions, we also implemented tags based on the state of room flags. These flags can be set or unset using room, mob, or object scripts. This allows a builder to create a unique condition that is displayed in the room description.

Here's my original example with a lever that players can pull to open the gate:

[ 1]  The cobbled road runs up to the city's thick wall, and a wide, arched
[ 2]  opening allows passage to the countryside west of town.
[ 3]  <open=west>
[ 4]    Beyond the open portcullis, the road makes its way across a rocky field
[ 5]    <winter>rocky, barren field with patches of crusty snow.</winter>
[ 6]    <spring>rocky field dotted with hints of sprouting greenery.</spring>
[ 7]    <summer>rocky field with clumps of green and yellow grass.</summer>
[ 8]    <autumn>field filled with rocks and clumps of browning grass.</autumn>
[ 9]  </open=west>
[10]  <closed=west>The opening is blocked by a lowered portcullis.</closed=west>
[11]  A lever mounted on the wall next to the opening is
[12]  <flag=0>up</flag=0>
[13]  <flag=1>down</flag=1>.

The room has a script that is executed when the player types pull lever. This script opens the door to the west and sets a flag on the room. Each room in our MUD has two types of these flags: one type is automatically unset when the room is reset, the other type is saved across resets (and reboots). We have three flags of each type in every room, allowing builders to create complex puzzles and other constructions.

Auto-formatting descriptions

One consequence of using tags is that you must automatically format room descriptions on the server. This means that if you allow multi-paragraph room descriptions, you will need to implement a special code for carriage returns. It also means that builders can write room descriptions in a way that is much easier to maintain. You'll notice that my examples break out the tags onto separate lines, which makes it easy to read and easy to edit. Changing a sentence is much faster. This is also an opportunity to remove the archaic double-space after the end of a sentence that some builders use.

Complimentary commands and functions

In order to review rooms with dynamic descriptions, especially when they are heavily used, we had to implement a look command that accepted a parameter. To use it, you enter look <tag name> where the tag name is exactly as it appears in the tag. For example, in the example room I've provided, you could type look open=west and you would see what the room looks like to a player when the portcullis is open. Nested and combined tags are handled properly. You can type look <tag1> <tag2> to see the room when both conditions are true.

You’ll also want to provide functions for your scripting system that allow a builder to create room, mob, or object scripts that can influence rooms, as appropriate. The possibilities there are literally endless.

Considerations

My experience with this type of system is that it helps to provide examples for your builders of what you want rooms to look like, and how extensively you want rooms to be tagged. Some builders will avoid them entirely, and others will go completely nuts. I would recommend that you encourage builders to combine partial sentences like I did in the examples, and only change phrases or words.

It’s also helpful to provide templates that your builders can quickly insert into room descriptions. If you have a web-based building tool, you could customize your text editor to include the tags.

I would love to hear what you think or how you implemented this on your MUD.

Janua is a professional technical writer who has been building and developing on one MUD or another since the late 90s. You can reach her at janua.tld@gmail.com.

References

« issue « article article » issue »