Rooms? Who needs them?
Dan Brumleve
MUD I've seen is the concept of "rooms". They usually work well
in a mostly fixed-sized setting, such as an indoor building or
even a city if done right, but everything falls apart when they're
applied to an outdoor setting as well. I've been trying to fix
this problem on Armageddon by simply increasing outdoor movement
costs a lot and making outdoor areas much more extensive, and some
people like Shawn have decided to get rid of outdoor settings
entirely. Rooms also make object-oriented systems troublesome
in a Diku-like system, in which objects need to be cloned from
default settings (imagine having 1000 'food' items in the database),
and rooms should be unique.
A friend of mine, Paul Vondrak, proposed a solution to the problem.
I think it's been casually tossed around on the net a few times in
the past, before being crushed to death as impossible to apply to
a MUD and too complicated for players. The solution is eliminating
rooms entirely, and assigning grid coordinates to all objects... That's
an oversimplification of it, however, and most of this article will
be about the programming aspect of it. I spent a couple hours thinking
about how to apply it without forcing players to move around with
commands like "north 17 meters" or making creators use a geometry
textbook next to their thesaurus, and I came up with something
feasible. Here's a "first draft" of the new "room" structure:
struct grid_data {
char *label; /* label for grid section */
int size[2]; /* each room is a size[0] x size[1] rectangle */
short int elevation; /* elevation from "ground" level */
char *desc; /* description for grid section */
struct grid_data *next; /* next grid section in list */
};
Simple, but it's a start. The world would be divided up into grid
sections, each with an internal coordinate system. There are no
"global" coordinates... Each object has two coordinates relative
to whatever grid section it is in. The label would take the place of
the "room number"... It would use more memory, sure, but considering
that main_street(5,5) is easier to remember than 40327(5,5) and that
one grid section can take the place of a forest made up of 500 identical
rooms, I doubt that will be a problem. The size array makes it necessary
that each grid be a rectangle, which isn't realistic, but it's still
usable. The elevation of a section would determine its distance
from the ground, allowing creators to make mountains and hilly
areas.
This structure is pretty much the extent of any ideas I've seen before
on the subject, and it contains many flaws:
1) Monotony. Players would see the same descriptions everywhere,
and get bored.
2) Movement. Imagine having to specify the exact distance you
wanted to move. I once played a Star Wars-based LPMUD called Kobra,
and piloting a spaceship required that you specify exact
vector coordinates for flight. Real pain. You also can't
move toward objects very easily in such a system.
3) Slopes. What if you wanted to make a hill, or even a wall
for that matter? Specifying an angle for orientation and inclination
would do the trick, but would still complicate things.
That isn't all of them by a long shot, but the structure can be
modified to accomodate them:
struct exit_data {
int range[2];
char *message;
struct grid_data *to;
struct exit_data *next;
};
struct move_data {
int loc[2];
int radius;
char *keywords;
char *message;
struct move_data *next;
};
struct grid_data {
char *label; /* label for grid section */
int size[2]; /* each room is a size[0] x size[1] rectangle */
short int angle[2]; /* angle of rotation and inclination */
short int elevation; /* elevation from "ground" level */
char *desc; /* description for grid section */
struct exit_data *exit; /* exits out of grid */
struct move_data *move_to; /* places to move to */
struct grid_data *next; /* next grid section in list */
};
Looks more complicated, but it solves a couple of the problems.
Data for the exits from the grid would be stored in struct exit_data.
Whenever a character stepped between coordinates range[0] and range[1]
on the specified side of the grid, s/he would be sent a message and
sent to the cooresponding coordinates on the other grid, if it exists.
If "to" is a null pointer, the character would be sent the message
anyway (which would be something like "You run into a stone wall."
or "The forest is too dense in that direction.").
Movement itself would be handled by the "walk", "run" or "go"
commands, which would take one argument. The argument would be a
direction (in which case the player keeps moving in that direction),
a visible object (determined by weight/size), or a keyword in
the move_to linked list. The player would start walking toward
the coordinates in the move_to structure (which needn't lie on
the grid), and stop upon reaching them.
Also, angles of inclination have been added, because I haven't
been able to think of anything better to solve the problem. They
wouldn't be used very extensively except in something like a three-
dimensional maze anyway, but if you think of something slightly
less compliated to do the job, please tell me.
There are still more problems with it, however, many of which
I haven't been able to come up with solutions for (e.g., stairs ;) ).
Making it simple for creators is also complicated, but I've put
together some commands which use as few numbers as possible. Any
coordinate on a grid could be referred to by grid_label(x, y),
and most creation involving specific grid coordinates would use
this notation.
Just to give you an idea of what playing in such a system would
be like, here's a "log" of what I envision it to be:
-----
>look
The bustling Grand Quarter stretches all around you, full of
rickety caravans, produce stands, watersellers, and normal, everyday
chaos. The giant Arena stands far to your south, touching the
side of this huge bazaar, and a fountain is in the center, shaped
in the form of a nine-sided crown, pouring water into the hands
of sand-starved people who pay their daily wages for the service.
The fountain is a ways to your northwest, and a Templar stands nearby.
An old caravan stands close to you, its Thuja wood frame almost crumbling.
>walk caravan
[no delay]
You walk over to the old caravan, which seems about to fall over.
>look
The bustling Grand Quarter stretches all around you, full of
rickety caravans, produce stands, watersellers, and normal, everyday
chaos. The giant Arena stands far to your south, touching the
side of this huge bazaar, and a fountain is in the center, shaped
in the form of a nine-sided crown, pouring water into the hands
of sand-starved people who pay their daily wages for the service.
The fountain is a ways to your northwest, and a Templar stands nearby.
An old caravan stands right next to you, made of rotting Thuja wood.
>walk fountain
You start walking northwest, toward the fountain in the center.
[~10 second total delay while walking]
An old elf walks near you, coming from the west.
The old elf walks away to the east.
You reach the fountain, a stone structure shaped like a nine-pointed crown.
>look
The bustling Grand Quarter stretches all around you, full of
rickety caravans, produce stands, watersellers, and normal, everyday
chaos. The giant Arena stands far to your south, touching the
side of this huge bazaar, and a fountain is in the center, shaped
in the form of a nine-sided crown, pouring water into the hands
of sand-starved people who pay their daily wages for the service.
The fountain stands close to you, watched over by a scowling Templar.
A porcine Templar in a black robe stands here, selling water from the fountain.
>walk arena
You start walking south, toward the Arena.
[~5 second total delay while walking]
You walk near a black-robed Templar, who stands south of you.
>stop
You stop walking.
>say Hi. My name is Friendly. Can you help me?
Ok.
The black-robed Templar says,
"Yes. Stop bothering me now and I assure you that your execution
will be speedy."
>say Please? Here, I'll give you this thingy I found in the desert.
Ok.
The black-robed Templar unsheaths a Khalian jambiya.
The black-robed Templar jabs you in the stomach with a Khalian jambiya.
>look
The bustling Grand Quarter stretches all around you, full of
rickety caravans, produce stands, watersellers, and normal, everyday
chaos. The giant Arena stands far to your south, touching the
side of this huge bazaar, and a fountain is in the center, shaped
in the form of a nine-sided crown, pouring water into the hands
of sand-starved people who pay their daily wages for the service.
An alley leads west behind a tavern on the west side of the Grand Quarter.
A black-robed Templar stands here, scowing and waving a Khalian jambiya at you.
>run alley
You dart into the alley.
-----
Et cetera.
I apologize for the length of this. If you have any ideas about
such a system, or any other similar one, please respond to this
article or mail them to me. Thanks.
--
_______________________________________________________________
Dan Brumleve, Illinois Mathematics and Science Academy
(brum...@atropa.stat.uiuc.edu, brum...@imsasun.imsa.edu)
"A computer chattered away to itself for no apparent reason.
This was because reason had in fact gone out to lunch."
-Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
dion...@u.washington.edu
>
> One of the single most unrealistic things about every Internet
> MUD I've seen is the concept of "rooms". They usually work well
> in a mostly fixed-sized setting, such as an indoor building or
> even a city if done right, but everything falls apart when they're
> applied to an outdoor setting as well. I've been trying to fix
> this problem on Armageddon by simply increasing outdoor movement
> costs a lot and making outdoor areas much more extensive, and some
> people like Shawn have decided to get rid of outdoor settings
> entirely. Rooms also make object-oriented systems troublesome
> in a Diku-like system, in which objects need to be cloned from
> default settings (imagine having 1000 'food' items in the database),
> and rooms should be unique.
>
ever look at the "virtual rooms" code in the TMI-II dist for MudOS?
/* deleted stuff */
> Just to give you an idea of what playing in such a system would
> be like, here's a "log" of what I envision it to be:
>
> -----
/* deleted log */
> -----
> Et cetera.
>
If/when you complete something that works like the "log" you showed, I
would like to look at it...
> I apologize for the length of this.
Ahhh, long no longer
> If you have any ideas about such a system, or any other similar one,
> please respond to this article or mail them to me. Thanks.
-CoHort
Stephen Schmidt
>
> One of the single most unrealistic things about every Internet
> MUD I've seen is the concept of "rooms". They usually work well
> in a mostly fixed-sized setting, such as an indoor building or
> even a city if done right, but everything falls apart when they're
> applied to an outdoor setting as well. I've been trying to fix
> this problem on Armageddon by simply increasing outdoor movement
> costs a lot and making outdoor areas much more extensive, and some
> people like Shawn have decided to get rid of outdoor settings
> entirely. Rooms also make object-oriented systems troublesome
> in a Diku-like system, in which objects need to be cloned from
> default settings (imagine having 1000 'food' items in the database),
> and rooms should be unique.
My first MUD coding project ever :) was something along these lines: I
was trying to write a large battle simulator and was looking at implementing
line of sight rules. The problem is that determining what is or is not
in sight in a grid-coordinate system is much too CPU intensive to work
when more than a few dozen objects are interacting. The room system's
most important convenience is that it nicely defines sight lines, and
the present() efun implements them: In the same room you can see it,
not in the same room, you can't. The largest problem with treating large
outdoor areas is determining this. If you try to calculate realistic
sight lines, the CPU chokes. If you impose an arbitrary limit on sight
range (this grid location only, adjacent only), then you're essentially back
to a world of rooms.
I came to the conclusion that if you really wanted to do this, the correct
thing to do would be to essentially rewrite the driver, doing the LOS
properly and putting the calculations in the driver. Done that way, it's
possible to make it semi-realistic in finite CPU time. However, since I
lacked time to rewrite the driver from the ground up :) the project
foundered.
Those are my experiences with the question, anyway... anyone else ever
tried to do stuff like this?
--
Steve Schmidt <>< wh...@leland.stanford.edu
I can no longer sit back and allow Communist infiltration, Communist
indoctrination, Communist subversion, and the international Communist
conspiracy to sap and impurify all of our precious bodily fluids!
Henry McDaniel
> One of the single most unrealistic things about every Internet
>MUD I've seen is the concept of "rooms". They usually work well
>in a mostly fixed-sized setting, such as an indoor building or
>even a city if done right, but everything falls apart when they're
>applied to an outdoor setting as well. [...]
[ deleted. (see the original article for full details) ]
> I apologize for the length of this. If you have any ideas about
>such a system, or any other similar one, please respond to this
>article or mail them to me. Thanks.
First off I'm going to be skimming over coding ideas the coders
will know of, my apologies to non coders. Secondly this isn't
a flame. Just my well of pointing out a few things which are
needed to make the proposed system work efficently, etc.
1.0 A Room is a Room is a Room
Well I'm a firm believer that MUDS should try to be more realistic.
I think your goals, in that, are noble. I see several familiar
things in your suggested new "grid area" structure etc. It looks
like a room by another name to me. You have exit data, room
descriptions, room locations. Thats not your fault: Every mud
which has a "large" domain needs smaller local frames of reference
for its players (read: rooms.) It seem to me that you would save
lots of work by simply adding your gird coordinate system to
the existing room structure of diku. There are of course lots
of reasons why not to do so. But short of writing your own server
it may be most time efficent for yourself.
1.1 Nebulous regions between 'rooms' ??
The major.. major.. and I do mean mega Major problem I see with
your interpretation of this idea is that you would like for there
to be time delays for players moving between rooms. Apparently
these delays would be directly related to the distances over
which the player is traversing. Now I have no qualms about that
(assuming of course that the player has commands available to
them during that 'delay' time... heh otherwise it be pre-meditated
net lag -ack) but the problem here is that you have now created
a 'nebulous' region between the points a player may be traveling
between.
If player A decides to walk 5 clicks to area 1. and player B
is crossing the other player's path what happens? Hopefully
nothing because you can't really check for collisons of stuff
that is in movement. If you did you'd be using alot of cpu.
See your system has no local list for quick searches of the
objects or players in a room/area. Your code would have
to search all game obejct locations to watch for collisons.
And why watch for collisons? If you didn't see when a player
crosses the path of an object: 1.) They wouldn't be able
to find objects lying along the route their using to go
between two points. 2.) When in a fight with a powerful NPC,
they could simply run away.. and the mud would kinda 'loose'
their location as far as players in their path of movemnet
are concerned.
Lastly, Most of the time a player spends exploring will likely
be in moving between 'boring' or sparse locations.... If you
have a grid area most of the space will be empty. Stands to
reason that Player B will find it hard to talk with player A
who is walking away from them -YET STILL SUPPOSEDLY IN THE
SAME LOCAL ROOM. You'd end up with a bad case of the 'bumper
cars' as players in varying states of net lag can't get their
legs to stop moving when they wish to stop and examine something
or chat with others.
Now with all that said. I think there is likely a better way
you or someone else must come up with to keep lots of 'small'
list for pointers to objects close to some of your grid lcoations.
This will increase the speed at which you can watch for 'collisons'
and probably other things aswell.
-McDaniel (Stellar)
Oh p.s.
Give creators some credit. Some are college grads, most are
well on the way... I think they can handle algebra.
Scarrow
> One of the single most unrealistic things about every Internet
>MUD I've seen is the concept of "rooms". They usually work well
>in a mostly fixed-sized setting, such as an indoor building or
>even a city if done right, but everything falls apart when they're
>applied to an outdoor setting as well. I've been trying to fix
>this problem on Armageddon by simply increasing outdoor movement
>costs a lot and making outdoor areas much more extensive, and some
>people like Shawn have decided to get rid of outdoor settings
>entirely. Rooms also make object-oriented systems troublesome
>in a Diku-like system, in which objects need to be cloned from
>default settings (imagine having 1000 'food' items in the database),
>and rooms should be unique.
Well, actually, getting rid of outdoor settings isn't exactly what I had in
mind. What I had in mind were outdoor sections of fairly local distance to
the city itself. As the area around the city expands, the level of detail
maintained with the city should be maintained with the outer areas, so that
moving, for example, through the surrounding countryside would be as non-
repetitive as possible. The main reason for this is not for more accurate
representation of distances or accounting for increased movement, but rather
to compensate for the fact that all players of the game are playing at one
fixed time rate (the problem with multi-player games it that you can't
accelerate time for one person without doing it for every person). Thus,
this is really a problem that switching to a coordinate system will solve,
since if the level of detail isn't great, there will still be times (say
crossing the vast desert) where little happens and little is to be seen for
vast amounts of time.
Another fundamental principle of my design is that everything, including
rooms, is an object. There can also be multiple copies of everything (just
as in Diku). Lets say, for example, I create a ship containing several
rooms, objects, mobiles, etc. It would be feasible and practical to create
several ships of the same basic design (by just loading each one).
As far as the co-ordinate system goes, my own feeling is that it is
needlessly complicated unless you are planning on very advanced effects
(sophisticated ranged weapons effects, partial cover from missile weapons,
visibility from certain angles, area effects spanning regular volumes
[earthquakes, fires, other natural disasters, spells, etc.]). This isn't to
say it's impossible (indeed, I've considered it once or twice), but it raises
almost as many problems as it solves.
--
Shawn L. Baird (Scarrow) | "By all means, take the moral high ground --
bai...@ursula.ee.pdx.edu | all that heavenly backlighting makes you a
-------------------------| much easier target." --Solomon Short
Steve
>brumleve@iboga (Dan Brumleve) writes:
>> One of the single most unrealistic things about every Internet
>>MUD I've seen is the concept of "rooms". They usually work well
>>in a mostly fixed-sized setting, such as an indoor building or
>>even a city if done right, but everything falls apart when they're
>>applied to an outdoor setting as well. I've been trying to fix
True, usually on muds there's lots of castles, each connected by
short paths of connected rooms.
>
>Well, actually, getting rid of outdoor settings isn't exactly what I had in
>mind. What I had in mind were outdoor sections of fairly local distance to
>the city itself. As the area around the city expands, the level of detail
>maintained with the city should be maintained with the outer areas, so that
>moving, for example, through the surrounding countryside would be as non-
>repetitive as possible.
I just want to point out one system which exists today, dealing with this
problem.
On Dartmud (fermat.dartmouth.edu 2525),
there's a grand outdoor map, which is quite different from the rooms in cities
or dungeons. When a player sets foot outside the city, she can type survey
and get this view:
>You gaze at your surroundings.
>
> ----- 1) There is a rocky cliff with an opening
> / n \ in the face.
> ----- n nn -----
> /^ ^ \ n n/ ^ ^\ 2) A jagged cave in the side of a mountain
> ----- ^ -----^ ^ ^-----
> /n nn\ ^ /nn n\ ^^ / %% \ 3) A sprawling city in the middle of the
>- nn nnn----- n nn----- % % - plain.
> \ nn n/ ^ ^\ n / n \ % %/
> -----^ 2 ^-----n n -----
> /. .\ ^^ / nn \n n /% %%\
>- . . -----n nn n----- % %%r
> \ . / ^ \n n / \ % r
> -----^^ ^ ----- n 3 rrrrr
> / ^^ \^ ^^/ n \ nr . .\
>-^ 1 ^----- n rrrrr. . .-
> \^ ^ /^ ^ \n nr. .\ . /
> ----- ^^ ^ ----r . .-----
> \ ^ ^/n nnr . /
> ----- n n r----
> \ nn r
> ----r
Each of the types of hexagons indicates a type of landscape.
Details in the distance are pointed out for you.
Details about your location are indicated when you type look:
>You are in the hills.
>There is a swift river to the southeast, and south.
>The entrance to a sprawling city.
Typing enter city will take you into traditional LPmud rooms.
This system distinguishes countryside and city. It Feels better
than standard LPmuds.
Hopefully, range combat will also be implemented under such a system.
...Steve
Dan Brumleve
>1.0 A Room is a Room is a Room
>Well I'm a firm believer that MUDS should try to be more realistic.
>I think your goals, in that, are noble. I see several familiar
>things in your suggested new "grid area" structure etc. It looks
>like a room by another name to me. You have exit data, room
>descriptions, room locations.
The seperate "grids" would be attached to each other, yes,
but it's still exactly the same as a "true" grid system (in which
everything would be defined by coordinates), except it's
slightly more simplified.
> Thats not your fault: Every mud
>which has a "large" domain needs smaller local frames of reference
>for its players (read: rooms.)
Smaller local frames of reference != rooms. The grid "exits"
can be defined in a number of ways. If you have a 100 x 100 meter
grid, you could define the exit between 0 - 10 meters on the north
side to lead to grid A, the exit between 80 - 100 meters on the
same side to lead to grid B, and everything in between to lead
into a wall. Rooms are much more limited.
> It seem to me that you would save
>lots of work by simply adding your gird coordinate system to
>the existing room structure of diku. There are of course lots
>of reasons why not to do so. But short of writing your own server
>it may be most time efficent for yourself.
I currently don't have any plans to add it to my own MUD (or write
a new one, for that matter). If I do, it will probably be sometime
this summer.
>1.1 Nebulous regions between 'rooms' ??
>The major.. major.. and I do mean mega Major problem I see with
>your interpretation of this idea is that you would like for there
>to be time delays for players moving between rooms.
Wrong. ;-) Players receive time delays for moving _within_ grids
as well as between them. Think of there being onnly one "grid" in the
entire world, and all players have two coordinates referring to their
location.
> Apparently
>these delays would be directly related to the distances over
>which the player is traversing.
A player wouldn't traverse a distance all at once... S/he might
type something like:
] walk inn
Every second or two, the player's position would be updated, and
movement would not affect the player in any other way. All commands
would still be available.
This is all completely wrong. Please reread my post. Players
would have no "location", but rather two coordinates referring to
their location. Whether they could talk to somebody would depend
on how close they are to the person they want to talk to. Something
like the following might be used for talking:
void cmd_say(struct obj_data *sub, char *arg) {
char mesg[256];
struct obj_data *obj;
for (; *arg == ' '; arg++);
strcpy(mesg, arg);
for (obj = sub->grid->local_obj; obj; obj = obj->local_next)
if (happy_pythagoras(sub, obj) < (DIST_METER * 5))
cprintf(obj, "~c says '%s'\n", sub, mesg);
}
That's an oversimplification of it, of course. There would need
to be different messages for different distances, as well as other
checks that I don't feel like writing right now. But you get the
point.
>-McDaniel (Stellar)
>Oh p.s.
> Give creators some credit. Some are college grads, most are
> well on the way... I think they can handle algebra.
Yes, but do most of them want to be doing geometry for recreation?
Creating on a MUD for fun is different than being paid to do it.
Kenneth K Lee
>Dan Brumleve writes
>>
[original stuff deleted]
I had at one time endevoured to create a Mechwarrior/Battletech themed
mud, which would have been based on a similiar non-room (at least close)
type of system. Various obstacles were realized which caused the project to be
scrapped (most important was the lack of a true site). Anyways, I did come
up with some code for the system, which I do believe was feasible, to an
extent.
The world was coordinate based, although only using integers, and each
coordinate was represented by a virtual room. Now a virtual room may not
have been the most efficient method of implementing it, but it was the easiest
at the time until the rest of the system had been worked out. Anyways,
information would be given to you in an ASCII drawing, sort of like:
> look
#######.....=.o.o 0: Guile, a stone, Ralph
#.....=..2o 1: A dead iguana
#.....=.... 2: Scrap metal
#..0..====1
#..........
#..........
#######..////////
of course, the #'s were walls of a building, .'s were "grass" icons
and the ='s were some sort of road.
We didn't really implement line-of-sight, because it would have been too
exhaustive of the resources available, but we did manage to hack in an
indoorness/outdoorness type of filter, such that you could not see into
different levels of "indoorness". Thus, people who were inside a building were
not seen by those on the outside. The idea of different light cycles and
perhaps inclement weather were considered, but scrapped for speed.
Actually, talking about this has made me long to do Battletech again,
but unfortunately, I'm not sure if I want to put the time into it. But this
was my vision for the mud, a mud in which the borders of a room seemed a
bit more tangible, where you could actually "see" where your opponent was.
(and of course, ranged combat with Battlecmechs! :)
-Guile@Lp's
David Bennett
> One of the single most unrealistic things about every Internet
>MUD I've seen is the concept of "rooms". They usually work well
>in a mostly fixed-sized setting, such as an indoor building or
>even a city if done right, but everything falls apart when they're
>applied to an outdoor setting as well. I've been trying to fix
>this problem on Armageddon by simply increasing outdoor movement
>costs a lot and making outdoor areas much more extensive, and some
>people like Shawn have decided to get rid of outdoor settings
>entirely. Rooms also make object-oriented systems troublesome
>in a Diku-like system, in which objects need to be cloned from
>default settings (imagine having 1000 'food' items in the database),
>and rooms should be unique.
I have thought over the grid system for describing objects rather a
lot. However, in a lot of ways it is very tricky to make it work
nicely. Your methods would work, but would not accomodate such things
as octagonal rooms. The room abstraction whilst being not very realistic
is very very useful. For one thing, you can move things around the
landscape much easier. The rooms only rely on nearby objects and not
on a overall co-ordinate. For another, even in the outdoors things will
tend to be able to be turned into room objects without that much loss
of realism. When you are wandering along a path, why stop and look at
all the boring foliage on the way? You would only really bother to stop
at the interesting bits.
The co-ordinate system has too many flaws. For text based muds I think
sticking with a room based system is a very good idea. Graphics muds
are a different concept altogether.
David.
--
David Bennett, gu...@uniwa.uwa.oz.au | University Computer Club
Where Pink fish swim backwards. | c/o Guild of Undergraduates
These words I am singing now mean nothing more than meow to an animal - TMBG
Disclaimer: Any spelling mistakes in this article are all entirly my fault. Any grammer errors spotted in this article were put there because I could.
Dean Gaudet
>brumleve@iboga (Dan Brumleve) writes:
>> One of the single most unrealistic things about every Internet
>>MUD I've seen is the concept of "rooms".
>
>I have thought over the grid system for describing objects rather a
> When you are wandering along a path, why stop and look at
>all the boring foliage on the way? You would only really bother to stop
>at the interesting bits.
On Arctic we have a zone called the "road zone" which connects most of a
continent on the mud. Unfortunately the road zone is pretty boring
because you know exactly where you are going, and just follow the exits.
I would prefer it to be a wilderness zone; you could still follow the
road. But we could "hide" other zones in the wilderness somewhere;
and people would really have to explore to find them. This is the reason
that we were thinking of doing a co-ordinate system a while ago... but we
never came up with a good data structure for implementing them.
(I was thinking of having the creator specify terrain types and then
have most of the zone randomly generated with the appropriate terrain
types. That would take care of the bulk of the zone. Then for specific
parts of the zone you could have complete control... i.e. the road above
would be a tailored part of the zone laid on top of the randomness of a
wilderness.)
Dean
Geoff A. Cohen
>In article <1qbnhb$8...@uniwa.uwa.oz.au> gu...@uniwa.uwa.oz.au (David Bennett) writes:
>>brumleve@iboga (Dan Brumleve) writes:
>>> One of the single most unrealistic things about every Internet
>>>MUD I've seen is the concept of "rooms".
>>>[..]
>>
>>I have thought over the grid system for describing objects rather a
>>lot. [...]
>> When you are wandering along a path, why stop and look at
>>all the boring foliage on the way? You would only really bother to stop
>>at the interesting bits.
>
>that we were thinking of doing a co-ordinate system a while ago... but we
>never came up with a good data structure for implementing them.
At the risk of releasing my secret data structures (snicker), I have a
pretty clean solution to this. It's similar to the concept in MUSHes
of "dynamic rooms." Essentially, wilderness rooms (called "zones" in
my hierarchy) are exactly like any another room. They have a description,
they have a linked list of objects and characters, they have an array of
exits.
However, in my C++ hierarchy, objects all have x,y,z coordinates. These
are ignored whenever characters are in standard rooms, but when they're
in a zone, you only see objects within a "visibility" of you. This way,
no additional memory need be allocated for parts of the zone which are
not inhabited, CPU overhead is relatively small (just a couple sqrt() calls),
and players can wander in arbitrarily large areas.
The neat thing about this is that rooms can be placed within the zones. So
a player might wander the desert, then see the "oasis" off in the distance.
Once they get close enough, they're automatically put inside the oasis room,
where things act like a node network again.
Geoff Cohen
Congressional Budget Office
Looking for a name for my C++ mud
Scarrow
>However, in my C++ hierarchy, objects all have x,y,z coordinates. These
>are ignored whenever characters are in standard rooms, but when they're
>in a zone, you only see objects within a "visibility" of you. This way,
>no additional memory need be allocated for parts of the zone which are
>not inhabited, CPU overhead is relatively small (just a couple sqrt() calls),
[I take issue with this down below ...]
>and players can wander in arbitrarily large areas.
Hmmm, there's a lot more to do with position than simply seeing the object.
There's the overhead for determining if an object can be picked up, for moving
toward an object, etc. You will need information as to the position of every
object, since at any given point you need to be able to calculate those that
are within your "vicinity", as it were. Lets say this is a small forest area.
As a nice round figure lets guesstimate fifty objects are in this area (only
some of which are within any one player's vicinity). We'll need to determine
which objects are close enough for every look, every get attempt, etc. Now,
there are some obvious spots where efficiency can be improved. For example,
there's no real need to perform square roots since (pardon the geometry lesson
for those of you who have no need of it) by the Pythagorean Theorem:
|\
a | \ c a^2 + b^2 = c^2
|__\
b
If you want to find out which objects are within, say, a 50 meter radius
(depending on units, etc. ... extend this to three-dimensions if you wish)
we can simply square the x and y differences (and the z for the third
dimension) and then check to see if this value is less than 50^2. This is
probably a significant optimization in that (assuming you are not using
floating point elsewhere) you remain integer based and skip the overhead of
the sqrt() call.
Something that might be more optimal might involve something like, oh,
an octree (not sure if this would work or not, but the spacial relationship
would be more apparent and thus perhaps quicker than searching the entire
object list for the room).
I'm still not of the opinion that doing things in such a manner really
lead to any visible enhancements to the game. If you're doing a graphically
based mud server, perhaps. In a text based environment, what you want to do
is to portray the world in the cleanest yet most meaningful way you can.
Understanding the concept of a room and how objects are organized in them is
fairly intuitive and quick (you don't have to re-read the room description
several times to build up an accurate enough picture in your mind). As
people have already mentioned with regards to combat (my, it seems we're far
more interested in making sense in the middle of a fight than we are in
general), one of the needs (especially for an RPG based game with physical
game mechanics) is for players to be able to process information as quickly
as possible. Diku, as an example, does not stand out in my mind as having
approached the limit of what can be done with this, but neither do I feel
that adding physical coordinates will solve the problem (in fact, if anything
they'll make the problem worse). What can be done is better use of terminal
capabilities (bolding key portions of the text, for example), better
organizing of what is display (obvious exits listed clearly, objects listed
in a brief and concise form), etc.
Tamber Kelsain
[Description of Legends spacial system deleted]
Coded and working.
Come see Legends Mud Next Fall!
-Will, aka Tamber@Legends
--
Will Stoltenberg | "We never said our love was evergreen, or as
Ames, Iowa (515) 294-1701| unchanging as the sea, but please promise me that
"Tamber Kelsain" | sometime, you will think of me."
gri...@iastate.edu | Christine, Phantom of the Opera.