[MUD-Dev] Room-based vs. coordinate-based
malachai at iname.com
Mon Jun 9 16:03:24 New Zealand Standard Time 1997
clawrenc at cup.hp.com wrote:
> In <3396ECE4.41C67EA6 at iname.com>, on 06/05/97
> at 07:38 PM, Shawn Halpenny <malachai at iname.com> said:
> >clawrenc at cup.hp.com wrote:
> >> In which case how do you handle remote effects? This was discussed
> >> back when for the Sceptre and the Elven Forest:
> >[ Sceptre moving in/out of forest means magic fails/works in Castle
> >Krak ]
> >This would likely be handled by putting a method on the Sceptre to
> >notify the rooms of Castle Krak whenever the Sceptre moved in and out
> >of the Forest. When the rooms receive notification of the Sceptre in
> >the Forest, the rooms would destroy any magical effect on any of
> >their contents and also temporarily redefine the method used to
> >create magical effect objects while within Castle Krak (note that
> >Thrud's Sword of Doom wouldn't change at all but anything it tries to
> >do that requires creation of a magical effect would fail--this should
> >have the (intended) consequence of the Sword essentially failing to
> >work. You may argue that Thrud's Sword should change in some further
> >fashion, but I will disagree, since there is nothing aside from the
> >magical-effect-creation that makes the Sword inherently magical--that
> >is, you can't necessarily tell something is magical just by looking
> >at it...things are magical only if they create magical effects). Once
> >the Sceptre moves out of the forest, the rooms again receive
> >notification and the effect-creation method is redefined to its
> >original meaning.
> How does this handle the case of Bubba sitting 20' off the ground on a
> magic carpet in the King's Hall? As soon as the sceptre enters the
> forest he should come crashing to the ground.
Of course, and he would. A magic effect object would exist on the magic
carpet which is an object in one of the rooms in the castle. As such, the
effect will be destroyed when the sweep is done, resulting in the carpet
(and Bubba) plummeting to the floor.
> The thing I really don't like about this /sort/ of solution is that if
> BubbaTwit programmer comes along later and adds rooms to Castle Krak
> he's fairly likely to not notice the special case magic handling and
> to thus leave it out. Of a sudden the sceptre only partially works.
Yah. I started thinking about this sort of thing after I'd posted.
Originally, it was my intention to have all such programmed objects run by
(probably) me before they'd be put in place; now, however, I want to take
myself out of that picture and let the system handle it. The solution
above is not exactly conducive to that.
> How I handle:
> The default state is the sceptre is out of the forest and magic
> When the sceptre enters the forest it locates the group container
> for Castle Krak. This is a container object which contains all the
> rooms in Castle Krak, and everything else associated with it.
This much I already do.
> The sceptre then iterates across the container spoofing every room
> to install a new magic handler. The actual code for Castle Krak never
> need be aware this has happened, or even could happen.
So in this case these spoofs are room objects that are functionally
identical to the old rooms, but with new magic-handling methods? And
if so, does that imply that creation of magical effects is handled by
the rooms themselves? I'm beginning to think that I posted my
procedure for the Scepter and Castle without enough forethought,
since the more I read here, the more it seems like this is akin to
what I'm doing (or at least the model was evolving in that
direction). My text above stated that there is a global magic-effect
creator--fine for a few spoof/watcher cases, but blows up horribly
when the number of different cases required becomes larger. So now,
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.
> The spoof thus registers a state change for all the rooms (spoof
> installed), The magical objects in the castle thus trigger via their
> watchers, re-evaluatate their current state and fail appropriately.
Right. There are always two things to be done in this case: kill
existing effects and prevent creation of new effects. Methods would
also have to be overriden to take care of objects coming into the
castle after the Sceptre has been brought into the forest (easy
[ handling the above in virtual rooms -- no change for me ]
> >Hmm. Is the above special casing the magic calls?
> Yup. Its unscalable and once you get a complex world with many such
> interactions. Consider having 20 or 30 or even 500 different areas in
> your world where magic gets turned on or off depending on other
> states. Going to have that many special case conditionals in all you
> magic code?
Well, not now (and not originally if I'd paid attention to what I'd already
had in mind).
> >[ three relics of GGGG and description of their function ]
> >This can be done in similar (though more complex) fashion. Whenever
> >object A requires notification of a change in object B, B must have A
> >in its list of objects who are notified of a change in B.
> What technique is used to add or remove an object from the "must be
> informed of changes" list?
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.
"I got food poisoning today. I don't know when I'll use it."
- Steven Wright
More information about the MUD-Dev