Monday, October 1, 2012

Redesigning the Trigger Manager

The trigger manager component of the game is proving to be difficult.  In this blog, I will design the flow process for the trigger manager.  Currently, there are two types of triggers: timed and other triggers.  Timed triggers execute once the game clock equals or exceeds the time field value in the trigger record.  The other triggers occur after the trigger manager receives a trigger from another script.  To execute, the received trigger and the trigger value in the record must have the same value.  The trigger manager will maintain two list for each of these types. 

The first list will be the timed trigger list (vTimeList); the second list will track the other triggers (vTriggerList).  The timed list will be check at during the Start() and Update() procedures.  The other trigger list will only be checked during the Update() procedure.  Time checks will precede the regular trigger checks.

Timed triggers are relatively easy to maintain.  A time index (from Time.time) is compared against the trigger's time field.  If the time field is equal to or less than the time index, the trigger is executed by the program.  Most timed triggers will occur at time index zero; therefore, the bulk of the timed triggers will execute in the Start() procedure.  The Start() procedure is tasked with executing all time index zero triggers.  The general process will iterate through the timed list until the first time field is larger than the time index.  Consequently, the timed list will be ordered by the time field.  To check for timed trigger execution the Start() or Update() procedure will call a TimeExecution() procedure.  This procedure will accept the Time.time value as a parameter (or 0f for the Start() call).  This will ensure that all triggers are checked against the same time index.

The other triggers are bit more problematic.  First, multiple triggers can be sent to the trigger manager between Update() calls.  These triggers will need to be stored in a list (vReceivedTriggers) and checked against the trigger list.  The general process will have the Update() procedure get the first trigger from the received list.  It passes this value to TriggerExecution() procedure.  The trigger execution procedure searches the trigger list for a trigger field that equals the received trigger.  It continues to search the entire list until all of the appropriate triggers are executed within the trigger list.  Initially, this process will utilize a sequential search algorithm; I don't forsee a large number of triggers in the trigger list.  However, later prototypes will probably utilize a binary search system to increase game performance. 

In both cases, the trigger is deleted from the timed or trigger list after it's execution.  However, certain trigger types need special consideration.  The trigger load type loads a trigger into the time or trigger list.  Due to the inherent complexity of this type (versus the other trigger types), it's process needs explanation.

A trigger load trigger, designated with a "tgr" prefix, will load a new trigger into either list.  Once the search algorithm executes this trigger, it first loads the additional trigger data into memory.  With this data, it will build a new trigger.  The new trigger will use the old triggers data; except, it will replace the trigger ID, Name (of the triggering trigger) and time field with the newly loaded data.  If the new Name is equal to "Time", it will add this trigger to the timed list.  Otherwise, it will add it to the trigger list. 

This should streamline the process for me. 


  1. In addition, any time delay on an non-timed trigger will have that trigger added to the time list. The time index will be equal to the current time index (Time.time) plus the delay value. The trigger will be removed from the trigger list.

  2. It's working at this point... I love programming!