Redefining the room

[Nathan F. Yospe]

Katrina McClelan <kit...@directcheck.aries.net> wrote:

:[Time to start a new thread, and maybe we can keep this one on topic for a
:week or so :)]

Sorry, couldn't resist... I've done a lot of work on this subject... I've
included a little bit of it below...

:I've been toying with an idea of changing the way rooms are done, making
:a "room" defined as a just a small area of space. Descriptions would be
:dynamic, incorparating any "objects" (mobs/players/items/fixtures) that
:are in your vision field. Vision would be based on a several "room" cone
:in the direction you're facing (see diagram):

:Facing --->

: [ ][ ]
: [ ][ ][ ][ ]
:[X][ ][ ][ ][ ]
: [ ][ ][ ][ ]
: [ ][ ]

What if there is a huge object dominating the landscape in the distance?
(One fix, though it puts some small restrictions on dynamicism, is the
"backdrop", a background pointed to by all rooms in a section of them,
like a QuicktimeVR picture in text...)

Example:

: [ ][ ] | Mountain
: [ ][ ][ ][ ] | Background
:[X][ ][ ][ ][ ] | Description
: [ ][ ][ ][ ] | Goes Here...
: [ ][ ] |

:Aditionally I plan to make movement commands something along the lines of
:"forward", "left", "right", and "back" to eliminate "imaginary compasses"
:found in existing bases.

This is also good. I have noticed that you have limited yourself to the
four directions still... at the very least, go with a 25-point cubic.

IE,

NWU NU NEU\
NW N NE\
WU U EU NWD ND NED
W X E
SWU SU SEU\ WD D ED
\ SW S SE\
\ SWD SD SED

Better with a radial system and some matrix algebra, if you know it. This
requires a "door off to the left a bit" to be approached, however.

:The end result makes things such as ranged combat (and spells), ambushes
:from behind, spinners/teleporters, and all sorts of things to work
:correctly. It also eliminates alot of the problems of describing a room
:for all cases (room descs that mention mobs and items for example), as
:well as the trouble of writing a zone that is a field. It also allows
:descriptions to take weather, lighting, and other dynamic attributes into
:account. Eventually (although this gets VERY complex) I can even
:dynamically create "air" above ground zones and fixate air to ground
:vision and combat things (a flying mage casting spells on a grounded party
:can be quite annying, as can a flying orc dropping rocks.... then a
:grounded party dispelling the flying mage can be quite amusing too).

And more. I tested the possibilities by using one char to tie another char
into a sack and drop the sack near the edge of a high cliff, then switching
back to the tied up char and trying to escape. Of course I rolled off the
edge of the cliff.

:Anyway, to the point, I was looking to get a feel for opinions on this,
:and even possibly some sugfgestions on things to consider in
:implementation, and perhaps ideas that lend themselves to this kind of a
:gaming environment.

:Regards,
:-Katrina

OK, here goes with a whole seiries of paste-ins.

---- snip ----

:>I have some questions regarding a room-based vs. a coordinate-based MUD
:issues.
:>
:
:Well, they aren't necessarily mutually exclusive...
:
:I do both. A "room" based system (really a N deep hirearchical tree of
:containers) where there is a coord system inside of each "room".
:
:JK

I've also done well with a fusion of both. The distinction is primarily in
how descriptions are presented, and in the fact that you are "contained"
in a room, with discreet -player-visable- boundaries. This does not mean
you cannot blow down the walls, and even roof and floor, for that matter,
of a room... though I don't think you'll be able to remain in the room if
you do that... but the output will always be presented with the assumption
that you are looking around in all directions. Fields, on the other hand,
direct your attention to where you are facing. Null-G fields are a bit
trickier... you no longer have an "up" and "down" to orient around, or a
ground to refer to. All of these, along with the other varients on a
locality, have coordinate systems internal to their operation. Some are
simple... the coordinate system of a bag is often negligable, and the
generic bag does, in fact, ignore it altogether. The coordinate system for
an exposed locality... the top of a bench or bed, for example, or the bed
of a pickup truck... might be a little more complex, but not by much. Each
locality remembers a list of its contents. Actual positions are checked
off of that list, which uses a polar transformation and spherical
approximation for most collision detection. With text, that works quite
well. I use the 1/3 torsal approximation for the sphere of a human. I have
minispheres for the individual parts of the body.

---- snip ----

:How would I implement the equivalent of room-spoofs in a coordinate-based
:setting?

Nodes of interaction - transparent sublocales with their own coordinate
systems, joined by message/information/object passing barriers. Just spoof
a node. And have your builders place nodes in terms of reasonable
boundaries.

---- snip ----

:} If you need more, I have a 12 page design document on nodes and
:} boundaries.
:
:Yes, please post it here.

Whoo, boy. How about a truncated version?

II Locations
A] The Node
- Nodes are the centerpoint of a Location. They define the core of
each Location's coordinate system, conceptually. In practice, the
Node is similar to the room construct of an LP, Tiny, or Diku. It
contains a generic list of all objects contained by the Location,
as well as a pointer to the Coordinate object of each Physical
object. Any relocation of a Physical object will check it with the
Node before scheduling, and, as the Node runs a local Event queue,
it can also be safely awarded posession of the Event thread socket

(Note: Event thread sockets are detailed separately, and are too complex
to go into here. Suffice to say that Events are executed by threads tied
to a Node. The threads themselves are drawn from a pool.)

without worry about concurency. The standard rules regarding
thread execution priority apply. See below for more details. The
node itself is subservient to the Location, and cannot be
inherited.

i. Node bounds:
Each node has a defined boundary, at which point, continued
motion effort by a physical object (see momentum) will be
transfered to a Boundary object, if present, or terminated, with
prejudice, if specified as a discreet boundary (note: location
MUST provide a layer of solid matter before a discreet boundary.
Invisable, indestrucatable, opaque walls are a BAD thing.) or
wrapped to the specified coordinates within the same region if
specified as a generic boundary. (most useful for regions
measurable in large numbers of square kilometers, where the wrap
point on each coordinate axis is about two kilometers behind the
boundary line.) The Room class predefines Boundary objects on
all sides, with open spaces in the boundaries optional. Default
construction of the Boundary is collapsed matter. This should
ALWAYS be changed. Collapsed matter is completely
indestructable, even under the influence of antimatter, which is
not appropriate for a room. Default thickness of these
Boundaries is on discreet unit (one cm, in the case of
Singularity 2) and this should be changed if the wall is meant
to be inpenatrable. A defined thickness of -1 yields an infinite
wall of whatever the choice material is. Excepting planetbuster
strength damage, which would delete the area entire, this should
yield satisfactory results, while still allowing the odd plasma
torch marks in said wall. The Field class defines NO Boundary
objects whatsoever. Note that this results in there being no way
for the player to know if they have been transfered between two
nodes.
ii. Objects "on" a Node
While an object resides in a given Location, they are subject to
treatment as a local object by that Location's Nodes, as well as
the parent Nodes. For example:
The "Ruby Pen" is in the pocket of the shirt worn by "Joe the
Nerd", who is standing in a shack in the middle of the "Plain
Plains of Plainness" on the planet "Yawn", somewhere in the
universe. There are five nodes involved here. The first is
the global node, which tracks the coordinates of Yawn, which
tracks the plains, which track that shack, which tracks Joe's
body, which tracks the shirt, which contains the pocket (it
doesn't actually bother with real coordinates. The pocket is
somewhere on the shirt. Within the pocket (again, no real
coordinate tracking) is the pen. Were someone to look for the
pen, while in the plains, a check would go to the shack, and
be rejected on the basis of visability. Within the shack, an
eventual query would reach the pocket. If the pen was sticking
out (likely) the searcher would be informed that the pen was
in Joe's pocket. Any conditions specific to the plains will be
applied to anything within the shack, or the pocket, unless
screened by the Boundaries. Rain, for example, would be
rejected.
iii. Crossing nodes
Boundaries allow a Location to transfer an object, or
information, or pass a message to the neighboring Location's
Node. When a Node needs to communivcate with its neighbors, it
calls on the Boundary. Occasionally, a Boundary might be
overloaded to be one-way, or even inpenetrably thick. In these
special cases, a Boundary only need know one side, or none.
Normally, a boundary maintains two discreet channels, one for
each direction. Collision within a boundary is not permitted. A
boundary will also contain information about a (normally two
sided) object, if applicable... the wall. If not applicable, the
boundary has no in-game representation, as it transparently
passes everything that is handed to it. If a wall is present, it
can be destroyed. This is not preventable. It can be
discouraged, but ultimately, an entire room could be destroyed,
resulting in an orphaned node sitting out in the open. The
showMe() function should not be overloaded by something that
does not accomodate this possibility.

*whew* That is enough of that. The point is, it retains advantages of
rooms (spoofability, discreet localities for events) with all of the
advantages of coordinate systems. Combat can occur without hassle across
two nodes... though there is a possibility of "passing in flight" if one
thread lags. This could result in things like

> Shoot arrow at Thag
You send the arrow off toward Thag.
... wait ...
Thag runs off and hides behind some trees.
Your arrow thunks into the ground where Thag stood mere seconds ago.

This is, however, desirable, over things like having Thag get hit before
he recieves the message about you shooting at him. (The message gets
queued, before the arrow itself, in the order recieved.)

---- snip ----

Subject: node-based 3D coord systems

A couple of members have expressed interest in 3D coordinate systems, or
coordinate systems in general, in the last few weeks. The two systems that
follow are both based around what I call "nodes", though their approaches
are significantly different. The first is my concentric/adjacent/connected
system for Physmud++, a hardcoded part of the design that is as much
conceptual as geographical. The second is the rigid grid of my GURU
project, which uses units of fixed size (a cube approx. 10m on a side) and
a (Q-ish)tree based access and compression system. Both address several of
the issues brought up in other posts, and allow for range and lockless
concurency management (though each has limitations - the GURU system has
an event horizon beyond which effects propogate only upon access, or in
the presence of players, thus eliminating things like volcanic effects
being seen for miles with no players present... I may eventually create
daemons capable of generating their own event threads to handle such
things... and the Physmud++ system has to invoke a top-down lock on all
threads lower on the concentricity heirarchy whenever an event ripens in
a non-empty domain (such as a room with a box in it, where the box
happens to have been designed with an active event node of its own).)

In any case, here they are:

Locations and nodes in Physmud++:

The node class has three purposes:
- Contain (and track position of) Physical and Informational objects, and
track boundaries to concentrically and spacially neighboring nodes
- Handle events for the current location level, including thread
management*
- Pass objects to and recieve objects from boundaries**

* "threads" means objects capable of holding an OS thread. Threads in
Physmud++ need not actually contain an OS thread at any particular point
in time, and a single OS thread (process) could be used to service the
entire mud, reducing to the lower limit of totally process managed
threads, or, at the opposite extreme, every thread could encapsulate a
seperate OS thread.

** Boundaries borrow processing incentive from the nodes on either side.
Effectively, each boundary is two objects, one in each node, which share
common variables, but effectively bypass the need for locks on the threads
on either side.

A sample world (I'll do a few types) could look like a Diku/Tiny/LP, with
world, zone/areas, rooms, and for the hell of it, roomlike containers in
some of the rooms.

The world would be a single node, with no adjacent nodes, no concentric
external nodes, and a concentric internal node for each area. The spacial
presence of the world is null, which means nothing will fit directly
within the world. Global events can be executed by the world, but rarely
occur, and alert the admins whenever they do, as they effectively render
the entire mud (sans socket related threads) monothreaded. The world would
have a spacial dimension of null as well, as it requires little else, with
no boundaries to worry about.

Each area would be a single node, with adjacent areas becoming adjacent
nodes (determined by the presence of boundaries, which are effectively
directly linked to the room-to-area boundaries that pass out of the edges
of the area), and with a spacial presence of null. Area wide events are
uncommon, as they effectively render the entire area temporarily single
threaded. Area wide events log their occurances, but, as they include such
things as broad weather conditions, do not immediately notify admins,
unless they are watching that particular event type (see wiznet
descriptions). Areas contain a concentric internal node for each room.

Each room would be a single room, with a spacial presence determined by
the size of the room and adjacent linkage (boundaries) to each neighboring
room, whether there is a door there or not. Local events are queued, and
because the queue is chain-linked (think newsgroup threads), events
relating to a particular content object are moved or destroyed with that
object, and destroyed if multiple dependancies are seperated.

Alternatively, there is the roomless model.

The universe is the outermost node, again. Under that are worlds, which
have a generic form (say, for example, desert or ocean over rock) managed
by the world's node, and using a derived node object of type field (one of
the predefined types)... within that field are spaces that are not part of
the generic form of the world - an outpost or an island, for example -
that are composed of discreet fields, each based on the constitution of
that expance. The island may be formed of jungle, beach, and rock... the
outpost may actually be steel walled rooms (rooms are another predefined
type, thus getting around the ackwardness of creating them in a coord
based system.)

As you can see, a highly flexible system, overall. It gets even better
when the boundaries' ability to pass sensory information seamlessly (or
not so seamlessly, as might be the case for a glass boundary and scents)
between node regions. The predefined physical nature of the universe, and
the fact that, in most cases, telling the system the material and
dimensions of an object are sufficient to generate a passable description
and presence in the game (Something gleams in the distance./An imposing
silver-gray smooth barrier rises from the ground, impedeing your progress/
Your missile detonates against the wall, melting a small portion of it and
leaving a blackened residue against the rest. - all from a simple def of
steel/300x7000x6cm and a placement with correct orientation) make it easy
to construct a believable world, leaving the real work in designing the
parts you _want_ to have a strong impact so that they have a literary
feel, and sufficient flexibility that they remain reasonably well
described even after a good deal of change. (I plan to rate the
persistance of descriptions, and revert to system generated descs as soon
as the persistance limit is overcome, unless contingency descs exist.
Automating this is a long way off, perhaps impossible.)

Discreet database points in GURU:

The GURU (Graphical User Rendered Universe) is not designed either to be
readilly programmed or described (naturally, being graphical) once
released. Instead, it is designed to be the ultimate in effective mass
social modeling, within the context of a completely dynamic and intensely
vast world. (User Rendered refers to the client's purported 3D rendering
capabilities... something that has yet to be completed. We're still
playing with generic tiles, even after three years of work.) The server,
which is my part of the design, uses a massive sort of tree based
database, mostly compressed and with details of the terrain extrapolated
from neighbors by a delta factor (a little more complex than that,
actually, but oh, well.) Parents of a leaf on a tree are cross
polinating... each leaf (room) shares parents with each of its 8(+18)
neighbors. Most rooms not on the ground level never evaluate, and are
therefore never even generated in the first place. There are exceptions. A
room is defined as a space 30m on a side. Internally, everything is
tracked as in a 3D coordinate system.

Now to the trick to management of the whole thing.

Rooms are active only in the viscinity of a player. This means the current
room, the 8 adjacent horizontals, and the 18 others above and below.
That's a cube 90 meters on a side, quite reasonable considering all races
are humanoid. (All players see their own race as human, and all other PC
races as humanoid bestial... they never are informed that there are PCs
that do NOT appear humanoid. This is added to the trick I have described
before about linking two PC/NPC pairs so that the NPCs mirror remotely
located PCs in combat - resulting in a (supposed) NPC fighting as
intelligently as a PC... remember, also, combat is supposedly eventually
going to become totally twitch here, if igt ever makes it to VR. In any
case, what happens is, a thread is assigned to each active PC, provided
that PC is not within the active region of another PC. If two PCs' regions
cross, one of the threads dumps all data and pending events into the other
and dies. If the two PCs drift away (twice as far away as the crossing
region - I create an ameobic fission effect here) the thread spawns a new
thread for the smaller player (or at random) and dumps everything into it.
If something happens that should be visable for a certain range, the
message propogates to the nth parent, and to each thread currently owning
a piece of the db in that range. Thus, effects as follows:

#### #### #### .... .... .... ....
#### #### #### .... .... .... ....
#### #### #### .... .... .... ....

#### #oo# #### .... &&&& &&&& &&&&
#### /][\ #### .... &&&& &&&& &&&&
#### #/\# #### .... &&&& &&&& &&&&

#### #### #### .... &&&& &@@& &&&&
#### #### #### .... &&&& A()A &&&&
#### #### #### .... &&&& &UU& &&&&

.... .... .... .... &&&& &&&& &&&&
.... .... .... .... &&&& &&&& &&&&
.... .... .... .... &&&& &&&& &&&&

--

#### #### #### .... .... .... .... .... ....
#### #### #### .... .... .... .... .... ....
#### #### #### .... .... .... .... .... ....

#### #oo# #### &&&& &&&& &&&& .... .... ....
#### /][\ #### &&&& &&&& &&&& .... .... ....
#### #/\# #### &&&& &&&& &&&& .... .... ....

#### #### #### &&&& &@@& &&&& .... .... ....
#### #### #### &&&& A()A &&&& .... .... ....
#### #### #### &&&& &UU& &&&& .... .... ....

.... .... .... &&&& &&&& &&&& .... .... ....
.... .... .... &&&& &&&& &&&& .... .... ....
.... .... .... &&&& &&&& &&&& .... .... ....

--

.... &&&& &&&& &&&& .... .... .... .... ....
.... &&&& &&&& &&&& .... .... .... .... ....
.... &&&& &&&& &&&& .... .... .... .... ....

.... &&&& &oo& &&&& &&&& &&&& .... .... ....
.... &&&& /][\ &&&& &&&& &&&& .... .... ....
.... &&&& &/\& &&&& &&&& &&&& .... .... ....

.... &&&& &&&& &&&& &@@& &&&& .... .... ....
.... &&&& &&&& &&&& A()A &&&& .... .... ....
.... &&&& &&&& &&&& &UU& &&&& .... .... ....

.... .... .... &&&& &&&& &&&& .... .... ....
.... .... .... &&&& &&&& &&&& .... .... ....
.... .... .... &&&& &&&& &&&& .... .... ....

Seperation results in shapes like

###
#O#
#####
#####
#O#
###

This design is far more PC centric, and assumes a rather limited model of
PC, something the Physmud++ design does not do.

---- snip ----

Dying{

A rocket streaks by overhead, but misses. Something explodes against the
bulkhead you are behind. The arkhen'yet captain gestures. An arkhen'yet
soldier screams in agony as Rose snaps off a burst of plasma tracers
from her plasma rifle.
> dirt captain
You are thirty meters away from a troup of several arkhen'yet soldiers,
in a spotlessly clean metal floored room... some primal instinct
suggests that you seriously reconsider trying to kick dirt in the
arkhen'yet captain's face. Kher'grrah throws a thermal grenade into the
center of the mass of arkhen'yet soldiers.
> dirt captain anyway (or simply '&', the override command)
Against every better instinct, you dive out from behind the bulkhead and
charge several arkhen'yet soldiers, intent on kicking dirt in the face
of the arkhen'yet captain. A cold blue pain cuts through your body,
almost an ecstacy in its intensity. The world seems to fade, stretching
away... something is very, very wrong... you can't feel your body.

. . .

Moses Arkhany is dead. It will cost you 40 mortality credits to resurect
him. Do you wish to resurect Moses Arkhany?
: y

You pry your eyes open, painfully. There is a bright white light
overhead, and everything feels a little... stiff. You have a vague
memory of a battle against a troup of several arkhen'yet soldiers, but
the details are vague. The chemical stench suddenly hits you... an
accelerated growth cloning room! You must have died... your head hurts
like a mother______.
>

}

Exploration{

> look
The flat green plain stretches away into a distant ridge of hills to
your right. Sixty meters to your left, a crop of trees springs up, thick
and forbidingly twisted. The strange, flat grass crunches under your
feet, releasing a pungent scent. Ahead, thirty meters off, a twisting
blue stream makes its slow, twisting way out of the small dark forest.
Sparse clouds drift by overhead.
Something streaks by overhead with a roar. A cluster bomb explodes ten
meters off ahead to your right! A piece of turf flies by, but misses
you.
> run
You start running toward the stream.
> run forest
You turn toward the forest, running as fast as you can. A roaring sound
reaches your ears. The forest is thirty meters away. Something roars by
overhead, leaving the impression of a silver streak in your eyes. A
whistling sound reaches your ears. An impulse makes you dodge left, and
a reddish object streaks by your right ear. The missile starts to climb,
but impacts into the forest. You keep running. The forest is ten meters
away. You dodge as branch as you reach the edge of the forest. You stop,
winded, to catch your breath. You are just within the edge of a small,
gnarled forest. Ahead and to each side, crooked black branches tangle
together, making it impossible to pass without considerable effort.
Mushrooms grow out of the mulch and rot at your feet, and there is a
damp smell to the air. The sun filters through the treetops, almost
entirely gone by the time it reaches you.
> look plain
You turn around and stare out through the edge of the forest. The plain
stretches out into the distance. Far ahead, the flat green plain
stretches away into a distant ridge of hills. Thirty meters ahead and to
the left, a twisting blue stream makes its slow, twisting way out of the
small dark forest. Far off to the right, a fence surrounds a complex of
buildings.
> hold rifle
You pull your plasma rifle out of the leather holster across your back
and cradle it in your arms.
> reload rifle
The current bolt has a full charge. You don't need to reload.
> hold grenade
Shifting your plasma rifle into one hand, you detatch a sonic grenade
from the strap across your chest and prime it.
A pack of about twelve Logran drones is approaching from the direction
of the complex of buildings. They are about 300 meters away.
> focus logran
You adjust your optical cybernetics to focus on the pack of Logran
drones. There are fourteen of them. Magnification is at x300. The pack
is led by a class three hunter. The Logran drones are carrying laser
rods. The Logran hunter c3 is carrying a rail cannon. They are heading
in your direction. They are about 250 meters away.

}

(Generated by a test run of Physmud++ v.6)

---- snip ----

And I'v tortured you enough... bye. :)

:PS: I curse the first person who tries to turn this into an LP vs diku, or
:a stock vs scratch debate to have all of their children be born naked :)

Pretty potent curse. I have a feeling it's for real. ;)

--
Nathan F. Yospe | There's nothing wrong with being a sociopath. Getting
yo...@hawaii.edu | caught is the problem. Mad scientists are for real. I
UH Manoa Physics | happen to be QUITE furious about a lot of things. The
Biomedical Phys. | scientist is also the dreamer. Magic is in your mind.

[Katrina McClelan]

[Time to start a new thread, and maybe we can keep this one on topic for a
week or so :)]

I've been toying with an idea of changing the way rooms are done, making

a "room" defined as a just a small area of space. Descriptions would be
dynamic, incorparating any "objects" (mobs/players/items/fixtures) that
are in your vision field. Vision would be based on a several "room" cone
in the direction you're facing (see diagram):

Facing --->

[ ][ ]
[ ][ ][ ][ ]
[X][ ][ ][ ][ ]
[ ][ ][ ][ ]
[ ][ ]

Aditionally I plan to make movement commands something along the lines of
"forward", "left", "right", and "back" to eliminate "imaginary compasses"
found in existing bases.

The end result makes things such as ranged combat (and spells), ambushes

from behind, spinners/teleporters, and all sorts of things to work
correctly. It also eliminates alot of the problems of describing a room
for all cases (room descs that mention mobs and items for example), as
well as the trouble of writing a zone that is a field. It also allows
descriptions to take weather, lighting, and other dynamic attributes into
account. Eventually (although this gets VERY complex) I can even
dynamically create "air" above ground zones and fixate air to ground
vision and combat things (a flying mage casting spells on a grounded party
can be quite annying, as can a flying orc dropping rocks.... then a
grounded party dispelling the flying mage can be quite amusing too).

Anyway, to the point, I was looking to get a feel for opinions on this,

and even possibly some sugfgestions on things to consider in
implementation, and perhaps ideas that lend themselves to this kind of a
gaming environment.

Regards,
-Katrina

[Scott McMahan]

In article <yospe-ya02408000...@News.hawaii.edu>,
yo...@hawaii.remove.this.edu (Nathan F. Yospe) wrote:

:This is also good. I have noticed that you have limited yourself to the

:four directions still... at the very least, go with a 25-point cubic.
:
:IE,
:
:NWU NU NEU\
: NW N NE\
:WU U EU NWD ND NED
: W X E
:SWU SU SEU\ WD D ED
:\ SW S SE\
: \ SWD SD SED

:

What about playability? Are people really going to want to play a MUD
where they have to worry about 26 different directions? While NSEWUD does
not accurately reflect reality, it does play easily.

--
Scott McMahan
mcm...@oncology.wisc.edu

[Michael Johnson]

Katrina McClelan wrote:

I see where you are going with this and the concept sounds cool, but
(and forgive me for sounding like an old fuddy-duddy that clings
desperately to an old convention) I could see it being more confusing
for separated groups trying to navigate back to one another and for
dungeon environments where you know that damn door is somewhere to the
east, but could easily get lost in convoluted passages (that's why the
map mode in Doom comes in so handy at times). I think I would find it
easier for my limited brain to handle if I didn't have to compute lefts
and rights to figure out what direction town was. In real life we have
the advantage of spying distant landmarks while outdoors to get a rough
feel for where we are - in a game this may prove difficult to implement.

One other problem I could see is keeping track of players facing
different directions in the same room, though it would be interesting to
have missed ranged attacks possibly hit friendly targets on the opposite
side, as well as blind-side attacks with increased damage and frontal
attacks with lessened hitroll. The introduction of wolf packs that use
the tactics of the jurassic raptors would be cool as well (one center
one distracts and focusses the attack while the rest of the wolves
attack from the sides and rear), but I digress.

It seems to me the main implementation concerns would be in the area
writing itself. A room square would have to have many descriptions to
be viewed from each vantage point (above, below, right, left, back and
forward) describing what is on or near each surface, and possibly what
can be seen in that direction beyond the boundries of the square itself
(assuming a multi-square room). This also introduces additional
direction views for looking diagonally across/up/down the room and
introduces spellcasting and ranged attack directional arguments leading
to carpal tunnel syndrome during combat <g>.

The idea of dynamically assigning views is intriguing, but I could
easily see it becoming quite server-intensive when computing all
possible views of thousands of room squares to be viewed by every mobile
(yes, those aggressives must track you down and kill you somehow) and
player. In visual games these things are possible based on texture
mapped virtual objects that you interpret into something you
understand. For a computer to see it and attempt to describe the
absolute position of every object in reasonably correct English is
another story, particularly in detailled environments. In a fast-moving
melee with mobiles entering and exiting view, the confusion on screen
could be tough on the player to comprehend. A good example of a
nightmare to implement would be the Astral Plane, and even the
2-dimensional Elemental Canyon would be an assault of information for
the player to digest. I fear that in the end, the detail would suffer
at the hand of ease of implementation and server resources. Losing
detail, in my view, leads to a less-immersive mudding experience.

All in all an ambitious idea with the possibility of being very nice if
coded and written properly. However the potential for a confusing
disasterous mess is extreme if it is not done absolutely perfect.

Anyway, those are my ideas and implementation concerns on it. I think
it is a wonderful idea, but perhaps better suited to the graphical mud
environment.

-Michael Johnson
Registered with mudconnect.com as Spooky
Currently residing on Isle of Death as Spooky and Phantom - come visit,
let's talk.

[mor...@niuhep.physics.niu.edu]

mcm...@oncology.wisc.edu (Scott McMahan) writes:
>yo...@hawaii.remove.this.edu (Nathan F. Yospe) wrote:
>

>:go with a 25-point cubic.

>:
>:IE,
>:
>:NWU NU NEU\
>: NW N NE\
>:WU U EU NWD ND NED
>: W X E
>:SWU SU SEU\ WD D ED
>:\ SW S SE\
>: \ SWD SD SED

>:
>
>What about playability? Are people really going to want to play a MUD
>where they have to worry about 26 different directions? While NSEWUD does
>not accurately reflect reality, it does play easily.

What is to worry about?

For mapping you can hit every thing with the 6 basics (unless you are in
a maze, but then a lot of muds already have NW etc. passageways.

Robert
Mor...@physics.niu.edu
Real Women change tires

[mor...@niuhep.physics.niu.edu]

Katrina McClelan <kit...@directcheck.aries.net> writes:

>I've been toying with an idea of changing the way rooms are done, making
>a "room" defined as a just a small area of space. Descriptions would be
>dynamic, incorparating any "objects" (mobs/players/items/fixtures) that
>are in your vision field. Vision would be based on a several "room" cone
>in the direction you're facing (see diagram):
>
>Facing --->
>
> [ ][ ]
> [ ][ ][ ][ ]
>[X][ ][ ][ ][ ]
> [ ][ ][ ][ ]
> [ ][ ]
>
>
>Aditionally I plan to make movement commands something along the lines of
>"forward", "left", "right", and "back" to eliminate "imaginary compasses"
>found in existing bases.

my kvetch with this is that in real life we have landmarks and visual
cues to make it easier to remember that a particular door allows a
lion to attack us whereas the door across the hall leads to safety.

In a mud coming to those door from one direction or the other confuses
things and the N/S designations even things out.

I also vote for 9 + 8 + 9 (= 26 not 25, for shame, Nathan!) possible
directions. (which may actually be implied by your drawing of the vision
cone?)

But I do like the idea.

[Nathan F. Yospe]

mcm...@oncology.wisc.edu (Scott McMahan) wrote:

:In article <yospe-ya02408000...@News.hawaii.edu>,
:yo...@hawaii.remove.this.edu (Nathan F. Yospe) wrote:

::This is also good. I have noticed that you have limited yourself to the

::four directions still... at the very least, go with a 25-point cubic.
::
::IE,
::
::NWU NU NEU\
:: NW N NE\
::WU U EU NWD ND NED
:: W X E
::SWU SU SEU\ WD D ED
::\ SW S SE\
:: \ SWD SD SED

::
:
:What about playability? Are people really going to want to play a MUD

:where they have to worry about 26 different directions? While NSEWUD does
:not accurately reflect reality, it does play easily.

Wow, was this taken out of context... especially considering everything it
was buried in. Oh, well... think of it this way... "ahead and to the left"
"directly ahead of you", "a little above you to your right", "directly
below you"... Besides, NSEWUD had already been discarded as a paradigm. I
was using the cardinals as reference points, but the coordinate system in
question was to be represented relative to player orientation...

[Katrina McClelan]

In <3422308B...@thegrid.net> Michael Johnson <mcjo...@thegrid.net> writes:

>I see where you are going with this and the concept sounds cool, but
>(and forgive me for sounding like an old fuddy-duddy that clings
>desperately to an old convention) I could see it being more confusing
>for separated groups trying to navigate back to one another

Oddly enough I tend to think the opposite given the increase range of
vision. In old formats the person could be right next to you and you'd
not see them.

>and for
>dungeon environments where you know that damn door is somewhere to the
>east, but could easily get lost in convoluted passages

I agree, but that's where real landmarks, and the fact that getting lost
is part of wandering in convoluted passages comes in.

>(that's why the
>map mode in Doom comes in so handy at times). I think I would find it
>easier for my limited brain to handle if I didn't have to compute lefts
>and rights to figure out what direction town was.

That's why you by a compass; something you'd never think to need on most
muds, but would in this kind of base.

>In real life we have
>the advantage of spying distant landmarks while outdoors to get a rough
>feel for where we are - in a game this may prove difficult to implement.

True, the range of visibility is problematic. I have a partial solution
to this that is not too terrible. Underground it's not a big deal since
walls tend to disrupt long range vision, but for overworld, my basic map
scheeme looks like:

^
|
+---+---+---+
| A | B | C |
| | | |
<-- +---+---+---+ -->
| D | E | F |
| | | |
+---+---+---+
|
V

This being the case, if you're in zone B facing west, I can have it check
zone A's information for long range landmarks, and if something like the
Great Tower of Pizotta is in zone A, I can drop note of it into the
description of zone B. It's not perfect, but the idea is that distance
vision is vauge and partial at best anyway.

>One other problem I could see is keeping track of players facing

>different directions in the same room.

This is not really a problem the way I intend to set it up. Each player
would simply see different text. Communication could become valuable.

>though it would be interesting to
>have missed ranged attacks possibly hit friendly targets on the opposite
>side, as well as blind-side attacks with increased damage and frontal
>attacks with lessened hitroll. The introduction of wolf packs that use
>the tactics of the jurassic raptors would be cool as well (one center
>one distracts and focusses the attack while the rest of the wolves
>attack from the sides and rear), but I digress.

Yeah, this format does open alot of overlooked tactics and realistic
problems that can be interesting.

>It seems to me the main implementation concerns would be in the area
>writing itself. A room square would have to have many descriptions to
>be viewed from each vantage point (above, below, right, left, back and
>forward) describing what is on or near each surface, and possibly what
>can be seen in that direction beyond the boundries of the square itself
>(assuming a multi-square room).

Aye, but describing an object and letting the code worry about random
factors such as light sources and weather is easier than writting room
descriptions. Take describing a dark web filled tunnel in existing code.
Well, what if someone lights a torch, or worse casts a continual light
spell. So much for dark. Next someone burns the webs off (presumably)
when he casts a fireball. So much for cobwebs. Existing descriptions are
hard to write because you can't describe things that may change.

>This also introduces additional
>direction views for looking diagonally across/up/down the room

Bleh... diagonals I had thought about, and decided to get by without for
starters. It loses some realism when turns are 90 degrees (but does make
navigation easier). The priniciples for description generation are
(roughly) the same when diaganols are introduced. The big difference is
that the square of graph paper definition goes, and enters the octagon
definition. I also decided that this advance would be better suited to a
world without flight to start with, and that I could add the skies (and
the complexities that go with it later (then I can advertise in alt.mud
"Come try us, we have skies above our world like it is some neat feature
<g>)

>and
>introduces spellcasting and ranged attack directional arguments leading
>to carpal tunnel syndrome during combat <g>.

This is a somewhat desired affect.

>The idea of dynamically assigning views is intriguing, but I could
>easily see it becoming quite server-intensive when computing all
>possible views of thousands of room squares to be viewed by every mobile
>(yes, those aggressives must track you down and kill you somehow) and
>player.

It will be more server intensive than spitting out predefined text, I'll
grant that. However, I have no intentions of describing the views to
mobs. For them all they care about is what (items) and who (players/mobs)
they can see. They could care less about the statues and such in the
hall. Also, most of the time intensive work is in describing the view in
English, not determining it. Even a ray caster finds it relativly easy to
determine WHAT you see, but has a more difficult time depicting it.

>In visual games these things are possible based on texture
>mapped virtual objects that you interpret into something you
>understand. For a computer to see it and attempt to describe the
>absolute position of every object in reasonably correct English is
>another story, particularly in detailled environments.

Well, outside of terrain, weather, and stuff such as light, the base
description assuming no one is around is pre-written for "fixtures".
Terrain is relativly easy to describe in text, as is weather, and lighting
is really simple (you can see or you can't). The tricky part is
describing groups of mobs (saving the plural of their name become
nessecary), objects, and other stuff that moves.

>In a fast-moving
>melee with mobiles entering and exiting view, the confusion on screen
>could be tough on the player to comprehend.

Yeah, but every thing I've read about historical melee is that it is very
chaotic. Keep in mind too that I don't intend to have the typical diku
attitude that a room without a mob is a waste. The mere threat of mobs
that you can't "see" is enough to create mood I think.

>A good example of a
>nightmare to implement would be the Astral Plane, and even the
>2-dimensional Elemental Canyon would be an assault of information for
>the player to digest. I fear that in the end, the detail would suffer
>at the hand of ease of implementation and server resources. Losing
>detail, in my view, leads to a less-immersive mudding experience.

Well, you'd lose some detail to gain other detail. Yes, a three
dimensional mess of astral void, would be a mess... of course my solution
is to stay away from that entirely rather than implement it poorly. As
far as the elemental planes, they'd be easy, beased on their
two-dimensional map. My algorithm I have in mind will handle 2 dimensions
very well. Three dimensions will cause it problems, until I figure out
how I wish to handle them. Basically, the biggest difference in the way
things will work will be that you (as a zxone writter) would describe the
contentes of the rooms rather than the rooms, then the mud would use those
descriptions of the contents to manufacture the description of the room.
I agree with you that it will add some degree of confusion over something
like diku. But it's a different style of play. In current muds the
confines of a room make rushing in with the heavy hitting the best
tactics. Without those confines, surprise, ambush, and missile tactics
gain in value.

-Katrina

[Nathan F. Yospe]

mor...@niuhep.physics.niu.edu wrote:

:my kvetch with this is that in real life we have landmarks and visual

:cues to make it easier to remember that a particular door allows a
:lion to attack us whereas the door across the hall leads to safety.

That just means we need them for muds as well...

:In a mud coming to those door from one direction or the other confuses

:things and the N/S designations even things out.

I don't like it, still...

:I also vote for 9 + 8 + 9 (= 26 not 25, for shame, Nathan!) possible

:directions. (which may actually be implied by your drawing of the vision
:cone?)

Oops. 0-25 inclusive == 26, not 25. Heh. Sue me, I'm better at manifolds
and transforms than arithmatic...

Originally, I implemented that 26 direction thing on a Diku, with letters
in place of the doornumbers in are files. That was long ago.

[Chris Lawrence (Contra)]

Scott McMahan (mcm...@oncology.wisc.edu) wrote:
: In article <yospe-ya02408000...@News.hawaii.edu>,
: yo...@hawaii.remove.this.edu (Nathan F. Yospe) wrote:

: :This is also good. I have noticed that you have limited yourself to the

: :four directions still... at the very least, go with a 25-point cubic.
: :
: :IE,
: :
: :NWU NU NEU\
: : NW N NE\
: :WU U EU NWD ND NED
: : W X E
: :SWU SU SEU\ WD D ED
: :\ SW S SE\
: : \ SWD SD SED

: :

: What about playability? Are people really going to want to play a MUD

: where they have to worry about 26 different directions? While NSEWUD does
: not accurately reflect reality, it does play easily.

Many non-LP and non-DIKU derived bases use 10 directions: N NE E SE S SW W
NW U D. I was quite dismayed at not having the diagonals when I first
played an Aber.

My tendency would be to support a 16 base for the planars (N NNE NE NEN E
ESE/SES SE SSE S SSW SW WSW/SWS W WNW/NWN NW NNW) as a macro overlay on
actual radial direction (360 degrees), but not explicitly expose that to
players. (I don't see a lot of value in the Up/Down variants for text games
(or arguably for graphic games)). This of course required abandoning the
entire concept of rooms and moving to a coordinate based system (not a Bad
Thing). The players would then use a variety of command sets to move
about, from the compass directions, rotations degrees, "face XXX object, go
towards XXX", LOGO style forward/right/left/back, etc.

--
J C Lawrence Internet: co...@ibm.net
---------------(*) Internet: claw...@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...

[Stephen Zepp]

Nathan F. Yospe wrote:

> :I also vote for 9 + 8 + 9 (= 26 not 25, for shame, Nathan!) possible
> :directions. (which may actually be implied by your drawing of the vision
> :cone?)
>
> Oops. 0-25 inclusive == 26, not 25. Heh. Sue me, I'm better at manifolds
> and transforms than arithmatic...
>
> Originally, I implemented that 26 direction thing on a Diku, with letters
> in place of the doornumbers in are files. That was long ago.

Umm, why not just dump the array implementation of doors, use a linked
list approach with unique ids within the exits, and have them named as
the builder sees fit? sure, they can name them as Northwest, Down to
the Southeast, or chute, trapdoor, whatever...no need to limit yourself
to anything, and why store pointers that you don't need?

Zoran, an ordinary coder with delusions of knowledge :)

[Katrina McClelan]

>Umm, why not just dump the array implementation of doors, use a linked
>list approach with unique ids within the exits, and have them named as
>the builder sees fit? sure, they can name them as Northwest, Down to
>the Southeast, or chute, trapdoor, whatever...no need to limit yourself
>to anything, and why store pointers that you don't need?

Well, two issues:

1) You have to save the text names for all the directions, which depending
on implementation can cause memory problems. That said, the common
directions would be re-used alot in a shared string system, but you still
add some overhead.

2) Back to the original post, the idea is to be able to have a description
generator not dis-similar to a ray caster. The more directions you impose
the more complex it becomes. However imposing arbitrary directions will
break any algorithm I can come up with to generate descriptions on the fly
(being that speed is DEFINATELY a concern).

The thing I think the person who posted this missed is that the original
thread was ways to discard what is generally thought of as a room.

-Katrina

[Nathan F. Yospe]

zeni...@fullnet.net wrote:

:Nathan F. Yospe wrote:

:> Originally, I implemented that 26 direction thing on a Diku, with letters

:> in place of the doornumbers in are files. That was long ago.

:Umm, why not just dump the array implementation of doors, use a linked

:list approach with unique ids within the exits, and have them named as
:the builder sees fit? sure, they can name them as Northwest, Down to
:the Southeast, or chute, trapdoor, whatever...no need to limit yourself
:to anything, and why store pointers that you don't need?

Eventually, I did this as well. Later, in Physmud++, I began implementing
spacial transform driven boundary spaces, where an exit was just a construct
built into a boundary space. Then I started tracking orientation and getting
the ahead/off to the right/directly below you

:Zoran, an ordinary coder with delusions of knowledge :)

I think you'll do quite well. All us other delusional supercoders started
out that way...

[da...@oceanic.demon.co.uk]

This is useful for terrain but even then having 25+ directions would not
noly have the potential to cause chaos and get people lost but do this -
design the area - I guarantee you'll have headaches for any large area!
Nice idea but unfeasable unless you have huge amounts of time and
patience.

Dave

>
>:
>:NWU NU NEU\

>: NW N NE\
>:WU U EU NWD ND NED
>: W X E
>:SWU SU SEU\ WD D ED
>:\ SW S SE\
>: \ SWD SD SED

>:

[Ron Cole]

Nathan F. Yospe wrote:
>
[snip]

>
> This is also good. I have noticed that you have limited yourself to the
> four directions still... at the very least, go with a 25-point cubic.
>
> IE,
>
> NWU NU NEU\
> NW N NE\
> WU U EU NWD ND NED
> W X E
> SWU SU SEU\ WD D ED
> \ SW S SE\
> \ SWD SD SED
>

Hm. Isn't the MUD L.O.R.E. trying something like this?
I believe they are using a (modified) SMAUG platform, though.

-= Rindar

[Nathan F. Yospe]

<da...@oceanic.demon.co.uk> wrote:

:This is useful for terrain but even then having 25+ directions would not

:noly have the potential to cause chaos and get people lost but do this -
:design the area - I guarantee you'll have headaches for any large area!
:Nice idea but unfeasable unless you have huge amounts of time and
:patience.

I think you're trapped in the "room" concept, here. This is actually
oriented toward phasing out rooms altogether. This was stage one, and
used a "left"/"right"/"ahead"/"above" frame of reference. Later versions
delocalized to the point of having a floating point conversion handling
the angles and an output parser interpreting them as natural english. In
this eventuality, players had to resort to landmarks. I'm taking it one
step further now... the locational nodes themselves have become dynamic,
and can merge, split, and consume. I'll post more at a later date, when
I've worked out some of the details.

:>:NWU NU NEU\

:>: NW N NE\
:>:WU U EU NWD ND NED
:>: W X E
:>:SWU SU SEU\ WD D ED
:>:\ SW S SE\
:>: \ SWD SD SED

:>What about playability? Are people really going to want to play a MUD

:>where they have to worry about 26 different directions? While NSEWUD does
:>not accurately reflect reality, it does play easily.

--

[Logic]

On Wed, 24 Sep 1997 14:38:44 -0500, ain...@enteract.com <ain...@enteract.com> wrote:
>On Tue, 23 Sep 1997, Nathan F. Yospe wrote:
>
>> I think you're trapped in the "room" concept, here. This is actually
>> oriented toward phasing out rooms altogether. This was stage one, and
>> used a "left"/"right"/"ahead"/"above" frame of reference. Later versions
>> delocalized to the point of having a floating point conversion handling
>> the angles and an output parser interpreting them as natural english. In
>> this eventuality, players had to resort to landmarks. I'm taking it one
>> step further now... the locational nodes themselves have become dynamic,
>> and can merge, split, and consume. I'll post more at a later date, when
>> I've worked out some of the details.
>

>Remember those BBS games that had an overhead map? Why not do something
>like that?
>
>.......|......&......
>.......+------+------
>..#...........|......
>.........^....|......
>..............|......

Holy nethack, batman. :-)

Actually, this is a good visual aid, but it's no replacement for what
can be supplied by descriptive prose. Instead, use it as a supplement;
generate an overhead view of your surroundings, taking light factors
and sight impediments into account (if you've ever played Ultima 1
through 5, you'll have a very good feel for what I'm describing), and
generating a description of what you see.

While the overhead view allows for the majority of cases, special-
purpose descriptions aren't possible without a fair bit of maneuvering
on the part of the player (for example, having one character represent
a "special thing", which you can't see until you explicitly issue a
"look at thing"...it precludes the possibility of you getting some feel
for the object before examining it in detail. What happens when that
special object happens to be a very nasty little snake that bites when
you get too close, such as when examining it...;-).

Whilst looking at this idea for my design, I finally ran into the wall
that plain textual characters simply weren't descripive enough. When
you start going this way, it begins to make sense to investigate the
possibility of a graphical client. My model has always been the
overhead views that the original Ultima games made famous...very bare-
bones in design, but allowing for good individualization of each unit
in the gameworld.

Here's another twist on the coordinate-based world design concept: wide
open spaces. Do you design everything to a single scale, making for
truly vast worlds, or do you work (as Ultima, for example, did) with
modified scales depending on location. (To be fair, Ultima only had two
scales: inside a towne/city/castle's walls, and in the great outdoors;
it also had a first-person viewpoint for undergrounds settings, giving
a great claustrophobic feeling.)

For example, would you go with a 1:1 scale inside a building, while
opening up to 1.5:1 or 2:1 outside the building, in a town, and going
as far as 6:1 or 7:1 in the "wilderness" outside of inhabited areas?

In this case, adopting the "party" design starts to look tempting
(ie. movements in the great outdoors can be done in groups). At what
scale do you start to adopt party design; ie. the whole party now
occupies only one unit of area as opposed to each person occupying a
unit of their own?

There's a lot to decide when moving to a scheme like this; luckily, a
lot of ideas (both good and bad) are available to us from older
adventure games; Wizardry, The Bard's Tale, Ultima, and others all
addressed the idea of only providing enough graphical interface to
describe what words couldn't handle in a manner that wouldn't seem
clumsy, and leaving the rest to your imagination.

Best games I ever played. :-)

--
_ ____ ____________________________________________________________________
/ /___/\__ \
/ \ \ \/\ lo...@logic.net \
\ \ \ / http://www.logic.net/~logic/ /
\___\___\/__________________________________________________________________/

[Steven Becke]

Hmmmm. i was thinking of moving away from a mud consisting of "rooms"
I started writing an engine such that the mud consisted of overlaying
2d arrays, i guess you could call them maps, that were then
"interpreted" by the mud. ie, it would look at the map, and describe
your surroundings. They worked like the maps in Magic Carpet to create
a mock 3d effect, except it would be a textual interpratation rather
than graphical. The problem is of course it doesn't make very interesting
discriptions, and i'm not sure how to handle movement.

here is a sample of the kind of output it would make

The ground is flat here. There are hills to the north. Far to the north
an ocean can be see. There are hills to the east. Far to the east are
mountains. The ground is flat to the south. Far to the south the ground
is flat. There are hills to the west. The hills to the west are covered
in a thick forrest. Far to the west are hills. The hills far to the west
are covered in a thick forrest.

as you can see it needs some work :)

[christopher john raehl]

Well, what you have isn't too bad actually. The description you've
provided is more than adequate for describing things that are in the
distance, it just does a poor job of describing where you are. You just
need to add in a 'customized' description that you only see when you're
actually there. Thus, instead of just displaying comments about the
terrain, you can display a description of where you are and then add the
general descriptions of what's in the distance.

Only problem is that it IS getting you back towards the room concept,
since your specific descriptions are each tied to a specific area.... On
the other hand, it wouldn't be too far fetched to just have general
descriptions. Obviously, if you're walking through a big field, you're
going to see grass. You don't need a detailed description of more grass
as you move through the field, or of more trees as you move through a forest.

Perhaps one could sort of combine the two systems. Start with a basic
map which consists of terrain, and contain the data in a high-resolution
array. (By resolution, I mean a traditional 'area' may have 10,000
different 'rooms', but you can interact with objects within 5-10 'rooms'
of you. Then you can perhaps define 16 different movement directions,
n, s, e, w, nn, ss, ee, ww, nnn, sss, eee, www, and nnnn, ssss, eeee,
wwww. (or 12, or whatever) Then say n moves you 10 'rooms' at a time,
while 'nn' moves you 5 'rooms', etc. Then you can easily move quickly
across lots of space, but then also not move so much if you're sneaking
around or checking out a spot of interest in detail.

So what we've created is an array of positions. Each player or object
or what not has a 'position' assigned to it, and players can interract
with objects that are within X positions of them. Back to the
descriptions, you just put a field in the object noting from how far away
it can be seen. Thus, you might have to be in the same position as an
ant to see it, but you can see a helmet lying on the ground from 4-5
positions away, and see that big dragon that is about to eat you from
10-20. The general terrain function you already have can then describe
how the terrain changes 40-50 or 100 positions away, i.e. you see this
building, there are some trees over there, yada yada yada.

On the note of an object, lets say you have your field, but somewhere
in your field is something a little more interesting than grass. Instead
of using the traditional 'room description', you define an object type
that exists soley as a description. Thus, instead of seeing something
like "There is a helmet here." the object yields a more detailed
description when you get close to it. Say, there is an area of the field
that has been trampled down. Instead of needing a separate 'room', or
needing to define part of your array as a room or needing to tag a
separate detailed descrription for each of the 100,000 positions in your
area, you just make an 'object' which can be seen for 8 positions with
the 'description' of the trampled grass in place of the traditional
'long_desc' you'd find in circle. (Just make it so the object type isn't
otherwise manipulated.)

So lets say we actually code this. The way it would work (this is
just off the top of my head here) is a player moves. Then the code
starts searching out from his position radially. As it encounters
objects, it checks to see if the object is close enough to the player to
be seen, and if it is, it puts it into one of 3 lists of "descriptive
objects", "objects", and "mobs/players". Then you'd display the
descriptive objects, then run the function to describe the terrain
you're on, then run the function you've already made to describe the
terrain that is more distant, and finally display the players and objects
that the player can see.

There are some extra bonuses with this. Firstly, you obviously get a
lot more positions and are freed from that troublesome room system. On
top of that though, players there's some added movement realism. Lets
say I'm in a hurry, and I run through an area really fast. According to
the room system, I see every object and mob I run past, no matter how big
or small. But with this system, if I have an object that is really
small, i.e. can't be seen inless you're right next to it, I might just
run by it without even seeing it.

On the same note, you can modify hide and sneak and camou so that
instead of making the player invisible or what not, it just makes it so
they can only be seen from 2 or 3 positions away instead of 10 or 20.

It would also be easy to code up a function which makes things more or
less visible based on terrain. Lets say you've enterred a heavily wooded
area. Then maybe your function makes it so you need to be twice as close
to an object to see it than you would normally. Or perhaps you make a
pair of binoculars, which allows you to see objects when they are 5 times
as far away, assuming you point the binoculars in the right direction.

I'm sure you can all come up with some more uses for this system on
your own. I'm putting the code together in my head, and it doesn't look
THAT bad, the only sticking point I'm hitting is areas that you don't
want players to go to. Obviously, it will take some adjustment to change
from the 'enclosed' system that most players are playing and back to the
'open' system that we are all used to in real life: There is no path in
the forest that only lets you go north and south, you can always go off
the path and go east or west.

Any thoughts? I have aparently become much more verbose than I
originally intended.

Here's a test: HEY, guy who wants that rec.games.mud.design group so
bad, are you reading this? Or are you too busy trying to assure your own
newsgroup (ego boost) to bother with actual design issues? I fugure the
best way to fight the bad signal to noise ratio is to post more signal.

- Erabus

Of course, it wouldn't hurt if you could get your program to use a
couple gramatical variations randomly so it wasn't always using the same
sentance structure.

[John Adelsberger]

Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
: mor...@niuhep.physics.niu.edu wrote:

: :I also vote for 9 + 8 + 9 (= 26 not 25, for shame, Nathan!) possible
: :directions. (which may actually be implied by your drawing of the vision
: :cone?)

: Oops. 0-25 inclusive == 26, not 25. Heh. Sue me, I'm better at manifolds
: and transforms than arithmatic...

Or spelling?:-)

Seriously, if you're going to keep a room based system(which makes sense for
a lot of muds,) you really don't even need a formalized set of directions.
Just link rooms with appropriately named exits and superimpose a coord system
for no purpose other than allowing you to make sure rooms don't overlap.
Maps will work out ok when drawn, and your area coders can make areas look
like whatever they want. Up, down, spiral stair, hell, why not use all of
them for exit names, where appropriate?

--
John J. Adelsberger III
j...@umr.edu

[John Adelsberger]

Katrina McClelan (kit...@directcheck.aries.net) wrote:

: PS: I curse the first person who tries to turn this into an LP vs diku, or

: a stock vs scratch debate to have all of their children be born naked :)

If a person were to attempt no such change of subject, but his children
were born naked anyway, would he be entitled to compensation?

[Szokoli Gabor]

Hi!

I'm new here, and like your idea a lot, BUT:
It looks a real CPU hog to determine what is near to me, let alone
obscuring objetcts, like hills or dragons :-)
And seeing an ant behind them sounds redicioulus (or how to spell that)

So, are you "raytraceing", or determining the distance of all objects
froom the one in question, or are you using any kind of caching?
(Eg if the hills were 100 miles away the last time, they are probably
still far)
Or are you creating groups of the objects from the point of view of
each player (seeing thing) on the field? That's almost caching again.

I'm interested, and have many ideas, but they are all EXPENSIVE.

Szocske

[Vadim Tkachenko]

This is a multi-part message in MIME format.
--------------0173ED27EB68775DD1F92909
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

John Adelsberger wrote:
>
> Seriously, if you're going to keep a room based system(which makes sense for
> a lot of muds,) you really don't even need a formalized set of directions.
> Just link rooms with appropriately named exits and superimpose a coord system
> for no purpose other than allowing you to make sure rooms don't overlap.
> Maps will work out ok when drawn, and your area coders can make areas look
> like whatever they want. Up, down, spiral stair, hell, why not use all of
> them for exit names, where appropriate?

By the way, the logical consequense is to define a 'link' object, which
you can then populate with features like locks, traps, one-way
connectivity, [partial] invisibility etc.

> John J. Adelsberger III
> j...@umr.edu

--
Still alive and smile stays on,
Vadim Tkachenko <Vad...@4CS.Com>
--
UNIX _is_ user friendly, he's just very picky about who his friends are
--------------0173ED27EB68775DD1F92909
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Vadim Tkachenko
Content-Disposition: attachment; filename="vcard.vcf"

begin: vcard
fn: Vadim Tkachenko
n: Tkachenko;Vadim
org: 4C Solutions, Inc.
email;internet: vad...@4cs.com
title: Web Developer
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
end: vcard

--------------0173ED27EB68775DD1F92909--

[Vadim Tkachenko]

This is a multi-part message in MIME format.

--------------341229828C05FE659E72B9A3

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sure.

For me, the alternatives are:

- least expensive - divide world into rooms (I suspect, all the
implementations that have rooms do that because of this) - you simply
restrict the 'sense' to zero length;
- more expensive and quite a bit latent - each object which should sense
anything at all just has a background thread which constantly monitors
the objects' movements and actions in the 'sensitivity zone' and stops
watching for them if they leave the zone, and other one, which checks
others with a low priority.
- combination - divide world into zones, not rooms - let you continue
the line.

> Szocske

--
Still alive and smile stays on,
Vadim Tkachenko <Vad...@4CS.Com>
--
UNIX _is_ user friendly, he's just very picky about who his friends are

--------------341229828C05FE659E72B9A3

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Vadim Tkachenko
Content-Disposition: attachment; filename="vcard.vcf"

begin: vcard
fn: Vadim Tkachenko
n: Tkachenko;Vadim
org: 4C Solutions, Inc.
email;internet: vad...@4cs.com
title: Web Developer
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
end: vcard

--------------341229828C05FE659E72B9A3--

[christopher john raehl]

Well, if you've taken a look at your MUD code recently, this isn't
really that intensive compared to the rest of it. Basically, anytime
someone does something to cause them to look around (i.e. move or type
'look') you just check all the positions within 20 of you or so.

Actually, another way to do this that would still allow easy building
and manipulation is to put a pointer list in each position and create the
pointer list when you load up the zone. Thus, when the zone is loaded,
for each position, you have a pointer list of pointers which point to all
the objects that can be seen from that position. This makes it easy to
figure out what you can see from any given spot without having to go
through some search pattern. Only problem I see with this is that when
players or objects move, you've got a bunch of pointers to change.
(Actually, you only need to change the ones which actually CHANGE, and it
shouldn't be too hard to determine how a move affects the position
change.) Another problem with this is that its still based on four
directions, you see the terrain in the distance to the north, south, east
and west, but what about that really big tree to the northeast of you? I
suppose you could have terrain objects dealt with just like other objects
in terms of being seen, but say if you get within X positions of the
position of a big hill, you no longer 'see' it because you are ON the hill.

So you could either construct a list of pointers to each of the
objects that can be seen from each position for each position, and do
that once when you load up the zone (but then have to deal with changing
all thos epointers when objects move) OR you could search out radially
each time you move (but then how far do you search before you stop
searching? There are a LOT of positions within 100 positions of one
position.) And we're still sorta stuck on the 4 directional thing. I
suppose you could keep it at 4 directions of movement, and then make a
small function to parse out descriptions which put objects in one of
eight directions from the character. There really isn't that much
difference between north and northwest anyway, so 8 different directions
should be sufficient for figuring out exactly which direction something
lies in. (You search an area around the player, but the vector from the
player to the object he sees is described as being in one of the 8
directions, even if it isn't exactly.)

Any more effecient ways anyone can think of to do this?

- Erabus

>
> I'm new here, and like your idea a lot, BUT:

> It looks a real CPU hog to determine what is near to me, let alone
> obscuring objetcts, like hills or dragons :-)
> And seeing an ant behind them sounds redicioulus (or how to spell that)
>
> So, are you "raytraceing", or determining the distance of all objects
> froom the one in question, or are you using any kind of caching?
> (Eg if the hills were 100 miles away the last time, they are probably
> still far)
> Or are you creating groups of the objects from the point of view of
> each player (seeing thing) on the field? That's almost caching again.
>
> I'm interested, and have many ideas, but they are all EXPENSIVE.
>

> Szocske
>
>
>
>

[Robert M. Zigweid]

"ain...@enteract.com" <ain...@enteract.com> writes:

[snip]

> > Seriously, if you're going to keep a room based system(which makes sense for
> > a lot of muds,) you really don't even need a formalized set of directions.
> > Just link rooms with appropriately named exits and superimpose a coord system
> > for no purpose other than allowing you to make sure rooms don't overlap.
> > Maps will work out ok when drawn, and your area coders can make areas look
> > like whatever they want. Up, down, spiral stair, hell, why not use all of
> > them for exit names, where appropriate?
>

I've been thinking about this kind of thing for a while, and I almost
agree with you. Accept there is nothing stopping the fact that two
rooms can have the same coordinates. I think that the size of a room
should vary based on a couple of factors.
1.) The size of the environment in question. For example, compare a
closet and a Ball room. Now, unless I'm misinterpreting you, if no
room is to have the same coordinates as another room, you either have
to break the ballroom up into closet sized coordinates, or you have to
have a REALLY big closet..

2. ) How near a 'point of interest' you are. If you are out in a
forest, It doesn't really make a whole lot of sense to have 400 rooms
separating two points of interest for the illusions of them being far
apart. I am more in favor of having the rooms be larger. To make it
take longer to get accross these rooms I still havent' seen or thought
of an adequate method for delay so that people don't use clients to
rip accross the distance in half a second

> Because a few people with lameass mud clients will complain that they can
> no longer use the 'arrow keys' to move around.
>
>
> ---
> "every existing thing is born without reason, prolongs itself out of weakness
> and dies by chance." - jean-paul sartre

Wah. Pretty sad day when mud administration would change things like
exits to support clients that a few people have so they don't whine.
Makem deal w/ it.

Tigran

[Alberto BARSELLA]

In article <Pine.SOL.3.91.97100...@ux5.cso.uiuc.edu> christopher john raehl <ra...@students.uiuc.edu> writes:

> Any more effecient ways anyone can think of to do this?

You can think to create a table which says what *places* you see when
you stand here. This way you don't have to track object movements, you
just have to take all objects which are in places visible from the
current point. "visibility" links could be conditional, too,
reflecting opened/close doors or atmospheric conditions.
The problem: you have to store a fairly big table for every position,
or you have to reduce the "resolution" of the positioning of objects.

Let me throw in a couple more ideas:

1) hierarchical structure

You use a quadtree (octree?) to partition the space, and keep the
"visibility links" at different depths of the tree. The objects also
are placed at different depths of the tree. For example consider a
depth 8 tree. At depth 8 you are at "room level", you use it to store
objects which are sub-room-sized, and thus visible from a short range
(you won't be seeing an axe from 1000 m). At depth 7 you store bigger
objects, like houses. Bigger and bigger objects are higher and higher
in the tree, for example a mountain might be at depth 5.
Creation of a room description the uses the "visibility table" of
depth 8 to check the nearby (depth 8) areas, then climbs up the tree
to depth 7 and uses the visibility depth 7 (which is assumed identical
for all the rooms in the node). Etc, etc, as you go up the tree.
This allows for some "reuse" of visibility links, but will still leave
you with a huge table (which BTW is static or almost static, so it
could be computed outside the server by some "area compiler").

2) statistical approach

visibility is not "yes" or "no", but a % of seeing an object.
This means that two rooms connected by a hole in the wall will not
have visibility 100%, but less. A character hiding might even lower
the visibility %, and environment (a forest) might lower it, too.
In order to avoid objects "appearing and disappearing" randomly if the
same description is generated multiple times you can use a reseedable
random number generator and seed it with (for example) position
in the room, or you might keep a "seed" for each character and define
operations which change it (hide, move), and operations who don't.
This way two people in the desert will always see each other
(visibility 100%), two people in two rooms connected by a hole might
see each other now, then one moves (seed changes) and they can't see
each other anymore.

Considering that you'll have a lot of mobs wandering around and
LOOKING around all this nice ideas will eat up a lot of CPU
power.....

Bye,
Alberto

--
Alberto BARSELLA
PGP fingerprint = 13 3F 22 D2 0B 0A D3 25 F1 89 FE B5 82 AD 75 2A
------------------------------------------------------------------
"Beliefs are dangerous. Beliefs allow the mind to stop
functioning. A non-functioning mind is clinically dead.
Believe in nothing..."
------------------------------------------------------------------

[John Adelsberger]

christopher john raehl (ra...@students.uiuc.edu) wrote:

: 'look') you just check all the positions within 20 of you or so.

20x20 is 400 checks per player move. That's a bit steep.

: Actually, another way to do this that would still allow easy building

: and manipulation is to put a pointer list in each position and create the
: pointer list when you load up the zone. Thus, when the zone is loaded,
: for each position, you have a pointer list of pointers which point to all
: the objects that can be seen from that position. This makes it easy to
: figure out what you can see from any given spot without having to go
: through some search pattern. Only problem I see with this is that when
: players or objects move, you've got a bunch of pointers to change.

How about just a 2d matrix of pointers mapped to locations if you insist
on fill-mapping? You'll consume memory like it was going out of style,
but not as badly as what you describe above. A better scheme, by far,
from the memory standpoint, but one that hurts your CPU, is to have a
cache of stuff near the player and update it when he moves, only at the
edges of his vision, and not even have a map, but rather just a bunch
of objects and their coordinates. If you really want to get fancy, you
could probably improve on this, but since I'm leaving town in a few
minutes for the weekend, I'm not going to ponder it right now.

: in terms of being seen, but say if you get within X positions of the

: position of a big hill, you no longer 'see' it because you are ON the hill.

Minimal distance for visibility is a valid concept. However, you should
still see the hill in this case - surely it'll be obvious that you're on
a hill?

"You are standing atop a rocky hill next to a pine tree."

: difference between north and northwest anyway, so 8 different directions

: should be sufficient for figuring out exactly which direction something
: lies in. (You search an area around the player, but the vector from the
: player to the object he sees is described as being in one of the 8
: directions, even if it isn't exactly.)

The caching technique described above will let you use a true coord system,
but then your main problem is generating reasonable looking descriptions,
instead of efficiency. That is a harder one, and is the reason this mud
coder isn't doing coords.

--

[Corey Brenner]

christopher john raehl <ra...@students.uiuc.edu> wrote:
: Actually, another way to do this that would still allow easy building
: and manipulation is to put a pointer list in each position and create the
: pointer list when you load up the zone. Thus, when the zone is loaded,
: for each position, you have a pointer list of pointers which point to all
: the objects that can be seen from that position. This makes it easy to
: figure out what you can see from any given spot without having to go

So, for each of m rooms you'll have n pointers in the list... That would
seem to me to be *way* too much overhead. M*N pointers would eat up more
memory than the areas!

: So you could either construct a list of pointers to each of the
: objects that can be seen from each position for each position, and do
: that once when you load up the zone (but then have to deal with changing

: all thos epointers when objects move) OR you could search out radially
: each time you move (but then how far do you search before you stop
: searching? There are a LOT of positions within 100 positions of one

Eeek! that'd be something like O(n^n) for the search!

--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
============================================================================
Corey D. Brenner -- (bre...@umr.edu) | C:enter:### -- Windows Users' Creed
----------------------------------------------------------------------------
"A blessing on anyone who seizes | If you're not part of the solution,
your babies and shatters them | you're part of the precipitate.
against a rock!" | -- Stephen Wright
-- Psalms 137:9, Jerusalem Bible |
============================================================================
"I yam Popeye of Borg. Resistinks is futile. You will be askimilgrated."

[christopher john raehl]

Well, I hope you've caught hte other thread on using positional
arrays and disregarding rooms all together. Thus, you have LOTS of very
small "rooms", (positions) but you treat a bunch of rooms in the near
vicinity to a player as the same room. So you see all the objects within
X of you (X can vary by objecT), you can define some positions to be
walls which block out what you can see. I suppose you could go three
dimensional arrays as well, maybe 100x100x4 or 5 levels for any given
"zone". Kepp the same 4 movement directions, but make it so you can move
in large incriments or small incriments. The difficulty comes in the
algorithms to search the vicinity for visible objects, which is where
we're at right now. The nice thing is that you've essenially eliminated
room descriptions, you can just have locations be described by what the
ground looks like and what objects (from a rock to a sign or the
mountains in the distance) can be seen. You're still on a coordinate
system, but the resolution is much higher. (Think like Diablo a little,
only not limitted to seeing what's on the screen.)

- Erabus

[christopher john raehl]

> > Any more effecient ways anyone can think of to do this?
>

> 1) hierarchical structure
>
> You use a quadtree (octree?) to partition the space, and keep the
> "visibility links" at different depths of the tree. The objects also
> are placed at different depths of the tree. For example consider a
> depth 8 tree. At depth 8 you are at "room level", you use it to store
> objects which are sub-room-sized, and thus visible from a short range
> (you won't be seeing an axe from 1000 m). At depth 7 you store bigger
> objects, like houses. Bigger and bigger objects are higher and higher
> in the tree, for example a mountain might be at depth 5.
> Creation of a room description the uses the "visibility table" of
> depth 8 to check the nearby (depth 8) areas, then climbs up the tree
> to depth 7 and uses the visibility depth 7 (which is assumed identical
> for all the rooms in the node). Etc, etc, as you go up the tree.
> This allows for some "reuse" of visibility links, but will still leave
> you with a huge table (which BTW is static or almost static, so it
> could be computed outside the server by some "area compiler").
>

This isn't actually too bad. I think tree is a bit of a misnomer
however. I think linked lists would be more appropriate. Thus, lets say
we have 8 levels of 'visibility'. When I make my room description, I
skip levels 1 through 3, since those are probably terrain featrues of
varrying size which I'm either in or on. So each room has an array of
0-7 each containing a pointer to an object (or not) which has pointers to
another object. So instead of having to check each object in each
position in the vicinity, I can just check the list of objects in certain
spots of the array. Then I'm not hopping all over a tree.
Of course, it would be nice if when I was checking positions that are
farther away (since there would be LOTS of them) I could just check a
couple positions and know if there's any BIG terrain there instead
ofhaving to check every position. Hmmm.... Maybe its just easier to
code terrain types and altititude into the room types....

- Erabus (the extremely tired and not thinking straight)

[christopher john raehl]

On 2 Oct 1997, Corey Brenner wrote:

> christopher john raehl <ra...@students.uiuc.edu> wrote:
> : Actually, another way to do this that would still allow easy building
> : and manipulation is to put a pointer list in each position and create the
> : pointer list when you load up the zone. Thus, when the zone is loaded,
> : for each position, you have a pointer list of pointers which point to all
> : the objects that can be seen from that position. This makes it easy to
> : figure out what you can see from any given spot without having to go
>
> So, for each of m rooms you'll have n pointers in the list... That would
> seem to me to be *way* too much overhead. M*N pointers would eat up more
> memory than the areas!
>
> : So you could either construct a list of pointers to each of the
> : objects that can be seen from each position for each position, and do
> : that once when you load up the zone (but then have to deal with changing
> : all thos epointers when objects move) OR you could search out radially
> : each time you move (but then how far do you search before you stop
> : searching? There are a LOT of positions within 100 positions of one
>
> Eeek! that'd be something like O(n^n) for the search!
>

Yeah, everything I come up with either eats all the memory or makes the
processor explode. I post it anyway hoping it'll give someone else an
idea. ;)

- Erabus

[christopher john raehl]

Yes, indeed, the memory etc concepts suck. But you all keep improving
on the ideas slightly, so eventually, we might get somewhere. As for
descriptions, MOST of a mud (or area) is non-descript. I mean, you're
walking through a field, what do you see? A field. the thing is when
you get to a point of interest, you DO need to describe that. But that I
coverred in another post, you just have an object there that is easily
visible and contains the description you want to display. Thus, you
don't need "room" descriptions at all, you just describe things in
detail, when you get close to things. For instance, lets say we have two
points of interest about 20 yards apart. No, lets say I'm standing 20
yards from one and 40 yards from the other. I might see the description
assigned to the one object, but not the one for the other. But lets say
I'm standing smack in the middle of the two, then I'd se the detailed
descriptions of both 'locations' described. I'm not in a 'room', I'm in
a place, and at this place, there are these things. you jus need to keep
in mind that places overlap. They don't neatly come to an end where the
next place begins. That's the weakness of the room design that we're
trying to get around: People right next to each other should ALWAYS be
right next to each other, wether or not they happen to be right next to
each other on opposite sides of the dividing line between the room or not.

Of course, its all great in theory, still need to figure out how to
code it without causing hte computer to explode. Right now, I've got a
combination of caching the area in the near vicinity of a player aong
with splitting objects into about 8 lists for each 'position' (keeping in
mind that most positions will be empty) so that I don't need to check ALL
the objects for each position. Thus, I can group objects into 8 ifferent
groups based on'size', terrain into one group, ants into the last group.

here's a thought: What if I have a 100x100 position 'zone', and you
can put things in any position, but I INDEX everything in a 10x10 array.
This would work pretty well since we're assuming most positions are
empty. Thus, if I'm in position 57,64, to see what object are nearby, I
just need to check the indexes for 4,5 4,6 4,7 5,5 5,6 5,7 6,5 6,6 6,7.
This would be much better than having to check everything on th range
47..67,54..74. then I can keep my 8 list divisions, and then have each
object in each 10x10 index also have a positional index that defines
where, exactly, in the 10x10 area it is.

So what we end up with is a hybrid between the room and position
system. Everything is still contained in rooms, but the "rooms" have a
bunch of positions within them for things to occupy. Then we can easily
check for objects and players like we normally would with a room system
(only also check the neighboring rooms as well) but allow people to see
objects in nearby rooms. Plus, then we don't have to search for terrain
features in the distance, we can just define the terrain features visible
for each room area in the room file, since the terrain features you see
in the distance won't change much over the small distance of one room.

So, we have something like: (excuse the syntax, cause I'm still kinda
just learning C syntax over the other languages I know)

#define x 0 /* to alias xyz coordinates for positions
#define y 1
#define z 2

struct obj_data = {

struct obj_data *next_obj, /* next object in list */
ubyte pos[3], /* position within the room */
longint type; /* object type, mob, terrain, description, object, etc. */
char *desc; /* description */
/* bunch of stuff to describe objects which we don't care about righ
tnow, pretty standard. */

};

#define TERRAIN 0
#define BUILDING 1
/* down to */
#define TAKEABLE 5 /* things you pick up, so you can check for objects people
take and the like easy */
#define MOBILES 6 /* special spot for things that move aroudn lots, check
for mobs and move them around easy */
#define REALLY_SMALL 7 /* so we can pick objects out of room arrays by
size */

struct room_data = {

int zone;
ubyte position[3]; /* position in zone array */
struct *obj_data objects[8]; /* 8 spots for lists of objects, so we only
have
to check certain lists of objects instead of a list for ALL the objects
based on how far away the room is. */

struct zone_data = {

struct *zone_data neighbors[6]; /* zones that are next to this one, in
the 6 directions. Null for no zone, etc. */
struct *room_data zone_array[10][10][5]; /* 5 Z coordinates, so you could
fly around too or something, move up hills, under hills, yadda yadda */

then just a table of all the zones.

so we've tabled everything up and drastically reduced the memory and
checking required. Any other further improvements? I'd love to polish
this off more, but its time to go. Thanks to all the other people in the
newsgroup who I stole ideas from.

- Erabus

On 2 Oct 1997, John Adelsberger wrote:

> christopher john raehl (ra...@students.uiuc.edu) wrote:
>
> : 'look') you just check all the positions within 20 of you or so.
>
> 20x20 is 400 checks per player move. That's a bit steep.
>

> : Actually, another way to do this that would still allow easy building
> : and manipulation is to put a pointer list in each position and create the
> : pointer list when you load up the zone. Thus, when the zone is loaded,
> : for each position, you have a pointer list of pointers which point to all
> : the objects that can be seen from that position. This makes it easy to
> : figure out what you can see from any given spot without having to go

[Szokoli Gabor]

How about this: (It mostly contains only the synthesis of earlyer posts:)

I have a "global" map, describing the locations of cityes, forests, fields,
and their linkage (explained later)

These areas are objects keeping track of all objects in them, by coordinates.
All objects have more levels of description, depending on distance.
Each object has sets for each distance level, containing the objects
it may have visual contact with (can see it, or be seen by it)
Or should I separate those?
Yes, I shold: seeing objects need " I see them " sets, moving r
changing objects need "I can be seen by them" sets .
So when an object movesjust a little bit, it checks only the
"rigt here" and "close" sets: notifies objects "right here", and
checks if the objects in both sets are still at the specified distance
, and rearanges the sets if necessary( if it went "right next to" an
object, that was only close before, then it is moved to the right set.)

When it moves more (it records the coordinates where it updated each set)
it also adjusts the sets of further objects.
(so that if a hill is rolling on the horizon, the players seeit move
sometimes, eg when it is no more to the west, but north-west.)

The same is true the other way around, but maybe that is unnecessary:
objects that can see keep track of the objects they see at the moment,
and those witch are only one "set" away from being seen,
update these sets as they move.
My problem is the following:
there is no obscurance
as I aproach an ant, it is not in any of my sets, till i get "close"
(I still can not see it then, but I must pay atention to it, because it may
easyly get "right here" ) To notice that it is "close", I have to
compute my distance from all small objects in the field.
It may be hashed by dividing the field to 10 by 10 squares, but thats extra
memory need on top of the first idea. Or is it?
The filed(or forest) does it, as all of the above, so it may be optimised.
And I think I know how!

Lets forget all the above, and consider this:
to each seeing (how should I spell that word?) object an object of
short range sight is assigned, to be presise, these may be common,
as players meet, or roam in a group.
These are enclosed by long range area objects, that may contain more than
one short range area.
This may continue to higher ranges, but I think it's enogh:
these area objects hash the area they cover, and keep track of the
lower level area objects in them,(the smallest scale one of the seeers)
and supply the set of objects that can be seen from the smaller scale area.
Each level considers only the objects of proper size, gets the bigger
objects from the higher levels of the hierarchy, and leaves the smaller ones
to the lower levels.

Am I making myself clear?

Obscuring (Is this the right word? I mean hidng behind)
is computed by the object that is looking arond, because x-ray eyes
may penetrate more, than the sonar of a bat :)

The scale of the area objects has nothing to do with the detail level,
the whole thing supplies only the set of objects that have to be considered,
when the full description of the scene is generated.

This may also solve the problem ofbeing on a hill we just saw:
the hill as seeable bjects only exists on highscale, to lower scale
examination, it is a modyfier to the area object (or a property, to be
presise).

I think, I should stop here, because my head is full of ideas,
mostly abouth a graphical tool to design such "layered" maps ...

Szocske

[CT Shock]

[snip]

> >
> Yeah, everything I come up with either eats all the memory or makes the

> processor explode. I post it anyway hoping it'll give someone else an
> idea. ;)
>
> - Erabus

Oh ick! The guy who suggests a quadtree/octree approach is on the right
track (IMHO). However, I wouldn't store pointers to objects into levels of
a hierarchical structure based on the size of the object. For starts, you
don't need a pure quadtree approach, but something like it can give
excellent performance. Without going into too much depth, consider the
following for quadtrees:

-- excellent performance for "spatial join", good performance for "window"
queries, can be implemented as a disk-based structure.

-- average performance for insert, good performance for search (O(log4(n)),
potentially hideous performance for deletion. In short, they make great
read-only structures.

Sooo... one suggestion might be:
1) Implement a quadtree that stores "tiles". Each tile is a region in your
world. The tile itself is static, however the contents of the tile are
dynamic. You can make the tiles fairly small and even implement them as an
array or something else that handles deletions and insertions well (with
perhaps average performance for "window" and search). Now you've busted up
your world into static chunks. The quadtree gets you to the right chunk
quickly and efficiently.

2) Use a disk-based implementation. This works out really well if a tile is
some multiple of the machine's page size. The classic implementation is to
use a B-tree or a grid-file as the underlying implementation with some
fancy indexing techniques (sometimes called "FD Quadtrees"). Now the world
doesn't eat up vast amounts of memory. As a bonus, a disk/tile based
implementation makes it easier to unload unoccupied regions of the world to
reduce CPU load.

3) Don't be afraid to use more than one. It is perfectly reasonable to use
a collection of structures to represent a region. So use a point-based
structure to locate people, a rectangle based structure for buildings, and
a region-based structure for basic terrain (woods, swamp, mountains... also
useful for mapping out regions that are lawful, nomagic, whatever). The
advantage is that you can use the most efficient implementation for each
type of data and only search the appropriate structure for a given question
(i.e. who cares about terrain when I'm casting an area-effect spell? All I
wanna know is who are the people or NPC's in range)

-Todd

[John Adelsberger]

ain...@enteract.com (ain...@enteract.com) wrote:
: On 1 Oct 1997, John Adelsberger wrote:

: > like whatever they want. Up, down, spiral stair, hell, why not use all of

: > them for exit names, where appropriate?

: Because a few people with lameass mud clients will complain that they can

: no longer use the 'arrow keys' to move around.

And any worthwhile mud admin cares because...? This gets back to the whole
issue of not letting players dictate your mud to you.

[A. Eschenburg]

ain...@enteract.com wrote:
>
> On 1 Oct 1997, John Adelsberger wrote:
>

> > Nathan F. Yospe (yo...@hawaii.remove.this.edu) wrote:
> > : mor...@niuhep.physics.niu.edu wrote:
> >

[...SNIP...]

> > like whatever they want. Up, down, spiral stair, hell, why not use all of
> > them for exit names, where appropriate?
>
> Because a few people with lameass mud clients will complain that they can
> no longer use the 'arrow keys' to move around.
>

> ---
> "every existing thing is born without reason, prolongs itself out of weakness
> and dies by chance." - jean-paul sartre

Well, let them whine, and ignore them.. (thogh i personally favour
the idea of having "directions" as normal exits, and if you want
something else, let people do "go <whatever>", that way, exits
never collide with any command offered by any item for any use.

A. Eschenburg
--
--------------------------------------------------------
curiosity kills... not only cats.
-unknown-

[Katrina McClelan]

In <Pine.GSO.3.96.971001153222.26149A-100000@ural2> Szokoli Gabor <s810...@hszk.bme.hu> writes:

>Hi!

>I'm new here, and like your idea a lot, BUT:
>It looks a real CPU hog to determine what is near to me, let alone
>obscuring objetcts, like hills or dragons :-)
>And seeing an ant behind them sounds redicioulus (or how to spell that)

Ok a few definitions:

Border : Something that obscures senses *
Object : Something that can be sensed... borders can be objects too.

* The "lack" of a border is done the same way except that it transmits to
all senses.

Basically all messages would have to pass through borders. All objects
would transmit messages (when applicable). Thus the door would not
transmit the sight of rotten cheese, but might transmit the smell. All
objects would have a means of describing themselves as they appeal to each
sense, and some sort of priority, and manners with which to combine them.
In this manner generating a description is mostly looping through possible
places to "sense" things, and checking borders. It is not terribly
expensive, although is not as detailed as a ray caster. In a way I'm
still using a "room" structure, but not pre-writing descriptions and
limiting sensory range to zero. It has "rounding errors", but is much
better than not seeing the giant approaching from the north. Then there
are more complex methods. Speaking of which I'd like to thank Nathan for
his input. It was most useful.

>So, are you "raytraceing", or determining the distance of all objects
>froom the one in question, or are you using any kind of caching?
>(Eg if the hills were 100 miles away the last time, they are probably
>still far)

I only algorithmically generate local stuff. The hills would be described
as a zone backdrop. In effect, the distant landmark is a special type of
object that doesn't sit in a room. Indoor areas simply would not have
such backdrops.

-Katrina