[Reality] Markov/Probability tables added

[Glyph Lefkowitz]

On Mon, 27 Dec 1999 sneftel@popmail.com wrote:

> > Sounds interesting.  This is the only part of your design which sounds
> > slightly erroneous.  Why do you need to extend them AND place them into a
> > super-location?  ("Zone" is what we called them in our proposal).  It
> > seems to me like UpdateDescHandler should be MetaUpdateDescHandler and it
> > should be handled on the zone only (outdoors).  It should cascade down
> > into each room and set the 'weather' description element on them, not call
> > event handlers (since, when does 'motif' ever do ANYTHING but update this
> > particular description?  Since you'd never want to handle another event or
> > do something different there, you might as well embed all the code in the
> > one toplevel event handler.

> You're absolutely right. I did this particular oddity because I didn't
> know (at the time) how to refer to each object in a room without
> broadcasting an event.

Okay, well hopefully you know that =)

> However, I had a good reason to extend Class_Outside: For each room,
> the weather strings can be unique and tailored to the room's
> setting("Sunlight filters through the trees" instead of "It is
> sunny"). At the same time, however, I didn't want to manually go
> through and write all the weather strings for every single room, just
> the important ones. So Class_Outside has default weather strings,
> which may or may not be overridden by the rooms' own strings. I could
> have implemented this in the handler, but I think this could give me
> slightly more flexibility in breaking up zones (e.g. insted of
> Class_Outside, have Class_Forested or Class_Streetlevel).

> What do you think? is the extra flexibility worth the double
> nomination required?

The double-nomination is more work on the part of the authors; this is
always bad =).  You should probably make it possible to override those
strings; but default to the ones in the meta-room rather than relying on
the presence of the superclass of each sub-room.  The extra flexibility is
good, but --

'---
|
|  String desc = room.getString("weather description");
|  if (desc == null)
|      desc=zone.getString("weather description");
|
`---

; something like that will preserve the flexibility and save the authors
work at the same time =)

Finally, if you want to get really complicated, as in your final example,
you could either do the subclass thing (but as I said, that's a lot of
work for authors) or do sub-zones, like

+ Outside
|
\--+ Street Level
   |
   \--o Street
   |  |
   |  o More Street
   |  |
   |  o Even More Street
   |
   + Forest
   |
   \--o Forest
      |
      o More Forest
      |
      o Even More Forest


And write the weather system to explicitly (do everything as tree, rather
than a two-level structure) or implicitly (broadcast an event, but
normally don't handle it unless your rooms are actually zones) support it.