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

[clawrenc at cup.hp.com]

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 <33943B87.41C67EA6 at iname.com>, on 06/03/97
>>    at 08:58 AM, Shawn Halpenny <malachai at iname.com> said:

>> >Well, I have a mapping of locations to objects as well as each
>> >objects existing in a container (i.e.  the room it's in).  To make
>> >Boffo arrive from the north, I (roughly):
>> >    - set Boffo's coordinates to the new location
>> >    - check the location->object mapping to see if there is a real
>> >      room at that location
>> >        - if so, add Boffo to that container and generate a message
>> >          for its contents
>> >        - if not (the room is deterministically generated, so there
>> >          is no room container), from the mapping grab all objects at
>> >          Boffo's new location and tell them of Boffo's arrival.
>> 
>> 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.

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.

How I handle:

  The default state is the sceptre is out of the forest and magic
works.

  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.

  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.

  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.
  
  Something tries new magic in the Castle, invoking the new spoof'ed
methods transparently instead, an fails.  An instant later when the
sceptre leaves the forest, the spoofs are removed, and the same magic
call works without any changes.

>If a region surrounded by Castle Krak were deterministically
>generated, this can still be done, but would have to be done by
>notifying an object within Castle Krak of the sceptre's whereabouts. 
>This object would handle destroying effects in each real room of
>Castle Krak as well as the deterministic, virtual region surrounded
>by the Castle (since it can't receive any notifications on its own).

This gets ugly for me.  (I don't dynamically generate containers).  If
I did, I'd guess that I'd have to handle by making a generic virtual
location from which actual virtual locations are instantiated at
runtime via inheritance, copy or simple reference.  Then the sceptre
can spoof the generic room and everything works properly.

>> Now, just to prevent you special casing the magic calls to go check we
>> had the relics of the Great God GooGoo and the Magic Sack.

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

>I suppose in a
>sense it is, since any call to make magic will do a check to see if
>the effect is being done in Castle Krak (the check is not on an
>effect-by-effect basis, though).  There would have to be a check done
>_somewhere_ no matter your implementation, though, no?  

Nope.  I just spoof the object and the rest is utterly transparent as
a new method which fails gets substituted transparently for the old
method which worked.  I can then write the magic code such that it
never need presume that magic may be able to be turned on and off.

>This seems
>general enough...if you had a large number of Castle Krak's ,
>however, things could start to slow down as the conditional for each
>was evaluated.

Bingo.  It also becomes a maintenance nightmare.

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

>I've no explicit concept for spoofs.  I would do that with variables
>that would be conditionally set in the objects that are the spoofs. 
>The methods that care about whether or not they're working with a
>spoof or not can then check that fact.

The disadvantage design-wise for this is that you end up having to
write your base code to handle all the possible variations which can
happen across your world.  What I've attempted to create is the
ability to have the base code only do and know about the normal and
regular functioning of a feature, and to then have all the special
case stuff put into spoofs, which _are_ the irregular and exceptional
case instances.  Keep the normal stuff simple and straight forward,
and then only add the complxities when needed.

>I had hashed out precisely this scenario (prompting a couple small
>modifications to the way effects and magic worked) when you last
>posted it to the list, so I know the remote effect handling works
>acceptably well.

Ahh.  I didn't recall when you entered the list.  I thought that was
before your time.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...