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.
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:
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
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.
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
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.
June 2000 Imaginary Realities, the magazine of your mind.
© Copyright Information