[MUD-Dev] RP thesis...

[Adam Wiggins]

[Marian:]
> On Wed 28 May, Adam Wiggins wrote:
> > [Marian:]
> > > Why not make the ashes of that bonfire a very real object in that
> > > area that will be present in the room every time that room is re-
> > > created. Of course you also have to make it decay over time but
> > > that's something I find in most muds anyway.
> 
> > Right.  The trick is, of course, that you just store a general description
> > of the world (things like terrain and elevation), and then *changes* to
> > that.  Things like tracks, campfires, objects on the ground, sigils
> > carved in trees, local mana depletions, and so on are stored as lists
> > rather than arrays.  If you only have one campfire, you only have one
> > item in the list.  [etc snipped]
> 
> I'm not sure I follow this all, but my simplistic idea would be to have
> a list for 'the forest of green shadows' and another list for 'the
> mountains of sorrow'. That should allow more special objects to be kept.
> And if that's not enough you can further subdivide the forest and the
> mountains until you have a manageable number of objects in each location
> in the world, right?

Well, not exactly.  I see no reason to divide it up like this.
The simplest way is to just have a giant list of objects (well, all muds
have this in one form or another).  All objects have coordinates.  Rooms
usually make things easier, because they have linked lists of objects that
are 'in' them, thus it's pretty easy to find out what's in the same room
with you.  With a simple grid system, you have to access the object list
and find all the objects in the same room as you, at which point it creates
a virtual room which is attached to your character and makes a new,
temporary linked list there (since you're likely to access those objects,
and there's no need to perform the serach again).  If you leave the room
is either deleted (no other pc's present) or passed to whatever other
pc's are in the room.  This doesn't destroy anything in the room, mind
you - it just means when you re-enter it has to look up and find out what
objects are in the room again.  Not really a big deal - if you find that this
is causing slowdown, there are 1,001 optimizations you could do to
speed things up.  We keep a simple list of flags for each grid area which
tells us what (if anything) is present, and then we can go look those things
up on the appropriate sub-lists.  Data about the world, such as elevation,
terrain type, and what plants grow near by can also be stored in very
generalized lists of data - ie, we specify what plants grow where in the
master list of plants.  You just specify where they grow, a radius, an
ideal clime, elevation, and terrain type for them to grow on.  This takes
almost no space at all (so little it's unnoticable).  You check this list
when the player wants to find out what plants are nearby, rather than
generating 10,000 fruit trees all over the map.
So the trick is, you only store as much as you need to, and no more - those
10,000 fruit trees are all pretty much the same as far as where and how
they grow.  The only time it even matters is when a player (or a mobile,
for that matter) wants to pick a piece of fruit of the tree - and then
it is simple enough to either generate a tree or whatever you like.