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.

1 comment:

  1. I think I have a functional Battlestar.Squadron, Battlestar.SquadronManager, PilotData and SquadronControl script. I can't really perform a logic test on it though. I need to incorporate these scripts into the trigger manager...

    I'll put off the launch test at this point. I will move on to another facet of capital ships. Once I got these component parts in place, I'll perform an indepth test.