[MUD-Dev] Ideas for dynamic worlds

[Nolan Darilek]

>>>>> "Chimera" == Chimera  <chimera at SoftHome.net> writes:

    Chimera> Hello, Glad to meet another lurker, though by these posts
    Chimera> I guess we don't qualify any more. What you have in mind
    Chimera> sounds similar to my own project (which has also been on
    Chimera> hold thanks to college and its trappings... funny how I
    Chimera> finally find time to work on it during _finals_, eh?
    Chimera> <grin>), so I thought I'd speak up for once.

Heh, same thing here. I can either study for a final that won't matter
very much next year anyway (I'm switching majors and this class won't
be required for the new major) or I can work on my project. I'd much
rather work on the project. :)

    Chimera> I want a grid-based system too, but I admit that I have
    Chimera> not thought about using layers. I think the problem with
    Chimera> mountains can be solved by assigning height to each
    Chimera> layer. The parser would then take into account only those
    Chimera> grids that are in the line of sight (on a plane parallel
    Chimera> to the grid the user is on). A side effect (which may not
    Chimera> be undesirable) might be that users can look down and up
    Chimera> as well as straight ahead.

Hmm, interesting. I had initially considered treating mountains as
objects atop which maps can be placed, but heights assigned to maps
might work. The only drawback that I can think of is, I don't know
quite how to simulate slopes. The slopes wouldn't be very important
for the descriptions, but they would be needed to assign coordinates
to each location on the map. Without a slope, a mountain might be
represented by a map whose hight is much higher, without any
sloping to reach that height. (Of course, that would probably be the
case for objects, too.)

    Chimera> I think it makes sense to assign "visibility" levels to
    Chimera> objects (but have it calculated automatically and give
    Chimera> builders the ability to modify this value if they want,
    Chimera> or it will get tiresome). A glittering tower will
    Chimera> certainly be more eye-catching than the rocks on the
    Chimera> ground! I want to make this visibility level dependent on
    Chimera> the user too, so a character with keener eyesight or who
    Chimera> is on alert will notice more things than someone who is
    Chimera> dozing off.

I was thinking of tying this into object size, maybe correlating it to
surface area, weather conditions, distance and the user's
eyesight. Since I'm designing a system which I want others to build
on, though, one of my aims is not to dictate a game designer's choices
of statistics. I may have some internal statistics such as strength
and perception, though these are more abstract. I.e. vehicles and such
can also possess strength; since maximum velocities may differ based
on terrain, the strength of something is merely how much energy it can
put forth. I may rename this to 'force', or something more
abstract. Then if someone wants to use the internal statistic for
their own games, it could tie into all pre-written systems.

    Chimera> Regarding roads, I've decided to use compass directions
    Chimera> for simplicity's sake. It would be nice to have "follow
    Chimera> road" commands, but my main concern is that with
    Chimera> increasing population the calculations will bog down the
    Chimera> server.

I thought about that too. My thoughts are that processing power is
continuously becoming less expensive, and that it should be possible
for most game designers to afford reasonably fast
machines. Furthermore, I don't anticipate the platform becoming
insanely popular if I ever finish it, and most of the community will
probably be happy with older servers. (Besides, by the time I finish
it, 2 GHz boxes may be extremely popular. :)

    Chimera> Another thing I'd like to do is make the objects
    Chimera> themselves composites of other objects -- a shovel is
    Chimera> composed of a pole and a metal head, the pole is composed
    Chimera> of wood... I hope to get all the way down to the atomic
    Chimera> level (with considerable simplification, of course). This
    Chimera> will make it possible for objects to "know" what should
    Chimera> happen to them if the user does something, without all
    Chimera> the contingencies having to be hard-wired except in the
    Chimera> lowest levels. As an example, suppose the user decides to
<snip>

Wow, I like this idea. Mind if I steal it? ;)

Seriously though, it's much better than my idea of coding in lots of
interactions. My only concern is with an object's descriptions: how
would you then describe the shovel head or the ashes once the shovel
burns? It may be possible to describe the ashes, since one pair of
ashes looks like another, but what if the person burns a rake instead?
You could probably tell the difference between a burned shovel head
and a burned rake head, but how would it be described? Would the
builder have to describe both the head and the pole?

     Chimera> To cut a long e-mail short, there is just one more point
    Chimera> I'd like to address. You mentioned having the server
    Chimera> concoct strings "on the fly". This is something I've been
    Chimera> thinking long and hard about, and I thought to use a
    Chimera> natural language processing subroutine which would make
    Chimera> it possible for the server to understand "plain English"
    Chimera> as well as produce sentences from raw information (this
    Chimera> is one of the things I got stuck at too). Again, I am
    Chimera> worried about performance. What did you have in mind, if
    Chimera> you don't mind telling?

No, not at all. The server isn't generating raw strings from
scratch. The user still writes descriptions in a markup language. The
markup language has tags which perform switches based on a large
number of variables which the user can expand upon. I.e. Something like:

<switch variable="daynight">
<case value="day">
<str>The sun shines brightly.</str>
</case>
<case value="night">
<str>The moon shines brightly.</str>
</case>
</switch>

In this case, daynight can either hold the value "day" or "night" and
is defined server-side. You could also have additional variables,
"timeofday" which could hold dawn, morning, afternoon, evening, night,
etc. It would even be possible to define game-specific variables. If, for
example, your setting had two moons, you could define a variable which
described the phase of both moons and tie that into the game
scheduler. The markup language would also be used for all messages, so
it would be possible to describe all actions differently based on any
factors. If, for example, you coded a black limousine, and coded it to
emit certain message events to those outside as it travels, during the
day its actions could describe it as a luxurious black limousine,
while at night it may appear as a sinister dark shadow.



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