This blog is designed to cover the basic concepts of my trigger manager. There are actually two trigger managers in the game. One exists in a “Battlestar.dll” file. This manager is just a mechanism to directly access the database. I will not cover this script here. The other script is the script that manages triggers within the Battlestar game. I will cover this script. This script has two major components: the starting load procedure and the update procedure.
The startup procedure loads the mission’s trigger data from the database and executes the triggers necessary for the proper execution of the mission. Waypoints are first loaded into the mission. This is followed by loading the player. The script then populates a timed and untimed trigger list. All timed triggers with a time index of zero are executed before completion of the startup procedure. On an average mission, these represent the bulk of triggers in a mission. Most of these triggers instantiate the game objects in the mission. These include asteroids, NPC fighters and NPC capital ships.
On the other hand, the update procedure handles the execution of triggers during the actual mission. These include timed events and triggered events. For example, a Cylon Baseship that jumps in at time index 60 (1 minute into the mission) would be instantiated by the update procedure. Triggered events include ending the mission after the player lands his or her fighter after completing all mission objects. This script has been placed in the Update() procedure. This script executes on every frame. It checks all of the timed triggers. Then, it iterates through the received triggers list and checks each non-timed trigger. At the end of the update, it clears all of the received triggers for the next update cycle.
Here’s the script:
This script is still under development. I do have plans to add other trigger types like a delete trigger. This trigger would delete another trigger from either trigger list. This will add some versatility to changing mission objectives in more complex missions. In addition, it could be used to simulate an “if-else” statement if utilized properly. I will continue to add to this script as it becomes necessary.
Currently, this script does use two game manager scripts: the resource manager and sound manager. These managers are special utility scripts. The resource manager sets up access to the database and retrieves data from the database. The sound manager accepts instructions from other scripts to play audio files. It does accept some parameters to give the manager some versatility. I’ll cover both of these scripts in another blog.