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.
Tuesday, October 23, 2012
Tuesday, October 16, 2012
Next Set of Priorities
Prototype #2 has made significant progress this month. The completion of the basic template for the first tutorial mission, the creation of a trigger manager and the start of a database system tool to more easily create and track mission data are big steps. Now, it is time to plan out the next few major steps for the project.
First, I need to complete the database management system. This is instrumental to future progress. It just takes too long to hard code each mission into the game. A secondary tool to generate the game database makes it much easier. In addition, future distribution will not need a secondary program to load the database. The database will have to be distributed with the application. In addition, this will allow for me to look at a centralized internet location for the database. This will allow for a web-based player in future builds.
Second, I need to start on transitions. The basic game flow is: start up screen, character creation screen, tutorial #1 briefing screen, tutorial #1 mission screen and tutorial #1 debriefing screen. Prototype #2 is not intended to incorporate character creation; it will be skipped for now. However, I need a starting splash screen that transitions into the first briefing. Another tranisition is necessary to get into the actual mission. Consequently, the next priority after finishing the database system is to create a briefing scene followed by transitioning between screens.
Third, I need to finish the first tutorial mission. While this is officially step three, this will actually occur concurrently with step two. At this point, I'll concentrate on fleshing out the asteroids in the mission and tweak the execution of audio files. As step two winds down, I'll need to add some new trigger types to the trigger manager. I'll need a delete trigger to remove triggers from the mission. This will be used to create an if-else situation. Other triggers are still on drawing board at this point.
Fourth, I need to start detailing the role and mechanics of capital ships in the game. This includes an AI routine to control capital ships and turrets. These AI routines will probably be two separate but interconnected scripts with the primary AI routine driving the turret AI routine. With the capital ship's AI routine out of the way, I can start integrating capital ships into the database and trigger manager.
Finally, I need to look at damage in the game. Currently, the system is haphazardly put together. I need to get the system to work for both fighters and capital ships. As it stands right now, it is almost impossible to destroy capital ships in the game. I need to figure out the damage role for capital ships.
These steps should keep me occupied for awhile and should last through the beginning of next month.
First, I need to complete the database management system. This is instrumental to future progress. It just takes too long to hard code each mission into the game. A secondary tool to generate the game database makes it much easier. In addition, future distribution will not need a secondary program to load the database. The database will have to be distributed with the application. In addition, this will allow for me to look at a centralized internet location for the database. This will allow for a web-based player in future builds.
Second, I need to start on transitions. The basic game flow is: start up screen, character creation screen, tutorial #1 briefing screen, tutorial #1 mission screen and tutorial #1 debriefing screen. Prototype #2 is not intended to incorporate character creation; it will be skipped for now. However, I need a starting splash screen that transitions into the first briefing. Another tranisition is necessary to get into the actual mission. Consequently, the next priority after finishing the database system is to create a briefing scene followed by transitioning between screens.
Third, I need to finish the first tutorial mission. While this is officially step three, this will actually occur concurrently with step two. At this point, I'll concentrate on fleshing out the asteroids in the mission and tweak the execution of audio files. As step two winds down, I'll need to add some new trigger types to the trigger manager. I'll need a delete trigger to remove triggers from the mission. This will be used to create an if-else situation. Other triggers are still on drawing board at this point.
Fourth, I need to start detailing the role and mechanics of capital ships in the game. This includes an AI routine to control capital ships and turrets. These AI routines will probably be two separate but interconnected scripts with the primary AI routine driving the turret AI routine. With the capital ship's AI routine out of the way, I can start integrating capital ships into the database and trigger manager.
Finally, I need to look at damage in the game. Currently, the system is haphazardly put together. I need to get the system to work for both fighters and capital ships. As it stands right now, it is almost impossible to destroy capital ships in the game. I need to figure out the damage role for capital ships.
These steps should keep me occupied for awhile and should last through the beginning of next month.
Monday, October 15, 2012
Battlestar Database Management System
I am currently developing a tool to quickly enter game data into the game database. It is in a Saiqodb format. I figured out how to get the format to play nicely with Microsoft C#. Currently, I can use the program to create or edit bullets, missiles, countermeasures, fighters and generic objects.
These are the bulk of the program; however, I still need to develop a method to enter triggers into the database. Triggers actually emcompass a variety of types. The main categories for this program will revolve around trigger types: audio, object (generic), fighter and trigger loaders.
Audio triggers should not be difficult to implement. Each of the audio trigger fields can be entered manually; there are no reference fields that could affect data entry. This makes this feature pretty straightforward.
Object triggers are more problematic. To simply the process, at least at this point of the development cycle, I will be using a one to one relationship between generic objects and object triggers. This will ballon the database size and will create some performance issues. However, I'll clean these issues in the next prototype. This feature will allow the user to select a game object already in the database. The user can create or edit the trigger associated with the object.
Fighter triggers will operate like object triggers. They will follow a one to one relationship with the same options as generic objects.
Trigger loads should be straightforward. It should follow the general format for audio triggers; however, I might have to add a "check" routine to make sure the trigger called already exists in the database.
When this tool is done, it will help develop mission scenarios faster...
These are the bulk of the program; however, I still need to develop a method to enter triggers into the database. Triggers actually emcompass a variety of types. The main categories for this program will revolve around trigger types: audio, object (generic), fighter and trigger loaders.
Audio triggers should not be difficult to implement. Each of the audio trigger fields can be entered manually; there are no reference fields that could affect data entry. This makes this feature pretty straightforward.
Object triggers are more problematic. To simply the process, at least at this point of the development cycle, I will be using a one to one relationship between generic objects and object triggers. This will ballon the database size and will create some performance issues. However, I'll clean these issues in the next prototype. This feature will allow the user to select a game object already in the database. The user can create or edit the trigger associated with the object.
Fighter triggers will operate like object triggers. They will follow a one to one relationship with the same options as generic objects.
Trigger loads should be straightforward. It should follow the general format for audio triggers; however, I might have to add a "check" routine to make sure the trigger called already exists in the database.
When this tool is done, it will help develop mission scenarios faster...
Thursday, October 11, 2012
Database Tools
Databases and Unity present some unique problems. First, most databases require a static definition to consistently access the database. Unity dynamically generates data structures. If you create a class consisting of just a couple of variables, it varies somewhat as a structure at each new instance. The easiest solution is to create the database access routines in C# and build it as a .dll file. Unfortunately, the database I chose can only be used in Unity due to certain security features. This is slowing down the development of each mission. I have two options, neither of which is completely ideal.
The first option is to create another program to manage databases. This will require me to create another database in another database, like MySQL or Access. At this point, I will need to create a .dll file for Unity access. Originally, this was due to the need to transfer the "other" database into the current database. However, creating a .dll file would make the original database irrelavent. I would just scrap it and use the new database.
The second option is to create a trigger generator within Unity. I would create a mission without the trigger manager. Instead, the trigger generator would cycle through each object and save it the database. This would work for time zero instantiations. However, I still haven't figured out how to create the other triggers. I might have to go with option #1 to augment this system.
In either case, I need to explore implementing a different database...
The first option is to create another program to manage databases. This will require me to create another database in another database, like MySQL or Access. At this point, I will need to create a .dll file for Unity access. Originally, this was due to the need to transfer the "other" database into the current database. However, creating a .dll file would make the original database irrelavent. I would just scrap it and use the new database.
The second option is to create a trigger generator within Unity. I would create a mission without the trigger manager. Instead, the trigger generator would cycle through each object and save it the database. This would work for time zero instantiations. However, I still haven't figured out how to create the other triggers. I might have to go with option #1 to augment this system.
In either case, I need to explore implementing a different database...
Wednesday, October 10, 2012
Prototype #2 Build #57 (2.57)
Most of the items ont the "to do" list are complete with the exception of adding asteroids to fill in "void" spaces. The addition of the asteroids around the waypoints present a signifcant change; therefore, I am including a link to a new prototype. There are actually six programs. Four are Windows based, and two are for the Mac. The Window programs are divided into 32 and 64 bit programs.
In order to run the program, the user needs to load the database. This program starts with prototypev2b57DatabaseLoad. It just loads the database. The other file, which starts with prototypev2b57Gameplay, runs the actual game. I would love some feedback on the placement of asteroids. I just want to know if having the larger asteroids make the game easier to visualize.
Here's the link to the new build:
https://dl.dropbox.com/u/43398523/Builds.rar
In order to run the program, the user needs to load the database. This program starts with prototypev2b57DatabaseLoad. It just loads the database. The other file, which starts with prototypev2b57Gameplay, runs the actual game. I would love some feedback on the placement of asteroids. I just want to know if having the larger asteroids make the game easier to visualize.
Here's the link to the new build:
https://dl.dropbox.com/u/43398523/Builds.rar
Tuesday, October 9, 2012
Fighter Instantiation
I fix the issue with the faction manager. In addition, I placed some preliminary asteroids around the waypoints to give the player a sense of perspective. I had to enlarge the asteroids. The smaller asteroids were just too small. The average player just could not see the smaller asteroids at any significant range. On average, I increased the asteroids' size by a factor of 100. Also, I created a dwarf planet. It's approximately 13 km in size. It's alittle small for a dwarf planet, and it doesn't meet the actual definition for a dwarf planet. An actual dwarf planet has cleared it area of asteroids. However, it does represent a massive celestial object. Despite this massive object taking up a significant portion of space, I still need to place more asteroids to avoid "void" areas; however, I am shifting my focus to the instantiation of NPC fighters.
Fighters are almost identical to generic objects. The major difference is the existence of a fighter AI script. This script has a number of additional variables that need definition. The most notable is the firing arc and distance variables. These variables not only affect weapon usage. They also impact flight behavior. In addition, fighters can have a waypoint variable and a mission target variable. The waypoint variable points to a waypoint and indirectly a waypoint manager. The mission target represents an enemy target, usually a capital ship, that is the primary target. This target will outweigh other targets in the target selection AI routine.
Waypoints are loaded before fighter instantiation. This means that the fighter instantiation process can load waypoints without any issues. However, mission targets are somewhat less predictable. While capital ships are usually mission targets, this is not always the case. Mission targets can be other fighters, asteroid stations or other space stations. Consequently, this variable cannot be loaded within the normal routine. The mission target variable needs to be loaded at the very end of initial load routine.
I will not program this feature at this time. I want to have the capital ship instantiation process done before tackling this feature, and capital ships will happen after I get the first tutorial fully operational. Mission targets is just not necessary for this.
Fighters are almost identical to generic objects. The major difference is the existence of a fighter AI script. This script has a number of additional variables that need definition. The most notable is the firing arc and distance variables. These variables not only affect weapon usage. They also impact flight behavior. In addition, fighters can have a waypoint variable and a mission target variable. The waypoint variable points to a waypoint and indirectly a waypoint manager. The mission target represents an enemy target, usually a capital ship, that is the primary target. This target will outweigh other targets in the target selection AI routine.
Waypoints are loaded before fighter instantiation. This means that the fighter instantiation process can load waypoints without any issues. However, mission targets are somewhat less predictable. While capital ships are usually mission targets, this is not always the case. Mission targets can be other fighters, asteroid stations or other space stations. Consequently, this variable cannot be loaded within the normal routine. The mission target variable needs to be loaded at the very end of initial load routine.
I will not program this feature at this time. I want to have the capital ship instantiation process done before tackling this feature, and capital ships will happen after I get the first tutorial fully operational. Mission targets is just not necessary for this.
Monday, October 8, 2012
Size Matters
I tend to create game content with one eye on realism. Consequently, I attempted to create a realisticly scaled dwarf planet for the first tutorial. I discovered that with my current format; this is impossible. I am currently using a one meter scale for the game. I use this scale in 3d Max and other modelling programs to keep everything standard. This scale is too large to realistically create a space scene.
I have two options at this point. I can scrap realism, which isn't a bad option. Or, I can rescale the game. In order to do this, I have to use a kilometer scale in 3d Max and divide all force calculations by 1000. The change of scale for 3D modelling is obvious. The change within Unity is less obvious. The Unity engine operates on a one meter scale. There is no easy, at least as far as I know, dial to change this default. To effect this change, the programmer needs to incorporate it in the programming code. This means that an application of force needs to be divided by 1000.
Right now, I am sticking with the current scale. The "dwarf planet" in the game is very large. Is it planetary large? I think it could qualify in a perceptual level. In addition, I don't think refitting the current prototype will be an effective use of my time. The next prototype might see a rescale as an option. I already know where the majority of the force applications are in the game; it shouldn't be too hard to add a size multiplier into the game.
The other consideration is the feel that a would result for a rescale action. If the game feels too slow, it would be a bad thing. Right now, I think the current feel, speed-wise, is very close to where I want it. That is subject to change as others start to playtest it.
In a nutshell, I need to rescale the force calculation if I rescale the model size. I need to remember that when prototype three is under consideration.
I have two options at this point. I can scrap realism, which isn't a bad option. Or, I can rescale the game. In order to do this, I have to use a kilometer scale in 3d Max and divide all force calculations by 1000. The change of scale for 3D modelling is obvious. The change within Unity is less obvious. The Unity engine operates on a one meter scale. There is no easy, at least as far as I know, dial to change this default. To effect this change, the programmer needs to incorporate it in the programming code. This means that an application of force needs to be divided by 1000.
Right now, I am sticking with the current scale. The "dwarf planet" in the game is very large. Is it planetary large? I think it could qualify in a perceptual level. In addition, I don't think refitting the current prototype will be an effective use of my time. The next prototype might see a rescale as an option. I already know where the majority of the force applications are in the game; it shouldn't be too hard to add a size multiplier into the game.
The other consideration is the feel that a would result for a rescale action. If the game feels too slow, it would be a bad thing. Right now, I think the current feel, speed-wise, is very close to where I want it. That is subject to change as others start to playtest it.
In a nutshell, I need to rescale the force calculation if I rescale the model size. I need to remember that when prototype three is under consideration.
Subscribe to:
Comments (Atom)