Mission Briefings

In prototype #2, I'm aiming for a simple mission briefing screen which will consist of a continue "button" and a briefing "text box".  Like the start up screen, the continue "button" will end the briefing screen and load the next step in the game, that being the actual mission.  The briefing "text box" will display the instructor's "lesson" to the new pilot.

In addition, I want to add sound to the scene.  The sound manager already exists with full capability to create the sound portion of the briefing.  Simulating the instructor's speech will be handled by the trigger maanager, and the text representation of the instructor's speech will be added to the "text box" via the trigger manager.

This means that I have to add another trigger type to the game.  Like the audio triggers, this trigger will be a text trigger and will have a "txt" prefix.  It will utilize a chat controller to print this text in a chat box, the previously mentioned "text box".  Later in the development cycle, I might merge this new trigger type into the audio triggers. 

The basic structure of the Chat data structure in the Battlestar.dll file will be:

int OID
string TriggerID
string AudioID
string Content

The ChatManager class will contain the standard operations of: save, load and delete.  The Load function will need a method to load an item using the AudioID.

The game's chat manager will require a source, or output, game object.  This will work like an audio source in the game's SoundManager.  When a "txt" trigger activates, it's data is passed to the ChatManager (the game one, not the Battlestar.dll).  This manager is charged with displaying the contents in the chat box.  In many ways, I expect alot of similarities between the SoundManager and ChatManager in structure and functionality.

Anytime during the briefing scene, the player can opt to end the briefing and go to the mission.  This is accomplished by the continue "button".  It should operate in an identical manner to the start up screen's "start" button.

Starting Scene Transitions

Now that I have two tutorial missions, it's time to create a transition between the tutorials.  To start this process, I will concentrate on building a very simplistic transition system.  Complexity will happen after I finalize things like a scoring system, experience point rewards, a skill system and other features.  That is further down the development process.

To start, there are two key mission loading variables: the mission name and player code.  The mission name dictates what triggers get loaded into the scene.  This includes the loading of asteroids, other fighter and, in the future, capital ships.  It also determines what waypoints are placed into the missions along with any mission objectives.  The player code, on the other hand, loads the player's fighters which can vary in combat capability in the future.

Consequently, the initial iteration of the mission tracker needs to incorporate a mission name and a player code.  Since we are bypassing character creation in this prototype, the player code can be a static "plydftAbanathie".  This is the Scorpion fighter used in the current prototypes. 

The mission names are more complex.  First, the game will need a "generic" mission briefing and debriefing scenes.  In future versions, these will be animated scenes with a NPC avatar briefing or debriefing the player.  In this initial version, it will be a simple menu screen with a section of text that will impart the contents of the briefing or debriefing scene.  These scenes will need to be able to get the next mission, briefing or debriefing data from a table. 

There are a couple things that are pretty static.  We always start with a briefing.  That is followed by a mission which is followed by a debriefing sequence.  The debriefing sequence is followed by another briefing.  While the next briefing is not necessarily a linear set of missions, it can be depending on story arc.  This leads to a third a variable, a must complete next mission flag.  For the tutorial missions, these are set to true.  In addition, the record should point to the next mission on the list, assuming the mission is in a sequence of missions.

This means the mission tracker table needs: a unique identifier, a category (briefing, mission or debriefing), mission name (or briefing or debriefing name), the next mission in the list and a must complete flag.  A load table will have the player code and the unique identifier.  This will provide the basic framework for transitioning between scenes.  Stuff may be added to these features in future iterations; however, this will represent the operating basis for this prototype.

Here's the summary (for when I reference this blog in the future):

MissionTracker
  int OID
  string Category
  string MissionName
  int NextMissionID (Briefing ID relationship - 1 to 1)
  bool MustComplete

LoadTracker
  int OID
  int MissionID (points to an OID in the MissionTracker)
  string PlayerID (points to a player code in the player data table)

The program flow should be:

Start up screen -
  "button" to click which loads "Tutorial #1 Briefing" and "plydftAbanathie".
Briefing Screen -
  "text box" prints out the briefing material
  "button" to click which loads "Tutorial #1 Mission" and "plydftAbanathie" -
    next items in table
Mission Screen -
  actual mission with a load "Tutorial #1 Debriefing" and "plydftAbanathie" before exit -
    next items
Debriefing Screen
  "text box" with debriefing material
  "button" to click which loads "Tutorial #2 Briefing" and plydftAbanathie" -
    next items

The cycle continues with the tutorial #2.

Overview of the Waypoint Manager

The first type of object loaded by the TriggerManager is the waypoint managers and waypoints.  These objects are loaded first as a prep to loading the player and fighters, both of which usually need waypoint data. 

Here’s the code:

The waypoint manager is simplistic in its structure.  It does not perform constant update function; it holds data and performs simple functions when requested by another script.  The waypoint manager’s primary function is to hold and track a collection of waypoints.  When queried with a waypoint, the manager will output the next waypoint in the list.  In addition, the waypoint manager has methods to add and remove waypoints from the waypoint list.

Battlestar.dll: Trigger and TriggerManager Classes

In the previous batch of blogs, I covered the Trigger Manager script within the actual game.  I did not cover the Trigger class or TriggerManager class created in C# that is used by the game script.  This blog will cover both of these classes.

Both of these classes were compiled in C# as a .dll file.  The statement used at the beginning of the game’s TriggerManager script, “using Battlestar”, gives the game access the methods and properties created in C#. 

Here’s the Trigger class:

It is just a bare-bones class.  It only possesses the variable declarations.  Ordinarily, I would avoid this format; however, the database used by the game requires a barebones format.  Each variable in this class represents a field in each record in the database table, “Trigger”.  Since this class represents a barebones class, I created another class to access the database using this class. 

Here’s the TriggerManager class:

This class has actual operations that access the database.  These are simplistic operations like: a save, delete and load operation.  To access these operations, the game scripts use a statement like “Battlestar.TriggerManager.Load(vPath, vMission)” to access the commands in this class.  The actual game scripts never touch the database; all database interactions are handled in .dll files. 

While it would be simpler, in principle, to have the MonoDeveloper in Unity handle these operations, it’s necessary to implement the .dll file format due to the nature of MonoDeveloper.  Unity dynamically generates class structures.  This means that a class, like the Trigger class detailed above, would vary each game execution.  This makes creating a stable table difficult from inside Unity.  Using .dll files is the easiest solution to this problem. 

Tutorial #2

I’ve finished to rough draft of tutorial #2.  This tutorial basically teaches the player how to land a fighter on a stationary battlestar.  The player starts in optimal position to land the fighter, and the instructor instructs the player each step necessary to land the fighter.  Key concepts for this tutorial is the ability to roll the fighter using the A and D keys to align the fighter with the battlestar. 

This tutorial is short, possibly too short.  The next tutorial in this series will put both tutorial #1 and #2 together.  I envision it being the player’s first solo flight.  The player launches from the battlestar, flies to each preprogrammed waypoint (three total) and lands the fighter on the battlestar.  The fourth tutorial will serve as a pre-test for the final tutorial.  Basically tutorial #4 would involve launching from the battlestar, travelling to each waypoint, performing a task (like rolling the fighter, gliding the fighter and so on) and landing the fighter onboard the battlestar.  The final tutorial would be a “final exam” for basic flight school. 

Back to tutorial #2, here’s the link to the build.rar that has the program files:

https://dl.dropbox.com/u/43398523/Builds.rar

 

It utilizes the same map as tutorial #1.  It just didn’t make sense to create a brand new map for the tutorial.  It uses the same basic framework of the previous tutorial programs.  The only major difference is the inclusion of some extra trigger generators attached to the gravity control scripts for the landing bays.  I guess I should have upped the prototype number to 258 versus using 257.  That’s my mistake. 

Now that I have two distinctive missions in the database, I need to create a system to load each mission using a single program.  The current setup requires the user to launch the two tutorials as separate programs.  To make this happen, the program will need to perform some basic operations.  First, it has to track the progression of missions.  Once tutorial #1 is completed, the name “Tutorial #1” needs to be replaced by “Tutorial #2” in the resource manager.  Second, it needs, well I really want this, to track the player’s files.  Each individual player will have a unique database record.  This will facilitate tracking the player’s career and progression in the game.  While prototype two will not have a character creation process, it needs to support the concept.  This will make transitioning to prototype #3 an easier process. 

These two factors should be incorporated as a table in the database.  Each player, with the proper player ID code, should track which mission is next.  It should also track things like prestige, number of kills and other things; however, I haven’t gotten that far into the process just yet.  This table will be used as a tracker between scenes.

As an example, the first “real” screen will be a mission briefing screen.  In this screen, the player receives a briefing for that mission.  I plan on making this an animated and interactive scene.  At the end (or during depending on perspective) of the scene, the player’s mission data is saved to the table.  When the actual mission scene is loaded, that scene loads the mission data from the previously saved record.  Once the mission concluded, key data is saved to the database, like the debriefing screen (if applicable).  The next screen loads this data from the database, and so on and so on…

Database Update and Tutorial #2

I had an issue with the database.  Due to the structure of the various trigger tables, the database did not convert over to user-friendly format easily.  I took a couple of days to review the needs of the system, and after 500 lines of code, I have the basic layout for system.  Currently, it only displays the data; however, it should have full functionality within the next couple of days.  It’ll probably only take another 500 lines.  I’ve come up with a solution to problem that will allow for future additions, like the addition of capital ships. 

As soon as the database is up and running, I plan on populating the first tutorial mission with more asteroids and making it more player-friendly.  In addition, I will complete the second and will use the second tutorial mission as a testing mechanism for the new database manager. 

The second tutorial mission will cover landing the fighter.  Here’s the plan for the basic flow for the second tutorial:

Start at optimal landing position for the destroyer

Instructor states the importance of rolling a fighter in landing.

Instructor orders the player to roll left.

Instructor orders the player to roll right.

Instructor orders the player to match the destroyer’s roll angle.

Instructor orders the player to aim the fighter towards the destroyer’s landing bay.

Instructor orders the player to lower the landing gears.

Instructor orders the player to increase the throttle.

After entering the landing bay, the instructor orders the player to cut throttle.

After getting within 50’ of the landing bay center, the instructor orders the player to hit the brakes.

End of tutorial.

This is a short and simple tutorial.  My plan is to have tutorial #3 incorporate the concepts in tutorial #1 and tutorial #2 as a “test.”  In essence, tutorial #3 becomes the “finals” for basic flight.  Once the player “passes” basic flight, they move on to the combat tutorials. 

With the basic flight tutorials out of the way, I plan on completing the priorities I outlined in a previous blog.

Overview of the Sound Manager

The sound manager, if you haven’t figured it out from the title, is in charge of playing audio files in the game.  The more recent Battlestar Galactica TV series attempted to be more realistic in its approach to the IP.  Sound does not travel through space, and this game attempts to adhere to that principle.  All sounds in the game come from the actual fighter, like pulling the trigger, or from the communication system.  This made creating a dedicated sound manager appealing for this game. 

There were various design needs inherent to the sound managers.  This required the creation of three sub-classes within this script.  Each class was necessary to keep relevant data within the same list.  The classes are: a source tracker, play tracker and trigger tracker.

The source tracker’s purpose is to make sure that an individual finishes a speech before beginning another speech.  It detracts from realism when another pilot tells you something, and another audio file begins to play with the same pilot telling you something else before the completion of the first statement.  The source tracker is designed to de-conflict these instances.  Every file designed to be spoken by an individual is placed into a source tracker list.  Before playing any clip from any source, the source tracker list is checked to make sure that individual is not already speaking to the pilot.  If he or she is speaking, the new audio is ignored or queued into a play list.

The play list utilizes the play tracker class.  It consists of a reference to the audio file and the source, or speaker, of the audio file.  Every Update(), the play list is checked against the source tracker list.  If the audio file’s speaker is done speaking, the new audio file is played by sound manager.  In essence, this system just delays the speech until it is ready to be played to the player.

Once the audio is played, a trigger needs to be generated at the completion of the audio file and sent to the trigger manager.  The trigger tracker is instrumental in performing this function.  Once the audio file is played, an end time is calculated by adding the current system time index to the length of the audio clip.  This information, along with the clip name, is stored in the trigger list.  Every Update, the trigger list’s contents are checked against the current system time index.  If the record’s time index is less than the system time index, a trigger is sent to the trigger manager.

To make the Update() procedure work properly, there are three distinct play overloads in this script.  The first accepts a clip as a parameter.  This overload method plays the clip without any criteria and designed for sounds that occur despite the source.  An example of this would be sound of the fighter’s gun firing.  Pressing the trigger before the gun audio file completes would cause another gun audio to execute despite the incompletion of the first gun audio.  The second overload method accepts a clip and a source.  This method will play the clip if source is not currently speaking to the player.  If the source is speaking, the clip is ignored and discarded without playing the clip.  Audio files that are not important generally fall into this category.  The third method requires a clip, a source and play list flag.  The play list flag designates this clip as important.  If the speaker is already speaking, the audio file is queued into the play list.  It is played once the speaker is done with its current speech.

Another play option, PlayCheck(), is used to play clips in the play list.  The major difference with this procedure is that it returns a Boolean value.  If the clip is played, due to the availability of the speaker, a true value is returned by the function.  This allows the script to identify whether a clip is played and should be deleted from the play list.

Here is the complete script:

Unlike the trigger manager, I don’t anticipate many changes to the sound manager.  It is relatively complete at this point.  The only thing I would want to add to it is a method to end an audio clip prematurely.  This would be useful in getting a speaker to change his or her speech if something important occurred during a mission.  I’m looking into how to end audio files in Unity; however, I haven’t come up with anything yet…

 

Overview of the Resource Manager

Despite having a limited role of accessing the game’s database, the resource manager is a key component of the game. Any time a mission needs to query the database, the resource manager handles that function; it is the only script that actually interacts with the database. This serves a couple of purposes. First, it centralizes all database interactions. If the data in the database is correct and incorrect data is outputted, the problem is probably within the resource manager. Second, it is designed to centralize key data fields. The database path, mission name and player name do not need to be replicated throughout the other scripts in the game. The resource manager avoids unnecessary replication. Currently, the resource manager is still under development. While a good portion is in place to make a mission functional, there are other procedures and functions that I want to include in the future. Here’s a quick breakdown of the key components.

The script has four global variables to track: the database location, the player’s ID, the mission’s name and a list of factions in the mission. The faction list was originally part of a faction manager; however, it was easier to eliminate the intermediary faction manager script and incorporate this function into the resource manager.

During the startup routine, Start(), this scripts loads the initial values based on the mission. Currently, all of these values are static. In the future, these values will be loaded from the database; I haven’t created this functionality yet. In addition to the variable loads, Start() also sets the default key map.

While this script does not possess an Update() routine, it does have a number utility functions that execute throughout the game. These scripts are called by other scripts to access the database.

Here’s the entire resource manager script:




This script is attached to an empty game object tagged as “Resource Manager” at location (0, 0, 0). This allows the game to locate the game object with ease. However, the resource manager is generally considered a global static script. This means that most of the routines can be called by calling the resource manager directly. For example, the simple statement, ResourceManager.LoadPlayerData(“objtt1Asteroid1”), will work in any script without defining the resource manager as an object. This feature makes the resource manager a versatile tool for the game.

Overview of the Trigger Manager

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.

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.

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...

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...

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

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.