[MUD-Dev] Ideas for dynamic worlds

[Nolan Darilek]

I've been a lurker on this list for nearly a year. After taking a 8-9
month break (more like 'forced leave of absence' :) from MUDding, I've
come back, sorta. :) I've had some ideas which I'd like to toss around
for criticism, since the community here seems 
knowledgeable. Since I'm writing a design document for a project which
I'm working on to implement these ideas, I'd like to expose any flaws
before I put much time and effort into this, and frankly, I'm not sure
how possible it is to implement.

For the past few months or so, I've been kicking around the idea of
designing a new MUD platform. One of the ideas I've had is to use an
already-available scripting language such as Java or Python instead of
creating my own, since I lack the experience and the time to do the
latter, and I don't really see the point, since I'd have to implement
the most basic functionality in my own language. So I initially began
developing a better object persistence system for Python (Basically I
made functions objects, with their code stored in a string to support
online editing of code and such.) I soon gave up on this when I
discovered Momoko, and since I hate duplication of effort, I changed
my design goals to encompass creating an environment rather than both
a server and environment. That was about a month ago, one long and
busy month, and now that my last final is approaching, I'm
anticipating pouring lots of work into my ideas.

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.

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. 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. (The language is parsed server-side and has
switch tags for conditionally displaying text blocks based on time of
day, weather, etc. along with tags which display short textual
descriptions describing one object's relative position to another. 'to
the right', 'to the left', 'ahead', ...)

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.

Maps can also be transparent or opaque, depending loosely on whether
the area is indoors or not. Of course, there are many exceptions to
this rule; a heavily-wooded patch of woods may be defined as opaque,
while the observation dome of a colony ship may be
transparent. Transparency/opaqueness is important for the description
algorithm.

The algorithm which I am considering for rendering text descriptions
has one major flaw, which I'll mention below. It 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. Since both likely
are impossible to see past, the description algorithm doesn't recurse
further.

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.

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. A disadvantage, though, is that it would be difficult to
represent a world which didn't conveniently use right angles for
everything. 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. Since most games use
compass directions anyway, I doubt that would pose much of a
problem. 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.

Another idea is to extend the concept of object-orientation to
descriptions as well. Currently, a room's description consists of a
text string. What happens if something changes in the room's vicinity,
though? What if someone builds a shop? Nukes an office building? What
if a fire rages through a city? Someone has to change room
descriptions to  accommodate for this. What if a room's entire
description doesn't consist of just a string, though? 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. If
the building were to be moved somehow, its description would disappear
from the old location description and be added to the new one. If it
were destroyed, the description for its 'destroyed' state could be
substituted. 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; buildings could consist of
walls, which could consist of windows, though a builder doesn't
necessarily need to create each wall and window; a building template
could create everything. Objects could also have pre-programmed
behaviors as well; trees and lamp posts could be climbed to conceal
someone, windows can be looked through and or broken into, and
buildings could be scaled.

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. 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.

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.

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.

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. :)



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