I finished up the Turret class along with the TurretData class. As a note, most classes in this project will have two distinct intertwined classes. In the namespace BSGS, classes like Turret, Vehicle and Entity will be accessed by Unity3D. Database functions will exist in the namespace BSGDB. These classes will have the same name as the BSGS classes with an addition of "Data" appended to the end. The BSGS classes are designed to be "readable" by any project programmer. The BSGDB classes are designed to be functional with the database being used by this project. If there is a change in databases, I would only have to change the classes located in the BSGDB namespace.
I digressed though. I need to figure out what to do next. I think my immediate goal should be to have a loadable player character. The most basic scene will contain the player's vehicle and a background "sky" box. So, my goal is to make this happen. I will be focusing on creating the parts of the trigger manager to load a player into a scene. To make this happen, I will need to create a player trigger load routine. This routine should be close, if not, to identical to loading a normal space object whether it is a Cylon raider or an asteroid. Battlestars and Basestars might have an added level of complexity; however, even those space objects would share a good portion of the PC load routine. Did I digress again?
Anyways, I will need to develop the tools needed to take all of the data out of the database so it can be moved into Unity3D. Right now, I have the basic entity, vehicle, bullet, missile and countermeasure data in the game. Unfortunately, I still need a method to idenify where to put the player, identify where to put the initial waypoints for the player and identify the faction data for the player. In addition, I will need some method of tracking which mission is active.
Let's start with a mission tracker. Every mission will have an OID and a mission name. However, missions could be a part of a story arc. This means that there should be a way to group missions together; so, there should be an Arc OID. If the mission is a stand alone mission, this OID can be set to -1 as a default value. The Arc OID will point to another table where additional data can be held, but I can put that off for right now. In addition, there should be "level" associated with each mission. More experienced pilots will get more difficult missions after all. There are two ways of gauging experience in the game. The first is through rank, and the second is through the player's prestige. These two data fields will be tracked by another class that is far off in the future. But they need to be present. Beyond that, a mission should also give prestige, which will be the currency the player uses to purchase ranks and other special things like a better fighter. Finally, I think a follow up OID is necessary. Or, do I want to put that in with the story arc class? I'll leave the follow up OID out for right now. I gotta give the an arc class a reason to live...
So, the next class should be the Mission class and should contain:
Name (of the mission)
Requirement (measured in prestige; Unity will probably use Rank or Requirement)
Award (amount of prestige for completing the mission)
With this basic data, I could create the basic part of the trigger manager that filters the database for data pertinent to a specific mission. So, I guess that's what is on the agenda for right now.