Creating an Event

This is probably my final post on creating an event within a mission.  Each event can be broken down into two primary parts: a trigger and an action.  Each part has smaller subparts that can further define the trigger.  For example, a timed trigger would have a time associated with it.  The event triggers at the time specified in the subpart.  Actions would have similar subparts.

For the most part, triggers share many similar subparts.  A trigger is usually described by a named trigger with a time and/or distance offset.  This means any system describing a trigger will need a trigger name, time and distance field.  In addition, other triggers could involve damage taken by a ship.  This would require a structure (HP) field. 

Consequently, a trigger data object needs these fields to hold a proper trigger.  In addition, it will have a field to hold a reference value for an action.  This field points to an action object as a unique identifier.  This is the final breakdown for triggers:

+ OID (Unique ID field, aka a primary key in a database)
+ MissionName : string (used to filter out irrelevant data records)
+ TriggerName : string (also used as a reference field)
+ Time : float
+ Distance : float
+ Damage : float (percentage)
+ Action : string (references a field within an action object)
+ ActionType : string (tells the computer where to look for the action parameters).

On the other hand, actions is much more difficult to define.  There are many different actions with different subpart requirements.  For example, creating a cylon fighter requires different information than creating  waypoint and inserting a waypoint into a waypoint manager object.  Playing a sound requires different data than creating an object.  This means that actions have to be broken up into different action objects "controlled" by a trigger object.

To start I will be limiting action categories to existing categories in the first tutorial.  The first action to happen in any mission is the instantiation (creation and placement) of all objects in the game.  This includes obvious game objects like the player's fighter and less obvious game objects like each waypoint and any other area trigger objects.  Both types of objects require a position (x, y and z) and rotation (x, y and z).  Fighter objects require player, vehicle and AI (NPC only) data.  Area triggers, including waypoints, will need a trigger distance. 

To facilitate instantiation of both types, the action object will need a pointer.  This pointer will consist of the name of another object (vehicles or controller) and a reference field.  The reference field will be a searchable primary key.  The fields attached to that primary key will hold the pertinent data to load the object.  Here's the breakdown for the general instantiation:

OID (Unique ID needed for the database)
MissionName : string
ActionName : string (actual primary key pointed to by the Action field of the trigger)
Position (x, y, z) : float (x, y, z)
Rotation (x, y, z) : float (x, y, z)
ObjectType : string (tells which table to load from - vehicle/controller)
Object : string (references a record in the table associated with ObjectType)

For vehicle objects:

OID
Object : string (primary key pointed to by the Object field in the Action table)
MissionName : string
FirstName : string
...
PC : bool

For controllers:

OID
Object : string (primary key pointed to by the Object field in the Action table)
Distance : float (triggering distance)
Manager : string (name of a waypoint manager or other manager object)
ItemNumber : string (mostly a waypoints index number)

These fields are expandable, and I will probably add fields as I need them in future missions.  This just represents the general breakdown of the structure.

In addition to instantiation, voice overs will play throughout the mission.  Voice overs are rather simple.  They should consist of a file name and a source.  The source is not the game engine audio source; it represents the entity speaking dialog.  This is necessary to avoid starting two clips from the same person at the same time.  So the breakdown for the audio table is:

OID
MissionName : string
AudioName : string
Source : string

In order to make things more searchable, all of these tables will need a mission name field.  When the intital data is loaded, only mission data (or default data for those actions that happen across all missions - if they exist) will be loaded into the mission lists.  This will cut down on search times as the event manager sifts through the lists.

This is the basic structure used by the event manager.