[MUD-Dev] Room-based vs. coordinate-based
jeffk at tenetwork.com
Wed Jun 4 21:26:45 New Zealand Standard Time 1997
At 08:14 PM 6/4/97 PST8PDT, you wrote:
>} >How do you handle cross-room actions?
>} As I understand your question, I don't. As I say "room" is too narrow a
>} term. My model is a world of nested containers, each iwth acoordinate
>} system. If you want something like a voice to be heard in multiple places,
>} or an arrow to arch across an area, the areas in questio nare all part of
>} the same "container" and exist in the same coordinate space.
>} As an example... a large expanse of desert might all be one container. The
>} streets of a city m,igth be another container. Inside a bar in the city is
>} in a third conatiner.
>} The whole purpose of containers is to cut down on the interraction between
>} players where logical and reduce the n-square problem. (Actually, thats not
>} entirely true, my parse system is also inhearently tied to the container
> +---------------------------------------+---------------+ N
> | | | ^
> | [A] Grassland [B] | [C] Forest | / \
> | | | |
> +---------------------------------------+---------------+ |
>Alfred is in the grassland. Position[A] = (30,30).
>Bubba is in the grassland, near the forest. Position[B] = (200,30).
>Calvin is in the forest. Position[C] = (230,30).
>How will the program handle the following scenarios:
>* Bubba sees Alfred ("in the distance") but not Calvin.
The room model maps to the existing front end nicely. The DSO front end is
built on the DarkSun garphic adventure games. They have logicly distinct
"maps" which are totally insulated from each other. Yo usolve the dilemma
in game design as mucha s possible... (ie "city gates" seperate inside and
outside, etc) and a little suspension of disbelief where less logical (like
out in the open desert... I dunno... Sand Dunes? I'm an old njudge, i can
justify ANYTHING with enough thought ;))
The short answer is calvin is NEVER aware of Alfred and Bubba or anything
each of them do.
This may seem a touch primitive to text mudders, but its actually stil
ladvanced technology for graphic mUDS, whci h are really behind the times.
(Go look at one of the msot popular, Never Winter Nights on AOL, and you'll
see what i mean.)
>In a purely "container-based" setting, $Calvin would send a message to
>$Grassland which would, in turn, send messages to $Alfred and $Bubba.
The limitations of the front end basicly render this irellevent for me. I
can take the easy way out :)
>} >What algorithms do you use?
>} Um... thats BIG question. All code is algorithymic. Im not sure what your
>} question is here...
>I meant data structures to represent spatial relationships and algorithms to
>compute message recipients.
Everything within one conatinaer is on the same map. Objects on the same
map can communciate. Obejcts on differnt maps cannot.
Every obejct holds its own x,y position. Their container holds a list of
all objects contained. Beyond that, who can so what to who is basicly by
AD&D rules with each coord positio nconsidred one 3yard/10' (a cheat) square.
Now the parser is mroe interesting, and you might be askign about this...
Im not sure...
Each object has 2 lists of verbs, an inernal list and an external list.
Parse order is as follows....
(1) My children's external verbs (child == contaiend by me)
(2) My neighbors' external verbs (neighbor is defined as 1 sq away)
(3) My container's internal verbs
(4) My internal verbs.
Each verb looks at the input and can act on it, modify it, and/or stop
processing on it.
Alot of subtle effects are achievable by putting invisible un-droppable
objects in the contaiend list of a player to modify their interface to the
Because all objects are the same thing and cna contain and be contained its
also possible to have people working from the inside of a cointainer and
making changes viewable on the outsid eof a contaienr (my favorite
example-- the giant japanese robot ;))
The container system is a result of soem base development of mine whiel the
AD&D and DSOII specifics were layered ontop fairly recently. You cna kidn
of see the break point in terms of generality v. app specificity ;)
More information about the MUD-Dev