Event sequencing: Building dependancy trees|
In a game there are two main things we need to sequence, namely graphix, and
sounds. We need this to be as simple as possible.
So we create a layer, or a kind of proxy between the calls to the gfx, and
sound objects, and the actual implementation
thereof. This middle layer being a command sequencer, or event sequencer if
you like which will send off tag values to objects which,
on startup, would have subscribed for them and know how to map them back to
the associated method call.. Based on the publisher / subscriber
model, command sequncer allowes us to perform synchronous, asynchronus calls
to the sound, and gfx objects with ease.
Another feature is event reference counting, or locking, and unlocking.
The main feature is creating dependancy graphs. eg:
event A, B, and C can only occur once D, and E are done.
then, event X occurs as soon as one of A,B, or C are done.
D , and E processing...
Complete D, and E
A, B, and C processing...
Complete A, or B, or C
And so forth, and so on.
Thus allowing for any combination of events, with whatever dependancies we
At the end of the day, each event, ie: X, Y Z, or whatever we choose to
call, typically maps back to a method call
with the associated data-set.
ManagedSpriteMethodA(INT i,INT nDependancyListOfEvents...);
To invoke SpriteMethodA, we use the ManagedSpriteMethodA version which,
internally, makes use of our command sequencer
to send off the command to the SpriteObject itself. As you can see, we have
the option of Making SpriteMethodA dependant on as many
existing events, nDependancyListOfEvents, as we like.
Maybe a pseudo code snippet...
// Subsriber object A
Subscribe for command X_Visible
Subscribe for command Y_Animation
OnCommand(INT CommandId,INT ReturnID)
if(CommandId == X_Visible)
set object visible
Ack(ReturnID); // Tells the command sequencer we are done processing
// this tag, and are ready for the next.
if(commandId == Y_Animation)
save ReturnID for later usage when animation is done.
Invoked Ack(ReturnId) on previously saved ReturnId from the OnCommand method.
// Lets say we have these 2 managed methods using the command sequencer to post of the
// X_Visible, and Y_PlayAnimation commands to the relevant objects.
INT ManagedSpriteSetvisible(INT nAnimationID,INT nDependancyList...);
INT ManagedspritePlayAnimation(INT nDependancyList...);
// The actual game module making use of the ManagedSprite object.
// The animation will start right away since we have no dependancied in the list.
INT nAnimationHandle = ManagedSpritePlayAnimation(animation_id_1,END_DEPENDANCY_LIST);
// The sprite will only be set to visible once the animation has completed.
INT nVisibleHandle = ManagedSpriteSetVisible(nAnimationHandle,END_DEPENDANCY_LIST);
// Here we can see the dependancy used when invoking the sprite set visible method.
The zip file viewer built into the Developer Toolbox made use
of the zlib library, as well as the zlibdll source additions.