Saturday, April 21, 2012

The Basics

I'm about 3/5 of the through recreating the previous build's HUD in the HUDControl script and have completed the DradisControl (which replaces the HeatSource script) and FactionControl scripts.  I'll provide a better update on these scripts after I've completely recreated the original HUD. 

Per some requests, I will be covering the creation process for some of my "completed" scripts.  Completed is in quotes because I tend to add features to my scripts as the needed by other scripts. 

Why am I covering the creation of my scripts?  First, I know that there are some aspiring game designers out there that are just intimidated by the whole programming process.  Dr. Joseph suggested creating this blog to document the creation process of a game.  Second, some of my cohorts that have promised to help me develop this project need to know what I did and why I did it.

In this blog, I will cover the construction of the PlayerData class.  As a starting point for the project, I wanted a source of baseline data for both the pilot and his/her fighter. The PlayerData script holds data concerning the pilot and allow for other scripts to access this data.  Besides holding data, it really doesn't do anything else.  This simplicity make it a good starting point for describing how to create a basic class (a script that holds and manipulates data). 

Here's the PlayerData class:

For those of you in Dr. Joseph's class, the first thing you will notice is the documentation remarks at the beginning of the code stating the class purpose and declarations.  The class purpose, at least in my style of programming, acts like a focus document for the script.  A script should have a purpose and should not deviate from it. 

Why?  It's called modular design.  If I put all the data together, I have to add everything to a game object or nothing.  If it is modular; I can just add the components pertinent to the game object.  For example, I won't add AI routines to a player controlled craft.  By keeping things modular, you save memory and increase performance.  In addition, if you need to add something (to let's say to PilotData), you can just go into that module and add it with less chance of breaking other code.

The second part of my documentation deals with the declared variables and statements in the code.  A "+" and "-" sign denote whether that variable or statement is a public or private access.  Instead of searching your code for a statement, you should be able to get an idea of what exists in the class from your declaration documentation.  It makes writing other scripts much easier...

Public access statements can be accessed outside of the class.  For example, the statement FirstName(denoted with a "+") is publicly accessible.  Let's say I have a variable of the PlayerData type called vPlayerData.  If I type vPlayerData.FirstName = "Berton"; that will set the vFirstName variable to the value "Berton".  I'll go over declaring and accessing a user developed class in more detail in a future blog.

Private variables and statements are only accessible within the class itself.  Variables, as a general rule, should be local access only.  You should create a public statement that allows you to change the variable's value.  Some statements, like the CheckRank() statement, are only needed locally and should be restricted as necessary. 

So in my code, I have a bunch of privately accessible variables with a bunch of statements with public access to change those values.  I have a statement that is restricted to private access to check a rank input, and I have a public Load and Find statement.  Load allows the programmer to mass load a set of values into the appropriate fields.  It's a useful statement and should be in every data oriented class.  The Find() statement is essential in Unity3D.  Each script is attached to a game object (whether it is a viper, cylon raider or something else).  Most of the time, you have a game object but need to access a script attached to it.  The Find statement allows you retrieve the script.  I'll explain the usage of Load and Find when we get a script that utilizes it in a future blog.

So, that is the first class in a nutshell...

No comments:

Post a Comment