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.