[MUD-Dev] Object Models

[Bruce]

Ben Chambers wrote:
> Bruce wrote:
> > Another, possibly interesting, way to look at this is in terms of
> > modelling aspects of the behavior of objects and the interaction
> > between objects and the behaviors of objects in their
> > surroundings.
> >
> > For example, a chest is something that can be opened.  A lock is
> > something that can constrain the opening of the chest.  This can
> > be implemented in many ways, depending upon your choice of
> > implementation language, any existing object models, among other
> > factors.
> >
> > Especially when you're trying to simulate an environment, the
> > last thing that you want to do is have to custom code the
> > interactions for each type of object. :)  To have a lego-like
> > world, I think it is valuable to step back from the individual
> > objects and look at the aspects of those objects and their
> > behaviors and how that might be abstracted from the vagaries of
> > any particular object.
> 
> Interesting concept, it has merit, but what about mobs
> and charachters?
> How do you model them?
> What about weapons.  I can see the merit in your system for a basic
> standpoint but what about for EVERY
> object in a MUD?

Hi Ben!

I haven't worked out entirely how this will work yet, but it is a
large part of an approach that I'm considering taking to the
system that I'm working on.  In my mind, this approach should
actually simplify scaling up to many objects, rather than become
more difficult.  It isn't really that different from some of the
event-based systems around, but just sounds different because I
want to focus on the interactions between the objects, rather
than objects themselves.

This fits in well with some of the component talk as well.  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.

Possibly relevant old discussions on MUD-Dev:

Regulating player-created objects:
  This thread discusses objects as composites of
  components.  An axe is a composite of a wooden
  handle, plus a metal head.
  http://www.kanga.nu/archives/MUD-Dev-L/1998Q2/msg00609.php

  I'm not really looking towards that type of system at
  the moment.  I'm more interested in modelling the
  behaviors, rather than the physical manifestation.

Tilting at the Sim Windmill:
  An orphaned post, but a good one.
  http://www.kanga.nu/archives/MUD-Dev-L/1997Q3/msg00316.php

I realize that I've given no substantive examples of how this
would work for the larger cases that you mentioned, so ...

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

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