Saturday, September 29, 2012

Revisiting Waypoints

I got the event manager, renamed as a trigger manager, to load sound files and generic game objects.  I was going to work on loading waypoints when I came to the realization that waypoints are too integral of a system to load into the game from the traditional trigger manager.  When a fighter craft that relies on waypoints loads into the game, part of the load process will involve defining its waypoint manager or initial waypoint.  This means that the waypoint object must already be loaded into the scene.  To make sure that waypoints are loaded first, all waypoints will be loaded separate from the main trigger load process. 

During the Start() routine, waypoints will load first, followed by capital ships and player's fighter and then by the normal trigger load process.  This will ensure that waypoints exist in the scene by the time other objects that depend on them are loaded into the scene.  The waypoint load process will break down into two parts.  The first will load the waypoint manager.  The waypoint manager's table will consist of the waypoint manager's ID, position and a flag to designate it as a looping waypoint system.  The second section will load the individual waypoints.  These waypoints will be stored in a separate table.  The waypoint manager's ID will be used to query and retrieve the individual waypoints.  The individual waypoint's table will consist of waypoint's ID, manager's ID, position in the waypoint list and position.

Once the waypoint load is complete, the Start() routine will move onto the capital ships and player's fighter.  Capital ships will be put on indefinite hold.  They are not ready for loading into the scene and will remain a static, preloaded part of scenes.  I will write the player load after the waypoint system.  This will be followed by the fighter load routine.

In addition, I will need to create a trigger load system.  This system will load a trigger into the table after receiving a trigger.  As an example, the first tutorial instructs the player to turn left.  After the player successfully turns left, the tutorial will then instruct the player to turn right.  Both instructions involve verbal feedback, a played audio file.  In this situation, I don't want feedback for turning right to play until after the completion of the turn left trigger.  This means that the actual turn right trigger records must be loaded into the trigger list after the completion of the turn left trigger. 

Finally, I will create a database interface system to make the database management easier.  The database management system will be written in C# (possible VB) to provide me with a quick and easy way to create missions.  This system will utilize a MySQL, MSSQL or Access database.  Once the database is ready for deployment, the database management system will convert the database into a Siaqodb format.  The Unity game will access the Siaqodb version.


  1. Waypoint system done! Now, I'm going to move on to the instantiation routine for the player's fighter...

  2. I got the player's fighter to instantiate into the game. It broke the waypoint system; however, I corrected that issue.

    I tried to get the scorpion to instantiate; however, the model was just broke. I don't why. The viper model worked perfectly... I'll have check some things with the Scorpion model to make sure there aren't any conflicts...