Event handling (was: request for comments)

[s001gmu at nova.wright.edu]

On Sun, 11 Jan 1998, JC Lawrence wrote:

> On Fri, 9 Jan 1998 13:51:24 PST8PDT 
> s001gmu <s001gmu at nova.wright.edu> wrote:
 
<old, and somewhat confusing attributions removed.  everything in here is
 mine, from my last post, JC's response, or my most recent response>
 
> > mmm.. I dunno that that is really a valid concern... I am leaning
> > more and more towards JC's Spoof/Watcher model, which allows for
> > such things nicely (definately planning on spoofs.. still thinking
> > about watchers..  
> 
> Spoofs and watchers have different function, altho their capabilities
> can cross.  The intent of a watcher is purely to tragger on sate
> changes.  This allows objects to react to changes in other objects:

*nod* And together with an event driven system, they make a very powerful
system.  

<watchers explination and examples removed> 
 
> I wanted a general solutionw hich could elegantly handle all of these
> without special casing.or requiring bizarre design or coding rituals.
> 
> > dunno if my design goals necessarily coincide with
> > the ones you chose that lead to spoofs/watchers, JC).  
> 
> I presume this means that requirement that any feature must be able to
> be programmed without requiring source access to any objects other
> than the ones embodying the featuer?

*nod*  I'm still debating that.  I like a lot of the power that shortcuts
provide, and I'm debating wether the cost of the shortcut (restricted
further developement) is worth the benefit.
 
> > W/O using
> > watchers (to watch the phase of the moon), I would schedule an event
> > to go off at the beginning of the time the lycanthrop should morph,
> > to trigger the morph, and then one to go off at the end of the time,
> > to morph the poor bastich back.  
> 
> What happens if Bubba manages to delay or accellerate moon-rise/set?

hadn't planned on letting ppl make changes of that scope, but it does
bring up the issue for less admin controlled situations (Castle Crack and
the Bucket... ;)

> What if this was thru administrative errors (Admin reset the time and
> forgot some details)?  You are creating an indepedant system which
> does not rely on or react to the data which it pretends to be
> dependant on.

Aye.  There  obviously has to be some form of information passing.  Which
leads to...  :

> There are two base approaches: watchers and messages.
> 
>   In the watcher case all lycanthropes merely matain a watcher on the
> relevant moon object and respond accordingly.  The moon
> sets/rises/whatever, the watcher is triggered and they have a chance
> to react appropritately.
> 
>   In the message passing case the moon state-changes and realises that
> other objects may be dependant on that state change, and thus sends a
> message to them, or directly invokes their methods to make the changes
> itself (ugly).
> 
> There really is very little difference here from the watcher model
> except that it is now the object itself determining that the state
> change is relevant, and the object itself also now needs to maintain
> its lists of who to send the state-change messages.  Watchers just
> virtualise this model by having external generic non-invasive objects
> do all the work of triggering and sending the messages.  
> 
> The programmer for the mood doesn't need to know a thing about
> lycanthropy or wolves howling, he just needs to account for the moon.
> Similarly the programmer for the were-wolves doesn't need to hack the
> source for the moon, he just has his were-wolf objects put a watcher
> on the moon (a very standard, on-line command), and then writes a
> couple lines of code to look for the state-changes he is interested
> in.  

<stream-of-consciousness>
given an event driven system, it becomes a problem of action-reaction.
each event has an unknown number of objects which are interested in the
event, IE: should react to it.
Some of those objects may have to interrupt pending events...
given the unknown number of interested parties, it makes sense to have
some centralized list, each party expressing what kinds of events it is
interested in (event masks? :)
Problem: potentially every object in the game (even those dumped in
cold-storage) could be on that list... in fact, should be.
Proximity to the event (range determined by perception method/ abitilies)
allows for most normal events to be 'broadcast' to the correct subset of
all objects... but what about non-proximate parties?
... hmmmm...
</stream-of-consciousness> 

I think I need to sit down some place quiet and think about this a lot.
:)  Part of me balks at adopting another's technique w/o first analyzing
it to death...  :)  I may go quiet for a few days as I sort things out...

> > No real worries about multiple
> > events targeting the same data at the same time, as the events would
> > occure once a month!  :)
> 
> Until Superman gets that moon spinning faster in a lower-orbit.

*nod*  see above thoughts, etc. :)

[switching topcis] 
> > I'm thinking the best solution might be to fall back on DB
> > backups...  every <so often> the program dumps a 'current state' of
> > the pc to the DB.  if a crash occurs, the last 'current state' is
> > loaded.  Current states would include enough info to reconstruct the
> > events for the character in question.  Some events would have to be
> > handled seperately... combat type events, etc.  mmm.. definately
> > requires some thought.  Mayhaps I shall go dig up my concurant
> > software design notes, and DB notes on rollback techniques.
> 
> One of my early design had the DB do periodic saves to backups.  The
> problem as you note was maintaining logical consistancy for changes to
> the DB __during__ the backup procedure without requiring the entire
> game to halt during the backup.
> 
> It can be done.  The solution consists of two parts:
> 
>   1) for object in DB, write object to backup DB.
> 
>   2) for object change during backup where object has been written to
> backup DB, flag object in backup as deleted, write changed object to
> current running DB __and__ backup DB, and update indexes appropriately.

hmm.. don't think I quite communicated our model correctly.  we plan on
having active parts of the game loaded into memory, and less active parts
stored in the DB.  The active parts will be changed frequently, w/o writes
to the DB.  the backups I spoke of were updates to the db.  Poor choice of
words on my part.  We planned on having the 'db writes' for active objects
occure at some regular interval, starting from the time the object became
active.  For PCs, this means when they logged in, NPCs and objects, etc,
from the time a player walked into the area (or whatever grain we go with
to pull a chunk out of cold storage).  Due to the staggered times for all
of this, each player/npc/etc will be 'saved' at different times, creating
ALL SORTS of fun.  :)

 
> > Bubba and Boffo are fighting.  Bubba and Boffo are on different
> > clocks for their 'db backup' events.  Combat is interrupted by a
> > crash / termination / reboot / whatever.  If all events are stored
> > in the db backup, Bubba and Boffo will have different pending combat
> > events, based on the different times at which their last backup was
> > made.
> 
> True.

A thought I just had.. what if events not generated by an automated
process (IE: combat, etc) are the only ones stored?  mmm... no... healing
events are auto-generated.  But then, I 'spose we could patch that at
login...

 if (hp < max_hp)
   generate_event("HEAL", &char-name);

hmmm.. we'd have to work up a fairly generic system to allow for future
expansion.. a way to store enough info to re-start the event chain
mid-way, for events that affect only the charater in question...
More fodder for thought experiements.  :P
 
> > Easy solution, put everyone on the same clock.  problem: large db
> > writes, all at once.  slams system pretty good with a lot of ppl on.
> 
> See above.  You can make the backup thread quite low priority.
> 
> > definately a DB rollback issue.
>  
> Nooo.  A consistancy issue.

how to maintain DB consistency in case of an unexpected shutdown?  sounds
like Rollback to me...
 
> > Any comments from the peanut gallery?  :)
> 
> More salt please.

heh... 's always nice to start a monday morning with a little humor.
Granted, I didn't get around to replying to this part of the message until
evening, but hey.  :)

-Greg