What does a game foundation consist of?

The starting point for any well built structure is a strong foundation. It is important that the foundation of your game is able to handle the basic functionality that will apply across all of your games, and does it simply with little to no extra effort on your part.

Also, what do all games have in common? They consist of various screens (Oh yes they do, or your game would be considered a tech demo my friend). With that in mind, our structure should be able to handle the following:

• Context Menu Setup
• Access to the Stage.
• Tweaking of game speed
• Frame Rate Tracking
• Sending updates to your game
• Custom Game Cursor ( if applicable to your game )
• Global game pause
• Ability to step through code 1 update at a time
• Screen switching

In order to implement all of these in a manner that we can easily and quickly transfer over to each and every project and use without any real need of changing the code at all we will create our structure using the following 3 classes:

• IScreenItem - Anything that will be considered a screen, such as MenuScreen, GameScreen, etc...
• AScreen - An Abstract class which handles screen switching.
• Root - Our meat and potatoes of the foundation. Handles the "Basic" functionality discussed above.

Lets build it!

A few concepts for me to mention now before we start are that almost all of our game objects will use an update and dispose method. Updates will filter down from the Root class so as to keep greater control of the game and eliminate the inconvenience and speed hog of creating multiple frame event listeners to the stage. Also it is good practice to clean up your code on removal such as removing any event listeners and nulling any outside references.

Also we will be using a constant time step to update our code. It is quite simple to interchange actually which I can show you, but in my experience a non-constant time step can cause inconsistencies that are difficult to debug.

When I refer to "Global Game Pause" this means that all updates to the game objects and rendering. You may have seperate pause logic within your game screen that pauses only certain features, still allowing menus or other GUI to run.

The IScreenItem and AScreen Classes

Okay, so let's begin with the IScreenItem class. This will be the interface for any screen used in the game...

public interface IScreenItem extends IEventDispatcher
{
	function setScreen(screen:Class):void;
	function update(timePassed:int):void;
	function dispose():void;
 
	function get parentScreen():IScreenItem;
	function get currentScreen():IScreenItem;
}

All screens will have an interface for updating thier logic. We will send the time passed since the last update so that it is calculated in a centralized location ( The Root ). Also each screen is responsible for disposing of itself...if necessary.

We also build an abstract class AScreen which holds the basical functionality of screen switching for us.

public class AScreen extends Sprite implements IScreenItem
 {
 // Initialization ---------------------------------------------------------------------------
 public function AScreen( parentScreen:IScreenItem=null )
 {
 	m_parentScreen = parentScreen;
 	m_parentScreen == null ? m_currentScreen = null : m_currentScreen = currentScreen;
 }
 // ------------------------------------------------------------------------------------------
 
 public function get parentScreen():IScreenItem{ return m_parentScreen; }
 
 /**
  * Will filter up to the top of the screen structure and return the root current screen.
  * This is done so that any screens created down the line may have access to change the
  * screen without actual reference to the root.
  *
  */
 public function get currentScreen():IScreenItem
 {
 	if( m_parentScreen != null )
 	{
 		return m_parentScreen.currentScreen;
 	}
 	return m_currentScreen;
 }
 
 // Override these functions with your subclasses ----------------------------------------------
 
 public function update( timePassed:int ):void
 {
 	if( m_parentScreen==null && m_currentScreen!=null ){ m_currentScreen.update( timePassed ); }
 }
 
 public function dispose():void{}
 
 // --------------------------------------------------------------------------------------------
 
 /**
  * Changes the root current screen to the screen specified.
  * All screen's dispose method are called for cleanup.
  *
  */
 public function setScreen( screen:Class ):void
 {
 	if ( m_parentScreen != null )
 	{
 		m_parentScreen.setScreen( screen );
 		return;
 	}
 	if( m_currentScreen!= null )
 	{
 		removeChild( m_currentScreen as Sprite );
 		m_currentScreen.dispose();
 	}
 	m_currentScreen = new screen( this );
 	addChild( m_currentScreen as Sprite );
 }
 
 // -- PRIVATE --
 
 private var m_parentScreen:IScreenItem;
 private var m_currentScreen:IScreenItem;
 }

The Root Class

Now finally we build the bread and butter, which is the Root class. I've left out loading of external data and setting up a custom cursor. We can discuss those topics in a later article. You can see that I handle game speed by using a multiplier on the update function. There is code in the handleInput function to help with some in game debugging.

Note also that I am using my Input Manager class. I HIGHLY recommend that you use some sort of class to manage input in your games, whether it is mine or one of your own creation. If you would like view the article on the Input Class you can go here. To download the input class files visit the google project page here.

public class Root extends AScreen
{		
 
	private const DEFAULT_QUALITY:String = "high";
 	private const TIME_PASSED:int = 20;
 	private const ONE_SECOND:int = 1000;
 	private const FRAME_RATE:int = 50;
 
 	// -- STATIC --
 
	public static function set gameSpeed( value:Number ) : void
	{
		m_gameSpeed = value;
		if( m_gameSpeed < 0 ) { m_gameSpeed = 0; }
	}
	public static function get gameSpeed() : Number { return m_gameSpeed; }
	public static function get fps() : int { return m_fps; }
	public static function get avgFps() : int { return m_avgFps; }
 
	public static var stage:Stage;
 
	/**
	 * Use to globally pause the game.
	 *
	 */
	public static function togglePause() : void
 	{
 		m_isUpdateOn = !m_isUpdateOn;
 	}
 
	/**
	 * Place in code where you would like a breakpoint. The game will be paused globally
	 * and the message will be traced.
	 * @param a_message The message to output when this breakpoint is reached.
	 * @param a_forced Force this breakpoint to run, even if breakpoints are turned off.
	 *
	 */
	public static function breakpoint( a_message:String, a_forced:Boolean ):void
	{
 		if( !m_areBreakpointsEnabled && !a_forced ){ return; }
 
 		trace( " Breakpoint: " + a_message );
 		m_isUpdateOn = false;
 	}
 
	// -- PUBLIC --
 
	public function Root(stage:Stage=null)
	{
		m_gameSpeed = 1;
 
		if( stage==null )
		{
			Root.stage = this.stage;
		}
		else
		{
			Root.stage = stage;
		}
		Root.m_fps = Root.m_avgFps = 0;
		Root.stage.quality = DEFAULT_QUALITY;
 
		m_isUpdateOn = true;
 		m_areBreakpointsEnabled = true;
 
 		Input.instance.activate(Root.stage);
 
 		// External data will be discussed in a future article
 		// Load External Data ----------------------------------------
 		// ExternalData.instance.addEventListener( Event.COMPLETE, onDataLoad );
 		// ExternalData.instance.load();
 		// -----------------------
 		onDataLoad( null );
	}
 
 	public override function setScreen(screen:Class):void
 	{
 		m_screenToSet = screen;
 	}
 
 	// -- PRIVATE --
 
 	private function onDataLoad( e:Event ):void
 	{
 		// ExternalData.instance.removeEventListener( Event.COMPLETE, onDataLoad );
 
 		Root.stage.addEventListener( Event.ENTER_FRAME,onEnterFrame );
 		Root.stage.showDefaultContextMenu = false;
 
 		// Set up custom cursor here -----
 		// Mouse.hide();
 		// m_customCursor = new CustomCursor();
 
 		m_stopWatch = new StopWatch();
 		m_deltaTime = 0;
 	}
 
 	private function onEnterFrame( e:Event ):void
 	{
 		recordFPS();
 
 		if( m_isUpdateOn )
 		{
 			update( TIME_PASSED * m_gameSpeed );
 		}
 
 		handleInput();
 		Input.instance.update();
 
 		//handle custom cursor
 
 		if( m_screenToSet )
 		{
 			super.setScreen( m_screenToSet );
 			m_screenToSet = null;
 		}
 	}
 
 	private function recordFps() : void
 	{
 		m_deltaTime = m_stopWatch.timePassed;
 		m_stopWatch.reset();
 		m_fps = ONE_SECOND / m_deltaTime;
 		m_fpsCount += Root.m_fps;
 		m_avgFpsCounter--;
 		if( m_avgFpsCounter <= 0 )
 		{
 			m_avgFps = m_fpsCount / FRAME_RATE;
 			m_avgFpsCounter = FRAME_RATE;
 			m_fpsCount = 0;
 		}
 	}
 
 	/**
 	 * Here we handle code for dealing with breakpoints, global pausing, and stepping.
 	 * Be sure to deactivate this code for the release of your game!
 	 *
 	 */
 	private function handleInput():void
 	{
 		if( Input.instance.isKeyPressed( KeyCode.END ) )
 		{
 			m_isUpdateOn = !m_isUpdateOn;
 			trace(" Game " + ( m_isUpdateOn ? "unpaused" : "paused" ) );
 		}
 		if( Input.instance.isKeyPressed( KeyCode.PAGE_DOWN ) )
 		{
 			if( !m_isUpdateOn )
 			{
 				trace( " Stepping foward " + TIME_PASSED + " milliseconds." );
 
 				update( TIME_PASSED );
 			}
 		}
 		if( Input.instance.isKeyPressed( KeyCode.PAGE_UP ) )
 		{
 			m_areBreakpointsEnabled = != m_areBreakpointsEnabled;
 			trace( " Breakpoints " + ( m_areBreakpointsEnabled ? "enabled" : "disabled" ) );
 		}
 	}
 
 	private static var m_isUpdateOn:Boolean;
 	private static var m_areBreakpointsEnabled:Boolean;
 
	private static var m_fps:int;
	private static var m_avgFps:int;
	private static var m_gameSpeed:Number;
 
 	private var m_screenToSet:Class;
 	private var m_stopWatch:StopWatch;
 	private var m_newTime:int;
 	private var m_oldTime:int;
 	private var m_deltaTime:int;
 	private var m_fpsCount:int;
 	private var m_avgFpsCounter:int;
 
}

Wrapping up

Now that you have the basic structure set up, starting any new game project is extremely simple. Have your preloader call a "Main" class whose sole function is to be the Root screen. The main class will call the first screen in the game, usually the Menu.

public class Main extends Root
{
	public function Main(stage:Stage)
	{
		super(stage);
 
		setScreen( Screen1 );
	}
}

Now when creating your screens, just extend the AScreen class:

public class Screen1 extends AScreen
{
	public function Screen1(parentScreen:IScreenItem=null)
	{
		super(parentScreen);
 
		var txt:TextField = new TextField();
		txt.htmlText = "<span style="color: #ffffff;"> Screen 1 </span>";
		txt.x = 100;
		txt.y = 100;
		addChild( txt );
	}
 
	public override function update(timePassed:int):void
	{
		if( Input.instance.isKeyPressed( KeyCode.ENTER ) )
		{
			setScreen( Screen2 );
		}
	}
 
}

Well, that's it for your game foundation! You can download the code along with an example project at the google project page.

This is the first post in a series "Programming Tidbits." Essentially there are some useful bits of information or code that I would like to relay, but don't REALLY warrant an entire article. You can view the full list of tidbits here.

The Wrong Thing...

When programming, a lot of times you may find yourself throwing together some code which uses "Magic Numbers." A magic number is basically just any static number sitting in your code such as:

public function moveMyCharacter() : void
{
	myCharacter.x += 5;
	myCharacter.y += 5;
}
 
public function damageEnemy() : void
{
	someEnemy.health -= 20;
}

Why is it bad?

Now obviously that is just a simple example, but let's say you have code ALL OVER your project using these "magic numbers." What happens then, if later you want to change these numbers? You have a long and tedious process of finding all times that they are used. Not only that, but you are prone to missing something which will therefore lead to unpredictable code and bugs.

The right thing...

Instead of being mean to yourself, do the right thing and create constants or variables for all of your magic numbers. The usual place to put them is at the top of your class. Even better would be to externalize the data into some sort of settings file ( if the data is worthy of course ). I'll be discussing externalizing data in a future article if you aren't quite sure how to go about that...

So here is the code once again, done properly.

// Top of your Class somewhere...
private const MOVE_SPEED:int = 5;
private const HERO_DAMAGE:int = 20;
 
public function moveMyCharacter() : void
{
	myCharacter.x += MOVE_SPEED;
	myCharacter.y += MOVE_SPEED;
}
 
public function damageEnemy() : void
{
	someEnemy.health -= HERO_DAMAGE;
}

Inspiration

When I first began programming, it seemed like there were a vast amount of tutorials out there which taught you how to do a specific task such as "make a shooting game" or something of that nature. These were great for me at first, as I didn't know my left toe from my right thumb. Eventually however, I began to get better and I craved more organized and useful information such as how to actually structure games, and how to use proper OOP techniques etc. There simply just isn't enough of it out there. I found a few articles explaining several ideas and concepts, and I read many different books on OOP and design patterns…then after about a year of working together the different I came up with a great mesh of it all to develop my current game structure.

Purpose

My purpose for this article and those that follow in this series is to teach you piece by piece how to build a reusable game structure for your games as well as explain different game coding techniques and concepts along the way. I'll be providing code that I've written, however for maximum benefit I recommend that you modify or rewrite it to your style and needs. For example, each time I start a new project I simply copy all of my game code over from my latest game and then delete classes which I won't need, as well as tweak existing code to fit the current project.

Requirements

It is good practice to write down some goals and requirements for what you would like your game engine to incorporate, so let's consider this now. Our game structure will have consist of the following:

• The ability to save game state, pause, speed up and slow down
• We can set a camera position and size to render what is in the game world.
• The game logic will be separate from the rendering logic.
• Data driven development. IE: Creatures and levels will be built outside of the core code engine itself, usually from XML or on a higher level in an editor of some sorts.
• Object creation is centered in one location
• Control of entities is done through "controller" classes.
• And of course...it will run incredibly fast.

If any of that sounded complicated, fear not. I will be discussing the reasons for each part as well as explaining how it all works. We will create one piece at a time and build upon the structure as we move along, making improvements along the way.

As I complete each section I will update this article to link to each piece. You may visit the google project page to aquire all of the project files and source code as well.

Additional Articles in this series:

• Building a Foundation For Your Games and Handling Screens
• Entity Class - Just what is an entity? ( Coming soon )
• Seperating Game Logic from Rendering Logic
• Setting up AI
• Game Object Management
• The Game Factory - How You Should REALLY be creating objects
• Data Driven Development
• And more...

I want to discuss a technique that I have been using which works very well to get past the initial strain of programming a new part into your game. Yesterday I was trying to figure out how I would program the abilities system for units ( it is a Diablo style game, so there is a possibility for a lot of abilities ).

After staring at the screen for a while, I pulled out the ol' handy dandy notebook and just began writing things down on paper. Shortly thereafter I had the entire system programmed, and it worked great!

So, the process of programming on paper works like this:

1. Decide your problem. Write it down.
2. List out the steps that need to take place from the player's view in order for the problem to work. IE:
   • Player chooses class ( Wizard for example )
   • Unit is given abilities.
   • Player presses ability 1 key, ability 1 activates.
3. Now that you see what is required to complete your problem it is much easier to program it. Decide on which classes will be needed, and then write out how it will all work using pseudo code...so for me it was something like this:
   • Ability Class, abilities will extend this...for example: HealAbility, ProjectileAbility, etc.
   • onKeyPress( "A" ) : Unit.useAbility( 1 );
   • Unit.useAbility(): ability1.execute();
   • ability1.execute(): unit.addHealth( 20 ); //or spawnProjectile( "Fireball" ); //or unit.addBuff( ... )
4. Once you have all of it written down in pseudo code like that it really makes it super simple to code everything because you are just basically putting it in Actionscript.

Originally I had thought it would be difficult and take quite some time to design and program all of the things I did yesterday (it was a lot) however since I used this technique I believe it relieved the pressure of creating code that doesn't work and just let me focus on the concept of HOW it should work. Hopefully you can find a style or programming on paper that works best for you as well.

Coincidence? Who knows...

Well I haven't written anything of value in a while due to being super busy ( and gone ) so here is a bit of an update. During half of September and most of October I was in Bridge City, Texas which is a small town that was probably hit the hardest during the hurricane. Only 14 homes in the ENTIRE city were not destroyed by flood. The town has around 4000 homes.

Now that I am back I am working diligently on a new project, which should be done in the latter part of November if I keep on track ( which I am doing ). Also I have some articles planned which you all should look out for.

I have converted all of the files to an MIT license so that you can reuse them in any way that you please. Be sure to visit the google code page to download everything.

http://code.google.com/p/cheezeworld

Anyways. I am back to work on Space Crusade and I should be done shortly. No more demo updates until I am done though sorry! Also I have some plans for new articles and videos after I get some work done. Hope everyone has been having a great Summer. See you around!

Occasionally I do tweak or add to my standards but for the most part I really do keep everything the same.

Currently I've been improving some habits of mine (mainly things like spacing and brackets etc) a bit so my older code is a little sloppier than my newer stuff which is okay. I also want to first point out this article by GamePoetry which links to the "UrbanSquall" coding standards. Those are basically what I stick to except for the few additions / changes mentioned below.

So let's get started.

Class properties / Members

Public
The idea here is to always avoid using getter/setter functions whenever possible. Well, atleast for anything that would be called once or more each frame. If it's an obscure variable that is rarely called or used for something that isn't speed related you can use them...otherwise NO. Anything that is both gettable/settable will be simply written as it is:

//it probably wouldn't matter too much if you externally modified this variable
public var maxSpeed:Number;

Read-Only
In order to decipher between variables that should only be read-only I will use an underscore to define them as follows:

//obviously you wouldn't want to externally change this variable...
public var _bulletsLeft:int;

The speed difference of NOT using getters/setters can be very apparent with something like a "Vector" class where the 'x/y' variables are public. This adds probably 20-30 FPS to a demo with about 2-3000 sprites all doing world bounds wrap checks etc. Just imagine the speed difference when ALL of your code complies with this.

Obviously sometimes we may want to reduce the "_bulletsLeft" safely so in that case create your function "shootGun()" inside the class that holds "_bulletsLeft" rather than implementing some external code to reduce the "_bulletsLeft" variable. (This is more of a proper OO design practice: 'Encapsulate Change')

Private / Protected
For all properties usable only by the class that created them we will use the m_:

//this helps avoid naming conflicts...which is good!
private var m_beanCounter:int;
protected static var m_nextID:int = 0;

Naming Conventions

Booleans
Any boolean properties and functions will always be structured in question format. They are followed by the words: "is, has, can, does":

public var _isCollidable:Boolean;
public function doesRayIntersectCircle(rayOrigin:Vector, rayHeading:Vector, circleCenter:Vector, circleRadius:Number):Boolean{ //code }
private var m_hasGun:Boolean;
protected var m_canComeToTheParty:Boolean; // lol

Constants
All constants will be in caps with phrases separated by underscores:

public static const HEAVY_ARMOR:int = 0x000001;
public static const WOODEN_SHIELD:int = 0x000010;
public static const SLARGH_FIGHTER:String = "slargh_fighter";
private static const ENEMIES_PER_WAVE:int = 15;

Public Functions / Private Functions
Usually I stick to the "Urbansquall" convention on this however I do not prefix an 'a_' before the parameter names. Sometimes my functions will stray slightly from the "verbNoun" format when parameters are available and instead I will try to complete a sentence with the parameters. In other words I use "verbPreposition(noun)" format:

public function addTo(vector:Vector):void;
public function wrapAround(topLeft:Vector,bottomRight:Vector):void;
public function dotOf(vector:Vector):Number;

Event Handler Functions
I will treat event handlers slightly different when naming them. I always name them as if they are happening because of an event (hmm...) Which means basically all of them have "on" preceding them.

onScriptLoad(e:Event):void{}
onEntityCollision(e:CollisionEvent):void{}

Alright well as far as I can think of those + the urbanSquall link from above are the conventions I stick with. Hopefully you decide to do the same! Also be sure to read: Better Debug Tracing for some tracing conventions that should be followed as well.

I currently don't really have any demos or anything showing how to use the code, however go ahead and take a browse through the functions and there may be some stuff you will use eventually. It's pretty self explanatory anyways and it is all documented. I will definitely be referring to a lot of the code from these classes in some upcoming posts as well so if you are waiting for a more detailed explanation of when and how to use some of it don't worry it's on the way!

You can download everything as a package or just get the classes you need in the repository from my google project page here: http://code.google.com/p/cheezeworld/

As of writing this I currently have:

Vector - Perfect alternative to using the built in "Point" class and has basically ALL of the Vector operations you would need to perform plus a few more.

AABBox - A very lightweight object to simply store "rect" data for whatever purpose.

Matrix2D - Handles any Matrix math needed. Use in conjunction with the Vector class.

Transformations - Some static functions for performing transformations to Vectors easily (such as local to global etc...)

Geometry - A very powerful bunch of static functions for doing a wide range of math such as line intersection tests between rays, segments, polygons, circles, etc etc... This is great for most hit test operations and ray casting + other stuff...just check it out.

Math Utils - This is pretty much just a small number of things that I actually just usually copy directly into the code I am working on or as a private function into a class that needs it but wanted to have a reference to it since they are useful so it's all bundled up in this class.

Check it out here: http://code.google.com/p/cheezeworld/

If you would like to contribute some code or a helpful tutorial etc I'd be happy to add it to the project!