Thursday, December 13, 2012

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.

Wednesday, December 5, 2012


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

Monday, December 3, 2012

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.