[MUD-Dev] Room-based vs. coordinate-based

[Adam Wiggins]

[Alex O:]
> I have some questions regarding a room-based vs. a coordinate-based MUD issues
> (*) Ease of coding and efficiency.
> Room-based seems much more efficient and easier to code.

Well, it depends.  In a limited scope, yes.  On a broad scope, no.
That is - muds (and textadventure games, etc) now are of limited scope.
There's a certain number of things you can do, and that's it.
What I've found, over the course of creating my own, more ambitious project,
is that a more flexible system is ALWAYS easier in the long run.  Every
time you go to add something new to a limited system, you find yourself
having to hack the system a little bit more to try to make it work.
A flexible system is able to absorb the new feature(s) seamlessly.

> Coordinate-based will require proximity calculations on almost any activity or
> command (in room-based I can just assume that objects inside a "room" containe
> are close to each other).  Motion, visibility, etc. becomes more complex.

Yes, absolutely.  Here's the thing: once you code these things, and assuming
you code them correctly, they will work forever.  That is, if you add some
new thing that you hadn't planned on, your simple visibility code will
still work.  A simple but rigid system is usually based on assumptions
like "players will always be able to see X distance" or "players will always
be able to interact with things X far away."  What happens when you, say,
add airplanes to a room-based system?  The players can't see the planes
because they are hundreds of rooms above them - yet they should be able to.
You will end up 'hacking' the system to allow for this special case.  What
about when you add infrared goggles?  Now players can see 'through' walls -
a simple change to a visibility system to consider heat the vehicle for
vision, instead of light.  Probably a room-based system (again, as it is
done on normal muds) will require yet more hacking.

> (*) Combat.
> 
> Coordinate-based makes ranged attacks, closing-in, retreats, etc. simpler to
> implement (any ideas how to handle this in a room-based system?).

Yes.  Rooms are vague.  Coordinates are specific.  Coordinates are 'harder'
to begin with, because you can't ever fake something - everything is
at fixed distances and positions, so you _must_ take into account
these things for anything you do.  Rooms have the advantage of just figuring,
"Yeah, he's in the room, he must be close enough."  But of course, as soon
as you want to do anything more complex (like combat), you find that this
starts to become a hinderance instead of a help - you *want* to know how
close they are, how they are positioned, etc.

> Also, consider the following sniplets (in the context of room vs. coordinate):
> 
> [JCL:]
> } The big reason for this is that I am
> } working hard to totally lose the concept of rooms.  As such I actively
> } want to support two players fighting who are also seperated by the
> } entire width of the land, a couple rooms apart, or right beside each
> } other.
> 
> [Adam:]
> } > notch arrow bow
> } You notch a wooden arrow into your bow.
> } > shoot north orc
> } [Here 'bow' and 'arrow' are already in your list of objects recently accessed]
> } You fire a wooden arrow north at the orc.
> } > notch
> } [Here everything it wishes to know is already in your list...]
> } You notch a wooden arrow into your bow.
> } > shoot
> } [Same thing - it just so happens the orc has moved west.]
> } You fire a wooden arrow west at the orc.

We have rooms.  Partially because we started creating areas that way, areas
that I like, and I like the handcrafted effect of rooms.  We also have
coordinates and ranges for purposes of combat, line-of-sight, and so on.
If I were to start another project from scratch, I'd probably ditch rooms
altogether.  They are a nice abstraction, for now, particularly being
limited to text.

> (*) Area effects.
> 
> How will I handle "Boffo arrives from the north" type of messages?

Again, this is one of those things that's somewhat complex to design
and code in the first place, but once you do it, you've taken care of
it forever - no special code to handle things like sneaking, flying,
arrows whizing by, and so on.
You just have a simple visual unit attached to each character.  This
visual unit has properties - how much it notices, what its field of
view is, what the medium for viewing is (this means that sound and smell
are also 'visual' units - perhaps a better name is sensory unit), how
detailed the unit is, what the range is, and so forth.  This will 'notice'
things and send the user a message based on a lot of different variables,
producing something as simple as 'Boffo walks in from the north' to
'A dark shape passes by, far overhead' and 'A strange and unpleasant
odor drifts in from somewhere off to your right.'  None of this requires
'special' code, once you've created the sensory unit.  All you need to
do is outline the properties of the character's senses, and then the
outputs of other objects.  (Ie, things need to put off a smell, put off a
heat signature, and so on.)

> Room-based (or, rather, "container-based") has an advantage here.  A container
> may send messages to the objects it contains.  In a coordinate-based system I
> will need to consult a "map" of object locations to determine message
> recipients.  Or am I wrong?

Yup.  You're right.  But again, with containers, you need special code -
if someone is talking inside that tent, shouldn't others nearby but not
inside the tent be able to hear?  These sorts of things are either
speciality coded in room-based, or (more likely) just ignored as being
unimportant (which is probably not that bad of an assumption in many cases).

> (*) Movement.
> 
> What will be the difference between "north" and "run north" in a room-based an
> a coordinate-based systems?

This becomes an arbitrary definition.  For one thing, it's easier to actually
do things like "run to the building" than it is "north".  You can set north
to map to "turn towards what I think is north" and then "walk a given
distance", of course.

> Coordinate-based systems also seem to imply finer movement granularity
> (closing-in for combat vs. walking towards the mountain) and therefore,
> additional user commands may be needed to realize this.

Absolutely.  Is this bad?  I don't think so.  There is a certain simplicity
to the n, e, s, w, u, d system, which I really like.  Some time ago
(might have even been on Wout's list, now that I think of it) we were
arguing over this.  I dislike arbitrary exits.  Co-ordinates are the
ultimate in non-arbitrary exits, since everything has a very specific
position in 3D space.  Making a good use interface for this is certainly
tricky, however.