Turret Update and New Models

I'm still stuck on turrets.  I came to the realization that the current Colonial destroyer will not function well within my proposed framework.  As a result, I created two new destroyers for the Colonial Fleet.  In addition, I created a new Cylon destroyer.  I've been under the weather for the past few days; creating models was the most taxing activity I wanted to tackle while sick. 

Here are the two Colonial Destroyers:

The purple destroyer is the Battlestar Aries; the pink one is the Battlestar Hercules.  These models will be easier to incorporate turrets.

Here's the Cylon destroyer:

All three models do not include turrets.  These will be added inside Unity.

In addition to the adding big turrets to these models, I'm thinking of creating a series of smaller turrets.  The smaller turrets will not be visible and will represent the flak guns seen during the Battlestar Galactica TV series.  I'll have to figure out how to incorporate these smaller turrets into the game.

Turrets

I want to create a turret manager that will manage all of the turrets attached to a capital ship.  Before I tackle this feature, I do want to create another model to represent a destroyed turret and implement a procedure to change models.  Here's a picture of the current Colonial turret:

I want to create a destroyed version of this turret.  It really shouldn't be too hard to create a destroyed version; however, we'll see if that's a true statement shortly.

As for the turret manager, this script should work as an intermediate script between the turret control (equivalent to the flight control script for a fighter) and the capital ship's AI script.  As intermediate script, I am hoping that it maintains a higher level of performance on older computers by breaking up the turret's AI routines from mechanical implementation of those decisions.  In addition, consolidating those scripts into an intermediate script will allow the game to control turrets as a single unit, when possible.  Passing the AI data directly to the turret control script is more likely to see turrets acting as individual units. 

The turret manager should accept a target from the AI routine as it's primary IO function.  Based on the received target, the manager will calculate the movement of each turret and will decide on whether or not to fire weapons at set intervals (FixedUpdate).  Basically, it will have the movement and firing routines of the Fighter AI's script.  It will not possess the full target selection script as a default.  If a turret absolutely cannot obtain a sufficient firing angle, the turret manager will be able to find an alternative target for each turret. 

Here's the process flow for the manager:

Main Loop:
Get target data.
Rotate turret to target
Fire weapons if the target is within 15 degrees of target
If it reaches the maximum rotation threshold and cannot obtain a fire solution, then place the turret into automated mode.
Loop to Main Loop

Automated mode loop:
Find the best target within threshold range; if there is no target, keep the main target as a target
Fire weapons if the target is within 15 degrees of target
If the main target is within 5 degrees of the threshold range, switch target to main target and take the turret out of automated.
Loop to Automated mode loop

Special note: Get target data doesn't happen within the Update() procedure; it is passed directly to the turret manager.

To make this loop happen, I need the following variables:

vMainTarget : Transform
vTurretList : List<TurretData>

TurretData will contain the following fields:

vTurret : Transform
vTurretControl : TurretControl
vFireControl : FireControl
vTarget : Transform

This should give me a decent starting point to start the process for finishing turrets...

Battlestar Squadrons

My initial post on getting capital ships to launch and land fighters was somewhat limited and didn't work out so well...

So, here's attempt number two. In this blog, I'll outline the entire process to make sure I get all the information into the system.

We'll start with the database loading routines. To load the squadron, I need the battlestar's name. With the name, I can access a list of pilots attached to the battlestar. While these names should be dynamic over the course of the game (i.e. names should change over time representing pilot transfers and deaths), I'm going to limit the initial list to a static list. I'll add routines within the game to dynamically change squadron compositions within the game itself. The loading routines will need the pilot's first name, last name, rank and fighter. The rank and fighter will be used to load the default values for pilot's skill. To make this happen, I will need a Squadron and SquadronManager in the Battlestar.dll file. The Squadron script will have these fields along with the battlestar's name. The manager script will contain standard database access methods to retrieve and save data to the database.

Once the database is accessed, the game will need to store this information. Each battlestar will have a SquadronControl script to hold this information. There will be a couple of lists in this script: a roster, an active list, a reserve list, a landed list and a killed list. Each of these lists need to have the same data structure, PilotData. This structure will contain the pilot's first name, last name, rank, fighter and a time field. These fields will remain pretty static except for the time field. The function of the time field will depend on the list.

In the roster list, it is set to zero; basically, it won't be used by this list. Similarily, the active list will not use the time field in a meaningful manner. It will contain the launch time; however, this is just in case for future expansion. The killed list will, similarily, not utilize the time field. It will just reflect the kill time for the pilot. This will exist for possible expansion of game features.

On the other hand, the reserve list will rely on the time field extensively. The time field will be used to track when a pilot is ready for launch. To launch a pilot, the script will need to receive and store a launch order. If there is no pilot ready or being prepped for launch, then the pilot's time field is changed to reflect when he or she is going to be ready. Once a pilot is launched, it removed the from the reserve list, added to the active list, instantiated into the game world and the launch order variable is adjusted to reflect the launch.

Like the reserve list, the landed list will heavily rely on the time field. When a pilot lands, he or she is removed from the active list and placed on the landed list. The time field will represent the amount of time it will take to get the fighter from the landing bay, repaired, refueled and reloaded with ammo to warrent it being placed back into the reserve list. Currently, I think the fuel amount, weapon amount and structure amount will be driving forces for the time field calculations. A fighter that is too badly damaged should take longer (maybe too long for the mission's purposes) to get back into space.

In addition to these list, the SquadronControl script will need other variables to track the launching procedures. Each battlestar will need a preparation time value. This value will dictate how long it takes to prepare a pilot for launch. Also, a launch order variable will be necessary to track launches. This will be a numeric value that is incremented to reflect how many pilots the battlestar wants to launch. As pilots are launched the value is decremented; this value shouldn't exceed the value of reserve pilots. Another important variable is a list of launch tubes. This list will contain the game object that represent the spawn point for launching fighters. As fighters are launched, the spawn point is deleted from the list and added to the end of the list. This will ensure that each launch tube is used in a continuous cycle.

I can't think of anything else to add at this point. So, I'll go with this to restructure the launching procedures. I need to add a Squadron data object and SquadronManager script to the Battlestar.dll file. After that, I can go back and create a SquadronControl script with a PilotData script as a data structure subscript. We'll see how this works out.

Overview of Player Data

After the setting up the waypoint game objects, the Trigger Manager creates the player.  The first script loaded into memory to create a player is the player data script.  This script is simple data script used to define a player.  In addition to defining a player, this script also contains the basic data necessary to define non-player entities in the game. 

Here’s the script:

 

This is a simple script.  It only contains a series of methods to access the stored data.  However, it is used as a primary reference to drive accessing the database for player data.  Its primary purpose is to centralize the data relating to the player.  Centralization, while not necessary currently, will become essential to implement a system to track scores during and between missions.  In addition, it will become more important after I add skills to customize individual players.

Capital Ships: Launching and Landing Fighters

I've been busy the last few days; so, I haven't had time to flesh out exactly how to approach the capital ship's role in launching and landing fighter craft.  This blog will, hopefully, give me a clear road map as to how to to handle this aspect of the game.

First, landing isn't a big concern at this point.  The current system needs alot of polish; however, it does represent a functional, bare-bones skeleton.  Adding features to this can come later in the development process.  Right now, it is more important to get all the capital ship's features a skeleton for future development.  Consequently, this round of priorities will not see any additions to the landing of fighter craft on a battlestar.

Second, launching fighters needs some significant additions to the game. 

First, I need to add launch points associated with each launch tube on the current destroyer model.  This will be a simple empty game object oriented 90 degrees off from forward.  Obviously, the 90 degree offset will depend on whether the launch tube is located on the port or starboard side of the ship.  The launch points will be used as instantiation points for launching fighters. 

In addition, I need to create a dedicated fighter manager script for the battlestar.  This script will be attached to main battlestar game object.  It needs to contain a pilot list at the very least.  It probably will need a pilot list (representing all pilots attached to the battlestar), an active list (all pilots current launched and in space), a reserve list (all pilots that are still onboard the battlestar) and a killed list (list of pilots shot down during the mission).  The script will need methods to move pilots from list to list as necessary.  The full pilot list should contain the pilot's name (first and last), rank and fighter type.  The combination of fighter type and rank would point the script to retrieve a record from the database.  This data would represent the baseline data for a non-player character flying a certain fighter of a certain rank.  The name fields from the database file would be replaced by the first and last name of the pilot list's record. 

This script will also need a method to launch a fighter.  This is a simple instantiation process and will probably be similar to the one currently used in the trigger manager.  A more complex instantiation process will be necessary for the fighters that are already launched at the start of the mission.  This will lead to a change in the trigger manager and will possibly lead to a new trigger type.

To make this model happen, here are the steps that I will use to make things happen.

1.  Add launch points to the launch tube locations.
2.  Create a new FighterManager to be added to the battlestar's game object.
3.  Create a list for all, active, reserve and killed pilots with methods to move members between lists.
4.  Create an instantiation process to launch a fighter.
5.  Create an instantiation process for fighter's launched prior to the start of the mission.
6.  Create a dummy script to test all of these functions

This shouldn't be too hard to implement at this point.  It might take alittle time though...

The Role of Capital Ships

The Battlestar IP features capital ships and the small fighters.  In order to remain true to the IP, the game needs to keep capital ships as a meaningful part of the game.  To do that, I need to figure out exactly what role, capabilities and other features to include with capital ships. 

First, capital ships, whether a Battlestar or a Basestar, served as a launching base for the smaller fighters.  Vipers, and the older Scorpions in this game, primarily launch from a Battlestar.  While I do plan on adding some non-carrier capital ships to the game, this is an exception to the rule.  Consequently, each battlestar needs some type of landing control script.  This is actually the GravityControl script attached to the landing collider for each battlestar.  It produces some key triggers, like a fighter entered and landing reached trigger.  In addition, it applies an artifical gravity force to each fighter inside the landing bay.  This helps simulate the landing experience.  I would like to expand this script to include the landing beacon points to facilitate landing NPC fighters.  The current system is functional though, this addition is a low priority.

In addition, each Battlestar and Basestar should come with a fighter roster.  When triggered the capital ships would instantiate a fighter with the appropriate roster stats.  This will simulate launching a fighter.  In away, this will have a significan impact on the trigger manager.  While the trigger manager can still create a fighter, whether PC or NPC, the primary instantiation of a fighter would fall to the battlestar game object.  In addition, some controls would need to be put in place to keep a battlestar from launching more fighters than it has launch tubes.

Second, every battlestar has big guns, and every basestar seems to have big missiles.  While Colonial craft do have missiles and Cylon crafts have guns, the primary weapon focus seems to be faction driven.  However, guns and missiles share some key similarities that will allow them to be integrated into a single control script.  A rudimentary system is already in place to handle gun and missile turrets.  Turrets have scripting that will turn and fire them.  Unfortunately, they don't have an actual AI routine yet that will give commands to turn and fire.  That needs to be a priority.  The TurretControl script will accept commands from a TurretManager script.  The TurretManager will be attached to the main battlestar game object while the TurretControl is attached to each individual turret.  The manager will provide commands to the control script. 

Third, I want to break up the collider meshes for each capital ship.  A key tactic used in the actual TV series, both of them, was an attack on a key battlestar subsystem, usually the landing bay.  I want to give the players a chance to knock out key systems on a capital ship or protect a key system on a battlestar.  Landing bays, FTL drive, sublight engines and individual turrets are things that I think should be targetable at this stage.  While I won't incorporate a fine-tuned subsystem targeting system at this point, I want this feature ready to go for incorporation.

Fourth, I need to write moving parts scripts for each battlestar.  I think this will be determined by the battlestar's class.  For example, the landing bay retraction and extension numbers will probably be slightly different for a Columbia Class Battlestar (Galactica) than a Caprica Class Cruiser.  I will make it generic if possible; however, the initial iteration will probably be class specific.

Fifth, I need to create an AI controller for capital ships.  The FlightControl script is already in place to accept movement commands.  TurretControl exists to move and fire weapons; however, there is no methodology to command these scripts to execute.  A primary AI, CapShipAI, is needed to animate the big ships.  Unlike the relatively enclosed FighterAI script, this script will need to work closely with the TurretManager script.  Data should pass between the two to optimize firing positions.  The AI script will be in charge of determining roll and angling to protect key subsystems and maximize weapon deployment.  The TurretManager will be in charge of the actual deployment of weapons. 

That's alot of stuff I need for a capital ship...

Current Priorities

Well, I only got two of the five priorities done from the previous build; however, I think it is time to do another set of priorities.  The screen transition process has a decent start; the trigger manager is in a decent format.  Unfortunately, I'm sick of programming the trigger manager; so, I'll put the trigger manager off to side for awhile.

The major point that really irks me at this point is the lack of focus on the capital ships.  I need to address that issue before picking the trigger manager up again.  I need to figure out what functions the capital ships will play in missions and how they will impact the gameplay.  This is my first priority.  It's just something that has been sitting on the back burner for too long.  The goal in this step is to get a fully scripted battlestar and basestar into the game.  While getting capital ships integrated into the trigger manager won't happen in this step, the goal is have the system ready and fully operational for integration.

The second priority is to polish the HUD.  The transition screens introduced me to the GUILayout options available in Unity.  I want to convert some of the HUD to utilize these options.  In addition, I need to figure out how the alternate view will work in the game.  Currently, you can hit the "Shift" button to get to the alternate view, but it is nowhere close to being in a playable format at this point.  Part of the HUD overhaul will be fleshout this alternate view.  There is a strong possibility that I will have redesign some models to accommodate the alternate view; however, I'll get to that when I get to it.  I will probably release another build at this point; I anticipate it being build 2.61.

Third, I need to flesh out the trigger manager.  It's currently in the most basic form.  It only accepts a linear progression in a mission.  I need to add different trigger types to make the game more playable and user friendly.  This includes a delete trigger and possibility an "if-else" trigger.  I'll flesh out the options for the trigger manager after I stop being sick of dealing with it.  This will be a major step in getting the game into a more playable format.  In addition, capital ships will be implemented into the trigger manager at this time, and I will be looking at restructuring triggers to make them more database friendly.

Fourth, I will need to redo the first two tutorial missions with these new features.  The tentative plan is to have a "finalize" tutorial #1 and #2 mission at this point.  The goal is to make these missions "dummy proof" and adaptable to player mistakes and deviations.  This will represent a major restructuring of the game and will probably warrant a different build number, 2.70. 

Fifth, I will finish up the basic flight series.  I anticipate a total of five tutorials in this series.  The first one covers the basic flight operations.  The second one covers landing on a battlestar.  The third one is a quick run around the block where the player travels to each waypoint and lands the fighter.  The fourth mission will be a pre-test of the final.  The instructor will run the player through the final exam.  It will represent "hand holding" the player through the final.  The fifth mission will be the final.  In some ways, it will be more similar to an actual mission in that the instructor will limit her interactions with the player.  Each additional tutorial will represent a slight change in versions: 2.71, 2.72 and 2.73. 

My general rule is to complete three of the five priorities before reprioritizing again.  That means the fourth and fifth priority are subject to change at this point. 

New Prototype Available

I completed the next build for the project.  This build represents prototype series 2 build 60.  It has a Windows 32 bit, Windows 64 bit and MAC version.  To install the game, the user will have to install the programs manually.  Each Windows versions consist of a .exe file, a resources folder and a database folder.  Each of these files need to be in the same folder for the proper execution of the game.  Personally, I recommand extracting the entire Build folder to My Documents.  This will ensure that all files remain in the correct location relative to each other.

Here's the link:

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

This game is still in a pre-alpha stage; however, some basic features are available.  This build incorporates a transition between missions.  These transition screens are in the most basic format.  I envision future builds incorporating a 3D avatar moving about the Battlestar between missions.  Unfortunately, that feature is long ways off at this point.  The current transition screens are only there to test the transitioning process. 

Feel free to provide feedback here.

Screen Transitions Update

I got the game to go through the first cycle for the briefing, mission and debriefing for the first tutorial mission.  In theory, it should automatically kick into the second tutorial mission cycle.  I need to create the dialog audio and chat files for the second tutorial; so, I can't really confirm that it will work perfectly at this point. 

I did run into an issue getting the first mission to transition to the debriefing scene.  The end of mission checks occur during an Update() function which happens every frame.  It's part of the trigger check routine.  The mission would see a end mission trigger and run the appropriate command, Application.LoadLevel("Debriefing").  However, I failed to delete the trigger after executing this command.  Since the deinstantiation process for the mission, mostly due to having over ninety game objects in the scene, takes more than one frame to complete, the game would execute another LoadLevel() command before the completion of the first LoadLevel() command.  This quickly cascaded into a hard crash of the program. 

So, lesson learned.  Don't try to load level every frame without a method to keep multiple instances of LoadLevel() from happening in your game!  It took me two to three days to figure out what was going on with this.  I got it to work though and am generally happy with the results at this point.

Right now, I'm creating briefing and debriefing dialog for the second tutorial and creating chat records for each dialog used in the second tutorial series.  Once I get those done, I can see if the game flows from tutorial #1 to tutorial #2.  If it works without any problems, I will be releasing my first multi-leveled program for this project...

Screenshots and the Chat Manager

I have started on the scene transitions and have completed the general layouts for the title and the mission briefing screen.  Here are the screen shots for the current screens:

These are just preliminary screens that probably won't survive for launch.  However, they provide a basic framework to start this phase of development.  In addition, I have the triggers created for the first first briefing and have updated all of the audio triggers for the first and second tutorial missions to be "chat" friendly. 

My current focus is on a basic chat window.  This window will have limited functionality at this point of the development cycle.  It's primary purpose is to accept and display text received from other scripts.  The primary purpose is to display dialogue from the instructor at this time.  Consequently, it will be simplistic at this stage of development.  It should have a method to receive new text from the SoundManager or another script.  It will take that text and display on the screen for the player.  The goal is to give a semi transparent background to keep it from interfering with the player's view of the battle space. 

The briefing screen will be primary location to test this new feature.  I'll have to nail down the timing issues within the game.  The text should only display right after the start of the dialog.  This means that queued speeches should be ignored until the it is actually executed by the sound manager.  This means that the sound manager and chat manager have to work closely together. 

I'll have to sit down and plan this out...

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.