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.
Sunday, September 30, 2012
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.
Monday, August 6, 2012
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.
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.
Saturday, August 4, 2012
Triggered Events
Well, I stepped away from BSG for a few weeks. I needed the rest. I started working on it again this past week. I created a new destroyer which should be more visually pleasing than the original one I created a few months ago. In addition, I created a model for the Scropion fighter that will be used as the "starter" fighter.
Here are a couple of images of the untextured versions (I don't have a good texturing setup at this time - btw, you can click on an image to enlarge it):
The Battlestar Trident (Destroyer):
Scropion Class Fighter (mk1):
I wanted both of these ships in the first tutorial, even if they aren't textured at this point. Both ships play a predominant role in the early game. It just makes sense to create both ships. In addition, it gave me more practice at the model creation process. In addition to these ships, I do have plans to build some asteroids (low polygon count, which is difficult to find), a space station and a "starter" Cylon fighter craft.
As for the tutorial, I have started some work on it. I have created a means to access the database and a means to retrieve player and vehicle data from it. I started to create another access module for mission data related to vehicles and objects. There are some issues that I need to consider before proceeding with this module.
First, there will be very few static models in a mission. Models, whether it is an asteroid or fighter, will be instantiated by the resource manager. The only static objects will be manager objects, even some of these will be instantiated by the resource manager. This will require a great deal of information to be stored inside the database. For example, the positions of all fighters in a mission will need to be stored in the database. When the mission loads, the resource manager gets each fighter along with positional and rotational data and instatiates it into the mission at time index zero.
Second, triggers need to be incorporated into the manager early in the development cycle. Triggers can be a time index or the player entering a trigger area. Each of these triggers need to be recorded into the database. The resource manager will load this data and track the triggers. The problem is identifying and implementing the triggers. Timed triggers are relatively straightforward. Other triggers can be problematic. Here are some triggers that I can think of (along with some variables associated with the trigger):
Timed - requires a time index value - what is the event
Enter - requires a triggering object - triggering distance - what is the event
Enter (delayed) requires a triggering object - triggering distance - time delay value - what is the event
Exit - requires an triggering object - triggering distance - what is the event
Exit (delayed) requires a triggering object - triggering distance - time delay value - what is the event
Destruction - requires a triggering object - what is the event
Health Trigger - requires a triggering object - triggering health value - what is the event
While I covered instantiate events, there are other events: audio execution, destroy object and others.
Third, the system needs to be flexible enough to implement new trigger events and actions. While the tutorial will have a timed, enter and delayed enter trigger events that involve executing audio, the systems needs to be able to easily implement code to include other trigger events and actions like instantiating an object. This also applies to the database. If the database cannot hold the data, it design of the code won't matter.
So, what is the solution? I'm going to think about it some and attempt to plan out the interactions between the code and database. If anyone has a suggestion, I'd love to hear it...
Here are a couple of images of the untextured versions (I don't have a good texturing setup at this time - btw, you can click on an image to enlarge it):
The Battlestar Trident (Destroyer):
Scropion Class Fighter (mk1):
I wanted both of these ships in the first tutorial, even if they aren't textured at this point. Both ships play a predominant role in the early game. It just makes sense to create both ships. In addition, it gave me more practice at the model creation process. In addition to these ships, I do have plans to build some asteroids (low polygon count, which is difficult to find), a space station and a "starter" Cylon fighter craft.
As for the tutorial, I have started some work on it. I have created a means to access the database and a means to retrieve player and vehicle data from it. I started to create another access module for mission data related to vehicles and objects. There are some issues that I need to consider before proceeding with this module.
First, there will be very few static models in a mission. Models, whether it is an asteroid or fighter, will be instantiated by the resource manager. The only static objects will be manager objects, even some of these will be instantiated by the resource manager. This will require a great deal of information to be stored inside the database. For example, the positions of all fighters in a mission will need to be stored in the database. When the mission loads, the resource manager gets each fighter along with positional and rotational data and instatiates it into the mission at time index zero.
Second, triggers need to be incorporated into the manager early in the development cycle. Triggers can be a time index or the player entering a trigger area. Each of these triggers need to be recorded into the database. The resource manager will load this data and track the triggers. The problem is identifying and implementing the triggers. Timed triggers are relatively straightforward. Other triggers can be problematic. Here are some triggers that I can think of (along with some variables associated with the trigger):
Timed - requires a time index value - what is the event
Enter - requires a triggering object - triggering distance - what is the event
Enter (delayed) requires a triggering object - triggering distance - time delay value - what is the event
Exit - requires an triggering object - triggering distance - what is the event
Exit (delayed) requires a triggering object - triggering distance - time delay value - what is the event
Destruction - requires a triggering object - what is the event
Health Trigger - requires a triggering object - triggering health value - what is the event
While I covered instantiate events, there are other events: audio execution, destroy object and others.
Third, the system needs to be flexible enough to implement new trigger events and actions. While the tutorial will have a timed, enter and delayed enter trigger events that involve executing audio, the systems needs to be able to easily implement code to include other trigger events and actions like instantiating an object. This also applies to the database. If the database cannot hold the data, it design of the code won't matter.
So, what is the solution? I'm going to think about it some and attempt to plan out the interactions between the code and database. If anyone has a suggestion, I'd love to hear it...
Thursday, August 2, 2012
Destroyer Vote
I have designed two Colonial destroyers. The first destroyer is the Battlestar Hermes, and I have posted it before. The second is the Battlestar Trident. This is a new destroyer that I created this week. I was just wondering which one is better.
Hermes:
.jpg)
.jpg)
Trident:
The Hermes is badly textured, and the Trident is untextured. Unfortunately, I don't have access to a good texturing program at this time.
Please let me know which one is better...
Hermes:
.jpg)
.jpg)
Trident:
The Hermes is badly textured, and the Trident is untextured. Unfortunately, I don't have access to a good texturing program at this time.
Please let me know which one is better...
Subscribe to:
Posts (Atom)