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!

Room for Improvement

by Donky + Scatter ///\oo/\\\

Most muds I visit do not look very promising - generally the sort of development that is going on is disappointing. There does not seem to be any real progress being made. Its difficult to make this point to the mud's staff though, because people have different ideas about what constitutes progress. This makes it hard to argue that no progress is being made. To me, adding the odd new feature and tacking on the occasional new area is not progress. Progress means modifying the supporting structure of the mud in a way that adds depth throughout the entire game.
Bay of Isles, Esperance, Western Australia

How an ocean really looks, as comparison.

There were several key ways that we wanted to add depth to our mud. One of the biggest changes was brought about by our desire not to limit players to rooms that have to be laboriously hand-built by our creators. To address this and really add depth to the game, the replacement room system had to fulfill several goals:

These were our basic requirements for a replacement 'room' system and we have come up with one that fulfills them. There is a lot of work still to do (for example, the actual shipping system) but the foundation is ready.

We encountered a number of difficulties in building the new, underlying room system. Setting aside the technical problems we had with the implementation, we found a number of issues that face players and creators when they interact with the new system.

The Implications for Players

The first issue to address is with movement and position within rooms. Given that movement occurs with fixed sized steps in a given direction, there is a concern that players may have to execute many movement commands to get from one side of a room to the other. Obviously this would have a serious impact on the games playability - especially when you consider that to move through a room you would first need to work out where you are in relation to where you want to be and then what route you need to take to get there from here.

There is an easy solution to this problem. If commands are extended so that you automatically approach a target object, movement within the room becomes largely transparent to the player.

Should you wish to move within reach of Bovis on the other side of the room, 'approach Bovis'. If your intent was to give Bovis some money, one option might be to issue a command like "approach Bovis then give him 500 coins." Alternatively, the command "give" could be designed to automatically approach the target, so that simply "give Bovis 500 coins" would make you approach Bovis to the appropriate distance and then give him the coins.

This auto-approach could be made configurable so that players can choose whether to control their movements or not. There is the question of what would happen if there was a spiked pit in the floor lying in their path. Our system would check to see whether they detected the trap and perhaps attempt to navigate round it.

Another issue facing the player is the vast expanse of generated terrain that can be explored. Players might be happy exploring for resources near their home city but exploring rapidly becomes tedious if nothing of interest is found. If the desert is vast and contains only a few interesting ruins somewhere in the middle, it may take a considerable amount of time to find them. Worse, players may give up and never find the interesting bits at all.

In addition there is the distance between the world's cities. If it is going to take players several hours of playing time to get from one city to another, they will need a very good incentive to bother traveling at all. No one wants to waste their time simply repeating 'north' for hours.

Most of these traveling problems can be overcome if traveling is automated. If the game is aware that the player knows the location of a destination (from having been there before, or perhaps through possession of a map), then 'travel to ' should be sufficient to set them on their way and to get them there. The process of traveling could still take a fair amount of time in a large game world. One way to address this is to let players keep traveling when they log off. They could specify where they wish to travel to and a desired form of accommodation to check into or other safe place to end up at. When they arrive, the character is saved and taken offline in the usual way.

Even with these aids, traveling any distance across a large game world might take a long time. Will players ever leave their starting city if it takes eight hours to take a coach from there to their chosen destination? I believe they will - because many players are explorers, like me. To an explorer, there are two important things a mud must have to be worth exploring - consistent theme and depth.

Consistent theme means that the world presented by the game is a coherent whole. It does not contradict itself from one place to another and generally the style of things found within it is also consistent. For example, in a medieval-type theme you might expect to find players with medieval sounding names playing warriors, mages and the like.

You would not expect to see CyberTurnip playing an Imperial Stormtrooper.

Consistent theme ensures that the enjoyment explorers gain from their travels is not reduced by them encountering inappropriate things in the gain. It maintains atmosphere. Anything that is in the world, should fit naturally into the world.

Adding depth means adding detail and underlying mechanisms that allow more things to be done or allow things to be manipulated at a lower level. This gives more possibilities for the player to explore. A 'shallow' mud might have a table. A bit more depth and you can put things on the table. More depth still and you can dismantle the table. More, and you can pick up one of the resulting table legs and beat Bubba over the head with it. Add even more depth and maybe you can go out into the forest, chop wood, shape it and build your own table from scratch. The more depth there is to the game, the more possibilities there are for the explorer to investigate and find out just what can be done.

If your goal is a game in which you can immerse yourself without being distracted by things that do not fit the world, having realistic distance is part of the picture that you are trying to paint. Without it, the picture does not look so good - some of the detail is missing. In the same way that seeing CyberTurnip ruins the feeling and distracts from immersion in the game, realistic distance enhances the feeling and increases immersion.

So, would players ever leave their starting city if it took eight hours to get to their destination? My answer is a definite yes. Here are a few more reasons why.

If there is something to be gained at the destination, then the traveling time (which should be a believable amount, not simply gratuitous) lengthens the anticipation and increases the perceived value of the reward. An item that has taken time and effort to find and obtain will be valued much more than one found on any street corner. Explorers will want to explore and seek out new challenges - perhaps later returning to regale others with tales of far off lands and exotic goods. Indeed, explorers may value the fact that others are not so willing to head off into the unknown - it gives them a better defined role within the game and offers social status in having rare knowledge that might come in useful to someone.

Finally, consider those vast rolling oceans that are being generated. Without realistic distances and travel times, half the fun of sailing them is gone. What challenge is there to sailing around the world if you can do it in half-an-hour?

The Implications for Creators

In theory, our system should result in a world that fits together nicely. However, actually designing and building a world with it can be quite a complex task.

The world starts without form. As undefined areas default to ocean, the world is a water world. Within this vast ocean, islands are defined by marking out a certain area. Structures, such as buildings, are defined by marking out further areas within the islands.

Suppose you are walking around on an island. If you were to reach a shore, then walking further would take you out below water level and you would of course drown. If you were to come within sight of a structure then you could enter it and move within its rooms. So far, so good. The complications start with the detail of how these areas are defined.

The world has a coordinate system. An island is placed within the world by specifying its size and shape using the world's coordinates. Each island in turn has its own separate coordinate system that is used to place structures within the island. The reason it has a separate coordinate system is so that if the island is moved for any reason, only the islands coordinates within the world need to change. The structures coordinates are relative to the island and so they do not need to be changed if the island moves. Similarly, each structure has its own coordinate system which is used to specify the positions of rooms within the structure. Finally, each room has its own coordinate system which is used to place objects within the room.

Obviously, this profusion of coordinates can rapidly become a confusing pile of numbers facing creators in a text-based mud.

The numbers alone are not the only complication. There are many other issues to take into account as well. For example, rooms have to be placed exactly beside each other with appropriately positioned doors between them for the exits to work. If the structure is a certain size, the rooms within cannot be allowed to exceed that size in total. Structures can not exceed the islands, and so forth. The jump from simply specifying a room with some exits to other rooms is fairly monumental.

The resulting problem is a big one - ease of use when creating rooms plummets. Suddenly a creator has to understand all these coordinates, and how to specify 3D shapes using them and get everything put together correctly. With a text-based, command line environment and a complex area to build, this can be a challenge even for the mathematically inclined. The risk is that innovative and imaginative areas end up not being written because the creator just could not get all the numbers to work out correctly.

All this can be addressed in one easy step - a graphical, point and click interface to build areas.

In the next part, we will describe the graphical editing system - what it is, how it is put together, and how it interacts with the mud.


Donky is the best mud coder out there. I look up to his abilities and one day hope I too could be as good as him. If he let me code on his mud, I would abandon Discworld in an instant.