[MUD-Dev] Object Models

[Travis Casey]

On Saturday, November 25, 2000, KevinL wrote:
>>>> 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.

Not being a software professional, I'm not sure what the distinction
between "tight" and "loose" contracts is, so maybe I've only dealt
with loose contracts.  In the contract models I've seen, though, a
contract only specifies what must be supplied and what must be done --
it doesn't specify that an object can't have any other data or
behaviors other than the contracted ones.

Thus, changing what all a low-level component will do (e.g., to add a
"temperature" variable and make the "sharpen me" behavior take it into
account) doesn't mean that you'll necessarily have to change all the
code that uses that component.

The usual problem that I've run into with adding things like that in
muds isn't updating objects that use those components -- it's going
back and changing everything that's already finished that *should*
have used those components.

To use a real example from a mud I worked on -- I added the ability
for monsters to move along a pre-set path rather than randomly, so
that guards could actually patrol a perimeter, go back and forth from
one place to another, etc., without custom coding being necessary.
People building new areas used it, but no one wanted to do the work of
going over all the existing areas, finding everywhere that that
ability should have been used, and adding the line or two to each
monster that should use it to make them use it.

> 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?

I'm not sure why you'd need to pass temperature in as an argument.  If
you have temperatures, then reasonably, every object on the mud that
represents a physical object in the game world should have a
temperature.  When the sharpening code needs the object's temperature,
it should be able to just get it -- not need it passed in.

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

Well, there's a old, well-known solution to that -- although it also
goes down badly:  Build one to throw away.  Engineers building
physical systems prototype, and it's a good thing to do with software
systems as well.

> 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?

Depends on what you want to consider to be a component system.  I'd
say that Forth can be, but then, Forth is designed to be a
language-building language.

--
       |\      _,,,---,,_    Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)      


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