We’ve been talking about procedural content generation for a MUD, but it would be rather sad to have a procedurally generated static MUD. A place where nothing ever changes.
If we want to talk about change over time, we need a notion of time.
In a MUD, you have three distinct notions of time: system time, which is real-world time, the time for people who aren’t involved in your MUD; game time, which is what an in-game clock would say; and simulation time, which is about timesteps at which you can schedule actions. I’ll quickly describe how to deal with simulation time, then move on to game time.
The idea behind simulation time is simple: it’s the amount of time that the quickest action in your game’s simulation takes. Or, for two actions that happen in sequence, it’s the minimum amount of time between them.
This is only partially related to how long they take in the real world. For instance, a zone might have a room scale of fifty meters. It would take Usain Bolt at least four seconds to sprint fifty meters. But you probably want that action to take a relatively short period of time. In general, things happen faster in games than in real life.
Once you’ve decided on that minimum timestep, you just have a few tasks left:
- Determine how long each action takes
- Write your MUD’s main loop
- Create an event queue for efficient far-in-future scheduling
We may come back to this part later, but for now, we’ll consider it done. (As an aside, you will get more flexibility if you describe the time a task takes in terms of system time, and you will get more accuracy if you use simulation time.)
There are two visible pulses in a world’s time: the day/night cycle and the turning of seasons. You must decide which of those you want (probably both) and how long you want them to be.
Minecraft uses a twenty minute day. Half of that is daytime; half is night. This is long enough to get something done before needing to bed down, and you also have a means to skip the night if it bothers you. Discworld MUD is somewhere between twenty and thirty minutes, and the day/night cycle depends on the season. For instance, at 10:18am on 7 Ick Secundus, which is during backspindlewinter (the Discworld calendar and seasons are complex), it’s still dark.
If it doesn’t much matter to your MUD what time of day it is — if you don’t have major game mechanics dependent on it — fifteen to thirty minutes is short enough for people to notice without bludgeoning them over the head with it. And if you do have significant differences in what a player can do based on time of day, spending more than an hour on the cycle makes it hard for a player to get what they want to get done if they can only be on for a short play session.
Some common differences between day and night, just to get the juices flowing:
- Room descriptions and emotes might change.
- Different NPCs might be around.
- You might only be able to see rooms with sufficient light, which is not the default outside at night.
- Street lights are only on from dusk til dawn.
- Many shops are closed at night (for a certain definition of “night”).
- Bars might be open from afternoon to late night.
- It may be easier to sneak around at night.
- Zombies may only be active at night, or may be passive and lethargic during the day.
- Vampires may burn or sparkle during the day.
Showing the time of day
You can use other cues for whether it’s day or night. For instance, if you have a line in the output of the
look command for the weather, time of year, etc, you might color it differently during the day and at night. Keep it relatively small — I don’t think many of your players want to see bold yellow text for all (outside) room descriptions during the day, replaced with gray at night.
If the client supports MXP, you could use subtle color differences, like using #F6ED90 during the day and #D5A7FA at night. However, that should be configurable — not everyone uses white text on a black background.
Ensure that coloring is not the only way to detect whether it’s day or night. For obvious reasons, MUDs can be some of the more accessible games around. (I promise to talk more about this in a later post.) If you put essential game information in the color channel, you’re telling blind players that they’re dead to you. So make sure there are multiple sources for that information.
Transitioning between night and day
There are a number of cues that day or night is approaching. The sky will lighten or darken. The sun will cross the horizon. Shadow angles will change. Members of certain professions will leave their homes or jobs on their commutes. You have to choose which of these you want to make happen, of course, but you also have to inform the players when they happen.
I should be able to tell that night is falling if I’m idling outside. I should notice something if I’m standing in a room with tons of windows. I should have opportunities to notice if I’m traveling outside. Obviously, there’s only so much text you want to devote to the purpose, and you have to balance it against other information you want to get across.
The types of information come in emotes, commuters, and some things in between. For instance, one MUD I play has a random room emote at dusk where you can see a person light a street lamp. If you want to do that, you could have a real NPC that goes around the city. You could alternatively use room emotes, or have a non-interactive script that goes between rooms if you don’t want the lamp lighter to be attacked.
That time of the year
The other major cycle is annual, seasons.
Seasons are specific to a biome. Some biomes have the same weather year round. This can be even more true in fantasy stories, or MUDs with space opera planets. Other biomes have some set of seasons — calm and monsoon, fall/winter/spring/summer, rainy/dry, etc.
We’ll talk more about weather later, but you should decide whether you want seasons, how much in-game effect they should have, and how long you want people to experience a season before moving to the next. At this point, you want to wear your game designer hat rather than focusing on extreme realism — for instance, you might want an in-game season to last a week of system time, which is likely to be 150 to 500 game days. Or maybe you want it to be a full month, and that could be over two thousand game days.
You probably want a calendar. This is a sequence of months and a number of days for each month.
A common way to arrange your calendar is based on a lunar sequence. Does your world have any moons? How long does it take them to orbit your planet? That’s a month. In our world, the Hebrew, Islamic, and Chinese calendars are prominent calendars that use lunar months. These calendars introduce leap months, which gives a larger variance between the calendar date and the season. That makes it harder to handle weather correctly — you have to introduce another calendar for that, probably just day of the sidereal year.
Another option (if you’re dealing with humans) is based on period cycles. They’re consistent per individual, of similar lengths across individuals, and quite handy to track (for early pregnancy detection as well as predicting when you will be painfully cramping for three to eight solid days).
A third option is to choose month lengths arbitrarily so they line up with the orbital year.
Day of month vs day/night cycle
When talking about the day/night cycle, we suggested having that cycle be about twenty minutes long. Naively, if our MUD is set on Earth, this gives us a game year every five system days, roughly. If you want a year to be a month of real time, your year is two thousand days long. With a reasonable twelve to fifteen months, that means at least 130 days per month.
That’s awkward. You can fix that by having a calendar day span several day/night cycles. For instance, to have an Earth-style calendar with a game year taking about a month of system time, you need a calendar day every two hours. That will be four to six day/night cycles.
That could be a complexity you don’t want. It might be confusing. But it’s an option for you to consider.
We’ve discussed options for the basis of time in a MUD, with an eye to making the world feel more dynamic. We’ve gone into some depth on daily things and established a basis for annual changes.
Next time, we’ll talk in more depth about how annual changes happen, with an eye toward the weather.