[MUD-Dev] Room-based vs. coordinate-based

[Alex Oren]

Which brings me back to the topic.

How would I implement the equivalent of room-spoofs in a coordinate-based
setting?


Shawn wrote:

} clawrenc at cup.hp.com wrote:
} > 
} > In <339C618C.167EB0E7 at iname.com>, on 06/09/97
} >    at 05:16 PM, Shawn Halpenny <malachai at iname.com> said:
} 
} [ original handling of user-programming ]
} 
} > You're going to have a checklist to run every piece of code past to
} > make sure nothing has been missed?  You're never going to skip or
} > skimp something on this list?  This list is going to always be updated
} > as the system changes?
} > 
} > >The solution above is not exactly conducive to that.
} > 
} > Quite.
} 
} _Originally_ that was my intent, though the more I thought about what I
} wanted to be possible, the less I looked forward to the amount of work
} involved.  So no, there won't be any checklist that I have to watch over,
} since if I can make things generic enough, everything will hold itself
} together and not need me to hold its hand.  The addition of user-programming
} was a fairly recent thing for me, so some changes of methodology are
} definitely necessary.
} 
} [ spoof implementation ]
} 
} Which is essentially what I'm getting at here:
} 
} > >I make the magic-effect creator a method on a container (say, a room)
} > >and whenever I want to "spoof", I just override the method in a
} > >derived object (something I already do elsewhere, hence my realizing
} > >I'd not thought the post through enough).  Simple enough, since all
} > >the rooms are derived from a common object (which would have been
} > >that magic-effect creator if you went high enough up the inheritance
} > >tree) anyhow.  That should now account for stupid programmers and
} > >make things much more scalable.  And of course, if one does the
} > >inheritance and overriding properly, it's nicely applicable to all
} > >sorts of other situations.
} > 
} > Bingo.
} 
} Good.  Nothing new or quirky going on here, just plain OOD.  What I called
} "inheritance" is your spoof-by-cloning, and your generic methods are what
} I do through overriding.
} 
} > >If A wants to watch B, A sticks a reference to itself in a list
} > >inside B.  State changes in B will now send notification to A
} > >provided the change matches the parameters required by the watcher.
} > >A can stop watching B whenever it chooses, but only the destruction
} > >of B can force A to stop watching B.
} > 
} > Ahh.  I don't have any sort of filtering or definition of watchers.  A
} > watcher just triggers whenever an object changes.  The result is a
} > message sent to the waiting object of the form, "I HAVE CHANGED".  I
} > then leave it up to the waiting object to figure out what changed, and
} > if they are interested in that change.
} 
} A watcher will only trigger if the correct property (or properties)
} changes so that the watching object isn't deluged by messages about state
} changes it doesn't care about on busy objects.  The waiting object only has
} to decide what to do with the change, since it only gets messages
} concerning the things it cares about.
} 
} > This allows a watcher to trigger on a state change for a private data
} > member in an object.  Depending on the strictness of your views on
} > data encapsulation, this can be thought of as a Good Thing, or a Bad
} > Thing.
} 
} Watchers can trigger on private data changes by not defining exactly what
} they're watching, but choosing to watch for a change in any property.  So
} I still maintain the low message traffic for watchers waiting on a few
} properties, and don't have to cheat my encapsulation by allowing watching
} on the entire object if desired.
} 
} -- 
} Shawn Halpenny
} 
} "Caesar si viveret, ad remum dareris"
}                             - Latin for All Occasions
} 
} 


Have fun,
Alex.