[MUD-Dev] Re: Dynamic muds

Katrina McClelan kitkat at marcus.pants.nu
Thu Sep 23 02:50:32 CEST 1999


On Tue, 21 Sep 1999, Marian Griffith wrote:

> If I understand all this correctly this is much the same as the solution
> I thought up to describe outdoor areas.  It is somewhere on the website,
> but the idea was to have any number of locations that have a description
> when you are inside of them, and a description for when you look at them
> from the outside.  If you use rooms to create a forest you end up with a
> hundred rooms with a hundred different descriptions  (or worse, with the
> same description !).  The idea I had cooked up would allow you to create
> a single forest location and descriptions for fifty different trees that
> are then  distributed over the forest area.  The obvious advantages  are
> that you have to write less, and you can stand and walk anywhere in that
> forest,  instead of moving on a chessboard.  Things like  line of sight,
> ranged combat and hiding behind other objects become much easier sudden-
> ly as well. It is somewhere on my website but I can not remember the
> exact adress right now.
> 

Similar yes, but this takes it a step farther.  It would add the notion of
positioning and ranged combat you describe, but the goal isn't to solve
_just_ the open space problem.  The basic idea is that you don't have any
rooms, for anything.  Everything is an 'object' that can be interacted
with. Most things are 'containers' to be exact.

Bubba is inside a hut inside the Drugewood Forest inside the North
Continet inside etc etc etc.

Note that yes, the forest is an object, and from a high enough scope, it
would be possible to target it.  Go ahead, cast a fireball on the forest
to set it ablaze.  Obviously anything inside it might have problems as the
fire is passed on to the contents of the forest.  I rather suspect that
players would be unable to target the continent and world objects, but
this is a play aspect, not a technical one (wizards would be able to
target them). Really the part of this design that is the trickiest is not
the description generation, but the damage/regen and object interaction
system.  So someone hits a forest with a fireball.  This doesn't 'destroy'
the forest outright, but it does (unchecked) eventually burn all the trees
and combustables in the forest.  Of course a player could jump _inside_
the pond that was inside the forest, and us the fact that the pond isn't
going to be damaged by the fire to protect himself from it.  The concept
of 'inside' carries very well.  I'm right now inside a cubicle inside an
office inside Santa Clara inside California inside the United States
inside North America inside Earth inside the Solar System inside the
Galaxy inside the Universe.  The biggest issue is handling containers that
border each other rather than one being inside the other.  It's easy to
think of "I leave the cubicle, so now I'm in the office.  I leave the
office, now I'm inside Santa Clara.  But what about I walk across the
street, and leave Santa Clara and enter Sunnyvale?  (convienient that I am
right by the border of Sunnyvale).  My thought was to represent this
internally in a way that doesn't make physical sense, but simplifies the
process.  Basically Santa Clara would be inside Sunnyvale, located at the
edge of it, and Sunnyvale would be inside Santa Clara, located at the
edge, so you could walk to Sunnyvale (target the object that is located at
the border), and then enter Sunnyvale.  The problem here is that now a
single object would have to be able to be inside more than one object at a
time (which again doesn't make physical sense).  There are any number of
ways to allow this relationship, but it does complicate things when the
parent/child relationship is a many to many instead of a one to many.  (I
had intended to use an SQL database to implement this since tables work
very well for handing a 'inside' scheme).

-Katrina



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



More information about the mud-dev-archive mailing list