[MUD-Dev] Re: MUD Design doc (long)

[Chris Gray]

[Caliban Tiresias Darklock:]

 >Instead of asking "how do we do X", it's productive in most cases to ask why
 >X is important in the first place. What does X give you? Why is it
 >important? If your rationale is "I have a flower and the player should be
 >able to smell it", you probably want to rethink whether this is important to
 >the game. It is certainly intuitive to think you can "smell" a flower, so it
 >might be a good idea to handle for the flower... but in the world as a
 >whole? Do we legitimately need a "smell" handler for all objects?

But that is precisely the reason why it is best to have a generic smell
handler (whether globally or attached to some universally inherited
'object'). You don't have to have a handler for all objects - you have
one for free, and it ought to say something reasonable. Hmm. Thinking
about this for a sec, I may have my blinders on here. It is trivial
in my system to have a simple string property optionally attached to
objects, so that the handler can see it if present and use it, else
do a default action if not. Then again, any system with inheritance and
a full object tree can just pile a zillion string messages (or methods)
on the base object, and get the same effect. So, I'll come around and
ask the question: is there any reason *not* to do this? As Caliban says,
many objects don't have any special response to, say, 'smell', but
that is a different matter from telling the user that the system
doesn't understand 'smell'.

--
Don't design inefficiency in - it'll happen in the implementation. - me

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA