[MUD-Dev] Realistic travel times/virtual terrain

[Inq Admin]

> From: Richard Tew
> Nice to find an admin that doesn't toady to the "change is implicitly
> bad" crowd :)  I find it so frustrating that people let their mud be
> limited by player objections against things that improve the depth of
> the game - although its not my playerbase at risk, obviously :)
> 
Due to the nature of The Inquisition (the MUD on which I work), which is
centered solely around roleplay, it was a point of contention with the
players that people, in the original Diku movement system, people could
simply zoom thru a room with no chance for others to react to them.  An
event handled movement system  works greatly to reduce that.


> > Our system divides a room into a matrix (width, height and 
> > length) based
> > upon the terrain type (city sectors are much smaller than say,
> > forests) and continuously updates their relative position in 
> > the room with
> > their direction of travel.  It can be halted at any time, with several
> 
> Ahah.  Very similar to how we do it.  I have seen the term "roomless
> coordinate system" mentioned in this forum, can someone confirm to me
> that something like this falls under that definition?  If not, a
> definition of roomless would be great.
> 
I don't believe ours qualifies as 'roomless', as the coordinates are
endemic to the room; they are reinitialized for each seperate room object.


> Do you do anything special with the terrain type, like:
> 
>   - Provide persistent placement of differing landscape withing that
>     terrained area?  Rare trees that can be used as landmarks?
>   - Provide resources based on the terrain type, like herbs, plants,
>     trees to climb and chop down?
>   - Provide persistence in resource availability depending on paste
>     use?
> 
We have persistent herbs, which are spread (and propogate
themselves) throughout a room or rooms, and thrive/die based upon the
terrain type.  Players can forage for food and 'natural' items (such as
torch wood or resources) in the rooms as well. While this functionality
exists, it is not as integrated to the movement system as we would like,
your post may very well spur us to do more with it.  We definitely do not
have resource-tracking as yet, which is something I would like to work
on.  Persistence over rebooots and/or time is something which is not
explored enough by the Diku model, imho (although it is relatively simple
to initiate).


> > People passing thru rooms no longer do so without giving 
> > those in the room
> > time to react to them, nor can OOC help be summoned from 
> > someone who is
> 
> Hmm, so are you saying you subdivide the movement space into fixed
> size rooms?  And if so, how do you handle modifying the room
> description to indicate the position of notable things within sight,
> but within other/distant rooms?

Room size is determined by sector type.  The room description itself gives
only the generalcies of the room, as in the stock Diku model.  We have
thus far linked doors and windows to the coordinate system, requiring a
player to be close enough (by 'step'ping towards it until close enough),
and plan on having the code generate unique positions within a room for
any objects which are in it.  Once this is done, XML flags (possibly) will
be used to generate text about landmark objects within the path of
travel.  A good question, and one which we hadn't considered until your
post.  :)    KaVir, if I remember correctly, has an excellent routine
which does just what you ask - it generates room descriptions on the fly
based upon surroundings and general direction of travel.

> > group.  We're working on making it possible for the 
> > less-honest players to
> > 'shadow' someone, trailing a room or so behind them without 
> > their noticing
> > (if the player's good and lucky).
> 
> A logical extension, will you be taking the terrain type into
> effect on this?

Terrain type and seasonal changes will both factor in, eventually.  This
is large-scope for us, and something which isn't currently being worked
upon.  I rather wish we'd taken Mr Mihaly's concept of zoned weather
patterns rather than the global model we used, we're going to have
problems once our world gets large enough to factor in hemispheres :)


> My own take on this is that there might be several types of
> trailing that a similar system provides.
> 
>   - Line of sight trailing, where the follower runs the risk
>     of being seen (sounds like your system).  Plan to have
>     terrain type influencing their chance of being seen.
> 
>   - Tracking trailing :) where you follow the signs they left
>     behind.  This may be ranger type tracking with physical
>     signs of movement, or magical detection even.
> 
Line of sight is the one to which I was referring - a player remains n
rooms behind the party they are trailing, with n being determined by room
size, terrain type, and speed of travel.  Much like 'follow' is in our
current system, but with room displacement.

Tracking is possible now, but is not very involved.  We have modifiers for
terrain, weather, and sector types, but are leaning towards a system which
tracks the actual _paths_ of the various players/mobs within the game,
degrades the trail over time, weather, and traffic, and improves it if the
situations are right (a player is bleeding profusely, or going thru a
muddy or snowy area).

> I would be very interested in any thoughts you have in how to
> describe the proximity of objects of note when players are in
> the midst of terrain.  Like other players nearby, landmarks,
> etc.
> 

Player and mobile positions are viewable with both the 'position' and
'map' command.  Map uses ansi to render a representation of the room and
all player locations within the room (planned to have it list objects as
well now, after your earlier question), and position gives a more general
text-based output of where they are ("Robbert, in the northwestern
corner").

Thanks for your input; I knew there was more we needed to do with the
system, but was not certain exactly _what_ that was.  :)

Robbert					-Duty is the most sublime word in
Programmer, The Inquisition MUD		-the English language.  One can never
http://www.theinquisition.net		-do more than their duty, and should
telnet://theinquisition.net 5000	-never wish to do less.



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev