Sunday, March 31, 2013

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. 

Tuesday, March 19, 2013

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.