Sublocation <was> Looking for... MUD design info
H. McDaniel
to kick me if it wasn't ;) Anyhoo,
In "Looking for freeware MUD design info"
dkri...@pollock.artists (David Kristola) writes:
>Actually, i do not like "give", since it implies forcing the action of
>someone else. You can offer something, but the person you offer it to
>does not have to accept it. You can put (sneak) something into their
>possession, but that is not the same as "give", and should require some
>sort of skill check (or a perception check on their part, or both).
>The difficulty depends on the recipient. If the recipient is a room,
>then the operation goes unopposed.
>However, "offer" is more of a targeted emote (which also sets up an
>internal state in the offerer that will allow the target of the offer
>to take the offered object).
Hmm. A concept I have been thinking about a lot lately which might
be related to your idea is what I call sublocation. Basically
that is the ability to locate an object with greater precision
than being simply "in" or "outside" of another object, it's about
the relationship between objects sharing the same space. Now,
strictly speaking this isn't new. On some games one can wear say
a helmet on their character's head. The head then is a sublocation
within the body object. In a game with a coordinate or "ranged"
system where objects are on a measured grid objects may or may not
be sublocated it all depends on their relation to container objects and
not the grid per se.
On my experimental game I have sized rooms. Rooms which are
one real object containing numerous "virtual" room cells. An
object in one cell of the room is sublocated. It isn't necessarily
visible from other parts of the room. An invisible object is in a sense
located somewhere else. One could argue that if the object can
still be interacted with by a character it isn't really somewhere else,
but I'd counter by saying that all distances are imaginary in a MUD anyhow
so it comes down to visibility (in the "look" output and the full OO
sense.)
So (long exhale) sublocation can, as in the first example of a wearable
item, be places on a character like "offering hand" or "palm of hand"
for your purposes. If an object on a player's character were sublocated
there it would be available to any passerby. Of course, IMO again,
you'd want some continuous way of letting other players know an offering
is being made which is *more* visible than requiring another player
to look at the one making the offering. I think modifying what is
in effect the short description of the player seen in room would do
the trick.
Now, I didn't have your offer thing in mind as I've been consider this
*thing* for the past few days.. actually I was thinking more about things
like object A. is above/on/under (some other preposition) object B. What
use might I put that sort of sublocation to... how might I implement it in
an efficent and useful way.
I don't want to model the real world in every detail. Yet, it
would be very useful (IMO) to be able to group any items in a
MUD and relate them to *one another* along these lines. Then I'd
have an intelligent text generator be abe to summarize the group
contents in a brief fashion. Come to think of it you could do
things like pack multiple items into a container like a bag, and
shake the bag allowing the contents to settle. Then when someone
looks into the bag they only see what's on top, but they also
are told that there is more beneath the stuff on top. Or a
character could re-arrange the contents of the container. This
could be applied to all objects from characters/items in a room
to rooms within a game area. If the rules for "gravity" or
settling out the contents when the container is shaken are right
this could be used to sort items too.
Were I to implement something like this I wouldn't allow players
to get an old style complete listing of a container's contents
or to extract items that aren't *currently* visible from the
container. Though, I'd allow them to take whatever is at
the very bottom of a container out, or to randomly take stuff
out of the middle.
This would mean that if one made a telephone booth room or an
open grave location it would actually be possible to pack characters
in there and have realistic perspectves available to those outside
of the booth/grave and those inside concerning the limited space
and the obscuring of things as a result. One could even use this
principal to generate plausible perspectives of whole game areas,
say the look of a town from up on a hill -- not saying it would
be easy, mind you but it is certainly possible.
Opinions?
-McDaniel
H. McDaniel
BTW, on the ultima-online NG I recently read a thread where some
guy was asking, "How do I stack crates up.. I've been trying
to stack crates in my house but I can't." Am I the only one
who finds this sort of problem funny?
-McDaniel
Richard
] ...
] On my experimental game I have sized rooms. Rooms which are
] one real object containing numerous "virtual" room cells. An
] object in one cell of the room is sublocated. It isn't necessarily
] visible from other parts of the room. An invisible object is in a sense
] located somewhere else. One could argue that if the object can
] still be interacted with by a character it isn't really somewhere else,
] but I'd counter by saying that all distances are imaginary in a MUD anyhow
] so it comes down to visibility (in the "look" output and the full OO
] sense.)
] This would mean that if one made a telephone booth room or an
] open grave location it would actually be possible to pack characters
] in there and have realistic perspectves available to those outside
] of the booth/grave and those inside concerning the limited space
] and the obscuring of things as a result. One could even use this
] principal to generate plausible perspectives of whole game areas,
] say the look of a town from up on a hill -- not saying it would
] be easy, mind you but it is certainly possible.
We've been working on something along these lines, minus the approach to
items. Basically, a room is a given size and shape and you can move
around the room in 1x1x1 steps, where your perspective might be different
depending on your position in the room - like line of sight through
windows and open doors. This allows for things like being able to stand
near an exit waiting for someone to come through, rather than the
standard of effectively being the same distance from all exits in a room.
Virtual terrain comes into this somewhere, with structures being defined
and being able to see them from a distance.
Our implementation is mostly done and is polygon based, which is pretty
strange for a text mud :) Or at least I think so.
--
Richard Tew (above spudent -> student, lame spam avoidance thingy)
Aristotle@Threshold
I think I am not understanding the joke here. Do you mean it is funny that
even in a "wonderful, oh-so-easy-to-use graphical environment", people STILL
have difficulty figuring out how to interact with it?
-Aristotle@Threshold
--
VISIT THRESHOLD ONLINE! High Fantasy Role Playing Game!
Player run clans, guilds, businesses, legal system, nobility, missile
combat, detailed religions, mature, detailed roleplaying environment.
http://www.threshold-rpg.com -**- telnet://threshold-rpg.com:23
H. McDaniel
>In article <7it6bh$7d4$1...@nntp3.u.washington.edu>, ha...@u.washington.edu (H. McDaniel) wrote:
>>
>>BTW, on the ultima-online NG I recently read a thread where some
>>guy was asking, "How do I stack crates up.. I've been trying
>>to stack crates in my house but I can't." Am I the only one
>>who finds this sort of problem funny?
>I think I am not understanding the joke here. Do you mean it is funny that
>even in a "wonderful, oh-so-easy-to-use graphical environment", people STILL
>have difficulty figuring out how to interact with it?
That too, but mainly I think it's funny that things which are merely
common sense in reality can become so complicated when replicated in
virtual reailty. "How do I smile?" or "How do I drink from the fountain?"
are funny too. I'm not laughing *at* the people who ask the question,
of course, but the fact that such questions have to be asked.
-McDaniel
David Kristola
>Hopefully it was a good decision to start another thread. Feel free
>to kick me if it wasn't ;) Anyhoo,
>
>In "Looking for freeware MUD design info"
>dkri...@pollock.artists (David Kristola) writes:
>
>>However, "offer" is more of a targeted emote (which also sets up an
>>internal state in the offerer that will allow the target of the offer
>>to take the offered object).
>
>Hmm. A concept I have been thinking about a lot lately which might
>be related to your idea is what I call sublocation. Basically
>that is the ability to locate an object with greater precision
>than being simply "in" or "outside" of another object, it's about
>the relationship between objects sharing the same space.
I had been thinking of using containers for all locations, and having
two basic types, ones with grids and ones with zones (cells). Containers
would then be associated with portals to allow entrance and egress.
These two are tied, egress from one area is entrance into another. This
action may cause an event to be propagated through the system, especially
if there is some sort of trigger associated with the portal (a magic
spell, for instance). This would also allow a trap door to exist in
cell j5, and entrance to j5 would cause the entering object to possibly
fall.
>On my experimental game I have sized rooms. Rooms which are
>one real object containing numerous "virtual" room cells. An
>object in one cell of the room is sublocated. It isn't necessarily
>visible from other parts of the room.
I had not been thinking along the line-of-sight path. That could
be difficult to compute. Interesting.
>An invisible object is in a sense
>located somewhere else. One could argue that if the object can
>still be interacted with by a character it isn't really somewhere else,
>but I'd counter by saying that all distances are imaginary in a MUD anyhow
>so it comes down to visibility (in the "look" output and the full OO
>sense.)
I have a problem with implementing invisibility as a different location.
An area effect might not work properly, for instance.
Besides, i was thinking of working invisibility magic as a wrapper to
the invisible object, the wrapper would take control of the "look"
method, and return a "no, you can't see me" response. All standing
spells were going to be wrappers. At least, that was the idea i was
playing with. It might turn out to be unwieldy.
>So (long exhale) sublocation can, as in the first example of a wearable
>item, be places on a character like "offering hand" or "palm of hand"
>for your purposes. If an object on a player's character were sublocated
>there it would be available to any passerby. Of course, IMO again,
>you'd want some continuous way of letting other players know an offering
>is being made which is *more* visible than requiring another player
>to look at the one making the offering. I think modifying what is
>in effect the short description of the player seen in room would do
>the trick.
I was thinking along these lines, with the addition of an announcement
going to all in the room at the time the offer is made. Something like
``David offers and apple to Jane.''
And then if someone enters the area, or looks at David, they would see
the apple being offered at that time.
>Now, I didn't have your offer thing in mind as I've been consider this
>*thing* for the past few days.. actually I was thinking more about things
>like object A. is above/on/under (some other preposition) object B. What
>use might I put that sort of sublocation to... how might I implement it in
>an efficent and useful way.
I was first drawn to the sublocation problem for similar reasons.
I am trying to provide a structured environment for role playing
that currently takes place in chat rooms on AOL. We often find
ourselves hiding under a table (to no avail).
Also, i want characters to be able to fly. This can open up
a whole can or worms. In a room, Bubba might fly over the trap
door at j5. Outside, he might fly over the city, and look down
on it. He might land on a roof top (a new area to add to the
environment). He might take up second story work.
This text based MUD is starting to feel a whole lot more graphical
and 3D.
>I don't want to model the real world in every detail. Yet, it
>would be very useful (IMO) to be able to group any items in a
>MUD and relate them to *one another* along these lines. Then I'd
>have an intelligent text generator be abe to summarize the group
>contents in a brief fashion. Come to think of it you could do
>things like pack multiple items into a container like a bag, and
>shake the bag allowing the contents to settle. Then when someone
>looks into the bag they only see what's on top, but they also
>are told that there is more beneath the stuff on top. Or a
>character could re-arrange the contents of the container. This
>could be applied to all objects from characters/items in a room
>to rooms within a game area. If the rules for "gravity" or
>settling out the contents when the container is shaken are right
>this could be used to sort items too.
Interesting, but that kind of detail will have to go way down on
my list of things to work on. I don't even have a working shell
of a MUD yet!
>This would mean that if one made a telephone booth room or an
>open grave location it would actually be possible to pack characters
>in there and have realistic perspectves available to those outside
>of the booth/grave and those inside concerning the limited space
>and the obscuring of things as a result. One could even use this
>principal to generate plausible perspectives of whole game areas,
>say the look of a town from up on a hill -- not saying it would
>be easy, mind you but it is certainly possible.
>
>Opinions?
A real challenge. I can picture a bunch of college students
packed into a phone booth, and it could be hard to tell who that
foot belongs to, let alone what might be obscured. The MUD will
be working with very limited information about what the objects
are actually doing, and will have to make some arbitrary decisions.
This is not necessarily a bad thing. We are not simulating all of
reality, only some interesting portions there of.
--djk
For email, try one of the following:
Home: David95037 at aol dot com
Spam: goto....@microsoft.com
H. McDaniel
>I had been thinking of using containers for all locations, and having
>two basic types, ones with grids and ones with zones (cells). Containers
>would then be associated with portals to allow entrance and egress.
>These two are tied, egress from one area is entrance into another. This
>action may cause an event to be propagated through the system, especially
>if there is some sort of trigger associated with the portal (a magic
>spell, for instance). This would also allow a trap door to exist in
>cell j5, and entrance to j5 would cause the entering object to possibly
>fall.
Interesting. You just gave me an idea to improve my own code... BTW
because I've been checking both sides of my exits when dealing with
inter-room exits (I also have the ability to enter/exit from room
sublocations to anywhere else.) If we concieve of exits as seperate
objects, that is if we make portals containers as you say, then there
will be no need for code to check the status of say a door in multiple
objects, you simply consult the portal object itself.
In other words, the old model is to have:
ROOM1 { exits->ROOM2 }, ROOM2 { exits->ROOM1 }...
But the new one says to:
ROOM1 { exits->EXIT }, ROOM2 { exits->EXIT },
EXIT { left->ROOM1, right->ROOM2 }.
Ie: the rooms contain portal objects. We've all probably seen/done things
like that before, but not as SOP (far as I know.) All of the portal
code can be encapsulated in the portal object. Perfectly logical and
brilliant.
Now this cascade effect thing you hint at... I can't quite picture that.
I mean so a player action at portal 1 triggers other events in other
portals/rooms and so on... but to what end exactly?
>>On my experimental game I have sized rooms. Rooms which are
>>one real object containing numerous "virtual" room cells. An
>>object in one cell of the room is sublocated. It isn't necessarily
>>visible from other parts of the room.
>I had not been thinking along the line-of-sight path. That could
>be difficult to compute. Interesting.
Well, it's pretty simple because I limit the number of possible cells
in my rooms to a very finite number ;) You can have a 2x2 or a 3x3
sized room, or a traditional non-celled room. The main reasons
I created cells was 1.) to facillitate the efficent creation of places
within a game where one wnats to give the player a sense of space
(allows for the reuse of lots of things in common to the cells,) 2.)
to make a very small game seem larger in the population sense as
players within a sized room will get glimpses of each other.
Though now that I think about it.. there are far more efficent
ways to go than the celled thing. Ways I played with on MudOS
eons ago (and others have too.)
>>An invisible object is in a sense
>>located somewhere else. One could argue that if the object can
>>still be interacted with by a character it isn't really somewhere else,
>>but I'd counter by saying that all distances are imaginary in a MUD anyhow
>>so it comes down to visibility (in the "look" output and the full OO
>>sense.)
>I have a problem with implementing invisibility as a different location.
>An area effect might not work properly, for instance.
I was seeking a definition for "here" and "elsewhere" within a MUD.
IMO, if you can't percieve something in the real world it isn't here
as far as you're concerned. If a player doesn't see a cat it isn't
there until they do percieve it. If they "kick cat" and the cat
screams, then they've discovered the cat.. but up until that instant
was the cat really there? This is a metaphysical thing if you ask me,
because a wizard might snoop on a player who is in another room,
who are we programmers to say that the wizard is not infact with the
player and wherever he himself appears to be located, if that's
what the player believes? We know it comes down fundamentally to
object queues... or does it? That's how we conceptualize it and that's
how game code might typically treat it, but anything done one way can
be simulated/re-done another way. I just don't see how there can
be any real distance in a MUD, except and only according to a limited
perspective. But it is virtual... am I making any sense?
>Besides, i was thinking of working invisibility magic as a wrapper to
>the invisible object, the wrapper would take control of the "look"
>method, and return a "no, you can't see me" response. All standing
>spells were going to be wrappers. At least, that was the idea i was
>playing with. It might turn out to be unwieldy.
Look code generally is unwieldly anyhow ;) Not that it needs to be.
It's amazing how much MUD code is written a certain way just because
that is the way others have done it and not because it's a really
good way to do it. I'd like to see how your idea does... or more about
the planning/concept sometime.
[...]
>>to rooms within a game area. If the rules for "gravity" or
>>settling out the contents when the container is shaken are right
>>this could be used to sort items too.
>Interesting, but that kind of detail will have to go way down on
>my list of things to work on. I don't even have a working shell
>of a MUD yet!
>>This would mean that if one made a telephone booth room or an
>>open grave location it would actually be possible to pack characters
>>in there and have realistic perspectves available to those outside
[...]
>A real challenge. I can picture a bunch of college students
>packed into a phone booth, and it could be hard to tell who that
>foot belongs to, let alone what might be obscured. The MUD will
>be working with very limited information about what the objects
>are actually doing, and will have to make some arbitrary decisions.
>This is not necessarily a bad thing. We are not simulating all of
>reality, only some interesting portions there of.
Yeah, I don't think detail to the level of "someone's foot is visible"
is necessary anyhow. Just "Joe and others behind him" -- of
course others could be expanded a bit to be a little more helpful,
but without going outside the level of detail normally present in the
characters.
BTW, I'm a writer. I value the written word's evocative power. I would
never want a computer program to auto generate the bulk of descriptions,
which would be the danger if one takes this to the extreme as in the "look
at an area from a top a hill" example. Writers would still have to
supply all of the descriptive roots necessary for the server to
generate an overview in my plan. The game would simply organize
pre-existing detail, and invent nothing on it's own.
I once played with what I call dynamic text. Something I hear
is out there somewhere now. Basically that is having a lot of
flexibility in room descriptions for automated purposes. It
includes things like embedding room content listings in the
"long" room description rather than having a seperate list. I think this
sort of thing is fine under special conditions but shouldn't be the
standard for one's game.
-McDaniel
David Kristola
>
>>I had been thinking of using containers for all locations, and having
>>two basic types, ones with grids and ones with zones (cells). Containers
>>would then be associated with portals to allow entrance and egress.
>>These two are tied, egress from one area is entrance into another. This
>>action may cause an event to be propagated through the system, especially
>>if there is some sort of trigger associated with the portal (a magic
>>spell, for instance). This would also allow a trap door to exist in
>>cell j5, and entrance to j5 would cause the entering object to possibly
>>fall.
>
>Interesting. You just gave me an idea to improve my own code... BTW
>because I've been checking both sides of my exits when dealing with
>inter-room exits (I also have the ability to enter/exit from room
>sublocations to anywhere else.) If we concieve of exits as seperate
>objects, that is if we make portals containers as you say, then there
>will be no need for code to check the status of say a door in multiple
>objects, you simply consult the portal object itself.
Yup. Isn't a door an object in the real world? It might be locked,
it might be black, it might be broken, it might be stuck..... it knows.
>Ie: the rooms contain portal objects. We've all probably seen/done things
>like that before, but not as SOP (far as I know.) All of the portal
>code can be encapsulated in the portal object. Perfectly logical and
>brilliant.
Beginner's luck, honest. I'll get worse as time passes.
>Now this cascade effect thing you hint at... I can't quite picture that.
>I mean so a player action at portal 1 triggers other events in other
>portals/rooms and so on... but to what end exactly?
Lets say that Jane and David are in a room. Now Bubba enters.
How do Jane and David's player's know that someone has entered
the room? The way i was thinking of doing this is with events:
Bubba enters room -> events are generated and sent to contents of room
Visual event (Face135 enters room)
Sound event (footsteps or door closes or whatever)
Smell event (maybe Bubba has been playing with a skunk)
-- taste and feel events are ignored in this case
The room controls these events, and propogates them down to objects in
the room. This way, if there is a silence spell on the room, the wrapper
that encapsulates the spell can intercept the Sound event and keep it
from going further. Likewise, if the lights are out, the Visual event
can be intercepted. Hmmm, this is clunky. I need to work on light.
Using the sublocation idea, the room would pass these events on down.
Maybe one of the sublocations does not have line-of-sight to the door,
so the Visual event wont go there.
Eventually, the events make it down to the characters. Now if Jane is
blind, her character object won't pass the Visual event on to the
player's MUD client. Say she is not blind, but does not know Face135,
the Character object can then say something like "Someone has entered
the room". That object will also keep information set by the player,
so if Jane's player has told it in the past that Face135 is Bubba, then
the message "Bubba has entered the room" would be sent.
The events also go the other objects in the room. If someone has a
camera (line-of-sight on door), then the Visual event will go to the
camera object, which is an event conduit to another location, and
the event will propogate out of a monitor somewhere. If someone is
watching that monitor, the would see Face135 (or Bubba) enter the
room.
Likewise, a bug (listening device) could send the sound to a remote
location. In a table-top RPG, a Necromancer NPC was using severed ears
as bugs, leaving them in strategic locations. The PCs were grossed
out to find a severed ear. Little did they know how much more it was.
Now to the Window portal. It too gets the Visual event, of course
assuming it can "see" the door. Anyone looking through the window
would then also see the event.
This trick should also make mirrors work for looking around corners
(they would be conduits, transmitting the event).
Of coarse, at each level, wrappers could intercept the events and
change them.
I am not sure how i want to handle the event propogation. Maybe
as a character changes location, the events would be unregistered
from the previous location, and reregistered to the new location.
that could be a lot of work, but computers are good at that sort
of thing.
>>>On my experimental game I have sized rooms. Rooms which are
>>>one real object containing numerous "virtual" room cells. An
>>>object in one cell of the room is sublocated. It isn't necessarily
>>>visible from other parts of the room.
>
>>I had not been thinking along the line-of-sight path. That could
>>be difficult to compute. Interesting.
>
>Well, it's pretty simple because I limit the number of possible cells
>in my rooms to a very finite number ;) You can have a 2x2 or a 3x3
>sized room, or a traditional non-celled room. The main reasons
1x1
>I created cells was 1.) to facillitate the efficent creation of places
>within a game where one wnats to give the player a sense of space
>(allows for the reuse of lots of things in common to the cells,) 2.)
>to make a very small game seem larger in the population sense as
>players within a sized room will get glimpses of each other.
>
>Though now that I think about it.. there are far more efficent
>ways to go than the celled thing. Ways I played with on MudOS
>eons ago (and others have too.)
Since a friend of mine suggested i keep a graphical MUD in mind,
i have also been thinking in terms of 3D areas. This then opens
up the gateway to R*-trees and other stuff for simple rooms.
>>>An invisible object is in a sense
>>>located somewhere else. One could argue that if the object can
>>>still be interacted with by a character it isn't really somewhere else,
>>>but I'd counter by saying that all distances are imaginary in a MUD anyhow
>>>so it comes down to visibility (in the "look" output and the full OO
>>>sense.)
>
>>I have a problem with implementing invisibility as a different location.
>>An area effect might not work properly, for instance.
>
>I was seeking a definition for "here" and "elsewhere" within a MUD.
>IMO, if you can't percieve something in the real world it isn't here
>as far as you're concerned. If a player doesn't see a cat it isn't
>there until they do percieve it. If they "kick cat" and the cat
>screams, then they've discovered the cat.. but up until that instant
>was the cat really there? This is a metaphysical thing if you ask me,
>because a wizard might snoop on a player who is in another room,
>who are we programmers to say that the wizard is not infact with the
>player and wherever he himself appears to be located, if that's
>what the player believes? We know it comes down fundamentally to
>object queues... or does it? That's how we conceptualize it and that's
>how game code might typically treat it, but anything done one way can
>be simulated/re-done another way. I just don't see how there can
>be any real distance in a MUD, except and only according to a limited
>perspective. But it is virtual... am I making any sense?
Yes. There are also two (maybe more) ways to model things. One
version of invisibility might be the "out of phase" concept, where
physical interaction is impossible or limited. Then "elsewhere"
is valid. Invisible by hiding magic or technology, IMO is "here"
but can't be seen. Yes, this causes a problem with "kick the cat",
but maybe the command parser should "look" to see which cat is being
kicked, and error out with an "I don't see a cat."
Oh yes, another type of invisibility; the psionic version where
Bubba reaches into David's mind and places a block to hid him.
I would consider using a wrapper here that would block visual events
from Bubba when they get to David. That way Jane and the camera
and the person looking through the window would still be able to
see Bubba.
>>Besides, i was thinking of working invisibility magic as a wrapper to
>>the invisible object, the wrapper would take control of the "look"
>>method, and return a "no, you can't see me" response. All standing
>>spells were going to be wrappers. At least, that was the idea i was
>>playing with. It might turn out to be unwieldy.
>
>Look code generally is unwieldly anyhow ;) Not that it needs to be.
>It's amazing how much MUD code is written a certain way just because
>that is the way others have done it and not because it's a really
>good way to do it. I'd like to see how your idea does... or more about
>the planning/concept sometime.
I hope to make some (maybe not all) of the stuff available.
Maybe this weekend i will start a web page for it. My AD&D web
page has spurred me on to create more for the game world, and
has been an overall benefit to myself (which is good, since
almost no one else visits it).
For my first cut, and maybe inperpetuum, i was thinking of having
a gross parser for generating output. When you look at something,
you would get text writen by the author, and then choppy text about
additional information. No particular attempt would be made to make
it look pretty. I want to distinguish between the user interface
parsers and the AI parsers for computer run characters. Those will
look as natural as i can get them (but that is a very long way off).
With respect to "look at an area from top of hill", maybe the author
of the area should have short descriptions from the various vantage
points. The R*-tree with blocked out gross level regions and
a description at that level for each region would work. This would
then accomodate a character flying over a city: "the warf disteract
looks dank and muddy from this altitude, you can see the river snake
on to the south". Then as the character flies closer to one of the
subregions, they would get that description, all the way down until
they land somewhere and stand outside of a building (or on it's roof).
Hmmm, now that i think aobut it, that is an awful lot of detail. Maybe
some of it should be generated by the computer. Or maybe not... the
whole region of the city may only be modeled at a high (abstract)
level, no individual locations, only a general description for the
region. The character can move around in it, but everthing is basically
the same until told otherwise. In my table-top games, i don't bother
to detail whole sections of cities, i give out a few quick generalizations
and leave it at that. The warf section could have one bar of interest
but otherwise be just "you are in the warf section".
So much work to do, so little time. :-(
--djk, keeper of arcane lore & trivial fluff
For email, use one of the following:
H. McDaniel
>On 3 Jun 1999 07:31:43 GMT, H. McDaniel <ha...@u.washington.edu> wrote:
>>Interesting. You just gave me an idea to improve my own code... BTW
>>because I've been checking both sides of my exits when dealing with
>>inter-room exits (I also have the ability to enter/exit from room
>>sublocations to anywhere else.) If we concieve of exits as seperate
>>objects, that is if we make portals containers as you say, then there
>>will be no need for code to check the status of say a door in multiple
>>objects, you simply consult the portal object itself.
>The problem there is that all of your rooms (and exits/doors) would need
>to be loaded. While this is the case in Diku family, this is definitely
>not the case in the LP family. You could overcome this with having the
Nope, you wouldn't need all of the rooms related to a portal to be
loaded. And it's only traditional that rooms are all loaded in the Diku
family not an absolute necessity at all.
>second room loaded check if the door object is already loaded, but this
>then requires that you have unique objects for all doors. This isn't
>necessarily desirable.
I don't think so. Take a piece of paper and draw a square with a
small circle in the middle and an "x" in the upper right hand corner.
The square is a room, the "x" is the portal object and the "o" is
a character. Now, draw a line from the "x" off to the right and
put another "x" at the end of that line. What you have now is an
"x-----x", this is the portal object as it exists without there being
any rooms loaded but the first square you drew. So, let us say that
"o" wants to go to a room through "x".. Fine, draw another square
around the second "x" you drew. The portal object loaded a new
room. The portal object *knows* that it just loaded the room and
it can now: draw another "x" inside of the new square at the lower
right hand corner. Connect the new "x" with a line going right
to yet another "x". We now have another portal object, loaded
when the room was loaded. Stop.
The thing is to have the portal totally control the transit
process.
Note: you'd have to be careful and make sure that when a room is
loaded by a portal, it does not create duplicates of portals
already in existance and that any portals already existing
that should link to the room but aren't are linked in.
I think a simple registry would eliminate that problem.
So... anyhow, you should be able to load/unload rooms and portals
anytime you want to.
-McDaniel
Elysium
rest of the thread, so please ignore me if I repeat anyone :)
I can't help but wonder what cellular rooms do to movement routines... if
some items are obscured from some points of the room, then it is necessary
to let characters move between the defined parts of the room object. This
would mean that characters would have to have additional commands to
traverse between cells, as well as rooms, which would be confusing except in
indoor areas where room boundaries are clearly defined. In addition, combat
routines might have to be altered to allow for manouevres between such
areas? Are you modifying an existing lib, or starting from scratch? IMHO, a
point can very easily be reached where advancing the "realism" of a game is
detrimental to its playability.
In a different way of thinking, I have been trying to alter a TMI mudlib to
be able to account for different (but not relative) sublocations of
objects... not so far in rooms, but in containers, via prepositions. For
example, one candle could be "on" a chest of drawers while another is "in"
it. You can look at the possessions "of" another player. I've done this by
giving the default object a mapping of invisible objects, which are created
and destroyed with their owner. Each of these is refered to by its
preposition, and game objects are put into the inventory of these rather
than the original. It is possible to check the inventory by calling the
function defined as
object* inv(string prep) { return query("prepositions")[prep] } /*
oversimplified, of course */
in the object. Its a very basic system, and I can't help but feeling that it
must have been done a thousand times before... probably in some other mudlib
that I've never used :)
Elysium
~~~~
/"\ icq#36698237
\ /
X ASCII ribbon campaign
/ \ against html mail
Richard
> I can't help but wonder what cellular rooms do to movement routines... if
> some items are obscured from some points of the room, then it is necessary
> to let characters move between the defined parts of the room object. This
> would mean that characters would have to have additional commands to
> traverse between cells, as well as rooms, which would be confusing except in
> indoor areas where room boundaries are clearly defined. In addition, combat
> routines might have to be altered to allow for manouevres between such
The way we have done it is by just sublocating a room into what we call
coord-spaces. Basically a 1x1 room would have 1 coord-space, a 4x4 room
would have 16. Moving around a room just alters the position of a
character in the room, the same movement commands are used.
We're an LP who use the MudOS driver, so basically if you know what I
mean, for a given room, whichever coord-space you are in, you still stay
in the same room/environment - its up to the verbs to take into account
distance.
The main advantage I see is it gives a feeling of perspective and makes
entering a room more realistic. For instance, if Bobo is waiting by a
door on the east wall for Cooch to come through so that he can ambush him,
and Cooch comes through a door on the west wall, it sort of adds a whole
new dimension. Bobo can't simply attack Cooch anyway, he has to get close
enough first.
The main disadvantage we have found is positioning of exits, its a whole
new ball game. With room sizes actually meaning something, having the
ability to handle more than one door on a given wall is a must. To
clarify, the actual problem part is specifying something like which of
the three exits on the east wall you wish to use. We're considering all
sorts of things like embedding keys into the room description and more.
Like, use 'e1' for this one we're describing in this part of the room
description, and 'e2' for the next one we describe.. etc.
We're thinking of adding a setting for players so that if a command is
used that would fail because the target is too far away, if the setting is
set, they would automatically approach the target, then the command would
take effect. Of course, anything could happen in the time that it would
take to reach the target. Theres definitely a lot of considerations that
need to be considered :)
Some sample commands we have yet to code:
- approach: approaches something in the room, might be someone, something
or even an exit.
As I said, verbs have to provide the feeling of distance along with the
room description, which would provide the characters perspective of the
room. So, for instance, if the auto-approach setting is on, and the
character typed 'attack cooch' then, they would approach cooch as if they
used the approach command first and then attack Cooch.
> areas? Are you modifying an existing lib, or starting from scratch? IMHO, a
> point can very easily be reached where advancing the "realism" of a game is
> detrimental to its playability.
We think its worth it, but then we're going for a lot of way out things,
like providing player professions which actually replicate how things were
done in medieval times, a realistic coordinate system that takes into
account gravity, trajectories of thrown objects, ability to see structures
in the distance when outside - and to approach them. A realistic ocean,
flight etc. And shiteloads more.. Chances are we'll only be able to
support two concurrent players when its all in :)
> In a different way of thinking, I have been trying to alter a TMI mudlib to
> be able to account for different (but not relative) sublocations of
> objects... not so far in rooms, but in containers, via prepositions. For
> example, one candle could be "on" a chest of drawers while another is "in"
I don't think this is the way I would approach it.
I take it that rather than keeping the candle (on the chest) in the same
environment as the chest, you keep it with the chest as its environment?
I'd go for positioning code in the chests environment to handle that.
Anyway, feel free to ignore this post, all my other posts get ignored :)
I'm starting to wonder if everyone has me kill-filed :)
(not that I care, perfectly happy talking to myself)
If anyone is interested in seeing our coord-space in action, log into
sorrows.imaginary.com 3000
and head north-east (ne) ten times, you should find yourself in a shack.
Wall collision detection isn't in yet, but I'm pretty sure its a 4x4 room.
Points for being able to guess where you are in the room and where the
walls are :)
H. McDaniel
This is precisely the main disadvantage.
>sorts of things like embedding keys into the room description and more.
>Like, use 'e1' for this one we're describing in this part of the room
>description, and 'e2' for the next one we describe.. etc.
In my system there are cells but there are no coordinates within the
cells. A player or object is merely within one of the cells or
not (2x2 and 4x4 sized rooms available.) The default assumption
is that one can walk from one cell to another using n/s/e/w/ne/ etc.
So there is no need for an "approach" command (I think) in my system,
the player simply is or isn't in a cell which for those who
are confused by all this ;) you can think of as being a room within
a room.
BTW, I am becoming more convinced that multi-cellular rooms aren't
the cure for the original problems I was trying to solve. I'll
be working on some other notions in the near future ;) But cells
are still fun.
-McDaniel
David Kristola
>"Elysium" <n...@fadeout.freeserve.co.uk> writes:
>> I can't help but wonder what cellular rooms do to movement routines...
{snip}
>The way we have done it is by just sublocating a room into what we call
>coord-spaces. Basically a 1x1 room would have 1 coord-space, a 4x4 room
>would have 16. Moving around a room just alters the position of a
>character in the room, the same movement commands are used.
{snip}
>We think its worth it, but then we're going for a lot of way out things,
>like providing player professions which actually replicate how things were
>done in medieval times, a realistic coordinate system that takes into
>account gravity, trajectories of thrown objects, ability to see structures
>in the distance when outside - and to approach them. A realistic ocean,
>flight etc. And shiteloads more.. Chances are we'll only be able to
>support two concurrent players when its all in :)
I would like to hear more about flight and gravity. I am working on a
design that will hopefully accommodate these, but it is early in the
development process. Let me outline what i had in mind:
I am planning on using 3D grids everywhere (this is going to cause
problems with building, but hopefully some smart tools will solve most
of this). The "approach" idea (oops, i snipped that) will be built in.
If a player wants to avoid it, he/she/it can specify lower level detail
in the actions ("go bar" vs. "n, n, e, n, e" to get to the bar).
Each character will have a box that describes their basic size and
shape. This will be used for collision detection, among other things.
They will probably have several boxes, representing different positions
(standing, sitting, laying down, crawling, flying (wings out), etc.).
Off the cuff: gravity will basically be worked as a check each chronon
against location (is box of character in contact with a solid surface
in the direction of gravity, or is character somehow suspended?).
Flying is motion in 3D, other motion is generally assumed to be in 2D.
I have not thought about jumping yet, but maybe i will use some sort of
ballistic arc for the character box, and maybe check it against
obstacles.
This is going to be a lot of code, but it is not interpreted, and with
a good compiler, should not be slow (i am keeping my fingers crossed).
>Anyway, feel free to ignore this post, all my other posts get ignored :)
>I'm starting to wonder if everyone has me kill-filed :)
>(not that I care, perfectly happy talking to myself)
Well, when i figure out how to use the kill-file functionality on
this news tool..... j/k
>If anyone is interested in seeing our coord-space in action, log into
>sorrows.imaginary.com 3000
>and head north-east (ne) ten times, you should find yourself in a shack.
>Wall collision detection isn't in yet, but I'm pretty sure its a 4x4 room.
>Points for being able to guess where you are in the room and where the
>walls are :)
>
>--
>Richard Tew (above spudent -> student, lame spam avoidance thingy)
--djk, keeper of arcane lore & trivial fluff
Home: David95037 at aol dot com
Spam: goto....@welovespam.com
Richard
> I would like to hear more about flight and gravity. I am working on a
> design that will hopefully accommodate these, but it is early in the
Well, as we are still fleshing out the basic usage we haven't really
worked on either more than in initial stages. Gravity is in, but its
extremely limited.. sort of like if I transfer to the absolute area
(which all the islands are placed in) at some arbitrary coordinates at
sea-level, then I get a message saying I dropped X many meters because
the next surface is the sea floor. Theres no dropping as yet, simply the
message. We do support gradients and moving west might move you down as
well.. which has the added advantage that if you are at a coord which is
solid rock (inside an islands polygon), you can't move around cause
things are too steep. Anyway, now I'm rambling :)
As for flight, well, the guy doing all the donkey work is working on
that, my limited thoughts are that its a simple matter of fly north :)
Special case exclusion from gravity, although if you have an automated
flight, and the magic peters out, there'd be a nice curved downward
flight path.
> I am planning on using 3D grids everywhere (this is going to cause
> problems with building, but hopefully some smart tools will solve most
> of this). The "approach" idea (oops, i snipped that) will be built in.
> If a player wants to avoid it, he/she/it can specify lower level detail
> in the actions ("go bar" vs. "n, n, e, n, e" to get to the bar).
Well, I'm not sure whether I mentioned this, I suspect not..
Basically the way we have decided to do it is by having each area with
its own relative coordinates for everything in it. Theres an absolute
area in which the individual areas are placed at relative locations.
We want structures to be visible from the distance, like a castle across
a valley, so rooms are grouped into structures which have a location in a
given area. We figure the best way to do ships is by having them as
structures in the absolute area, so they don't have to be moved from area
to area - what a nightmate that would be..
Basically to create at this stage, you practically need a 3d modeller :)
> Each character will have a box that describes their basic size and
> shape. This will be used for collision detection, among other things.
> They will probably have several boxes, representing different positions
> (standing, sitting, laying down, crawling, flying (wings out), etc.).
This is way beyond what we are planning, perhaps with you not using an
interpreted language, you might be able to do this, but it'd reduce our
goal of supporting two concurrent players down to one severely lagged
player.
> Off the cuff: gravity will basically be worked as a check each chronon
> against location (is box of character in contact with a solid surface
> in the direction of gravity, or is character somehow suspended?).
The way we are set up now, I guess how we would do this is when someone
moves to a coordinate, if they are not on a surface, then they fall at
9.81 ms^-1 :) Its a matter of putting an 'effect' on them when the need
is judged, and that effect as time passes moves them down until - splat.
> This is going to be a lot of code, but it is not interpreted, and with
> a good compiler, should not be slow (i am keeping my fingers crossed).
Sounds like you're going for more of a 3D game than a text based one what
with jumping :)
David Kristola
>dkristol@seebelow (David Kristola) writes:
>> I am planning on using 3D grids everywhere (this is going to cause
>> problems with building, but hopefully some smart tools will solve most
>> of this). The "approach" idea (oops, i snipped that) will be built in.
>> If a player wants to avoid it, he/she/it can specify lower level detail
>> in the actions ("go bar" vs. "n, n, e, n, e" to get to the bar).
>
>Well, I'm not sure whether I mentioned this, I suspect not..
>Basically the way we have decided to do it is by having each area with
>its own relative coordinates for everything in it. Theres an absolute
>area in which the individual areas are placed at relative locations.
>We want structures to be visible from the distance, like a castle across
>a valley, so rooms are grouped into structures which have a location in a
>given area. We figure the best way to do ships is by having them as
>structures in the absolute area, so they don't have to be moved from area
>to area - what a nightmate that would be..
The idea i am working with is to have areas (an object that can contain
other areas, or "rooms" (buildings)). Areas let you get around between
the smaller, well defined things in the game world. They also provide
higher levels to place descriptions. In this way, i can have a general
description of the area, and list the buildings that are in it. Some
areas will be very big (like a lake or a sea), others may be no more then
a part of a city block.
It shouldn't be too much trouble to have mobile "buildings" (like a
ship), and let them move around (the object stays the same, only it's
coordinates change). If you have an area for the sea where the ship
can travel, then it does not move from one area to another, it just
moves around in that area. (Why is it hard to bring it from one area
to another?)
>Sounds like you're going for more of a 3D game than a text based one what
>with jumping :)
Yes, it will be. Someday, it may grow to be a graphical mud. I am
going to look into using a graphics library to take care of some of
the 3D processing (OpenGL?).
>Richard Tew (above spudent -> student, lame spam avoidance thingy)
--djk, keeper of arcane lore & trivial fluff
Richard
> The idea i am working with is to have areas (an object that can contain
> other areas, or "rooms" (buildings)). Areas let you get around between
> the smaller, well defined things in the game world. They also provide
> higher levels to place descriptions. In this way, i can have a general
> description of the area, and list the buildings that are in it. Some
> areas will be very big (like a lake or a sea), others may be no more then
> a part of a city block.
This reminds me of something that I wonder if our system can handle.
Before we moved to the new system we had expanded our old one to handle
recursive areas of unlimited depth, allowing for things like an island on
a lake on an island.. I am not sure whether we allow for things like this
with in our current system :(
> It shouldn't be too much trouble to have mobile "buildings" (like a
> ship), and let them move around (the object stays the same, only it's
> coordinates change). If you have an area for the sea where the ship
> can travel, then it does not move from one area to another, it just
> moves around in that area. (Why is it hard to bring it from one area
> to another?)
Ok, thought about it. With the absolute area you only have to check where
its moving, with the individual areas, you have to check that and whether
it crosses between or spans more than one area. As the absolute coords
map invisibly to the relevant place in an individual area, you can
completely avoid thinking about the individual areas.
Well, it makes sense to me :)
As I mentioned, another guy is doing most of the work, I just have a fair
idea of what we wanted to achieve and what his code allows for. So, most
of my statements are for the most part educated speculation :)
> Yes, it will be. Someday, it may grow to be a graphical mud. I am
> going to look into using a graphics library to take care of some of
> the 3D processing (OpenGL?).
We suspect we will (as in the other guy) be converting our polygon related
code into a driver package (rewriting it in C), are also thinking about
submitting it to be included as part of MudOS, but what the chances of
that are, I do not know.
--