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:

Computer-Generated Terrain:
For example, a part of the world might be specified to be a desert. The mud would generate realistic desert terrain as a backdrop and a creator could then place a ruin somewhere within it and scatter some oases. Similarly, a part of the land specified to be a forest would result in generated forest terrain - into which creators could place clearings, towns and villages, and lay roads from place to place.

The most obvious gain from generated terrain is that it removes the limitation of players being only able to move within the rooms that were built by creators. Not only does this flesh out the game world and make it more believable, there are other equally valuable advantages. The resulting backdrop gained from this does not have to be bland filler that merely enables a player to get lost or at best take an unconventional route from A to B, it can also provide places for use by other systems to add further depth to the game.

For example, say a forest is being generated. That can mean trees and plants available for harvesting and wildlife for hunting. Resources like these that can act as a basis for other player (and NPC) activities like alchemy, arts and crafts, building, tanning, etc.. Climbing trees might also be possible, giving a better view.
The Oceans:
Anywhere we had not specified islands, the system would need to default to ocean terrain. This has a lot of potential to exploit. For example, imagine being able to own your own ship and set any course you like - ending wherever your skills and the winds and waves take you.
The Skies:
You are standing on a rooftop over here. You can see another rooftop over there. For some reason or other you have the ability to fly - through magic or the use of wings. Why should not you be able to fly from here to there? Of course, if your flight fails for some reason then gravity should take its revenge.
Movement and position:
A while ago, one of our creators suggested it would be nice if there was a way to position things within a room, depending on the actual size of the room. What he was actually asking for was a way to allow a player to wait by one door and ambush someone coming through it. If the intended target came in through another door then he would be seen and there could be no ambush.

One of the biggest cop-outs in many types of mud is that all rooms are a fixed size and there is only one position within it. You are either in the room, or you are not in the room. Our solution to this was to subdivide a room into one meter square positions. A movement in any direction would moved you to the next position in that direction unless a wall or other obstacle blocked the way.

This also addresses the problem of having more than one exit from a room in a given direction. With only one position, either in the room or not in the room, differentiating between two doors in the east wall is very awkward. With multiple positions however, a player can move in front of each exit and go through it directly. A possible problem does remain in describing the position of each exit to the player, but the positioning system also provides the basis for room description generation. If done well, it more than solves the problem. Generating room descriptions has a bad reputation in some circles, but done well it can produce fairly good results.

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.