[MUD-Dev] Object Models
darius at bofh.net.au
Sat Nov 25 19:15:59 New Zealand Daylight Time 2000
>>> 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
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?
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev