[MUD-Dev] Object Models

Bruce bruce at puremagic.com
Wed Nov 22 05:11:12 CET 2000


KevinL wrote:
> John Robert Arras wrote
> > So, the "key/monster" thing I would set up by making
> > a monster, then make it so you can pick up the monster,
> > then make it so you can wield/hold the monster, then
> > add a "key" chunk of data, and then add some information
> > to that chunk (some flag) that says "if this key is used
> > in the wrong door, attack the user". I would then add a
> > small piece of code to the "unlock" function which says
> > if the key can fight and if this flag is set, and the
> > door is wrong, the key leaps from your hand and attacks
> > you.
> >
> >
> > At any rate, this method is really really simple. Stuff
> > just falls into place and works without me putting in
> > much effort.
> 
> Whereas, I'd create an object, and tell it to inherit from
> key and from monster, and optionally setup the behaviour
> of the critter in question (to attack if used in the wrong
> door) off the 'unlock' method provided by the key.

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.

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



More information about the mud-dev-archive mailing list