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.

No comments:

Post a Comment