[MUD-Dev] Ideas for dynamic worlds

[David Morgan]

Nolan Darilek wrote:
> 
> I've been a lurker on this list for nearly a year. 

Same here.  :)

> After taking a 8-9 month break (more like 'forced leave of absence' 
> :) from MUDding, I've come back, sorta. :) 

I've only really played one MU*, and haven't had much access to it for
a year and a half now, except during the summer.  It also has had a
playerbase of about 3 or 4 for the last year or so, and now they tell
me it's going down permanently..  :s
So take my input with a grain of salt.

> What are my ideas, you ask? I'm trying to design a framework for
> creating a very dynamic world with a very rich level of detail. I 
> have quite a few ideas, and I've noted several flaws in a few of 
> them, but I'm sure that I'm missing more.

whaddya know, I'm considering the same thing..  estimated release date
is in ten years, especially considering the current [nigh-nonexistant]
rate of development.
 
> I've often been obsessed with the idea of coordinate systems in
> MUDs. I don't mean the typical 'one room per grid square' idea which
> many MUDs use. Instead, I'm considering a system of stacked
> grids. 

Same here, at least to some degree.

> Each grid has a width and length, and an attached description
> written in an XML-based mark-up language which will be used for all
> text sent to the user. 
[snip]

hm..  I think I'm trying for a more dynamically-generated appraoch: 
the underlying layers have some environmental effects, but most of the
current description depends on what objects are visible.
 
> Maps represent a "logical area." On most MUDs, each room might be
> replaced by a map with the room's width and depth. Furthermore, no
> matter where you are, you are always present on a map. Imagine a
> tree-like structure. The root node of the tree represents the terrain
> atop which your world is set. In most cases, this would probably be 
> an ocean, but it could certainly be a desert, or maybe even the
> universe.

Again, this is similar but not the same as what i'm planning.  there's
a base 'ground' layer, which has various terrains on top of it (town,
forest, desert, mountain, etc) and those will likely have objects on
them for the room's appearance.  I don't think there would be a way to
translate the 'standard' MU* concept of rooms to my system, although
indoor 'rooms' might be similar.
 
> The algorithm which I am considering for rendering text descriptions
> is recursive, first displaying the description of the map atop which 
> the user stands, also describing surrounding objects. If the current 
> map is transparent, it recurses downward to the surrounding maps 
> until the map boundaries extend beyond visibility. So, if you are 
> standing on a forested road near an ocean, you first see a 
> description of the road concatenated with a description of the forest 
> and the ocean. 

That doesn't sound too bad, but I don't like your next statement:

> Since both likely are impossible to see past, the description 
> algorithm doesn't recurse further.

How do you know that both are likely to be impossible to see past? 
Perhaps you could implement some sort of sight radius for the
character which determines how far away you recurse?
 
> This algorithm doesn't take into account visibility of distant
> objects. If a mountain range rises past the forest, the algorithm
> would stop after noticing that the forest is too far to see past. One
> workaround which I've considered is marking certain objects as
> 'noteworthy', and thus continuing the recursion and only selecting
> marked objects from the countless others, but this would be a waste 
> of CPU time. I'm sure there are ways of handling this; I just don't 
> know what they are.

[someone mentioned heightfields, which you need for various reasons]
OK, another question:  do you recurse _through_ the neighboring maps
as
well, or just add them in?  I didn't entirely understand you there.
 
> This system would allow for some interesting features. Since movement
> is based on speed and direction, and not on typing a single command
> and moving an arbitrary distance in an arbitrary amount of time, it
> seems that adding vehicle systems would be a natural extension to the
> game.

It's not something I would've thought of easily, but it is needed for
my MU* for other reasons, so hearing that they're a "natural
extension" is good news for me :)

> A disadvantage, though, is that it would be difficult to represent a 
> world which didn't conveniently use right angles for everything.

Why must this system use only 4 directions?

> A winding wilderness road would be quite annoying to walk down if you 
> had to sit at your computer with a graphing calculator, punching in 
> trig equations every few seconds. 

You couldn't just say 'follow road' or something, and let the computer
handle the direction changes? [reads the next paragraph]  yeah,
something like that.  Mayhaps make roads etc with some sort of radial
vectors[1] that say where & how the road turns, and then the algorithm
can apply the same vectors to anyone following the road?

[1] I just made up that phrase, actually.. In this usage it appears to
be approximately a derivative of the road if it were a function..  it
would be a series of values for how much the road swerves; 
{.1,.1,.1,-.2,-.2,-.2} would be a gentle right curve followed by a
left curve that was twice as sharp.

> Since most games use compass directions anyway, I doubt that would 
> pose much of a problem. 

Perhaps, but it also would eliminate some of the richness your system
could have.

> Additionally, it may be possible to create an intelligent
> server-side algorithm for following roads, paths, bridges, etc. Since
> they would be represented by rectangular maps, the algorithm would
> only need to determine which border is the map's width and which is
> its length, and set the object's course to the path which the line
> follows, updating this every second or so.

Which is more or less what people do, right?  ..You might also be able
to use this to implement 'drunkenness'...  instead of following the
road straightly, you weave all over it. [randomly 'push' the
character's direction] heheh  :s

[snippage throughout]
> In my description algorithm, I mentioned describing the objects on 
> the map. What if buildings, lamp posts, trees, shrubberies, etc. were
> objects? A game developer would need only define a building and its
> basic description, as well as other states in which the building 
> could be and their accompanying description. Thus, a builder would 
> only need to change the building's normal description, and once it is 
> added to a location, the description is automatically added by the 
> algorithm. This would require additional development time for 
> designers, but it might add lots of descriptive realism to the world. 
> This could be taken even farther; a building template could create 
> everything. Objects could also have pre-programmed behaviors as well.

<nod>  That's how I intend my system to work.

> There are a few problems with this approach, though. If, for example,
> you are in a forest, you don't necessarily want to see the 
> description of every single tree nearby. Certain objects could be 
> defined as groupable with group descriptions. Thus, lots of trees 
> could be described as such, while a single tree could be described in
> detail. 

The MUD-Dev list mentioned something about uber-objects that I thought
applies to this..  Instead of grouping objects, make a group-object &
then say what individual objects it may contain.

> Additionally, depending on how far the object paradigm is
> extended, building could eventually require someone to plot out
> blueprints before starting, which isn't what I want to see. A 
> building object could handle the creation of all walls, windows, etc. 
> while giving the builder the chance to customize his work
> afterwards. Arranging room maps within the building to fit within the
> walls may also pose a problem. If the dimensions of the building are
> made into an easy-to-work-with number though, laying out rooms
> shouldn't pose much of a problem.

<nod>  I'm now toying with the idea (just an idea right now) of using
POV-Ray files (or something similar) as area files...
Sure it'll take a bunch of work, but you can see what the place
actually looks like if you want..   <g>
 
> I have quite a few more ideas, though none are quite this complex. 
> I'd like to steer away from writing text directly to the client for
> example, instead using events to signify changes in the
> environment. Eventually the events would be converted into message
> events depending on the user's immediate environment (in an attic,
> rain may be heard pounding on the roof, while it may sound more
> distant in a basement for example) but the environment will not be
> allowed to simply send strings to the client.

sounds good.
 
> On one hand, I can see how this could pose quite a problem for world
> developers, and I'm sure some of you are thinking that it would be 
> too much work. My reasoning, though, is that if reasonable defaults 
> for most options can be provided, the developers aren't necessarily
> required to put forth any additional work unless they want to make
> their world even more detailed than it already is. Using the above
> example, default weather messages can be provided for indoor and
> outdoor locations. If a builder wants to implement a special case,
> though, the facilities are there for him to do so.

<nod>  there more functionality you put into your part, the less
details the builders will need to mess with.
 
> I'd really like to hear your thoughts on some of these ideas before I
> pour much more work into the design documents. I currently have a
> rather shabby website for my project, but I'm almost embarrassed to
> give it out until I have more to show for my efforts, though I'd
> certainly welcome any folks who are interested in helping with
> these ideas. If you are, or if you're just interested in watching my
> slow progress (Though hopefully I'll speed up next week :) drop me a
> private message and I'll send the URL. Thanks for reading; I rambled
> on a bit longer than I had planned to. :)

This is really why I'm writing - I'd like to watch your progress :)
I may be able to help or I may not, but either way I'd like to see how
you do with this.  

Hope I gave you _some_ useful input..

 Strike & Co.
--
Rule # 1: There are always exceptions to the rules.



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev