Playable can be a misleading term; however, I have completed the general structure of the first tutorial. It is in a generally playable form. This first mission is the first basic flight tutorial for the game. It is designed as a part of a series of basic flight tutorials. This first tutorial explains some basic flight controls like turning with the mouse, applying thrust through the keyboard and mouse scroll button, stopping the ship, cutting thrust while maintain speed and "gliding". Gliding is when a fighter has cut thrust but is still moving along its last trajectory. While it is still in motion, the pilot can turn around while still traveling along that last trajectory.
While the tutorial is playable, it is not complete. The waypoints are not well placed at this point. Some are too far apart; while, others are too close together. In addition, more objects are needed in the tutorial to give the player a sense of movement. I'll have to fix the waypoint distances before tackling adding more objects. The addition of objects should not present an obstacle to the player; I need a finalized series of waypoints to ensure that the player's experience is not negative.
I hope some of test the new prototype and provide feedback on the controls. If you played any of my previous prototypes, the fighter in this prototype has a significantly worse turn radius and is generally less responsive. The starter fighter, represented in the tutorial, is designed to be more "controllable". I am especially interested on how this fighter feels to the player.
Here's the link the builds file that contains the latest prototype:
https://dl.dropbox.com/u/43398523/Builds.rar
and the installation guide for the prototype:
https://dl.dropbox.com/u/43398523/Running%20the%20Latest%20Prototype.docx
As I noted above, the game needs the database files loaded before the gameplay prototype will run properly. The instructions will detail how to accomplish loading the database.
Please use the comment section to leave any feedback.
Thursday, October 4, 2012
Tuesday, October 2, 2012
Loading Triggers for Tutorial #1
The trigger manager seems to be fully functional at this point. Now, tutorial #1 needs the triggers to be loaded into the manager. The general progression of the tutorial #1 dialog can be found here: http://abanathie.blogspot.com/2012/07/tutorial-1-dialog.html.
There will be some changes to the progression. First, the instruction to stop and use the mouse scroll button will occur while traveling to the first waypoint. The instruction to "glide" will occur between first and second waypoint. In this blog, I will breakdown the progression of the first tutorial into a trigger manager friendly format.
First, let's take a look at the general process.
The tutorial starts off with the instructor giving the pilot the instruction to turn left (audtt1Start). This dialog takes 14 seconds. After the 14 seconds, the manager needs to load two triggers. The trigger, tgrtt1Start, loads two triggers: audtt1Right and tgrtt1Right. The first is an audio instructing the player to turn right. The second is a trigger load for the next sequence of triggers.
audtt1Start
Time (0)
Audio
audtt1Start* (Instructor - true) - 14 seconds long
tgrtt1Start - Trigger Load
Left Turn (14)
Loads
audtt1Right(Instructor - true) - 5 seconds long
Turn Left (0)
Loads
tgrtt1Right
Turn Right (5)
The next trigger, tgrtt1Right, waits for a turn right trigger. Once it receives that trigger it loads two triggers from the trigger load table. The first, audtt1Up, plays an audio file to turn the fighter upwards. The second is another trigger load that waits for a Turn Up trigger.
tgrtt1Right - Trigger Load
Turn Right (5)
Loads
audtt1Up(Instrutor - true) - 6 seconds long
Turn Right (0)
Loads
tgrtt1Up
Turn Up (6)
The next sequence loads another set of triggers; however, I think I got the process down at this point. It requires me to make a slight adjustment to the trigger load routine. Instead of restricting the trigger load, the trigger load trigger needs to be able to create multiple triggers. Instead of a one to one exchange, a single trigger load can point to multiple triggers. This just makes it a one to many relationship in database terms...
There will be some changes to the progression. First, the instruction to stop and use the mouse scroll button will occur while traveling to the first waypoint. The instruction to "glide" will occur between first and second waypoint. In this blog, I will breakdown the progression of the first tutorial into a trigger manager friendly format.
First, let's take a look at the general process.
The tutorial starts off with the instructor giving the pilot the instruction to turn left (audtt1Start). This dialog takes 14 seconds. After the 14 seconds, the manager needs to load two triggers. The trigger, tgrtt1Start, loads two triggers: audtt1Right and tgrtt1Right. The first is an audio instructing the player to turn right. The second is a trigger load for the next sequence of triggers.
audtt1Start
Time (0)
Audio
audtt1Start* (Instructor - true) - 14 seconds long
tgrtt1Start - Trigger Load
Left Turn (14)
Loads
audtt1Right(Instructor - true) - 5 seconds long
Turn Left (0)
Loads
tgrtt1Right
Turn Right (5)
The next trigger, tgrtt1Right, waits for a turn right trigger. Once it receives that trigger it loads two triggers from the trigger load table. The first, audtt1Up, plays an audio file to turn the fighter upwards. The second is another trigger load that waits for a Turn Up trigger.
tgrtt1Right - Trigger Load
Turn Right (5)
Loads
audtt1Up(Instrutor - true) - 6 seconds long
Turn Right (0)
Loads
tgrtt1Up
Turn Up (6)
The next sequence loads another set of triggers; however, I think I got the process down at this point. It requires me to make a slight adjustment to the trigger load routine. Instead of restricting the trigger load, the trigger load trigger needs to be able to create multiple triggers. Instead of a one to one exchange, a single trigger load can point to multiple triggers. This just makes it a one to many relationship in database terms...
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.
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.
Sunday, September 30, 2012
Prototype 2.5
I got the basic trigger manager to function properly. The trigger manager can play audio files, instantiate generic objects (like asteroids), instantiate waypoints and instantiate the player's fighter. It still needs a method to load triggers after the scene starts and to instantiate fighters and capital ships. Capital ships are not complete; consequently, the instantiation of capital ships will delayed indefinitely.
The next feature for the trigger manager will be allow a trigger to load another trigger. After that, the instantiation of fighter craft is next.
The current player fighter in tutorial #1 is now a Scorpion fighter. It is slower and less manueverable than the Viper. I updated the new fighter with parameters for the Scorpion. I would like to get some feedback for the fighter. I am mainly curious if it turns too fast or turns way too slow...
Here's the link to the public builds folder:
https://dl.dropbox.com/u/43398523/Builds.rar
The latest build is prototype 2.5. I only have one audio file up and running for the mission. This is mostly due time and the fact that I can't load a trigger after a trigger.
The next feature for the trigger manager will be allow a trigger to load another trigger. After that, the instantiation of fighter craft is next.
The current player fighter in tutorial #1 is now a Scorpion fighter. It is slower and less manueverable than the Viper. I updated the new fighter with parameters for the Scorpion. I would like to get some feedback for the fighter. I am mainly curious if it turns too fast or turns way too slow...
Here's the link to the public builds folder:
https://dl.dropbox.com/u/43398523/Builds.rar
The latest build is prototype 2.5. I only have one audio file up and running for the mission. This is mostly due time and the fact that I can't load a trigger after a trigger.
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.
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.
Friday, September 28, 2012
New Cruiser Design
I attempted to create a video detailing the process for creating a low polygon model. The design process was to cover a real basic overview for beginners; however, I did run into some issues with video. First, it ended up being 83.3 GB in size (between all the segments). Second, some of the segments that I recorded did not turn out well. I can play the clips in media player, but I cannot use them within my video editing software. I'll have to look into fixing the issue.
For the process, I created a new cruiser for the game. It's 868 meters long and is primarily meant to be a smaller version of a Battlestar (1200 - 1400 meters - depending on source). In a way, it's a step in the evolution from the smaller destroyers to larger battlestars depicted in the series. Writing this blog, I realized that forgot the add the launch tubes. I guess I'll go back later to fix that issue. I've included some pictures of the untextured product.
So, does look enough like a battlestar?
For the process, I created a new cruiser for the game. It's 868 meters long and is primarily meant to be a smaller version of a Battlestar (1200 - 1400 meters - depending on source). In a way, it's a step in the evolution from the smaller destroyers to larger battlestars depicted in the series. Writing this blog, I realized that forgot the add the launch tubes. I guess I'll go back later to fix that issue. I've included some pictures of the untextured product.
I included the Trident class destroyer as a reference point. These pictures are from Unity. Like the trident, I created the base model in 3DMax. I added the turrets after importing the mesh into Unity. The landing bays can retract and extend and needed to be separated from the main body. The first two pictures depict the cruiser with retracted landing bays. The last picture depicts extended landing bays. So, does look enough like a battlestar?
Thursday, September 27, 2012
Event Manager
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.
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.
Subscribe to:
Posts (Atom)