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