Paradigms for Modeling Physical Space
Mathue
this group is supposed to be for. I've been giving a great deal of thought
lately to the subject of Paradigms used for modeling 3D space in MUDs. Most
MUDs that I'm aware of use the system we've all come to know (although many
never really think about it); a paradigm of containment. That is, the method
by which things are related to each other is by examining what they are
contained by. From the top down (although the first level is often weak or
non-existant), we have a group of areas, each of which contains rooms, each of
which may contain things (living or non-living) which may, recursively, contain
other things. Generally speaking, there is also the small addition of the
concept of direction, but only between objects at the room level. That is,
room foo is to the west of me, and room foo contains a gnome and a chair, and
the gnome 'contain's a dagger and a pouch that contains some coins. The only
relationship between me and the gnome is that the room the gnome is in lies to
the west of the room I am in.
Okay, so now you're probably either wondering what the heck I'm getting at or
reaching for the keyboard to advance to the next post... so here's my point:
Although this system seems wto work pretty well... is it, in fact, the best
system for our needs? Backing up a step, maybe we should ask ourselves what
exactly we want our space-modeling paradigm to provide. What do YOU think it
should support? These are the things I came up with off the top of my head
just now, but I'm sure there are others (and even these have varying priorities
among different people):
1) Ability to determine that things are located in the same small area,
2) Ability to determine a path from one thing to another, if such a path exists,
3) Ability to determine the existence of a LOS (line of sight) between two
things that are not co-located as per #1...?,
4) Ability to determine "distance" between two points,
5) Ability to determine what place lies in a given direction from some
particular location, with (and possibly without) the existence of some sort
of 'exit' (a data object or a command) in said direction,
6) Ability to determine the spacial relationship between two co-located objects
(e.g. below, on top of, next to, behind),
etc.
I know some people have tried working out entirely coordinate-based
paradigms... which would have their own benefits and drawbacks as far as what
goals can be accomplished (and how efficiently they can be performed). Has
anybody else given this subject any thought? Anybody have ideas for a new
paradigm? Or perhaps a different blending of existing systems? Anybody even
interested in this kind of discussion?
--
Mathue Moyer (aka Gollux @ Perilous Realms MUD)
Email: mat...@ucsd.edu URL: http://icse1.ucsd.edu/~mmoyer (under construction)
"Never underestimate the bandwidth of a station wagon full of magnetic tapes
hurtling down the freeway."
Scott G Cowell
Although this system seems wto work pretty well... is it, in fact, the best
system for our needs? Backing up a step, maybe we should ask ourselves what
exactly we want our space-modeling paradigm to provide.
This is the most important question. Whereas coordinate systems would be
very well suited mechanically to improving upon combat realism, I don't
think its wholly necessary for a more in-depth representation of the
spatial environment. It all depends on what you're interested in:
realistic combat situations, or more complex object relationships. I
personally am more interested in the latter (though essentially combat
is just a terribly complex object relationship)
In addressing your points of interest, I'll refer to both coordinate
systems and a system I will call a 'relationship' system, where object
relationships are based on simple connectives such as 'on', 'in', 'behind',
'near', etc. This is just a logical outgrowth of current systems that
just support the 'in' relation.
1) Ability to determine that things are located in the same small area,
In a coordinate system, this is simple. It could be expressed in a re-
lationship system with a 'near' construct.
2) Ability to determine a path from one thing to another, if such a path exists,
3) Ability to determine the existence of a LOS (line of sight) between two
things that are not co-located as per #1...?,
4) Ability to determine "distance" between two points,
5) Ability to determine what place lies in a given direction from some
particular location, with (and possibly without) the existence of some sort
of 'exit' (a data object or a command) in said direction,
There points are not supported well with a relationship system. It is in
these types of computations that a coordinate system excels. I think it
can be argued that many of these are not crucial for an in-depth spatial
representation. (3) and (4) are most likely outgrowths of a desire for
realistic ranged combat?
6) Ability to determine the spacial relationship between two co-located objects
(e.g. below, on top of, next to, behind),
etc.
Here the relationship system comes off strong, esp. with a text-based
display mechanism. Expressing these types of relationships with coordi-
nates as a base is a bit more complex (not that its a daunting task).
Here are some things I see as benefits from the relation system:
- simplicity: its just an outgrowth of current relationship mechanisms
- ease of expression: very easy to convert to a textual representation
- ease of specification: its not required to say exactly where an object
is, just what it's relations are to objects around it
- ease of emphasis: if a creator feels that it is important that object A
is near object B, expressing this to the player is simple; with coordi-
nates, object A may be near B, but also C and D - expressing the im-
portance of the connection between A and B spatially is not quite as
straightforward
Of course, if the main thrust is combat, a coordinate system is probably
worth the extra implementation complexity.
-sc
Travis S Casey
>very well suited mechanically to improving upon combat realism, I don't
>think its wholly necessary for a more in-depth representation of the
>spatial environment. It all depends on what you're interested in:
>realistic combat situations, or more complex object relationships. I
>personally am more interested in the latter (though essentially combat
>is just a terribly complex object relationship)
>
>In addressing your points of interest, I'll refer to both coordinate
>systems and a system I will call a 'relationship' system, where object
>relationships are based on simple connectives such as 'on', 'in', 'behind',
>'near', etc. This is just a logical outgrowth of current systems that
>just support the 'in' relation.
Hmm... I can see a bunch of potential problems with this approach.
Consider the "near" relation: if A is near to B and B is near to
C, is A then near to C?
If our answer to this is yes, then it becomes impossible to properly
represent a long chain without adding further layers to the system;
every link in the chain is near to the next link, but the first and
last links are not necessarily near each other.
If we choose to answer no, then every object must maintain a list
of all objects that it is near to; thus, if we have twelve objects
which are all near each other (twelve people in a small room, say),
each object has to keep track of 11 other objects, for a total
of 132 things being kept track of. Also, if an object is removed
from the room, not only does the list of things it is near to
have to be changed, but the lists of things that everything else in
the room was near to has to be changed. On a large mud with
thousands of objects, the extra memory requirements for maintaining
all these lists might become a major problem.
Next, consider the relation "behind". It should be obvious that
whether I consider A to be behind B depends on where A and B are
in relation to me. If A is behind B and I walk around to the
other side of them, B is now behind A from my point of view.
The only way that I can see to meaningfully add such relations as
"right", "left", "behind", and "in front of" is to implement
a coordinate system.
However, the "on" relation doesn't have too many problems; an object
usually won't be "on" multiple objects; indeed, I think we can ignore
that possibility simply for the sake of simplicity. Having something
"on" something else could be useful for implementing things like
the trap from the start of the first Indiana Jones movie, where
Indy had to swap something else with the golden idol that was on
the pressure plate.
Other relations that I can see as useful and without too many
problems are "above" and "below"; since these are in relation to
a fixed frame of reference (up and down), they don't have the problems
that "behind" and "in front of" do.
A related idea :-) is that of collections; sets of objects that can
be manipulated as if they were one object. A pile of coins could be
considered a collection; it can be manipulated as a group, but
individual members can also be taken out and manipulated separately.
Another example would be a suit of chainmail armor; it consists of
a hauberk, leggings, padding, gloves, and a helmet. As a collection,
you ought to be able to take all the elements by the command "take
armor", or wear them all with "wear armor". However, you should
still be able to manipulate the individual components as well.
--
|\ _,,,---,,_ Travis S. Casey <ca...@cs.fsu.edu>
ZZzz /,`.-'`' -. ;-;;,_ FAQ maintainer for rec.games.design
|,4- ) )-,_..;\ ( `'-' confirmed cat person
'---''(_/--' `-'\_) No one agrees with me. Not even me.
"We are GNU of Borg. Your operating system will be assimilated."
Nicolas Bryant
coordinate-based system like the one being discussed in this thread. For
some time I've thought this might be a good idea, the trouble starts when
you start subdividing into locations. Apart from the obvious situation
where, if you leave through an underground passage to the west there's no
reason why the passage shouldn't curve on the way to the next room, and
you end up entering it from the south, there's the more thorny problem of
the dimensions of a room. If I move 5 rooms west, north, 5 east and
south, the only way I would come back to my original starting point is if
the "rooms" were all the same size. And when a MUD location can be
anything from a small hut to a large area in the middle of a flat desert,
there's no reason why the dimensions should coincide. Now, obviously you
can simply flag each "room" with a set of coordinates, but trying to
insure consistency over a large scale starts to be a real headache after
a while, particularly when the MUD grows over time. Before you know where
you are, Euclidean geometry just breaks down, and trying to work out
which point in the southern plains is due south of a point two hundred
locations away in the northern mountains is as much a matter of trial and
error as anything else.
But having said all that, some form of coordinate system does have a lot of
advantages. I'm not thinking in terms of location within a room for combat
purposes, I think the spatial relationships there are too complex for the
player to easily visualise without the aid of an advanced sort of
graphical interface. I'm thinking more in terms of magical location - it
might be useful to sense that there is large treasure somewhere to the
northeast without it necessarily being in the next room; you just know you
have to head generally north and east. You could work out an exact
distance by triangulation. This would also allow you to get a rough idea
of where you are in the middle of a wilderness by (for example) taking a
bearing on a nearby mountain which would be big enough to be visible from
a long way off. Or the amount of effort required to reach a particular
spot might depend on how far a journey the trip from one "room" to another
is.
Where you really hit trouble, of course, is when you start trying to do
things in three dimensions. How, for instance, do you handle the location
of a monster which can fly and hover at varying heights? Or how do you
handle various depths in an underwater zone? I suspect that if and when I
ever get round to coding such a thing, I may simply have to fudge it and
say that a flying creature occupies the same "room" as an earthbound one,
but that it can only be attacked by a creature whose reach exceeds the
height it's flying at, and can only pick up or examine objects when it's
on the ground itself.
My personal feeling is that if you try and get too accurate about spatial
location (for instance if you try to determine whether or not a player can
see someone who is standing on the other side of a tree) then the whole
thing will break down because you don't have a sufficiently accurate means
of conveying to the player what is going on. Can you imagine being told
"You are standing in a field. Four and a half yards away on a bearing of
253 degrees is a tree 70 feet tall and 5 feet wide at the base of the
trunk." Then spending ages trying to decide where to stand in order to be
invisible to someone entering from the northwest? This sort of thing is
best reserved for Doom. But in terms of keeping track of large-scale
movement, I think it might be worth the effort.
Nick Bryant
--
******************************************************************************
* "I am Pentium of Borg. Division is futile. | nic...@ibmpcug.co.uk *
* Accuracy is irrelevant. You will be approximated." | n...@st-and.ac.uk *
******************************************************************************
Mark Clements
nic...@ibmPCUG.CO.UK "Nicolas Bryant" writes:
> My personal feeling is that if you try and get too accurate about spatial
> location (for instance if you try to determine whether or not a player can
> see someone who is standing on the other side of a tree) then the whole
> thing will break down because you don't have a sufficiently accurate means
> of conveying to the player what is going on. Can you imagine being told
> "You are standing in a field. Four and a half yards away on a bearing of
> 253 degrees is a tree 70 feet tall and 5 feet wide at the base of the
> trunk." Then spending ages trying to decide where to stand in order to be
> invisible to someone entering from the northwest? This sort of thing is
> best reserved for Doom. But in terms of keeping track of large-scale
> movement, I think it might be worth the effort.
Nonsense!
Just because a co-ordinate system is in place, the player does not need
to be constantly made aware of the fact.
I am looking from the ne:
"You are standing in a high-walled courtyard, with a well at it's center
and a large oak tree against the left side. Through an archway in the
center of the opposite wall a long road stretches off across the fields
to the mountains in the distance."
You arrive in the nw:
"You are standing in a high-walled courtyard, with a well at it's center
and a large oak tree against the right wall. There is someone on your
side of the tree who seems to be hiding - perhaps from Mark who is
at the opposite doorway."
This would work, although I doubt it would be as specific about people
who are not hiding. It would probably say "Mark who is also present."
as only if you were hiding would your exact location be known.
If Bernard was also in the room, it would say "perhaps from Bernard or
Mark who are both present." if he could not see him either, or
just tag "Bernard is also here" at the end if he could. It depends how
detailed you want to get.
You could hide by saying 'Hide from ne behind tree' where either 'from ne'
or 'behind tree' (or even both) could be ommitted, depending perhaps
on a hiding skill - the computer would pick the best spot matching your
specifications. (Or you could 'hide from Mark' or whatever).
However whilst this would make for a great load of possibilities
as a player, it would be a coders nightmare ;).
On your point about mapping - now why hadn't I thought of such an
elementary problem. (different sized locations).
I guess if exact mapping doesn't matter to you, then nor will this.
I will give it some thought.
--
(Message of the day: It's Monday).
___ ,';_,-,__
Writing is just backwards reading. /~_ ,',' |O|,:,\,
Reading is just clever seeing. / /,',' /--|_|-;:;|
Seeing is believing. ( )',_) ) ):;)
To write, you must believe... >\,(__ / /:;;|
:...Mark...//~ /:;:;:\
Nicolas Bryant
Well, no, that still doesn't really work. What you've done effectively
here is simply to add a few more sub-locations. Consider a rock out-crop
which (viewed from above) looks like a horse-shoe. By standing against
the centre of it you are shielded from more than one direction. And a
player might choose to hide in a place where he is shielded not just from
someone coming in from a particular exit, but from someone who has walked
from the north exit to a rose bush and is currently searching it.
What is much worse is to consider a room which contains not one tree but
several. In a real life situation like this, a careful choice of hiding
place means that each tree shields you from a different direction. But can
you imagine the player typing "hide ne of tree 1, se of tree 2, w of tree
3..." ? All you've really done is to introduce an extra location within
the existing one, "hiding behind the tree," with a variable set to
indicate which side of it you're on. If you truly want to extend the
"within-the-room" coordinate system to its realistic limits, you have to
allow the player to occupy a point in a continuous two-dimensional space,
rather than one of a set of discrete points. If you don't believe me, then
think about a player who wants to follow a complex curved route that will
allow him to look at all possible sides of three different trees while
staying out of sword-range of anyone who might be hiding behind them.
Now don't get me wrong, this sort of coding is a very good idea, and if
and when I ever run a MUD of my own, you can be sure it will allow people
to hide in crevices and in the branches of trees, such that they can see
what's going on outside or below but cannot be seen unless someone
searches the crevice or the branches. But this isn't going to introduce
complete 2-D spaces, and I don't think anything non-graphical really can.
Besides which, it's a heck of a sight easier for a player trying to map a
new area if he is told "there's an exit to the north" rather than
"there's an exit to your right." You have to take playability into
account here.
>However whilst this would make for a great load of possibilities
>as a player, it would be a coders nightmare ;).
Correct. :-) Trying to work out whether a player hidden on the nw side of
tree 1 can see a player on the se side of tree 3... Yuck.
>On your point about mapping - now why hadn't I thought of such an
>elementary problem. (different sized locations).
And different distances between locations, which comes to much the same
thing. Actually, if you started out by insisting that the whole MUD is
going to exist on a cartesian grid it wouldn't be too tough, especially if
you work out a large world plan at the outset, listing the main
geographical features, and then demand that all coders work within it. The
main problem is that you don't always know where a location is going to
have to be when you start coding it. You might start off at one end of a
road, and then code a string of locations to the north of it that don't
actually link until you get to the other end of the road. It's only once
you know how many rooms lie between one end of the existing road and the
other that you can assign coordinates to any of them.
But on top of this you have to worry about magical portals which can
transport you to a totally different geographical area. You'd have to be
very careful about a direction-finding spell that identified a monster as
lying to the east if, by stepping east, you went through a portal and
ended up in the arctic wastes. And remember Uglagrok's mirror maze? If you
are too young to have seen it, it's a simple square grid of 25 rooms (I
think) but within every other room the directions are switched round. So
if a player moves east and then east again, he ends up where he started,
but if he moves east then west he has moved two rooms east of his starting
position. Not too tricky once you get the hang of it, but it would play
mery hell with a cartesian system if you had to switch the rules from
room to room.
>I guess if exact mapping doesn't matter to you, then nor will this.
>I will give it some thought.
Well, if mapping *isn't* going to be exact, why have it? If the
calculation as to whether a distant mountain approximately to the north is
east or west of due north isn't going to be reliably accurate, why make
it?
Brandon Van every
>>I am looking from the ne:
>>
>>"You are standing in a high-walled courtyard, with a well at it's center
>>and a large oak tree against the left side. Through an archway in the
>>center of the opposite wall a long road stretches off across the fields
>>to the mountains in the distance."
>>
>>You arrive in the nw:
You are setting yourself up for some horrendous parsing problems here.
To do this in a generaly way, do you have any idea how much 3d
collision detection code you'd have to implement to come up with the
deduction that the large oak tree is "against the left side" of the
well? The problem you are posing is harder than rendering the whole
thing with 3d graphics in the first place. 3d graphics doesn't have
to make deductions about the relative positions of individual objects
- you just drop everything into your z-buffer (or whatever your
algorithm of choice is) and out it spews.
Moreover, how is the computer going to decide which spatial
relationships to emphasize, and which to leave out? Why wouldn't the
computer simply give an exhaustive, boring, terribly hard-to-read list
of all the spatial relationships between all objects in the area? If
you say "with a visibility algorithm," then once again, you might as
well just implement a genuine 3d mud.
Finally, with such a spatial system you would totally destroy the
artistic poetry of description that so many people work so hard on.
Everything becomes a cut-and-splice insertion of "spatially accurate
detail," instead of a compelling literary experience.
If you want 3d, do it right and implement a 3d MUD.
Cheers,
Brandon
--
Brandon J. Van Every | Computer Graphics | The sun attempts
| | to be white,
vane...@rbdc.rbdc.com | C++ UNIX X11 Motif | as white as
http://rbdc.rbdc.com/~vanevery | HTML CGI Perl TCL/Tk | daytime.
Jon Briggs
>
>I know some people have tried working out entirely coordinate-based
>paradigms... which would have their own benefits and drawbacks as far as what
>goals can be accomplished (and how efficiently they can be performed). Has
>anybody else given this subject any thought? Anybody have ideas for a new
>paradigm? Or perhaps a different blending of existing systems? Anybody even
>interested in this kind of discussion?
>--
>Mathue Moyer (aka Gollux @ Perilous Realms MUD)
>Email: mat...@ucsd.edu URL: http://icse1.ucsd.edu/~mmoyer (under construction)
>"Never underestimate the bandwidth of a station wagon full of magnetic tapes
> hurtling down the freeway."
I'm very interested in this. I started thinking about it, because I
really _hate_ non-Euclidean areas in MU*'s, so I wanted a paradigm
that would describe space realisticly (sp?).
I found a nice method of describing area in an article I read in
"The C/C++ Users Journal" (useful magazine, IMHO). This method used
"quadcodes". The way quadcodes work is like this:
+--------+--------+
| | |
| 00 | 01 |
| | |
+--------+--------+
| | |
| 10 | 11 |
| | |
+--------+--------+
An area is divided into four quadrants, and then each quadrant can be
divided into four more quadrents, down to as much detail as you like.
For example, if you're referring to 00, that's the top left corner.
If you refer to 0011, that's the lower right corner of the top left corner.
(I put the most significant quadcode first)
A really nice feature of this method is that it is easy to locate what
area you are in from a coordinate. If "Joe" is located at 5,2:
5 = 101 (binary) 2 = 10 (binary)
Quadcode that Joe is located in = 011001
Starting from the LSB, just take the first X bit, then the first Y bit, then
the next X bit, etc...
(If you'd like more detail, or the article reference, email me)
What I did with them was to expand the idea and use "octcodes", using
octants rather than quadrants, so that I could represent 3D space.
Each room has a octcode, which defines both its location and area.
Each object has 3 coordinates. I use a one meter minimum resolution,
32 bit coordinates, and 96 bit octcodes. Each octcode also has an
integer that defines how many octs are significant.
So that is a meter on the small end of the scale, and 4 million
kilometers on the large end (which is plenty to define an entire
planet)
Then an "area" has a sorted array of structures which look
like (rough sketch):
struct
unsigned long oct[3];
Room* room;
int long sigocts;
Then to find the appropriate room, I construct an octcode from the
location coordinates and search for the octcode that matches best.
I also have objects that are also areas. They place themselves in
another list/array in their parent area when they are created, and that
array is checked when moving objects, so the moved objects can be
inserted into the object/areas. So I create a world object, which
exists in the global "space". Maybe later I'll make the global space
bigger and have several world objects and a "star" object and do a
gravity simulation. (That would be _so_ cool)
Have fun!
+----------------------------------------------------------------------+
| Jonathan Briggs <Caution! This sig under construction!>|
| email: jbr...@ball.com <Lazarus Long / Heinlein quote here> |
| <standard disclaimer here> |
+----------------------------------------------------------------------+
Mikolaj Habryn
>In article <807207...@mabsy.demon.co.uk>,
>Mark Clements <Ma...@mabsy.demon.co.uk> wrote:
>>In article <3viuan$k...@gwen.ibmpcug.co.uk>
>> nic...@ibmPCUG.CO.UK "Nicolas Bryant" writes:
>>
>>You could hide by saying 'Hide from ne behind tree' where either 'from ne'
>>or 'behind tree' (or even both) could be ommitted, depending perhaps
>>on a hiding skill - the computer would pick the best spot matching your
>>specifications. (Or you could 'hide from Mark' or whatever).
>Well, no, that still doesn't really work. What you've done effectively
>here is simply to add a few more sub-locations. Consider a rock out-crop
>which (viewed from above) looks like a horse-shoe. By standing against
>the centre of it you are shielded from more than one direction. And a
>player might choose to hide in a place where he is shielded not just from
>someone coming in from a particular exit, but from someone who has walked
>from the north exit to a rose bush and is currently searching it.
Hmm. I may be missing the point here... but it seems to me that you're
asking a great deal of the user parser needlessly. For example, the idea
of 'hiding', IMHO, shouldn't really be a parser concept. (nb, i'm
assuming a co-ordinate system a la angband here, so you can manually
walk into the center of said horseshoe, and type 'hide' or 'crouch' or
whatever. Optimally, when someone looks in your direction, then all
variables would be automatically considered - how you position yourself
wrt terrain etc. *shrug* just an idea :) I don't really believe it would
be possible to make a discrete location type of thing flexible enough...
then again, i'm probably wrong.
>indicate which side of it you're on. If you truly want to extend the
>"within-the-room" coordinate system to its realistic limits, you have to
>allow the player to occupy a point in a continuous two-dimensional space,
>rather than one of a set of discrete points. If you don't believe me, then
>think about a player who wants to follow a complex curved route that will
>allow him to look at all possible sides of three different trees while
>staying out of sword-range of anyone who might be hiding behind them.
Er, yes. Commands of that complexity will probably be non-trivial to
implement in any coordinate system. However - i tend to object to the
idea (if i've understood it correctly) of having a separate 'hiding'
concept that translates directly into something that affects your and
your environment's physical attributes. Um. That didn't make a great
deal of sense. Basically, i'd prefer to see 'hiding' be a natural
consequence of simpler operations. ie, if someone is standing behind a
tree, then they are 'hidden' to some extent regardless of whether or not
they intend to be. Once again, this is assuming some form of continuous
n-space that you can move within relatively fluidly. ie, doom as opposed
to dungeon master.
>Now don't get me wrong, this sort of coding is a very good idea, and if
>and when I ever run a MUD of my own, you can be sure it will allow people
>to hide in crevices and in the branches of trees, such that they can see
>what's going on outside or below but cannot be seen unless someone
>searches the crevice or the branches. But this isn't going to introduce
>complete 2-D spaces, and I don't think anything non-graphical really can.
>Besides which, it's a heck of a sight easier for a player trying to map a
>new area if he is told "there's an exit to the north" rather than
>"there's an exit to your right." You have to take playability into
>account here.
Well - 'graphical' covers a great deal of turf. I'm currently (and
temporarily) aiming for a system which is completely 2-d mapped - and
have an angband-like display, at least. However, the parser will be able
to (hopefully) grok commands like 'go to library', and, provided you know
where said library is, it will take you there. This, needless to say,
has it's own problems. The idea is to allow one to completely ignore
movement along the lines of 'walk ten paces north' until it's utterly
necessary. In fact, provided one doesn't enjoy plotting complex ambushes
on innocent passerby, it would hopefully be completely unnecessary to
use the map at all.
>>However whilst this would make for a great load of possibilities
>>as a player, it would be a coders nightmare ;).
>Correct. :-) Trying to work out whether a player hidden on the nw side of
>tree 1 can see a player on the se side of tree 3... Yuck.
Hmm. Perhaps :) But it's an interesting challenge, no?
>lying to the east if, by stepping east, you went through a portal and
>ended up in the arctic wastes. And remember Uglagrok's mirror maze? If you
>are too young to have seen it, it's a simple square grid of 25 rooms (I
>think) but within every other room the directions are switched round. So
>if a player moves east and then east again, he ends up where he started,
>but if he moves east then west he has moved two rooms east of his starting
>position. Not too tricky once you get the hang of it, but it would play
>mery hell with a cartesian system if you had to switch the rules from
>room to room.
Ah. And this is precisely why i wrote '(temporarily)' above. The
system i've described so far does lock one into a 2-d euclidean world.
Erm - i've had some fever dreams of relative coordinate systems.
Currently, these are certifiably vaporous. However... the benefits of
such a thing (or perhaps the definition of it) would be interesting...
Provided one leaves the cardinal directions available for movement, one
could wreak merry hell with a player's direction sense at the poles of a
spherical world, for example.
But the real wishitem for me is this: if it is possible to define a
sufficiently abstract co-ordinate system, then it's representation is
removed completely into the user interface level. ie - you can do it in
text, ray-traced graphics, or html 3.0 code just by altering the display
routines, as opposed to rewriting all of your mapping code. *shrug* then
again - maybe i had a beer or two too many...
* * Mikolaj J. Habryn
dic...@tartarus.uwa.edu.au
* "The truth is out there"
PGP Public key available by finger
* #include <standard-disclaimer.h>
Travis S Casey
this thread so far have been either very complicated to
implement or (IMHO) unduly limit the types of areas that
can be created. (e.g., not allowing non-Euclidean areas).
Personally, I'm not searching for a perfect way to represent
space in muds... just a better one. With that in mind,
here's an idea I had today:
Instead of basing the mud on rooms, use areas instead. In
the muds I've been on, each space a character enters is a
room. In these rooms, one cannot see into adjacent areas
except by using commands that are specifically for this;
that is, simply doing "look" only shows you the contents
of the room you're currently in; you have to "peer
<direction>" or something like that to see into other
rooms.
Instead of this, why not have areas designed so that when
a player "look"s, he/she also gets information about adjacent
areas, unless the builder of the area has set it up otherwise?
For example, imagine representing an L-shaped room on a mud:
+-----+
| A | ^
| | / \
|.....+----+ | N
| . | |
| B . C |
+----------+
On a typical room-based mud, this would need to be implemented
as two or three rooms to be done properly; either the A, B, and
C sections would each need to be a room, or AB could be a room
and C another, or BC a room and A another.
In any case, someone who's character was in the B section of
the room would need to use "peer" or some other such command
to see into either A or B or both.
With the area method I'm thinking of, someone in B would
get a description of the things in B, plus "to the north you
see..." for the things in A and "to the east you see..."
for the things in C. Someone standing in C would also see
things in B, and someone in A would as well.
Now, this would require a good deal of extra processing on the
mud's part, since it might have to describe up to ten rooms
besides the one the player is in (the eight "standard" directions
plus up and down), and for those muds that load on demand, extra
rooms would wind up being loaded. However, I think it would improve
the feel of really being there... other opinions?
Oh... as I said before, the builder could choose to have one or
more directions not be automatically seen into; this could be used
to help simulate fog and other conditions of poor visibility.
Alternately, seeing into other areas could be made optional, and
the standard setting could be to not see into them automatically.
I can't think of any really good reasons to prefer one over the
other, though.... anyone else?
Scott G Cowell
Each room has a octcode, which defines both its location and area.
Each object has 3 coordinates. I use a one meter minimum resolution,
32 bit coordinates, and 96 bit octcodes. Each octcode also has an
integer that defines how many octs are significant.
The quad/oct-code system you describe is very interesting, but I'm at a bit
of a loss after reading over this a few times as to how you are gaining
anything over just storing the 3 coordinates as is? You lose no granularity
on the scale, and you'd save yourself the conversions. Do these octcodes
simplify performing certain actions related to coordinate systems?
Then to find the appropriate room, I construct an octcode from the
location coordinates and search for the octcode that matches best.
Do you have this area representation sorted to take advantage of the octcode
in searching? I would guess this is the main use of the codes...
-sc
Martian
++It seems to me that most of the ideas that have come up in
++this thread so far have been either very complicated to
++implement or (IMHO) unduly limit the types of areas that
++can be created. (e.g., not allowing non-Euclidean areas).
++Personally, I'm not searching for a perfect way to represent
++space in muds... just a better one. With that in mind,
++here's an idea I had today:
++Instead of basing the mud on rooms, use areas instead. In
++the muds I've been on, each space a character enters is a
++room. In these rooms, one cannot see into adjacent areas
++except by using commands that are specifically for this;
++that is, simply doing "look" only shows you the contents
++of the room you're currently in; you have to "peer
++<direction>" or something like that to see into other
++rooms.
++Instead of this, why not have areas designed so that when
++a player "look"s, he/she also gets information about adjacent
++areas, unless the builder of the area has set it up otherwise?
++For example, imagine representing an L-shaped room on a mud:
++ +-----+
++ | A | ^
++ | | / \
++ |.....+----+ | N
++ | . | |
++ | B . C |
++ +----------+
++On a typical room-based mud, this would need to be implemented
++as two or three rooms to be done properly; either the A, B, and
++C sections would each need to be a room, or AB could be a room
++and C another, or BC a room and A another.
++In any case, someone who's character was in the B section of
++the room would need to use "peer" or some other such command
++to see into either A or B or both.
++With the area method I'm thinking of, someone in B would
++get a description of the things in B, plus "to the north you
++see..." for the things in A and "to the east you see..."
++for the things in C. Someone standing in C would also see
++things in B, and someone in A would as well.
++Now, this would require a good deal of extra processing on the
++mud's part, since it might have to describe up to ten rooms
++besides the one the player is in (the eight "standard" directions
++plus up and down), and for those muds that load on demand, extra
++rooms would wind up being loaded. However, I think it would improve
++the feel of really being there... other opinions?
++Oh... as I said before, the builder could choose to have one or
++more directions not be automatically seen into; this could be used
++to help simulate fog and other conditions of poor visibility.
++Alternately, seeing into other areas could be made optional, and
++the standard setting could be to not see into them automatically.
++I can't think of any really good reasons to prefer one over the
++other, though.... anyone else?
I do not think it is necessary to do so. There is nothing wrong with
describing an L-shaped room, so you can use ABC as one room. Sure, you
could argue that if you stand in the A part you cannot see what is in
the C part, but you have that same problem if you make AB one room and
do some (automatic) peering into C.
If you want to go for `realistic', forget it. Usually rooms describe
everything in the room, not only the direction I am facing. If I look
north, I can't seen the painting on the south wall. Noone makes a
problem of that. Being in a room should imply roaming around in it,
just as you don't have to do a command to cross a room if you enter
from the west, and leave to the east.
Note also that often seeing what is in an "adjacent" is not obvious.
Indoor rooms are usually separated by walls and a door, so a special
peer command is not unrealistic. Outside rooms are different, but even
then the suggested "distance" is often large enough that not beeing
able to see what is in the next room is not unrealistic.
For a long time, I have been tossing with a different concept of
rooms. Areas like forests or a desert should be one room, with
different sublocations. A player can see the objects in the same
sublocation as the player is, and some of the objects on the
sublocations around him/her. Which ones would depend how far the
player can see (tall persons can see further, some races might have
better eyesight), and how large the other objects are. A tower can be
seen from much further distance than a mouse. The problem is how to do
that efficiently. A desert can easily have 100 x 200 sublocations,
with hundreds of objects scattered in it. Checking all of them doesn't
sound like a good idea. Using some kind of partition tree would find
the visible objects in n^gamma(d) + k time, for some gamma(d)
0.5 < gamma(d) < 1 (n number of objects in room, d the dimension of
the room (usually 2 sometimes 3), k the number of visible objects),
but I'm afraid the constant overhead will be too much. Perhaps some
kind of k-d tree and using a manhatten geometry for the players range
of view would give acceptable times.
The reason for all this problems is of course that a discrete space is
a very poor approximation of a continuous space. Anyone ever looked
into using continuous movement in muds for longer than the 15 minutes
than I did?
Abigail
Peter Stewart
[snip]
: Instead of basing the mud on rooms, use areas instead. In
: the muds I've been on, each space a character enters is a
: room. In these rooms, one cannot see into adjacent areas
: except by using commands that are specifically for this;
: that is, simply doing "look" only shows you the contents
: of the room you're currently in; you have to "peer
: <direction>" or something like that to see into other
: rooms.
: Instead of this, why not have areas designed so that when
: a player "look"s, he/she also gets information about adjacent
: areas, unless the builder of the area has set it up otherwise?
: For example, imagine representing an L-shaped room on a mud:
: +-----+
: | A | ^
: | | / \
: |.....+----+ | N
: | . | |
: | B . C |
: +----------+
[snip]
: With the area method I'm thinking of, someone in B would
: get a description of the things in B, plus "to the north you
: see..." for the things in A and "to the east you see..."
: for the things in C. Someone standing in C would also see
: things in B, and someone in A would as well.
You can already do this sort of thing on TinyMUSH. Simply set up three rooms
and link them with exits that are both transparent (so you can peer through
them and see things in that other room) and audible (so you can hear people
talking in that other part of the area, if the area is such that you could
ICly hear someone over there). I don't believe it would be desirable to
get the description of all three parts of the area at once as you suggested.
If the builder has a vivid imagination, you're likely to have long, detailed
descriptions. Getting spammed by three of them at once is a little too much
to handle, even for someone with a client, IMHO :)
Granted, there are some limitations to this. For instance, with a three-room
setup, poses from A would not be relayed to room C (though this could be
solved in a manner similar to what you mentioned in some text that I snipped,
combining A & B into one room, or B & C. The only thing that you would not
be able to do is peer through an exit and look at an object on the other
side to get its description. However, if you really needed this functionality,
it could always be hacked into the server code.
P'tran@PernMUSH
-------------------------------------------------------------------------------
Pete Stewart | "Violence is the last refuge of the incompetent"
ste...@bae.bellcore.com | - Salvor Hardin
-------------------------------------------------------------------------------
Scott G Cowell
It seems to me that most of the ideas that have come up in
this thread so far have been either very complicated to
implement or (IMHO) unduly limit the types of areas that
can be created. (e.g., not allowing non-Euclidean areas).
You could design a coordinate system that allowed non-Euclidean areas,
I suppose, but that would mean using non-Euclidean geometry. The point
being that more complex spatial representations depend much more heavily
on the underlying geometry.
Instead of basing the mud on rooms, use areas instead.
Yes but you must still consider how the concept of an area is represented.
How do you know room A is in a specific area? Where is room A in this
area? How much space does room A take up in this area? Does it even
make a difference how exact the measurement of space/size is?
Underneath the concepts you present, you need a mechanism to answer
these questions. The best concepts of areas I've been able to come
up with use coordinate systems mapped onto the abstract idea of an
'area', and rooms are then just objects (of any shape corresponding
to grid lines) placed in the area. This way, just as long as you
associate some display mechanism with unoccupied spaces in an area
(descriptions for example) you dont necessarily need the requirement
that room A be explicitly linked to room B. This eliminates the
need for one of my biggest pet-peeves: so-called 'connection' rooms,
the long, dreary roads, the endless deserts, the dull forests, etc.
If there is no point of interest to a player, there is no need for
the more complex notion of a room.
-sc
Mark Clements
nic...@ibmPCUG.CO.UK "Nicolas Bryant" writes:
[see a previous post for context]
> Well, no, that still doesn't really work. What you've done effectively
> here is simply to add a few more sub-locations. Consider a rock out-crop
> which (viewed from above) looks like a horse-shoe. By standing against
> the centre of it you are shielded from more than one direction. And a
> player might choose to hide in a place where he is shielded not just from
> someone coming in from a particular exit, but from someone who has walked
> from the north exit to a rose bush and is currently searching it.
If that player was called 'Trevor' you could 'Hide from trevor' which
would move your player automatically to hide from that person as best
you can (accoring to a skill?). I have also done more than add a few
sub-locations. You are located in 2D space - the server calculates
whether you can be seen - it is not defined simply by a flag (as you
later stated).
As for "hide ne of tree 1, se of tree 2, w of tree 3..." this is up to
the programmer. If they make the parser good enough to understand this,
and code a system to work out where they mean, then good luck to them.
> >However whilst this would make for a great load of possibilities
> >as a player, it would be a coders nightmare ;).
>
> Correct. :-) Trying to work out whether a player hidden on the nw side of
> tree 1 can see a player on the se side of tree 3... Yuck.
At the moment I am putting forward ideas, and am not really trying
to think of methods to solve them (code). I'll worry about that later.
I always find it very restricting to dismiss ideas because they
are difficult to code, as you tend not to end up with the best game.
I try to work out exactly what I want and then see if I can code it,
and drop things that are too difficult. The advantage of doing
it at this stage, is that you know what other features rely on the one
you are dismissing, thus you know it's true importance.
> But on top of this you have to worry about magical portals which can
> transport you to a totally different geographical area. You'd have to be
> very careful about a direction-finding spell that identified a monster as
> lying to the east if, by stepping east, you went through a portal and
> ended up in the arctic wastes.
I don't see a problem. If the arctic wastes are east, they are east,
if they are north, the spell will say north and so on. The portal just
changed the co-ordinates of the player.
> And remember Uglagrok's mirror maze? If you
> are too young to have seen it, it's a simple square grid of 25 rooms (I
> think) but within every other room the directions are switched round. So
> if a player moves east and then east again, he ends up where he started,
> but if he moves east then west he has moved two rooms east of his starting
> position. Not too tricky once you get the hang of it, but it would play
> mery hell with a cartesian system if you had to switch the rules from
> room to room.
Using a system similar to the LP system to add verbs, this wouldn't be too
hard. The standard movement commands (left, right etc.) will be defined in
the player object. However verbs not declared as 'vital' will be
overidden by occurences outside of the player file. Therefore placing
a mirror with the code for 'left' moving the player 5 instead of -5 units
on the x axis would sort out the problem.
> >I guess if exact mapping doesn't matter to you, then nor will this.
> >I will give it some thought.
>
> Well, if mapping *isn't* going to be exact, why have it? If the
> calculation as to whether a distant mountain approximately to the north is
> east or west of due north isn't going to be reliably accurate, why make
> it?
>
What I meant by this, was that say for example you are in a town,
there are all sorts of shops and things. At the moment one move generally
takes you from an area with a shop on two opposite sides, and a road
through the other two, to the next set of shops (a similarly laid out room).
However if you are in a desert (which is not a fighting area) you will
generally either have two or three rooms representing the entire desert,
or spend an eternity trekking through nothing. As the first system is
already used (so for example the town is larger than the desert, when it
should be the other way round) there is no harm in using it in a proper
2D landscape. i.e. one movement could move you 5 units, whilst another
moves you 20. This could be calculated by each static object having a
flag indicating whether it causes the player to stop if they move past it.
However I would intend it to be more realistic (and thus more complicated)
than this.
All directions would be relative - left, right etc. as opposed to the usual
compass directions (unless you have some sort of pointing device: compass/
lodestone/whatever) as this is how we see the world anyway. Thus if
you approach a room from two opposite angles, objects would change from
left to right.
The distance moved might be based on how tired you are, so you may move
fewer units if you are weak. This system would need objects to have a
stop_player flag. My original system had each room as a 10*10 grid,
where most things that needed no spatial co-ordination resided in the
bottom/left corner, and the rest was used only for certain special objects
and for fighting, but that system is a little limiting (although it could
be used)
>
> Nick Bryant
> --
> ******************************************************************************
> * "I am Pentium of Borg. Division is futile. | nic...@ibmpcug.co.uk *
> * Accuracy is irrelevant. You will be approximated." | n...@st-and.ac.uk *
> ******************************************************************************
>
--
Mark Clements
vane...@rbdc.rbdc.com "Brandon Van every" writes:
> >In article <807207...@mabsy.demon.co.uk>,
> >Mark Clements <Ma...@mabsy.demon.co.uk> wrote:
>
> >>I am looking from the ne:
> >>
> >>"You are standing in a high-walled courtyard, with a well at it's center
> >>and a large oak tree against the left side. Through an archway in the
> >>center of the opposite wall a long road stretches off across the fields
> >>to the mountains in the distance."
> >>
> >>You arrive in the nw:
>
> You are setting yourself up for some horrendous parsing problems here.
> To do this in a generaly way, do you have any idea how much 3d
> collision detection code you'd have to implement to come up with the
> deduction that the large oak tree is "against the left side" of the
> well? The problem you are posing is harder than rendering the whole
> thing with 3d graphics in the first place. 3d graphics doesn't have
> to make deductions about the relative positions of individual objects
> - you just drop everything into your z-buffer (or whatever your
> algorithm of choice is) and out it spews.
>
> Moreover, how is the computer going to decide which spatial
> relationships to emphasize, and which to leave out? Why wouldn't the
> computer simply give an exhaustive, boring, terribly hard-to-read list
> of all the spatial relationships between all objects in the area? If
> you say "with a visibility algorithm," then once again, you might as
> well just implement a genuine 3d mud.
You will not be told the spatial relationships of each object in the
room. (a 'relate x to y' command if necessary - but you won't be told
as a matter of course). Basically each object in range (depending on
size, terrain type, weather conditions etc. will be mentioned in the
description, as they are now (see below for exceptions). Each object
will have an 'importance' variable (e.g. 0-10 with higher being more
important). Working through these objects from 10-0, they will be added
to the description either in the form 'they are present' or the form
'is positioned relative to another object'. This second type would
mean the object may be shown as 'next to' or 'behind' (or whatever) an
object that has already been mentioned.
> Finally, with such a spatial system you would totally destroy the
> artistic poetry of description that so many people work so hard on.
> Everything becomes a cut-and-splice insertion of "spatially accurate
> detail," instead of a compelling literary experience.
This is very important, which is why the look function will be so
complicated. In fact a default look function should probably be built
into the server.
This will admittedly be tricky, but not impossible. There are muds around
already which avoid the common, but not 'artistic' list of objects/players
present (e.g. Avalon) where they are linked into the text.
Basically each object may have a description function which either returns
a more poetic description of itself or a (null) to indicate that
the server must add it's description (which will also happen if the function
is not present). It will be called with an argument indicating whether
it is the beginning, middle or end of a sentence. Thus there can be as
many descs. as wanted, and these can be as varied as desired, using a random
number to pick a description.
But can this be done quickly? ;)
--
(By the way - If you haven't done so already, this would be an ideal time
to stop reading this post).
Donald Magee
Mark Clements <Ma...@mabsy.demon.co.uk> wrote:
>> Well, no, that still doesn't really work. What you've done effectively
>> here is simply to add a few more sub-locations. Consider a rock out-crop
>> which (viewed from above) looks like a horse-shoe. By standing against
>> the centre of it you are shielded from more than one direction. And a
>> player might choose to hide in a place where he is shielded not just from
>> someone coming in from a particular exit, but from someone who has walked
>> from the north exit to a rose bush and is currently searching it.
>
>If that player was called 'Trevor' you could 'Hide from trevor' which
>would move your player automatically to hide from that person as best
>you can (accoring to a skill?). I have also done more than add a few
>sub-locations. You are located in 2D space - the server calculates
>whether you can be seen - it is not defined simply by a flag (as you
>later stated).
>As for "hide ne of tree 1, se of tree 2, w of tree 3..." this is up to
>the programmer. If they make the parser good enough to understand this,
>and code a system to work out where they mean, then good luck to them.
consider if you will (*voice of Rod Serling in background*)...
If the screen presented to the user was curses based with subwindows
including a small map of the location ala Ultima. Allow the character
to type go north (or n) and the character's ascii representation would
remain in the middle of the window, but the terrain surrounding it
would scroll down within the window until stop, rest, sit, or they
walking into something (-1hp). Type run north, and the character
moves at twice speed, flee 3 times, etc., all with appropriate
decrement of mv. Provide a nethackish window which would allow the
leader to really lead or tell a ranger to scout ahead of the party in
the wilderness. I envision two windows, the first a higher level view
which could convey (via color & ascii characters perhaps) the terrain.
Green reverse video space for plains, blue reverse video space for
water, green reverse video '.' for small stones, on a plain, '*' for a
large boulders which would block your view or some such convention.
Utilize the information at this level to define what a given player
can see. Use a second window to give a micro view, say 9x9 of the
character and those in the immediate area, and map their ascii
representation to a list which changes as needed. Allow a user to
only pickup objects which he is on or immediately next to, and use
ranged weapons according to their range.
If the terrain is brown rev video space (ok, ugly), the area would be
dry grass (or similar). A mage casting a fireball could set a
wildfire (turn the brown rev red) and would have to be sure his
compatriots could escape safely. Mob animals would try to flee the
fire areas. A circle of fire could be done by carefully dropping
sufficient water on each square of concentric circles and then
lighting a square between the two. The party could trap something or
perhaps isolate themselves for safety from animals in a nasty
wilderness area. Maybe build in a circle macro to walk in a circle of
varied diameter and do an action, "circle 10 pour water ground".
I would not do away with the text interface, but add this to give to a
feeling to terrain and more tactics, rather than the typical enter
room, try to slay *whatever*, flee, heal, return. Roll a boulder down
hill, set fire to the country lands. Cast 'control weather' to put
out fires raging in the farmland (a mob farmer could set a bit in a
terrain map to determine if the land is being tended to improve
production - kill the farmer and the wheat grows poorly, and no one
brings it to market, etc.)
I ported and expanded a multiplayer space war game I wrote in college
(85-88) "mpsw" to UNIX to include a routine which disallows viewing
through certain objects. If you want to know what is behind that
space cloud, you either have to go through or around to see. A player
at a different angle sees different things and may or may not have a
better position - which is really nice for team play. Are nasty PCs or
NPCs chasing you, hide in a dense forest by running into it and then
changing direction. The pursuers couldn't see beyond 2 squares and
would have to use other skills to find you. (hearing, track skill,
seeing eye)
The leader should enter the room first and see things first, the
person entering the doorway first just gets hit first, and does not
get to yell to #6 in line, "Run, ancient red!". Hearing should be
invaluable to players in a vision impaired area (due to either light
to vision blocking objects). Let that (elf - whatever) hear the
whirling vortex even though it is not in sight yet, "to elf: You hear
the wind to the north, but it is different."
>I don't see a problem. If the arctic wastes are east, they are east
You could allow a wasteland to have recognizable contours and feature,
and be a real bear to cross, instead of just a bunch of looping rooms,
with near same descriptions.
Don Magee
d...@jolt.att.com
Mathue
++It seems to me that most of the ideas that have come up in
++this thread so far have been either very complicated to
++implement or (IMHO) unduly limit the types of areas that
++can be created. (e.g., not allowing non-Euclidean areas).
*sulk* Well shoot. Here I went, started a thread about something useful, and
missed every single response before the one that quoted this text. Hmph.
Ain't no justice. I don't suppose anybody's collecting the stuff that's being
posted about it....
Michael Sellers
: : a player "look"s, he/she also gets information about adjacent
: : areas, unless the builder of the area has set it up otherwise?
: : For example, imagine representing an L-shaped room on a mud:
: : +-----+
: : | A | ^
: : | | / \
: : |.....+----+ | N
: : | . | |
: : | B . C |
: : +----------+
: [snip]
: : With the area method I'm thinking of, someone in B would
: : get a description of the things in B, plus "to the north you
: : see..." for the things in A and "to the east you see..."
: : for the things in C. Someone standing in C would also see
: : things in B, and someone in A would as well.
Except this doesn't handle a simple situation like the following:
+-----+
| A | ^
| | / \
|--.--+----+ | N
|m . | |
| B . C |
+----------+
In a case like this, a person in A wouldn't see a monster (say) hiding
in the NW corner of B, while a person in C would. The line-of-sight
logic could be pretty cumbersome, even in a text mud.
: You can already do this sort of thing on TinyMUSH. Simply set up three rooms
: and link them with exits that are both transparent (so you can peer through
: them and see things in that other room) and audible (so you can hear people
: talking in that other part of the area, if the area is such that you could
: ICly hear someone over there). I don't believe it would be desirable to
: get the description of all three parts of the area at once as you suggested.
: If the builder has a vivid imagination, you're likely to have long, detailed
: descriptions. Getting spammed by three of them at once is a little too much
: to handle, even for someone with a client, IMHO :)
True, but you might well want a brief description giving you some idea of
what is in the next room. Further, suppose you are in a crypt of some
sort, made up of little burial rooms. Some of these rooms have monsters,
treasure, clues on the walls, etc. (not just "another little room"
descriptions). You might want to have a set of rooms lined up on their
north-south axis so that you can see, by standing in the middle of the
room and looking through the northern doors, two huge golden doors
representing your goal -- and have some idea of how many other rooms lie
between you and your goal (with no idea of the terrors to be traversed
between here and there).
This would be impossible to do on most/all mud systems without a great
deal of customer owkr by the area/room designer. (SoA, anyone?)
--
Michael Sellers Terra Nova Interactive Corp. mi...@terranova.com
(503) 538-2745 FAX (503) 538-9517 http://www.terranova.com/~sellers
Email me for info on UI Design seminars: 2-5 days, in-house or public
Travis S Casey
You seem to have missed the part where I said I'm not looking for
a perfect solution, but just a better solution. The commonly-
used room-based system doesn't handle this either, so this is
not a new disadvantage of the area-based system.
I specifically chose an area-based system to allow a gain in
realism without going through the line-of-sight logic needed in
a grid-based system.
>: You can already do this sort of thing on TinyMUSH. Simply set up three rooms
>: and link them with exits that are both transparent (so you can peer through
>: them and see things in that other room) and audible (so you can hear people
>: talking in that other part of the area, if the area is such that you could
>: ICly hear someone over there). I don't believe it would be desirable to
>: get the description of all three parts of the area at once as you suggested.
>: If the builder has a vivid imagination, you're likely to have long, detailed
>: descriptions. Getting spammed by three of them at once is a little too much
>: to handle, even for someone with a client, IMHO :)
>
>True, but you might well want a brief description giving you some idea of
>what is in the next room. Further, suppose you are in a crypt of some
>sort, made up of little burial rooms. Some of these rooms have monsters,
>treasure, clues on the walls, etc. (not just "another little room"
>descriptions). You might want to have a set of rooms lined up on their
>north-south axis so that you can see, by standing in the middle of the
>room and looking through the northern doors, two huge golden doors
>representing your goal -- and have some idea of how many other rooms lie
>between you and your goal (with no idea of the terrors to be traversed
>between here and there).
>
>This would be impossible to do on most/all mud systems without a great
>deal of customer owkr by the area/room designer. (SoA, anyone?)
Which is why we're discussing it here... so that hopefully someone
out there with the spare time to do this stuff will code it and
share it. :-)
Travis S Casey
>I do not think it is necessary to do so. There is nothing wrong with
>describing an L-shaped room, so you can use ABC as one room. Sure, you
>could argue that if you stand in the A part you cannot see what is in
>the C part, but you have that same problem if you make AB one room and
>do some (automatic) peering into C.
I think you misunderstood me... I never said anything about making
AB one room under my system; I simply stated that it was one way
it could be done under most existing systems.
>If you want to go for `realistic', forget it. Usually rooms describe
>everything in the room, not only the direction I am facing. If I look
>north, I can't seen the painting on the south wall. Noone makes a
>problem of that. Being in a room should imply roaming around in it,
>just as you don't have to do a command to cross a room if you enter
>from the west, and leave to the east.
As I said at the top, I'm not looking for a perfectly realistic
system; just one that allows me to do more than the current
"one room = one space" system used by most muds.
>Note also that often seeing what is in an "adjacent" is not obvious.
>Indoor rooms are usually separated by walls and a door, so a special
>peer command is not unrealistic. Outside rooms are different, but even
>then the suggested "distance" is often large enough that not beeing
>able to see what is in the next room is not unrealistic.
You seem not to have noticed that I said that exits could be set
up so that they worked in the "normal" way, requiring a special
peer command.
>For a long time, I have been tossing with a different concept of
>rooms. Areas like forests or a desert should be one room, with
>different sublocations. A player can see the objects in the same
>sublocation as the player is, and some of the objects on the
>sublocations around him/her. Which ones would depend how far the
>player can see (tall persons can see further, some races might have
>better eyesight), and how large the other objects are. A tower can be
>seen from much further distance than a mouse. The problem is how to do
>that efficiently. A desert can easily have 100 x 200 sublocations,
>with hundreds of objects scattered in it. Checking all of them doesn't
>sound like a good idea. Using some kind of partition tree would find
>the visible objects in n^gamma(d) + k time, for some gamma(d)
>0.5 < gamma(d) < 1 (n number of objects in room, d the dimension of
>the room (usually 2 sometimes 3), k the number of visible objects),
>but I'm afraid the constant overhead will be too much. Perhaps some
>kind of k-d tree and using a manhatten geometry for the players range
>of view would give acceptable times.
This is basically the same thing that I'm suggesting; allowing rooms
to be carved up into areas. The only difference is your suggestion
that different objects could be seen at different distances. The
main reason that I went with only the adjacent rooms is that this
minimizes the number of sublocations that need to be checked.
>The reason for all this problems is of course that a discrete space is
>a very poor approximation of a continuous space. Anyone ever looked
>into using continuous movement in muds for longer than the 15 minutes
>than I did?
Hmm... I don't think it's possible to set up a *truly* continuous
movement system; you need to have some way to tell where players
are, and that implies a coordinate system. Since numbers cannot
be specified to infinite precision on a computer, the system must
be discrete, even if it locates things to the millimeter. The
question that needs to be asked, IMHO, is "How fine-grained do
I want movement to be?"
ro...@jpd.ch.man.ac.uk
: Michael Sellers <sel...@teleport.com> wrote:
: >Peter Stewart (ste...@bae.bellcore.com) wrote:
: >: Travis Casey (ca...@cs.fsu.edu) wrote:
: >
: >: : +-----+
: >: : | A | ^
: >: : | | / \
: >: : |.....+----+ | N
: >: : | . | |
: >: : | B . C |
: >: : +----------+
: >: [snip]
: >: : get a description of the things in B, plus "to the north you
: >: : see..." for the things in A and "to the east you see..."
: >: : for the things in C. Someone standing in C would also see
: >: : things in B, and someone in A would as well.
: >
: >Except this doesn't handle a simple situation like the following:
: >
: > +-----+
: > | A | ^
: > | | / \
: > |--.--+----+ | N
: > |m . | |
: > | B . C |
: > +----------+
: >
: >In a case like this, a person in A wouldn't see a monster (say) hiding
: >in the NW corner of B, while a person in C would. The line-of-sight
: >logic could be pretty cumbersome, even in a text mud.
: You seem to have missed the part where I said I'm not looking for
: a perfect solution, but just a better solution. The commonly-
: used room-based system doesn't handle this either, so this is
: not a new disadvantage of the area-based system.
: I specifically chose an area-based system to allow a gain in
: realism without going through the line-of-sight logic needed in
: a grid-based system.
It's possible to code some v. efficient LOS algorithms on text-based
mu*s. Naturally, efficiency is going to be inversely proportional to
quality, but you can't get round that. The more complex the algorithm,
the slower it'll be.
The optimum for LOS, then, is something that'll be quick to execute
and produce usable results. The algorithm I'm playing about with at
the moment is essentially lifted off Advanced Squad Leader, with a
few refinements. All rooms have a base height. For each object you
need to recurse through, add in its height. Finally, add on your
height. This gives you the height you are at. At a distance of zero,
you can only see objects level to you. At a distance of 1, you can
only see objects up to +/- one unit of height from you. And so on.
For this, you need 2 attributes on each object: Object height +
cumulative height. Then, all you do is compare
abs(cumulative height of observer - cumulative height of test obj)
against abs(rooms away).
Travis Casey
At a distance of zero, you can only see objects level to you? I
presume that you're assuming that characters are not capable of looking
up or down? Using the algorithm you describe, a six-foot tall character
would not be able to see a one-foot tall box lying at his feet.
Also, the algorithm you give only uses the height of the character and
the object he/she is trying to see; this doesn't seem to allow for one
object blocking your view of another.
I'm sure that what you said isn't what you really meant... if you
would be kind enough to take another shot at describing what you
mean, I'd be happy to listen. :-)
However, I still see many problems with a height-based algorithm; for
instance, the assumption that all objects have constant height. Such
an assumption does not allow one player to crouch down or lie down to
hide from another; it also does not allow for a 3x4x5 box, which can
be a different height depending on how it is oriented. Lastly, if you
just use heights and allow things to stack, what about hiding something
under something else? To account properly for that, you need to take
into account the lengths and widths of objects as well.
I have no doubt that a simple LOS system works for a pencil-and-paper
game; however, the reason that it works there is that the humans
playing the game are capable of coming to an agreement about what
happens when something is not covered by the rules. To do this in
a mud, you'd either have to have the code "beep" a wizard whenever
it couldn't figure something out, or have it ask the player if he/she
ought to be able to see the object in question. :-)
In a visual game, such as Doom, it's possible to implement a LOS system
simply by using object layering; things that can't be seen don't wind up
getting drawn on the screen. However, in a text-based system, the system
must do the work of figuring out what can and can't be seen, and then
write a description for the area on the fly. In addition, where Doom
only has to do LOS computations for the player and any enemies in the
immediate area, a mud would need to be able to do them for 30+ players
and all the monsters in any of their areas. I can't say for sure, not
having tried it, but I feel that such activity would slow a mud down
considerably.
Of course, an LOS system also implies many other things; as noted above,
a good LOS system needs to account for orientation of objects and for
players and monsters crouching or lying down. It also brings up several
related issues, such as facing, turning around, whether one should have
a search command or have players move about the room looking for things,
etc.
All-in-all, I have to say that I feel that a more abstract movement system
is better suited to a text-based game.
Ian Macintosh
: In article <40jh6l$6...@yama.mcc.ac.uk>, ro...@jpd.ch.man.ac.uk () wrote:
: >Travis S Casey (ca...@ioctl.cs.fsu.edu) wrote:
: >
: >and produce usable results. The algorithm I'm playing about with at
: >the moment is essentially lifted off Advanced Squad Leader, with a
: >few refinements. All rooms have a base height. For each object you
: >need to recurse through, add in its height. Finally, add on your
: >height. This gives you the height you are at. At a distance of zero,
: >you can only see objects level to you. At a distance of 1, you can
: >only see objects up to +/- one unit of height from you. And so on.
: >
: >For this, you need 2 attributes on each object: Object height +
: >cumulative height. Then, all you do is compare
: >abs(cumulative height of observer - cumulative height of test obj)
: >against abs(rooms away).
:
: At a distance of zero, you can only see objects level to you? I
: presume that you're assuming that characters are not capable of looking
: up or down? Using the algorithm you describe, a six-foot tall character
: would not be able to see a one-foot tall box lying at his feet.
:
: Also, the algorithm you give only uses the height of the character and
: the object he/she is trying to see; this doesn't seem to allow for one
: object blocking your view of another.
:
: I'm sure that what you said isn't what you really meant... if you
: would be kind enough to take another shot at describing what you
: mean, I'd be happy to listen. :-)
Heh. He's talking about the height of the room. Each room will have only
one height. If the room next to you is more than one level higher or
lower, you won't see anything in it.
ie. You are climbing a steep mountain, you can't see anything above or
below you. Not a perfect solution, but a nice idea nonetheless. Perhaps
a calculation using a gradient?
Anyway, that calc simulates you not being able to see what is on top of
the mountain when you are on the side.
: In a visual game, such as Doom, it's possible to implement a LOS system
: simply by using object layering; things that can't be seen don't wind up
: getting drawn on the screen. However, in a text-based system, the system
That's not how it really works. Remember, mobiles in Doom run through a
non-visual LOS calculation.
: must do the work of figuring out what can and can't be seen, and then
: write a description for the area on the fly. In addition, where Doom
: only has to do LOS computations for the player and any enemies in the
: immediate area, a mud would need to be able to do them for 30+ players
: and all the monsters in any of their areas. I can't say for sure, not
: having tried it, but I feel that such activity would slow a mud down
: considerably.
To a certain degree, yes. But keep in mind that Doom spends a vast
proportion of it's time doing the actual graphic work, an a rather tiny
amount doing the actual calculation.
Regards,
Ian.
Travis Casey
>: presume that you're assuming that characters are not capable of looking
>: up or down? Using the algorithm you describe, a six-foot tall character
>: would not be able to see a one-foot tall box lying at his feet.
>:
>: Also, the algorithm you give only uses the height of the character and
>: the object he/she is trying to see; this doesn't seem to allow for one
>: object blocking your view of another.
>:
>: I'm sure that what you said isn't what you really meant... if you
>: would be kind enough to take another shot at describing what you
>: mean, I'd be happy to listen. :-)
>
>one height. If the room next to you is more than one level higher or
>lower, you won't see anything in it.
Hmm... maybe, but that's certainly not how it sounds to me. He said:
*begin quote*
All rooms have a base height. For each object you
need to recurse through, add in its height. Finally, add on your
height. This gives you the height you are at. At a distance of zero,
you can only see objects level to you. At a distance of 1, you can
only see objects up to +/- one unit of height from you. And so on.
For this, you need 2 attributes on each object: Object height +
cumulative height. Then, all you do is compare
abs(cumulative height of observer - cumulative height of test obj)
against abs(rooms away).
*end quote*
This sounds to me like the algorithm is supposed to add the height of
the room, the height of any objects the character is standing on, plus
the height of the character. That, or he's being extremely redundant
in his description. :-)
>ie. You are climbing a steep mountain, you can't see anything above or
>below you. Not a perfect solution, but a nice idea nonetheless. Perhaps
>a calculation using a gradient?
>
>Anyway, that calc simulates you not being able to see what is on top of
>the mountain when you are on the side.
Why should that happen? I can look up the slope of the mountain, can't
I? Unless you're talking about a mountain with a flat peak, and something
on that peak... still, I don't see any reason why I can't look straight
up to see something in the air directly above me, which the given algorithm
does not allow for.
The algorithm still makes no sense, even if room heights are being used.
Why should I be able to see one room up at one space away? What if the
room that's one away and one up is blocked from my vision by a
ceiling in the way? The algorithm makes no mention of sight being
blocked by objects of any sort, which seems to me to make it useless for
LOS calculations.
>: In a visual game, such as Doom, it's possible to implement a LOS system
>: simply by using object layering; things that can't be seen don't wind up
>: getting drawn on the screen. However, in a text-based system, the system
>
>That's not how it really works. Remember, mobiles in Doom run through a
>non-visual LOS calculation.
I didn't say that's how Doom works; I simply said that is a possible method
for implementing LOS in such a game.
--
Travis S. Casey (ca...@cs.fsu.edu)
FAQ maintainer for rec.games.design