[MUD-Dev] Object Models

[Christopher Allen]

Bruce wrote:
> What makes up an object in a simulated virtual world?  For the most
> part, an object is an aggregation of data and behaviors.  By
> concentrating on modelling those behaviors, I think it should be
> more straight forward, both from a coding perspective and
> hopefully from a building perspective to get a logically and
> physically consistent simulation.
...
> Taking the example of a weapon, we might look at the case of a
> sword.  Possible characteristics of a sword, in trying to model
> how it interacts with its environment might include:
>  * Can be wielded in one hand.
>  * When used, it can inflict damage:
>    * Slicing
>    * Piercing
>    * Blunt trauma
>
> Perhaps we want to allow the user to be able to sharpen weapons,
> potentially allowing them to cause greater damage.  To do so, we
> create a new action that can be carried out:  sharpen edge.
> Sharpening an edge knows to look for the slicing behavior of an
> object, and then seeks to collaborate with that behavior to carry
> out its effect.  Doing so would allow the sharpening edge
> behavior to work with -any- object that implements/possesses a
> slicing behavior.  (In practice, we'd probably want to constrain
> this further to just work with metal-edged weapons, and possibly
> only those which are sturdy enough to hold an edge.  But, I'd
> rather keep an example that I'm typing out at 1:30am simple.)
> So, adding this behavior would allow a user to sharpen their axe,
> a spear head, a knife, a sword.
>
> Do you have an example that you think might be hard to handle
> with this style of system?  Maybe even a nice non-violent one. :)
>
> One potential pitfall with this might be that depending upon the
> implementation, it may require additional upfront design, should
> the implementation not make it easy to add new behaviors and
> constraints over time.  I wouldn't plan on implementing this
> though without a mechanism for extensibility, IMHO.
>
> But, when looking at the work involved in a more tranditional
> approach, I don't think that this one is any additional work,
> except that it requires some additional design effort.  But, I'm
> fine with that. :)

One thing that we've found amazingly powerful with the Skotos StoryServer,
is that all physical objects in the game are actually a single LPC class -
thing. There are *no* sub-classes of things. Rooms are things, players are
things, NPCs are things, containers are things, etc. In fact, you can in our
system +possess (switch your soul object's pointer) from a player object to
a cat or to even a pillow (The pillow waves its tassles at you.)

Thus any new behavior added to an object, is immediately available to *all*
objects.

Instead of LPC class inheritance, we do have a separate data inheritance,
what we call our "ur" system. An 'ur-parent' object is an object of the
thing LPC class with a number of properties pairs set on it (name-value). If
a property is requested of an 'ur-child', if that property doesn't exist, it
will use those of its 'ur-parent'. However, if it the property is changed,
the changes are only made in the 'ur-child'. This let's us have some
heirarchical organization of data of similar objects without them actually
being different LPC classes.

-- Christopher Allen

------------------------------------------------------------------------
.. Christopher Allen                                 Skotos Tech Inc. ..
..                           1512 Walnut St., Berkeley, CA 94709-1513 ..
.. <http://www.Skotos.net>               o510/647-2760  f510/647-2761 ..

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