Damage Control

The more I jot down notes for this script, the more I realize that this script will undergo some huge changes.  In previous versions, Damage Control was a relatively small script with a specific objective that really didn't need to exist outside of Flight Control.  Now, it might just get to be a key script with a lot of code.

Basically, it will have access to the Flight Control script and will be able to update the current structure of the parent ship.  Right now, this is its only true interaction with Flight Control.  In addition, it will need a list of interchangeable parts.  This is where Damage Control will start to get complicated.

The list of interchangeable parts will actually be a list of a programmer defined type.  This type will contain a collider, a component, a replacement component and a damage threshold.  Basically, this script will get the collider hit by an attack.  It will find the collider, if the collider is in the list, and compare the amount of damage dealt to the damage threshold.  If the damage dealt exceeds the damage threshold, the script will "turn off" the original component and "turn on" the damage component.  This will allow space craft to be visually damaged in the game. 

In addition to these visual effects, damaging a craft should have an actual effect on the effectiveness of the craft.  Consequently, this script will need a series of subsystems.  When a collider is "hit", this script will also check for a keyword.  For example, the "left engine" collider has the keyword "engine".  These keywords will funnel hits on specific parts of the ship in a certain direction.

With a keyword system in place, the script will damage various subsystems.  An "engine" hit can affect "thrust", "fuel consumption rate" or other set subsystems.  Hits to other keywords can affect an entirely different set of subsystems. 

So, what are subsystems?  A subsystem is simply a float value representing a percentage.  Hitting the sensor subsystem would decrease the maximum sensor range by a certain percentage.  Hitting the maneuverability subsystem would have a similar effect on the ship's ability to turn.  Other systems would see an increase.  For example, damaging the fuel lines would increase the fuel consumption rate by a certain percentage.

Each of these subsystems would be accessible by other scripts.  The HUD Control would look up the sensor subsystem and incorporate that number into what is displayed to the player.  Flight Control would look up other relevant subsystems, like the fuel consumption, maneuverability and thrusting subsystems as part of its calculations. 

The plan is to eventually make Damage Control into a database compliant object.  This will allow me to use Damage Control to customize various ships using a single model or model set.  Actually, it may be two different database tables: one for cosmetics and another for subsystems.  However, this particular feature will be further down the road.  I will develop this script with a preload routine.  A "testing" script, will be attached to each object and will load the default values for a ship for the time being.  I want to see the new script in action before developing the database portion.

December

I've been busy the last two weeks with work; however, this did give some time to mull things over. 

First, I really don't want to import models into the game until I am ready to texture them.  I hate to say it, but prematurely importing models will just create a situation with I have 15 models of the same plane with only one being used by the game.  I should be getting a texturing program before Christmas; so, I will hold off on importing models until then.

Second, Damage Control will be undergoing a huge revision.  It's going to be a bigger revision than I originally anticipated earlier.  Many features found in the older Flight Control will migrate here.  I'll write a blog dedicated to the changes, but Damage Control will look completely, well very, different from previous versions.

Third, I want to institute a new system in loading scripts.  In the future, I will have to game files.  The first will be the working copy.  I will use a liberal import rule for this version.  When a system is done, I will export it from the working copy and import it into the current copy.  This is just to practice some quality control.  Past prototypes got bogged down with unused models, discarded scripts and many other things.  Every once and awhile, I do plan on purging the working copy and creating a new working copy based on the current copy. 

That's about it for right now.  I got the model done...  Well, ready for painting.  I have the basic colliders ready.  I just need to get a painting program.  I want to map out the changes for the new Damage Control script.  I'm still in the process of discarding, reincorporating and rethinking the script...

Update (November 17, 2013)

I've been offline for the past few days.  I went on trip and spent a lot of time in a car without any internet access.  Before my trip, my computer crashed and required a complete refresh.  I managed to save my game files for this prototype and the previous prototype.  Unfortunately, I couldn't save the programs; I had to reformat and reinstall Windows. 

I've been spending a lot of time reinstalling important programs.  Unity3D is reinstalled; I just reinstalled 3DS Max.  Those are the two important programs.  At this point, I can start making progress again. 

Scorpion Class Fighter

I'm going to be extremely busy for, at least, the next week.  I probably won't be able to post for awhile.  I'll probably get to work some on the project, but that time will be limited.  At this point, I got a functional, well hopefully, flight control script.  There really isn't any great way of testing it at this point.  I need a couple of things to start testing.

First, I need to import the "official" Scorpion fighter.  I got the mesh done.  I still need to create a collider system for it, and I need to create "damaged" parts for the model.  These are the pics of finalized Scorpion:

I still haven't textured this model.  I do plan on getting a decent texturing program this month.  Once I get this model fully imported, I still need to work on a couple of scripts.

I will need a PlayerControl script.  This script will allow me to input movement commands and test FlightControl.  After PlayerControl, I will work on the FireControl and DamageControl scripts.  HUDControl will be the final script developed for the game object.  I might have to develop a level wide FactionManager to make HUDControl functional though. 

So, this week will involve prepping the Scropion to be imported in Unity3D and developing a good flow for the PlayerControl script. 

The New FlightControl

FlightControl is up next.  I just wanted to make some quick points on the new direction of the script. 

First, FlightControl will become a universal script.  Every interactible object will have a flight control script attached to it.  This is to standardize the access of various types of game objects.

Second, this script will receive its inputs from PlayerControl, FighterControl or some other script.  While this script is in charge with the "physical" movement of a vehicle, it cannot move a vehicle without being told to do so by another script.  This means that I will have to move the player control elements from the old FlightControl into the new PlayerControl.  As a side note, FlightControl will end up being an "input" for most scripts attached to a vehicle.

Third, it will use an applied thrust and turn variable like the previous version.  These values will range from -1 to 1 and will be used like percentages.  The turn variable will be a Vector3 with each coordinate representing a different turn component.  X will represent yaw.  Y will represent pitch.  Z will represent roll.  Applied thrust, like the previous prototype, will be a float; however, I want to make significant changes to the thrusting system with this prototype.  There will not be a set maximum speed in this iteration; the maximum speed value stored in the Vehicle type will represent a speed increment.  The amount of applied thrust will be dependent on current speed of the craft.  This equation will be the basis for determining the amount of thrust to apply to the craft:

      applied thrust = (1/(2^(current speed / maximum speed)))thrust

As a vehicle travels faster, it will become more difficult to turn the craft.  On the flip side, craft can travel faster.

Fourth, setting whether a player is in charge of the script will be removed from FlightControl.  The existence of the PlayerControl script will be sufficient to designate a player controlled craft.  This "setting" will occur as part of the triggering process.

Fifth, FlightControl will continue to have the basic collider listeners from previous prototypes.  This will make DamageControl very dependent on FlightControl.  I'm just not prepared to make the alteration of separating the listeners from FlightControl at this point.  I will note that the FlightControl script, in itself, will not touch the structure values.  This will be left up to DamageControl.

Depsite these changes, I don't anticipate FlightControl going through a major coding rewrite.  Most code from the previous prototypes will be lifted straight out of the previous version.  Except for the thrusting rewrite, FlightControl will mostly see a cut in the amount of code in it.  Alot of the past code will be cut and pasted into other scripts.

The Player Game Object

I'm pretty close to finalizing the Scorpion model.  There are a few things that need to get done.  I'll add a quick preview of the Scropion since people seem to like pictures...  Well, I like pictures...

Right now, I want to map out what the player's fighter will have to have script wise to function.

Mulling it over, I've come up with: a flight control, fire control, player control (input), HUD control and damage control script.  Each of these scripts would handle key parts, some of which will apply to non-player craft, of the game.

Flight control (FlightControl) will handle the movement of the fighter or other craft.  It will receive input from the PlayerControl script, or a dedicated AI script for non-player objects.  The output will be the actual movement of the vehicle. 

Fire control (FireControl) will handle the discharge of weapons by the vehicle.  Like FlightControl, it will receive its inputs from the PlayerControl script.  The output will be the release of ordnance.

HUD control (HUDControl) will manage the display of data to the player.  There will be two primary modes, a game and cockpit mode.  The player can select a metagame or a "realistic" display system.  This script will receive inputs from various sources.  Dradis contacts will be received by a "triggered" spherical collider around the player's fighter.  As objects enter or exit the sphere, they will be added to the player's detectable objects list.  In addition, FlightControl will pass data about the vehicle for display.  The output, obviously, is the actual HUD.

The player control (PlayerControl) script is a new script being implemented this prototype.  Its purpose is to manage keyboard and mouse inputs and pass that data to the appropriate scripts.  It will also allow for the customization of keyboard layout.  So, it receives inputs from the player.  Its output are the FlightControl, FireControl and HUDControl scripts.

Damage control (DamageControl) is primarily an event handler for collisions.  Its inputs are from collisions from various colliders.  It also takes damage data from objects that caused the collision to calculate the amount of damage dealt to the player's vehicle.  It outputs to FlightControl and HUDControl scripts.  It also outputs to the trigger manager for the game if the player's vehicle is destroyed. 

So, there will be five scripts to control the player's vehicle.  I just wanted to outline the general inputs and outputs for each of these scripts.  As I start to develop each script, I will created a post dedicated to that script.  I do know that I want to change some fundamental things with this prototype.  For example, I want to eliminate the "hard" maximum speed for fighters.  I will outline these changes in the appropriate scripts. 

Scorpion

No, I haven't finished the scropion.  I'm getting closer though.  I'll probably be offline for a couple of days; so, I figured I would make one post before then.  I finished most of the model.  I still have to do the gun mounts on the bottom of plane, and I want to setup the model properly.  Currently, the wings are a single mesh.  I want to divide them into a left and right mesh.  That way, I can display wing damage as it occurs. 

Here's a quick picture of the new Scorpion model:

The engines are a different color because I haven't made a final decision on how I want to combine these parts.  I might keep each part separate; I might combine the engines into a single mesh.  I'm just not sure how I want to do that part quite yet.  In other words, anything that doesn't look grey is something that I haven't made a decision on.

I placed my model, the one closest in the picture next to a high resolution model made by Smallworld.  I didn't add any textures to these models.  So far, I think my version is looking acceptable.  Currently, it has fewer than 4,000 vertices.  My budget is 5,000 or so.  I can go over, espeically if you take into account some of the less visible features like the landing gears... 

Models

Well, part one is to build a Scorpion class fighter model for the game.  I've built a number of models for past prototypes.  For this particular iteration, I will be changing some fundamental concepts. 

First, I will be building two models, at least, for each ship.  One model will be a player model and will contain a cockpit.  The second model will be a non-player ship and will not come with a fleshed out cockpit.  The goal is save some vertexes, or calculation power. 

Second, I will not be doing unimesh models.  Each ship or fighter will come in fragments that are tied together.  This will allow me to hide part of a model and replace it with another component.  This will come in useful when trying to display battle damage.  For example, one of the engines on a viper might take significant damage.  I want to be able to replace the fully functional engine with an engine that looks like it has taken a beating. 

Third, I will take a similar approach with colliders; however, the main collider will be a unimesh.  I will design the models in a manner that I can place a smaller collider just outside the main collider.  When I get a detection on one of these specialized colliders, I can write code to "damage" specific components.

So, that's about it on models.  I just need to keep these points in mind as I develop, or more accurately redevelop, the Scorpion.  I'm about a quarter way done with it right now.  We'll see how it goes.  Model building will be the slowest part of development in my opinion.  I'm getting better at it, but I still need more experience with it.

Gearing up for the Trigger Load

I finished the Position and PositionData types which means that I'm getting closer to creating the game object for the game.  At this point, I need to do a few things. 

First, I need to create the "physical" object.  This will be a Scorpion class fighter.  I have the basic model done.  I'll be using the same model from previous prototypes.  I do need to clean the model up and make sure it is compatible with the things I plan on implementing in this prototype.  I also have to pay attention to the scale.  I want to shrink all of the models for this prototype which should increase the game space.  I will also need to look at iTween to draw a HUD on the actual model.  I'll use Prototype #2 to test out this option.

Second, I need to implement the new FlightControl script.  This script will be pretty close to the previous prototype; however, I will strip this script down.  It will only contain the most base functions to pilot a ship.  It will not have the player control functions or any AI routines.  These functions will be moved to dedicated scripts that pass values to FlightControl.  FlightControl will continue to track damage and visual damage effects due to being intertwined with the DamageControl script.  I do plan on making some changes to the FlightControl thrusting procedure.  I might take out the top speed at this point.  I'll look at this when I get to it. 

Third, I will need to implement a new FireControl script.  Like the FlightControl script, this script will contain only the basic functions and will not accept player inputs.

Fouth, I need to create the PlayerControl script.  This script will take all of the player input commands found in the FlightControl and FireControl scripts of previous prototypes. 

Fifth, I need to create one temporary load script to test out the new FlightControl and PlayerControl scripts. 

Sixth, I need to design the basic trigger manager and flesh out the procedure to load the player section of the trigger manager.  This will mean that I will need to create the overall trigger list class.  I'm still mulling over this part.  I'm kinda tired of programming C# at point.  I'll take a break and work with 3DS Max for abit, and then work with the actual game engine for alittle while. 

This might take some time...

More Skyboxes

I just wanted to show off the new skybox textures.  I got these free from the Hedgehog Team on the Unity Asset store.  Here are three of the textures:

 

 

These look alot better than my past starfields.  I will definitely incorporate Unity's built-in Skybox features into the next Prototype.  Please note that these scenes were built from the previous Prototype.

Skyboxes!!! Oh, and what I need to load a player...

I finished up the Mission and MissionData classes earlier today.  They weren't too hard.  Most of these data structures follow a pretty standard format.  Alot of work can be avoid by copy and paste followed by a replace all.  I also forgot to add key database functions to the Turret and TurretData class.  I fixed that issue.  All four classes should be go to go at this point.

I decided to play around with some graphics.  One of my biggest problems in past prototypes was presenting a great visual background.  I was using a space sphere.  I basically created a sphere in Blender and flipped the normals.  That basically allowed you to see the sphere from the inside.  I then scaled it and put in the scene with a generic starfield.  I found a better way just messing around with Unity3D. 

Unity3D, as I discovered, has two built-in methods for skyboxes.  The first is to set a skybox by using the Edit>Render Setting option.  This will pull up a global setting which include a global skybox texture field.  The second method, the one I plan on using in the future, uses the camera.  You just select the camera and add a skybox by choosing Component>Rendering>Skybox.  This adds a skybox script to the camera.  You just drag your skybox texture onto the correct field.  Alternately, you can set a new texture with code.  You reference the camera, find the skybox script and set the texture field to the desired texture.  I'll be using this method in the future. 

Which brings me back to the Mission and MissionData classes.  I need to add a field for the skybox texture to both classes.  The mission will detail the desired background.  This will be a string field, and backgrounds will be stored in the "Resource" folder.  A "Random" value in this field will lead to a random generation of the background.

After that, I will start working on the Player class.  This class will store the basic data for a player and will probably be extended from the entity type.  The Player class should hold additional basic data like the amount of prestige earned by the player.  This shouldn't be hard to implement. 

This will be followed by the first real trigger type.  I will work on a method to load a player into a scene.  This will require a positioning trigger.  This will require a position variable which should include a X, Y and Z.  In addition, the trigger should contain a starting rotation which should also include a X, Y and Z or pitch, yaw and roll.  It will also include a starting speed.  It will also need to reference a player OID.  The loading routines for non-player entities will reference an Entity OID.  We can keep this in one table by adding a player flag flield.  I already created a GameVector class to hold the X, Y and Z data.  So, the class will need:

OID
MissionOID (for reference purposes)
Position (GameVector)
Rotation (GameVector)
Speed (float)
EntityOID (used to reference the Player or Entity class)
Player (boolean; true will tell the class to reference the Player class, false = Entity class)

While the class looks like it will be more complex, it really won't at this stage.  The decision to use the Player or Entity class will occur in Unity3D.  I'm not touching Unity3D at this point; my goal is get my tools in place first.  I might have to go back to the Entity class and add a constructor and function to set the record by using an existing Player class...

Missions...

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:

OID
Name (of the mission)
ArcOID
Rank
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.

Turret class

At this point, I have the basic data classes done.  The Entity and Vehicle classes are ready for Unity3D and SQO.  The Structure, Thrust and Expendable classes used by the two big classes are, obviously, done and ready for the next prototype.  In addition, I have the Bullet, Missile and CounterMeasure classes ready for the next iteration.  These classes are derived from an Ordnance class to help organize the similarties.

So, what's next?  I'm thinking that the turret class should be next.  I plan on implementing turrets that use the basic flight control script despite being a child object to a battlestar or other larger entity.  Destroying turrets will be a key part of the game afterall.  So, I should develop turrets keeping this in mind.  To properly implement turrets, flight control will attempt to load any turret data, if the object is an actual flying entity, the turret variable will be a null.  The turret class will contain just the fire cutout zones.  The ammo, turn speed and other variables used in past iterations will be contained in the Vehicle class; however, each turret will need a reference variable to its parent vessel.  This reference variable will be the OID of parent battlestar. 

That way, a loading function can take the parent's OID and load a list of turrets.  Unity3D will iterate through the list to load the actual data into individual turrets.  This will require additional variables to implement.  First, it will need an OID of the flight control variable related to the turret.  Second, it will need the physical name of the turret attached to battlestar or other object. 

So, we get:

OID
Name
VehicleOID
Minimum.X
Minimum.Y
Maximum.X
Maximum.Y

Additionally, I will put the standard Delete, Save and Load routines in class.  The game probably won't utilize the Load function often, if ever; however, it might and standardization shouldn't hurt anything.

After that, I will want to create a Squadron class for the battlestars and basestars in the game.  My plan is to have two different instantiate methods for fighters.  The first is identical to the prior prototype.  The trigger manager loads the fighter into a specified location.  The second will involve the battlestar or basestar actually launching fighters.  These fighters will be instantiated by the individual battlestars or basestars in the game.  I guess I can figure out the handling of that after I finish the Turret class.

Starting Prototype #3

I'm back.  I decided to start on Prototype #3 which will be the final alpha prototype for this project.  Hopefully, I will have all of the big pieces in place to create a fully functional game.  What are the major goals?

First, I want to standardize and streamline the data structures in the game.  Instead of relying on Unity for data structures, I plan on creating the major "variable types" in Visual C#.  For example, I will move the data structure "PlayerData" from Unity to C#.  FlightControl will define the C# version of the old PlayerData, renamed as an Entity type. 

Second, I shrinking the game.  The current models are pretty big.  I plan on reducing the scale of all models by 95%.  This will require me to rework alot of numbers; however, there will be benefits.  With small objects, I can reduce the actual speed of every object while maintaining a fast paced game.  Slower objects will translate to more reliable collision detection.  It will reduce the distance between collision error detection and should reduce the game's processing overhead.  It will also allow for better depiction of larger objects, like planets or really big asteroids. 

Third, I plan on reworking the trigger manager to follow a relatively standardized process.  I identified the major triggers in Prototype #2; now, I just need to figure out the best way of implementing those triggers in Prototype #3.  I plan on adding a couple of features to help with this like a decision, if-else, trigger.

Fourth, I want to standardize each object to make the game easier to manage from a programming standpoint.  Each destructible object in the game will possess a FlightControl script.  FlightControl will possess the old PlayerData and VehicleData scripts as C# user-defined types.  These types will be renamed Entity and Vehicle.  This will allow for easier implementation of various different game objects into the game.  Unfortunately, I will have to rewrite missiles and turrets, with a possible rewrite of bullets and countermeasures, to implement this.  However, this should allow me to better maninpulate significant game object as a programmer.

Fifth, I want to implement the concept of pre-loading as much as possible.  I got Prototype #2 to work in a manner.  However, there were hitches in the screen due to excess loading of objects from the database.  When possible, every object will be loaded early with all values from the database.  When it comes to actually loading the object into the game, it should just be a matter of instantiating the object instead of looking for the data associated with object after loading it.

These are my major points.  I just got bit by a dog, big old boxer.  I'll finish this up later...

Refactoring, Part #2

After some consideration and research, the primary classes can be written using a standard model.  It does require a few additional lines; however, that is a minor issue.  Of the classes that need to be developed, there are two classes that are inherent to all objects ranging from asteroids to capital ships.  These are the classes designed to hold the player's data and vehicle's, or object's, data. 

Player data is primarily non-numeric data used to identify an object.  This includes the object's faction, name and type vehicle.  In previous prototypes, this data grouping existed inside the battlestar.dll file and in the Unity game engine script files.  The resource manager acted as a go between to convert the battlestar.dll structure into a usable Unity data structure.  In this prototype, the player data will be attached directly into the flight control script, a relatively common script attached to most objects in the game. 

On the other hand, vehicle data is primarily numeric data used to define the vehicle or object.  It includes the object's structural integrity (damage capacity), turn speed and thrusting speed.  Like the player data, this data grouping existed in the battlestar.dll file and the Unity script files and will be integrated directly into the flight control script. 

In my next blog, I will define the player data class in more detail.  The goal will be to establish guidelines, for documentation purposes, that will guide in the construction of future scripts. 

Refactoring, Part #1

There is still a serious issue in the loading of certain objects into the game, most notably missiles.  Consequently, I am ending prototype two and moving on to prototype three.  In prototype three, the primary goal is to refactor, or rewrite, the basic data structures to have less overhead on the player's computer.  While I tend to be a stickler for "proper" programming style, the refactoring process will have to deviate from the standard due to database.  This document outlines the general structure for these new data structures.

First, each "table" in the game, like the character data, vehicle data and so on, will possess a basic, bare-bones class.  This class will outlined in the simplest method possible.  For example, the player data class will consist of a header (public class cPlayerData) and variable declarations (public string LastName { get; set; }).  This simplified class will represent a block of data to be stored in the database.  The class name will have a prefix of "c" to denote it as a base class.  Variable names will be kept as "make sense" names.  For example, the character's first name would be "public string FirstName { get; set; }."  The character's last name would be "public string LastName { get; set; }."

Second, a functional class will be extended from the "table" class.  This class will follow more strigent guidelines of programming.  This class will consist of a header that extends from the "table" class (public class PlayerData : cPlayerData), any additional variables with accessors, any routine functions for the class and a set of database functions.  This class, unlike the "table" class, will not have a prefix; it will appear with a "make sense" name.  Variables will be designated as private with a prefix of "v".  Accessors will access these variables and will have "make sense" names.  I'll go into more detail on accessors later.  Since I want these classes to do the "heavy lifting,"  any functions that can be placed into the class will be placed into the class.  For example, merging the first name, a space and the last name is relatively routine.  This would become a routine function in the class.  In addition, all database functions will exist in this class.  All structures should have a save (which also functions as an update), delete and load (probably multiple loads).  Both the routine and database functions will have a "make sense" name. 

Hopefully, this approach will standardize the general functions in the game.  Instead of having a C# base class, a non-extended database handler, a Unity class equal to the C# class, another Unity resource manager and the actual Unity code that uses the data, the goal is consolidate these into a C# class that extends off of a base class that is directly incorporated into the Unity code.

Functional Turrets

Turrets are now functional! I finished creating the dummy load script to bypass the trigger manager. The dummy script loads all of the data necessary to give a battlestar (or basestar) minimal functionality in the game. With this data loaded, I created quick workaround to manual set a battlestar's main target. With a main target set, the turrets turn and fire on the new target. Here's a picture of the Aries Battlestar and the Cylon frigate:

 

 

Turrets still need alot of work.  I need to add a system to target secondary targets.  This portion of the code that I developed did not function properly.  Turrets also need a method to check for a clear firing path.  Turrets should never attempt to fire through it's own ship.  Those are the next two features that I'll need create to complete turrets. 

 

After the completion of turrets, I will create the AI routines for capital ships.  Due to the inherent differences in the methodology of propulsion, I might have to break this feature in a battlestar and basestar AI routine.  If I make sure that both routines utilize the same parameters, I might be able to keep both scripts accessing one table, instead of two separate tables.  I'll have to flesh out AI in a future blog.

Overview of Vehicle Data

After loading player data into the game, the trigger manager loads vehicle data into each game object.  The vehicle data holds data essential to the definition for vehicle game object.  This includes the vehicles' name, structure, ammo type, ammo capacity and other important fields.  Like the player data script, this script just stores data and provides the programmer with a method of retrieving the data. 

Here’s the script:

 

The next script that I will cover will be more complicated than a simple data storage structure.  The flight control script actually manipulates stored data to allow the player or computer to maneuver individual vehicles.

Update

The data entry for the new Aries class cruiser and the Cylon frigate are in the database.  This includes the turret data.  At this point, I will create a dummy load script to load the database information into each ship.  This should load enough data to test the turret control routines.  I will have to create a "mission", which I will call asset building, to establish some basic mission parameters.  The game doesn't function properly without a defined faction control script.  This script needs to be defined in the database and loaded into the game. 

After testing the Aries and Cylon frigate, I will complete both ships by adding gravity zones to the landing bays, launch tube spawn points and other small features to each model.  Before I define more ships, I will complete the artificial intelligence routines for capital ships.  This routine will have to be more elaborate than the fighters' AI scripts.  The biggest concern is that a battlestar doesn't meet enemy ships "head to head".  It engages at angles to maximize weapon coverage, and weapon coverages will vary from class to class.  This means that I will have to figure out an "optimal" attack angle for each ship and implement it.  Preferability, this will be "soft-coded" into the AI routine.  The routine should be able to calculate a ship's optimal vector.  This will allow a single script to be attached to different models.  A "hard-coded" routine will require a specific routine to be attached to a specific model. 

With a solid AI routine, I will finish up the major ships listed in the previous post.  Here some pics of the current ship models under construction.  Here's the colonial destroyer:

Here's the Cylon frigate:

These models include the placement of turrets.  The Colonial ship relies on large guns, and the Cylon ship relies on missile launchers.  Neither model is textured at this point; I do plan on purchasing a good 3D paint program to make decent texture maps in the near future.

Battlestars, Database and New Models

I got the basic template for battlestars incorporated into the database manager.  Currently, the feature is extremely limited in the manager.  The current feature includes a methology to save the battlestar's player data, vehicle data and turret data.  It does not include any methodology to save artificial intelligence parameters at this time.  In addition, there is no feature to actually place a battlestar into the actual trigger manager section.  However, this is a relatively significant step in the overall process.  The current features will allow me to quickly build the basic battlestar data and, more importantly, turret data. 

The current goal is to build some battlestars and basestars for the game.  I will be working on creating the basic parameters for two Colonial destroyers (the Aries and Hercules as shown in a previous post), a Colonial cruiser (the Venus, a Berzerk type, shown later in this post), a Cylon destroyer (shown later in this post) and a Cylon cruiser (shown in a previous post).  Once each of these templates are done, I will test the previously created routines.  Once these routines work as intended, I will create the artifical intelligence routine to control each battlestar. 

Here are some pictures of the a new battlestar and basestar.  The battlestar is actually based on a ship, the Battlestar Berzerk, shown during the Battlestar Galactica movie, Razor.  I have designated this vessel as Venus class cruiser originally built by the Leonis colony. 

Here are the pics of the game model:

Here is a picture of the actual movie model (actually the development sheet used for the movie):

The Cylon cruiser was created and used in a previous prototype; however, I never posted it in my blog.  It has also gone through some changes from it's initial presentation.  I made the missile turrets smaller and less pronounced in this iteration.  These pictures do not include the turrets. 

Here are the pictures for the Cylon cruiser:

What is a Battlestar?

I'm back after a long vacation.  I'm still looking at completing the capital ships for the game.  In order to get a clearer picture of the role of capital ships, I'm going to post a series of blogs that will help me define them better.  This blog will cover the general overview of capital ships.

First, what is a battlestar?  Prior to the Cylon War, the term battlestar was used to define any space going warship.  In many ways, it is a similar term to warship in American society.  It did not define a class of ship, like a destroyer; it defined an entire concept of ship.  Prior to the war, colonial battlestars were very much like modern carriers.  They were designed to carry various fighter and support craft.  These smaller crafts are used to project power around the capital ships.  Just prior to the war, Caprica, a leading colony in the development of new technologies, conceptualized the first true battlestar.  These newer ships, that would take over the term of battlestar from a generic term to specific class of warship, were designed to operate as a naval station, not just a carrier.  The new battlestars would be capable of maintanence of a massive fleet of fighter and support craft, the fabrication of equipment and arms, the storage of an unprecedencted number of fighters and an extended operational "up" time.  They were designed to, not only conduct war, but supply an entire fleet of smaller battlestars with fighters, water, ammo and fuel. 

Second, what are the current classifications of battlestars?  The game currently uses a simplified size variable to track ship sizes.  Size one is anything less than 50 meters.  Each size category beyond one respresents a multiple of 50 meters.  For example, a size of five represents 250 meters.  A size of 10 represents 500 meters.  Battletars are categorized by size.  The categories are:

Escorts are small capital ships with limited support craft.  These ships usually have a small hanger bay; however, they are generally incapable of launching and landing fighter craft.  Their primary mission is to act as a mobile jump platform and are used in scouting missions.  The maximum size for this class of ship is two (100 meters).

Frigates are slighly larger than escorts and are capable of launching fighters.  Usually, a frigate is limited to two flights (approximately 10) of fighters.  Like escorts, these ships are primarily used in scouting missions.  In addition, these ships are often selected for small scale infiltration missions.  The maximum size of a frigate is four (200 meters).

Destroyers are, at least at the start of the Cylon War, the most numerous class of capital ships.  The usually have a full squadron (approximately 20) of fighters.  Some destroyers are armed with capital ship sized guns.  The mission profile for these ships vary depending on individual class; however, they are primarily a fleet ship.  They tend to operate better in groups.  The maximum size for a destroyer is a size of 12 (600 meters). 

Cruisers are, at least at the start of the Cylon War, the largest warships in any of the Colonial fleets.  They can support multiple fighter squadrons.  They are armed with capital ship sized gun turrets in addition to smaller flak turrets.  Before the inclusion of the newer battlestars, these vessels were the primary capital ships of the fleet.  The maximum size for a cruiser is 20 (1000 meters). 

Battlestars are a relatively new edition to the war effort.  After the first year of the war, the only class of battlestar was the Columbia Class Battlestar (built by the Leonis Colony; the Caprican ship was delayed due to a Cylon attack).  The Columbia measured at 1440 meters and is capable of maintaining twenty squadrons; however, most squadrons are assigned to smaller ships in the fleet.  After the eighth year of the war, a new class of battlestar is introduced to the war.  I'm still working on the design of the newer battlestar.  However, a battlestar is classified as anything larger than a size of 20 (1000 meters+).  It has large capital ship guns and represents a devastating power on the battlefield.  In addition, it houses factories that can keep a fleet supplied for extended operations. 

The game will feature each of these five classes of ships.  Since the start of the game is two years after the start of the war, there will be four Battlestars (Columbia, Galactica, Acheron and Athena) operational in the game.  This number will ballon up to nine as the progresses.  The final three Battlestars will be of a different class built within the final two years of the war.  The player will be assigned to a Battlestar at all times during the game.  However, players will be assigned a smaller battlestar (frigate, destroyer or cruiser) for temporary duty (TDY).  TDY assignment can be selected by the player based on a "prestige" cost.