My computer took a dive, and I just got it up and running again. Consequently, this is my first post in awhile. I have been reviewing my approach to creating an event manager, and I decided to change my approach (again). I learned to program back in the 80's, and the popular trend was top-down programming. I lose sight of some of those principles when programming in the modern world. I'm changing my approach to a more top-down methodology.
The goal is to create a trigger manager that passes each trigger to specialized trigger managers. For example, the primary trigger manager will receive all the trigger events for a mission. Based on the name, it will pass instantiation of fighter craft to the appropriate manager and audio triggers to an audio manager. Currently, the game will need a fighter, waypoint, generic object, audio and destruction managers. In addition, a capital ship manager will become necessary as the game progresses. Each of these managers will receive data from the primary trigger manager.
The primary trigger manager will grab data from a trigger table. The trigger table fields are:
OID (Primary key)
Mission Name : String // Used to query by mission name
Name : String // First three letters designate a target table; full name is a key field
Trigger : String // Name of trigger that triggers the event
Time : Float // Time index (if it's a time trigger) or time delay (on other triggers)
Position : Vector3 // x, y and z coordinates for the instantition of objects
Rotation : Vector3 // x, y and z rotation for the instantition of objects
The Name field will contain the action category in the form of a three letter prefix. The following managers will have these associated prefixes:
Fighter instantiation - ftr
Waypoint instantiation - way
Generic Object instantiation - obj
Audio commands - aud
Destruction commands - des
The prefix will be followed by a unique identifier. The prefix will direct the data to the appropriate manager and its associated table. The full name will be used as a search key for a unique record in the table. This record will contain additional data, like basic fighter data, needed to properly execute the desired action.
The trigger table will be sorted by the time field and read into a list. The trigger manager will read from the list by retrieving on a first item basis. During the normal update procedure, the trigger manager will retrieve the first "Time" event from the list and will compare time indexes. If the event needs to be executed, it passes it the appropriate manager for immediate execution. As the trigger manager receives triggers from other scripts, it retrieves the first item with the trigger name. If an item is retrieved, it is passed to appropriate manager. That manager handles any time delays that might be present for the action.
The plan is to create the primary trigger manager followed by the audio manager, generic object manager, waypoint manager, fighter manager and destruction manager in that order.