[MUD-Dev] Object Models

[Andy]

----- Original Message -----
From: KevinL <darius at bofh.net.au>
To: <mud-dev at kanga.nu>
Sent: Saturday, November 25, 2000 8:15 AM
Subject: Re: [MUD-Dev] Object Models


>
> >>> Gavin Doughtie wrote
> > I would attempt to assemble a composite object in this case, with some
implementor
> > of "edge", in turn containing a "material" property and methods like
"sharpen" and
> > "cut". The whole assemblage (combat stats, etc.) might live under a more
generic
> > "weapon" interface.
> >
> > Seriously, you can go crazy with this stuff, but the whole point is to
make things
> > easier for the user (programmer, world builder) to understand. In real
life you
> > see much more "has a" than "is a subclass of" relationships among the
objects you
> > encounter. You also tend to solve problems by applying prebuilt
components (i.e.,
> > you don't manufacture your own drywall screws).
>
> Yup, and I'm sold on components in cases like this.  I was just curious
about
> that particular suggested way of tying things together - I can't help but
> wonder when I look at that whether things aren't being made more complex
> rather than less for the builders - especially if you introduce tight
> contracts into the mix, where you can't change a component without
updating
> everything that uses it because the contracted interface has changed.
>
> Regardless, here's the question:  You have a component that implements
edge,
> material, maybe size, whatever.  You decide you need to modify the
component's
> behaviour based on some aspect of the object it's being included into that
> you'd never considered - this runs close to some of JCL's previous posts
about
> being able to affect the behaviour of an object under new conditions
without
> having to recode that object.  Say, you've added the temperature of the
object
> in question into the mix (heat it up, it's easier to sharpen, or
something).
>
> Do you now have to go back and re-make that component to accept
temperature as
> an argument to sharpen, then modify every object using that component to
pass
> the temperature in?  Or can you somehow make the component simply grab the
> temperature from the object it's been included into, thus dodging
potentially
> large-scale changes?

IMHO, that is exactly how it should work  A sharpen method should have a
reference
to the object being sharpened and the object performing the sharpening.
>From these two objects it should be possible to use the relationship links
to find
out all other information required, such as:

    - Any attached child, sibbling or parent objects.
    - The environment they are in.
    - The objects holding/supporting them, all the way up the chain to the
PC/NPC
        holding the item.

The sharpen method then needs only to hunt down the information it needs.
Access
to internal state information of an object/entity such as temperature should
only be
available either through methods, or my preference, as temperature objects
which
can have there internal structure modified and backward compatablity
maintained,
with a little help from overloading of assignment operators and type
casting.
The sharpen method could return an activity object that contains information
on
the activity that has been started i.e. has it finished yet and if so
whether the outcome
was a success or a failure.

IMO, the flow of events, everything should boild down to objects that are
passed
as part of the axiom.  What do you think the object/class catagories should
be?
i.e. Events, Components etc.


>
> This is my concern with components and contracts, at the end of the day -
that
> they're good in a situation where you can nail down your requirements from
the
> word go, but they're going to be a distraction where you want to be able
to
> mutate things on the fly.  And (and I know this'll go down badly ;) I've
never
> worked on a project that didn't mutate part-way through.  More, I'd
suggest
> the places that encourage non-techs to build are the places where things
can
> be wired together, and changed, with minimum fuss - on the fly.
>
> Are there component systems around that don't implement the strict
interface
> requirements John's argued for?
>
> KevinL
>
> _______________________________________________
> MUD-Dev mailing list
> MUD-Dev at kanga.nu
> https://www.kanga.nu/lists/listinfo/mud-dev
>

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