Introduction

[Dan Armstrong]

I would like to finally introduce myself.

Around January of this year, I started talking to a friend and
considering how hard it could be to make a MUD server.  After
about two weeks of putting ideas together I decided to hit the
code, I brought up and empty text buffer and began to type.

About three weeks into it I had a game which could be brought up
locally or across a network, and could be played.  You could walk
from Room to Room, but that wasn't enough.  I continued to work
and came up with the ideas of see-though exits, which would allow
for vision into any direction, ranged combat, and a little more
intelligent NPC's.  I worked on the code, making it ever more
efficient.  I came up with new ideas and by about 5 months into
the project, have it so fast that the look command takes only
544=B5s, running interpreted on a 100MHz machine (the reference to
interpreted is due to using Java).  I created by own string class
and directly used byte arrays and two dimensional byte arrays to
come up with the fastest, functioning server I could, capable of
thousands of players and millions of objects.

Five months have passed, I am very happy with the efficiency of
the system, but it is still not enough.  I started to see a MUD
designed around a full coordinate system.  How could it be done?
I put myself to the task, thinking about how to store the objects,
how to store the environment, and how they can all work together
to create a playable, versatile game.

I have been subscribed to this list for about four months now and
have not introduced myself until now because I wanted to get all
my ideas straightened out before I started speaking about them
with others.  I read the threads about R-Trees and the
descriptions given were a little vague, so I decided to come up
with my own system.  I have never had a formal class in
programming, just seemed to have a knack for it since elementary
school.  The storage method I using I'm sure has been created
before and has a name, but I wouldn't know what it's called.

For storing objects I use a tree that is twenty levels high, based
on the following pattern.  Each level in the tree, except for the
last, holds four smaller pieces of the tree.  If any of those four
are null, then there aren't any objects in the area covered by
that piece.  The last level in the tree is either null if nothing
is there, or points to the head object of a linked list of every
item that is at that location.

For the environment I have a database for the ground and a
database for the ceiling.  I used a similar system, except the
major difference is that for storing objects you want the minimum
memory used to accessibly point to the objects, while storing the
ground you want the minimum amount of memory used to cover the
entire world.

What I've put together is a world which is 1048576x1048576 meters.
There is ground at every position in the world from the very
start.  There is the sky at every position from the beginning.=20
The world immediately exists, it just needs to be filled in with
the imagination of builders.

Open areas are compressed well by the database, as are groups of
objects.  I've discovered ways of efficiently handling sound and
finding all objects within a given area, but what I am currently
working on is figuring out how the look command will work.

Every Living has a minimum size of object that they can see, a
maximum distance they can see, and a height for their point of
view.  If I am three feet tall, and you are six, you will be able
to see over a five foot wall, while I cannot.  If you lift me up,
then I can see over.  If a dragon is flying 100 meters in the air,
and I am three feet tall, stepping right up to the wall I will not
see the dragon flying.  If I then take a couple steps back from
the wall, I will see the dragon flying beyond the wall.

The processing of objects and their positions is not a big
problem, but how to give the player an intelligent description of
what they see is difficult.  I could simply list everything from
closest to farthest, but that would not be very intelligent.

You see:
a wall
a tree
a squirrel (climbing a tree)

I would like something a little more like:

You see a wall, behind the wall is a tree with a squirrel climbing
it.

I've seen a recent discussion about sparse arrays and putting
rooms into coordinates.  Full coordinate based is proving very
powerful.  I sometimes fear that I may be going too large scale,
but once the game is actually done, computers should be capable
of what I expect.  I am considering details such as night and day,
seasons, seasonal weather, currents in the ocean, and the big
kick, grass that grows.

Persistence plays a large part in the game, if our hero Bubba
digs a hole immediately in front of the main entrance to a city,
that hole will be there until somebody decides to fill it in.  If
I cut down a tree in the forest, the tree will stay there until it
rots away or gets moved, burned, or cut up.  The stump will remain
in the ground until it rots away or gets burned, pulled out, or
removed by some other means.

I am able to save the world to disk, but only as a backup.  Resets
will not exists.  I will not cache to disk.  If I do not have
enough memory for the world, I will either buy more RAM or
simplify the world.  I am designing the system with the idea of at
least 1 gigabytes of ram to use, another example of how I might be
going to large scale.

Memory results so far:
I currently use 24 bytes per instance of objects in the game.
Ground types are a single instance referenced by multiple
locations in the ground database, which leads to a significant
savings in memory.  The object database is at worst 456 bytes and
at best 9 bytes per location that contains objects.  A location
without an object doen't take any memory.  Due to creating my own
strings and a way for them to be loaded automatically from disk,
I am able to get memory savings over the Java 16-bit Unicode
String class.

I have also written the client which must be used with the game.
It supports the server by doing all the work it can, to save the
server's CPU time.  The system is capable of embedding graphics in
any string handled by the server.  It is the client that
determines how to break apart the string and display it.  The
description of an object can be a small picture, and will be used
seemlessly in place of the text.  The graphics are here just for
some added flavor, but not as the basis of the game.  I am hard-set
on keeping the game text based.  I don't want to lose the feel of a
good text based MUD.

This message is long enough for an introduction, I will post a
message about my ideas of bulk compression and wrapping of objects
soon.  A couple of ideas I am most proud of.

Dan Armstrong
orion at pixi.com