I want to leave by giving huge thanks to my readers, and have no worries I will continue to leave the website / code up for all to view. In addition I plan on releasing a large part of my unfinished code / projects as open source for anyone to learn / expand upon.

I am also willing to support any guest posts as well, if anyone has a topic they wish to share with my audience. Farewell, and I wish you all a great 2010!

So without further delay, I now introduce you to Ginger :

Features :

• Extremely fast and optimized animations
• Set the rotation precision, and each frame is pre cached for speed
• Attach an event dispatch to any frame of animation
• Adjustable frame rate
• Set your own offset for each frame of animation
• Queue up multiple animations
• Import Tile sheets and convert to an animation
• *NEW – 9/10/09* Import MovieClips, Sprites, and Bitmaps and convert to an animation

Download the example files from SVN here.
-or-
Download in .ZIP format here.

Future Plans

• Create a real time loader for larger animation files
• Optimizations to rotated animations
• Tools for building animations using XML format
• Tools for loading MovieClips / swfs – Done!
  
• Easy integration with my game framework

What is an FSM / What is it used for?
An FSM can be used to determine the behavior of an entity based on specific conditions. Essentially they imbue an entity with the illusion of intelligence. Coding a state machine is a simple matter. There are in fact numerous ways to implement an FSM and there isn’t necessarily one “right” way to do it.

First We will look at a simple, although potentially problematic approach.

public function update() : void
{
	if( health < 0 )
	{
		changeState( DIE_STATE );
	}
 
	switch( currentState )
	{
		case IDLE_STATE:
			patrol();
 
			if( isEnemySighted )
			{
				changeState( CHASE_STATE );
			}
 
			break;
 
		case CHASE_STATE:
			chaseEnemy();
 
			if( isEnemyInRange )
			{
				if( health < 30 && mana > 20 )
				{
					castHeal();
				}
				else
				{
					attackEnemy();
				}
			}
 
			break;
 
		case DIE_STATE:
			if( isDeathAnimationComplete )
			{
				removeEntity();
			}
			else
			{
				playDeathAnimation();
			}
 
			break;
	}
 
}

As you can see setting up a switch and several if statements can accomplish basic AI behavior. The problem with this approach begins to surface as more states, conditions, and transitions are introduced. Imagine how big of a monster it would be to edit this structure of code on an entity that had over a dozen different states and transitions. Also it would be hard to switch out the behaviors of entity. For example, what if you wanted the player to be able to control this unit? You would have to create a separate class altogether. More on that later.

The State Design Pattern

The best way that I have found to implement an extensible FSM is with what is called the State Design Pattern. With this approach we will be embedding the rules for the state transitions within the states themselves.

Actionscript doesn’t allow for any type of function templates unfortunately. So we will have to work around that in order to allow for varying types of entities to be used in our FSM. The user will be forced to do his/her own error checking, so only a small annoyance. With states, generally you will want to have transitions when the states are being changed, so our pattern will allow for an enter, execute, and exit function.

Here is the Interface for the states:

public interface IState extends IEventDispatcher
{
	function setEntity( a_entity:* ) : void;
	function getEntity() : *;
 
	function enter():void;
	function execute():void;
	function exit():void;
}

As you can see the structure is actually quite simple. The states will contain a reference to the entity they are operating upon. Here is an example of a somewhat fleshed out state:

public class PatrolState extends EventDispatcher implements IState
{
public function setEntity( a_entity:* ) : void
{
	if( !(a_entity is Unit) )
	{
		throw new Error( "<PatrolState> a_entity must be of type Unit!" );
	}
	m_entity = a_entity;
}
 
public function getEntity() : *
{
	return m_entity;
}
 
public function enter():void
{
	// set up patrol path and steering behaviors
}
 
public function execute():void
{
	// if enemy is close, set state to chase state
	// else continue patrolling
}
 
public function exit():void
{
	// clean up patrol paths
	// remove steering behaviors
}
 
private var m_mine:Mine;
private var m_base:Building;
private var m_entity:Harvester;
 
}

So now that we have a state set up, we can improve this system a lot by creating a reusable state machine that handles the switching / updating of the states. Here is the interface:

public class StateMachine
{
public function StateMachine( a_owner:Entity, a_currentState:IState = null, a_globalState:IState = null )
 
public function update() : void
 
public function dispose() : void
 
public function changeState( newState:IState ):void
 
public function changeGlobalState( newState:IState ):void
 
public function revertToPreviousState() : void
}

In my implementation I allow for a “global” function as well, which will be called every tick in addition to the actual states. This may or may not be used depending on the behavior you are looking for. Also, a reference is being held to the “previous state” so that temporary behavior can be given and then the entity can switch back to what it was doing before. For instance, if a unit was on a patrol path and spots an enemy…it can switch to an attack state, and then once the enemy is dead it can revert to it’s patrol path.

Here is a quick example I created in order to display the FSM in action. ( might be a bit shitty, but I was in a hurry )

So as you can, FSM’s can be used to create fairly complex and intelligent behavior. Not only that, but imagine creating an RTS style game where units are given commands by the player and the units all follow those orders. Rather than creating dozens of different classes with built in behaviors based on if they are on the players team or being controlled by the AI, you could toss in the correct states to the FSM controller. Then let’s say you decided to give one of those units top down shooter style controls if you clicked on them…that could be done as well, again by just changing the state. So the possibilities are limitless.

With that, I would like to also give some reference to another useful method which works well in some less complex scenarios, instead of this full blown approach. For instance, I actually used this method to manage the 3 states of a “ball” which can be grabbed, aimed, and then launched on another project of mine.

Be sure to add me to your RSS reader if you haven’t already. I plan to slowly get back to more consistent posting very soon. Sorry about the long wait guys! So until next time…be sure to download the new code and examples at my google project page, and here a list of the updates to the game structure code:

Code Changes

• GameFactory:
• If no parent is specified for getEntity function, it will default to the instance of the gameworld ( if it exists )
• No longer need to specify entity t ype on getEntity…IE: var myBoid:Boid = m_factory.getEntity( “boid” ) as Boid. You can now take off the “as Boid”
• GameWorld
• Fixed error with the Gameworld’s bounds setup.
• Moving Entity
• Added BOUNDS_STOP behavior
• Fixed the bounds behaviors for entities inside of other entities in different locations than 0,0
• Entity
• Entity now implements IEntity which will improve use with other classes etc such as the game factory.
• Fixed the bounds size calculation
• Root
• Made a change to the stageWidth/Height thing that makes it lookup what the dimensions are.
• Follow Path
• Fixed so that if it is set to “not” patrol, it will not create an error.

Also I’ve made several adds / changes / fixes to the game structure which I’ll list out below. I wanted to write a big article ( or several ) explaining this big AI library and how each thing works, but I didn’t want to keep everyone waiting any longer so I am going to go ahead and release it now and I’ll write up articles about it as time permits. ( which I have more of now )

For those of you who want to dig in and learn it all on your own go ahead, but for everyone else I promise I’ll get some articles up soon explaining the changes and some tutorials on how steering behaviors work and how I’ve designed mine.

Here is a demo app that I created which shows off everything. You can download the source from the google project page. I highly suggest setting up a repository folder on your PC and keep it updated with the current game library folder, as that is the one which I will be submitting updates to. I won’t be updating the various zips any longer. I recommend tortoise SVN.

So anyhow, here is a list of changes to the game structure that I have made so far. Be sure to check back soon for more AI / Game Structure fun!

ENGINE CHANGES:

• Added more functionality to the Sound Manager class.
• GameFactory is no longer a singleton.
• Added creation of gameworld to GameFactory for easy game setup.
• Fixed dispose function on Entity.
• MovingEntity now restricts its movements to the max speed variable.
• MovingEntity has a MaxAcceleration var, which is mainly just for external use.
• Added a damping variable to MovingEntity.
• Fixed an incorrect math function on Matrix2D.rotateVector()
• CreateCallback function added to Root
• Updated all classes extending EntityParams with the ability to pass variables in the constructor IE:
  new EntityParams( { radius:10, type:”Blob” } );
  NOTE: be sure to call super( a_params:Object ) AFTER you set any of your defaults, or anything passed in will be overwritten ( by the defaults )
• Added a createCallback function to Root. Quite useful in some cases, check it out.
• Cleaned up Root by taking out the FPS calculation. Use a custom FPS class for this now, such as the Urbansquall one which I am using in the Main() class.
  - Added astage width/height const to Root for ease of use. Obviously you will have to change it depending on your games size.
• Fixed the lineIntersecton function of the Geometry Class. ( Thanks to Ryan from Mochimedia for pointing this out )
• Added a “getRandomPolygon” utility function to the Geometry class which returns an array of points based on some parameters

I’ve also released a little tidbit about constraining rotations to a max amount per second.

This is the third post in the series “Programming Tidbits.” These articles consist of useful bits of information or code that I would like to share, but are not necesarily full length articles.

Sometimes you may wish to constrain the amount of rotation an entity can rotate per second or tick or whatever, such as the turret on a tank or the turning of the tank itself. This can be done with a bit of math. It could seem a bit complicated without using the math libraries I have already created.

Here it is using my code:

We are going to assume the maxTurnRate will be in degrees per second.

if( maxTurnRate > 0 && currentVelocity.angleTo( newVelocity ) > ( maxTurnRate * MathUtils.DEG_TO_RAD ) * stepSize )
{
 	var mat:Matrix2D = new Matrix2D();
	mat.rotate( ( ( maxTurnRate * MathUtils.DEG_TO_RAD ) * stepSize ) * heading.sign( newVelocity ) );
 	mat.transformVector( currentVelocity);
 	mat.transformVector( heading );
 }
 else
 {
 	velocity.x = _newVel.x;
 	velocity.y = _newVel.y;
 }

The Code Explained

So let’s take a look at what is happening there. First, we are checking to see if maxTurnRate is > 0…because we will assume if it is set as 0 then the entity should be able to turn freely. If it is greater, then we will get the angle from our current velocity and check to see if it is greater than the max turn rate multiplied by the step size. The step size is generally just: tickSize / 1000.

The math to get the angle from one vector to another is:

public function angleTo( vector1:Vector2D, vector2:Vector2D ):Number
{
	return Math.acos( dotProduct( vector1, vector2 ) / ( vector1.length * vector2.length ) );
}
 
public function dotProduct( vector1:Vector2D, vector2:Vector2D ):Number
{
	return ( vector1.x * vector2.x ) + ( vector1.y * vector2.y );
}

Next, if the rotation is greater than the max amount aloud…we will use a matrix to rotate the velocity vector to it’s correct position and transform it and the heading ( the direction the entity is going ). Note: The “sign” function just returns -1 if vector is counterclockwise, else 1 if clockwise. We need this to know which direction to rotate obviously.

The Matrix Code

Here is some of the matrix code, though I definitely don’t plan on explaining matrices in this post. Which is why it’s best to just use the library if you don’t actually understand the math part itself.

/**
 * Use to rotate.
 * ( Considers that the Vector object represents a point, not an actual vector )
 * @param rot
 *
 */
public function rotate(rot:Number):void
{
	var sin:Number = Math.sin(rot);
	var cos:Number = Math.cos(rot);
	multiply( new Matrix2D( cos, sin, 0, -sin, cos, 0, 0, 0, 1 ) );
}
 
/**
 * Use to multiply two Matrixes...mainly used internally.
 * @param matrix The Matrix to multiply by.
 *
 */
public function multiply(matrix:Matrix2D):void
{
	var m:Matrix2D = new Matrix2D();
 
	//first row
	m.a1 = (a1 * matrix.a1) + (a2 * matrix.b1) + (a3 * matrix.c1);
	m.a2 = (a1 * matrix.a2) + (a2 * matrix.b2) + (a3 * matrix.c2);
	m.a3 = (a1 * matrix.a3) + (a2 * matrix.b3) + (a3 * matrix.c3);
	//second row
	m.b1 = (b1 * matrix.a1) + (b2 * matrix.b1) + (b3 * matrix.c1);
	m.b2 = (b1 * matrix.a2) + (b2 * matrix.b2) + (b3 * matrix.c2);
	m.b3 = (b1 * matrix.a3) + (b2 * matrix.b3) + (b3 * matrix.c3);
	//third row
	m.c1 = (c1 * matrix.a1) + (c2 * matrix.b1) + (c3 * matrix.c1);
	m.c2 = (c1 * matrix.a2) + (c2 * matrix.b2) + (c3 * matrix.c2);
	m.c3 = (c1 * matrix.a3) + (c2 * matrix.b3) + (c3 * matrix.c3);
 
	Set(m.a1,m.a2,m.a3,m.b1,m.b2,m.b3,m.c1,m.c2,m.c3);
}
 
/**
 * This is used to do the final transformation upon the Vector
 * @param point The Vector to apply this Matrix transformation to.
 *
 */
public function transformVector(point:Vector2D):void
{
	var tempX:Number = (a1*point.x) + (b1*point.y) + (c1);
	var tempY:Number = (a2*point.x) + (b2*point.y) + (c2);
	point.x = tempX;
	point.y = tempY;
}

And that’s all!

So anyways…I’ve shown the internal workings of the math code there for you, though the first code block is all that should really matter to you in the end…since it shows how to actually use the math.

No example today, since I’m pretty sure you can imagine a turret rotating at a max speed…lol. However, it will be used in the next Game Structure post for the entities.

Also for those of you waiting for the next article…be patient, it is a BIG one! I’ve created many Artificial Intelligence behaviors and a great OOP structure to use them, and I’ll be discussing Boids and many of the behaviors in detail. I’ll try to get it finished as soon as possible.

I hope everyone is enjoying their Christmas break!

Dealing with sounds in Actionscript can be kind of wacky. Sound Objects, Channels, Transforms…blah. I don’t like messing with all of that, so I’ve built a sweet, easy to use Sound Manager. I don’t suppose it has any magical powers or anything but that’s only because I couldn’t think of anything magical a Sound Manager should do…other than play sounds and control volume.

The Sound Manager Class

It is a Singleton, and can be used from anywhere in your game / project. Simply register all of your sounds to the manager, and play them using IDs rather than having references to the sounds themselves.

Also, I have made it so that you can play a “sound”, or play “music” which is controlled at a different volume. Also, it is set up so that only one music sound will play at a time.

Here is the interface for the Sound Manager:

public class SoundManager
{
 
	// -- INITIALIZATION ---
 	public static function get instance():SoundManager
 
        // Volume Control
 	public function get soundVolume():Number
 	public function set soundVolume( volume:Number ) : void
	public function get musicVolume():Number
	public function set musicVolume( volume:Number ) : void
 
 	public function SoundManager( enforcer:SingletonEnforcer )
 
	public function registerSound( a_sound:Sound, a_id:String ) : void
 
	public function playSound( a_id:String, a_startTime:int = 0, a_loops:int = 0 ) : void
	public function stopSound( a_id:Sound ) : void
 
	public function playMusic( a_id:String, a_start:int = 0, a_loops:int=0 ) : void
 
	public function stopMusic() : void
 
}

Example Usage

I like that I can use ids to play the sounds, because in my games I tend to use 2-3 sounds for certain effects such as death or explosions, which I like to randomly choose. In the example code you can see how I do this:

public class MainScreen extends AScreen
{
	[Embed(source="../assets/gunshot.mp3")]
	private var GunshotSound:Class;
	[Embed(source="../assets/murloc.mp3")]
	private var MurlocSound:Class;
	[Embed(source="../assets/diemaggot.mp3")]
	private var DieMaggotSound:Class;
	[Embed(source="../assets/mario.mp3")]
	private var MarioSound:Class;
 
	public function MainScreen(a_parentScreen:IScreenItem=null)
	{
		super(a_parentScreen);
 
		SoundManager.instance.registerSound( new GunshotSound(), "sound0" );
		SoundManager.instance.registerSound( new MurlocSound(), "sound1" );
		SoundManager.instance.registerSound( new DieMaggotSound(), "sound2" );
		SoundManager.instance.registerSound( new MarioSound(), "music" );
 
		var tf:TextField = Utils.createTextField( this );
		tf.htmlText = Utils.createHtmlText( "Click the mouse to play 1 of 3 random sounds. \n Press 'spacebar' to play music. \n Press 'up' or 'down' to control sound volume.", "#FFFFFF", 16 );
		tf.x = 550/2 - tf.width/2;
		tf.y = 400/2 - tf.height/2;
 
	}
 
	public override function update(a_timePassed:int):void
	{
		if( Input.instance.isMousePressed )
		{
			var rand:int = Math.random() * 4 - 1;
			SoundManager.instance.playSound( "sound" + rand );
		}
		if( Input.instance.isKeyPressed( KeyCode.SPACEBAR ) )
		{
			SoundManager.instance.playMusic( "music" );
		}
	}
}

As always, download the source at the Google project page.

Here it is in action.

In previous articles we have put together a framework to handle various issues with our game. As of now, it would be quite sufficient for creating many simple games. One problem however, is that the creation of multiple types of entities in various places in our code can get cumbersome and is prone to errors and/or problems if we begin to make changes to the way we want our entities to be created

The Factory Method

The proper way to handle the creation of multiple objects with similar functionality is to use the Factory Pattern. The benefit of using a factory class to create our entities is that not only can it return a new instance of an entity to us, but it can also provide additional functionality. Our GameFactory will also create a renderer for our objects, and add any constant forces such as gravity, wind, etc. This effectively reduces the amount of things we must deal with on creation to just the one call: GameFactory.instance.getEntity( “type” );

The goal of a properly implemented factory class should be to encapsulate change. In order to do this, we identify the parts of our code that can change, and separate it from that which does not. In the case of object creation, the word “new” is a bad thing. With the factory class which I have created you can always expect to have an entity correctly instantiated by calling GameFactory.instance.getEntity( “type” ); Now, if after writing several hundred lines of code which multiple entities being instantiated all over the place I decide that each time a certain entity is created, I will also play a sound…I simply add that to the Game Factory. I do not have to worry about finding all cases where the object is created and changing it there. Now you can see where the power of the factory method comes into play.

A Barebones Example

The basic factory method would be to create a class which looks somewhat like this:

getEntity( a_type:String ) : Entity
{
	switch( a_type )
	{
		case "type1":
			return new Type1();
			break;
		case "type2":
			return new Type2();
			break;
		case "type3":
			return new Type3();
			break;
		default:
			throw new Error( "Type not recognized!" );
			break;
	}
}

The Mother of All Factories

The GameFactory that I have created is actually much more functional than that. What I have done is program all entities and renderers to a common interface, and keep the constructors matching as well. There is no proper way in Actionscript to force subclasses to follow the same constructor format, however if they do not, then a runtime error will be generated to explain the problem.

The goal of the factory class which we will be implementing is to allow us to simplify the creation of any new entities as much as possible. We will create and register entities to the GameFactory using the “EntityParams” classes. Once it is time to create new entities, we will simply call: GameFactory.instance.getEntity( “type” );

Let’s take a look at the code for our GameFactory now:

public class GameFactory
{
 
	// Game Factory is a Singleton, use this to access its methods
 	public static function get instance():GameFactory
 
	public function GameFactory( enforcer:SingletonEnforcer )
 
 	public function getEntityParams( a_type:String ) : EntityParams
        public function registerEntityType( a_params:EntityParams ) : void
 
        // These two functions are called by the classes themselves
 	public function registerGameWorld( a_gameWorld:GameWorld ) : void
 	public function registerGameWorldRenderer( a_renderer:GameWorldRenderer ) : void
 
 	// Will add a constant force to all entities of type MovingEntity
 	public function addGlobalForce( a_force:Vector2D, a_name:String ) : void
 
 	/**
 	 *  This does NOT remove the force from any entities that were created
 	 *  using it! To do that you must remove the force by calling the appropriate
 	 *  function on the entities themselves.
 	 */
 	public function removeGlobalForce( a_name:String ) : void
 
        // This is the meat and potatoes of this class. Check out the source.
 	public function getEntity( a_type:String, a_parent:Entity=null ) : Entity
 
 	// Attaches a renderer to an entity
 	public function getRenderer( a_entity:Entity, a_renderer:Class, a_data:Object ):ARenderer
}

Code Changes

I have also made some changes and improvements to existing code. Here it is:

• Added type, customClass, rendererClass, and rendererData to EntityParams for GameFactory purposes.
• Removed “parent” variable from EntityParams…it didn’t make sense to have it there.
• Entity class now adds type to the id to further distinguish itself in debugging purposes.
• All renderers now use the same constructor template.
• GameWorld and GameWorldRenderer now activate themselves in GameFactory. ( This somewhat goes against “proper” OOD by coupling with a Singleton class, although I prefer the ease of use in this case. )
• Altered the “Root” class to use the Timer class from GamePoetry.com for the game loop. The game loop is now more accurate.
• Fixed an error caused with the removal / disposal of entities.

The Example

From now on, you will generally want to create a seperate file of some sort to do the initialization of your entity types. For most people this can just be a designated .as class, however other options would be to use an external .xml file or to REALLY harness the power of this sort of game structure, you could load your entities from a database. This would allow things such as user created content, or whatever you can think of.

For the example, I create a “BouncyBall” type in a seperate .as file called EntityTypes. Then for the main code, I simply initialize a couple of editable textfields and a button that changes the BouncyBall params to match what you enter. One thing that you could try out is that you could make some code that lets you register your own entity types and properties, and then another textfield that lets you type in the name of the entity you would like to spawn, and a button that creates that entity.

Final Words

I didn’t necessarily go over all of the fine details of the ACTUAL Factory Method Pattern here, so if you are curious of the exact implementation of it try searching Google, however I believe that my implementation makes object creation MUCH more flexible and robust.

Our core game structure is now quite solid, and we are moving into things such as game AI, particle effects, collisions, and other such things. The next article in the series will focus on one of these concepts, so be sure to download the new game code at the google project page and sign up for the RSS feed if you haven’t already.

This is the 3rd article in the series Building a Game Structure. Be sure to read the introduction which also has links to the rest of the articles in the series.

There comes a time when working on a game that you realize the need for an effective way to manage all of your entities and game objects. Also, not all games consist of just one simple non-scrolling screen so you must devise a robust way to deal with the problems of displaying your entities in the correct position based on where in the world you want the view to be centered, not to mention handling the mouse’ world position. Not only that, but it would certainly be nice to have some basic, simple, and reusable classes for rendering your entities so that you don’t ever have to deal with it again.

These are the issues I will be covering in today’s article, and of course I will wrap up by showing the code that I use and handing you the source to play with. I’ve made a few slight changes to some of the classes which I will talk about below.

Game World: A Central location for managing your objects

One of the benefits of creating a manager for the game’s objects is that you can eliminate errors caused by adding or removing entities in the middle of some logic. The manager should queue up additions and removals and then handle them all at once at the end of the update function.

The GameWorld itself is an Entity. It’s dimensions are the size that you wish your world to be, whether that be the size of the screen or a larger scrolling area.

Collision detection can be handled through the GameWorld class as well. What I have done is set up a hook function that calls an class: ICollisionResponse. If you wish to handle collisions within the GameWorld, you can simply create a class that does this by plugging into that interface.

Finally, We will use the Game World class to set up our GameCamera and activate a helpful “worldMousePos” variable within the Input class. Those I will talk about shortly.

The code is quite short and simple. Here is the Interface:

public class GameWorld extends Entity
{
        // Add collision response to the Game World
	public function set collisionResponse( a_value:ICollisionResponse ) : void { m_collisionResponse = a_value; }
 	public var camera:GameCamera; // The camera is left public since it may be accessed often.
 
        // The Constructor will initialize the camera and the collision response if necessary.
	public function GameWorld( a_worldSize:Vector2D, a_cameraSize:Vector2D, a_collisionResponse:ICollisionResponse = null )
 
        // We can set the size of the world here
 	public function setSize( a_width:int, a_height:int ) : void
 
        // Here we update the entities, process add and removes, and handle collisions
 	public override function update( a_timePassed:int ):void
 
 	public override function dispose():void
 
        // We override these and queue up the operations rather than doing them immediately
 	public override function addChild(a_entity:Entity):void
 
 	public override function removeChild(a_id:String):void
 
}

Also the collision response interface is quite small, requiring only one function to operate:

public interface ICollisionResponse
{
	function handleCollision( a_entity1:Entity, a_entity2:Entity ) : void;
}

Using a Game Camera to Assist With Rendering

In order to display the position of entities in a scrolling world, an inexperienced programmer might choose to simply move all other objects in relation to the main character. This is a very inflexible way to handle things. The more sensible approach would be to create a camera entity which all other entities will render thier locations based off of.

The camera class may also allow for nice effects such as movie style camera panning and zooming. For this version of the camera class, we will create a restraint that makes sure that the camera does not pan past the bounds of the game world. Also we will give it a function if called will cause it to follow a position by passing reference to a Vector2D object ( one of the many benefits of using the class, rather than a basic x/y variable )

Once again, the interface is fairly simple:

public class GameCamera extends Entity
{
	public static const MOVE:String = "camera_move_event";
 
	public function GameCamera( a_gameWorld:GameWorld, a_width:Number, a_height:Number )
 
	public function setSize( a_width:int, a_height:int ) : void
 
	public override function update( timePassed:int ):void
 
        // The camera will lock onto this position
	public function followPos( a_pos:Vector2D ):void
 
}

Simple Reusable Rendering Classes

Obviously with this game model the actual rendering of the entities has been seperated from the data and logic. In order to speed up and simplify production of any new projects as well as testing we create several rendering classes to make our lives easier.

These next few basic renderers will handle rendering different data types such as bitmaps and sprites. Also I have written somewhat of a “debug” entity renderer which simply renders the radius and rotation of the entity. ( We don’t always have graphics to attach to our objects right away! )

First off, I use an abstract Renderer function to supply the interface and the common functions that are used for most renderers. The abstract class will use hook functions that are expected to be overridden by subclasses to provide the full functionality. Also, Renderers are considered “Game Objects” so they will inherit that interface.

What the renderer class does is take whatever graphics you wish to display for the entity and place it inside of a “container.” Each update the container is positioned on the screen relative to the camera based on the entities position in the world. If the entity is scaled, the container will handle that scaling operation. Also on creation the renderer will center the registration point to the graphics being displayed, since that is the most common and easiest way to deal with graphics in games.

If the viewable area of the entity is off of the screen then the renderer will set it’s visible property to false, to increase rendering speed. Ultimately the only thing you have to worry about is setting up the renderer initially and it will take care of the rest. That is the idea.

Here is the interface for the abstract renderer class:

public class ARenderer extends EventDispatcher implements IGameObject
{	
 
        // the a_canvas variable will be the layer which the container is added to.
	public function ARenderer( a_entity:Entity, a_camera:GameCamera, a_canvas:DisplayObjectContainer )
 
        // It is not recommended to override this function unless absolutely necessary.
	public function update( timePassed:int ):void
 
	public function dispose():void
 
	// -- PRIVATE --
 
        // Handle any updating of the entity representation here
	protected function draw():void
 
	/**
	 * Update values m_viewBoxX, m_viewBoxY, m_viewBoxWidth, m_vewBoxHeight
	 * so that the culling will work correctly.
	 *
	 */
	protected function updateViewBox():void
 
        // The view box was left as individual variables rather than using
        // the AABB data structure in order to speed up the renderer class.
  	protected var _viewBoxX:Number;
  	protected var _viewBoxY:Number;
  	protected var _viewBoxWidth:Number;
  	protected var _viewBoxHeight:Number;
        // The canvas is the sprite which will be rendered to the screen
  	protected var _canvas:DisplayObjectContainer;
        // The container is added to the canvas, and contains the actual graphics used
        // to represent the entity.
	protected var _container:Sprite;
  	protected var _entity:Entity;
}

The three renderers I’ve created for this article are the EntityRenderer (for debug rendering), Sprite Renderer, and the BitmapRenderer. They are pretty basic:

public var boundsColor:uint;
 
public function EntityRenderer( a_entity:Entity, a_camera:GameCamera, a_canvas:DisplayObjectContainer )

public function BitmapRenderer( a_entity:Entity, a_camera:GameCamera, a_canvas:DisplayObjectContainer, a_bitmapData:BitmapData )

public function SpriteRenderer( a_entity:Entity, a_camera:GameCamera, a_canvas:DisplayObjectContainer, a_sprite:Sprite

Game World Renderer

Finally, the GameWorldRenderer will contain the main canvas which all of the containers should be added to. Also, it it will manage entity layers for us. Here is the interface:

public function BitmapRenderer( a_entity:Entity, public class GameWorldRenderer extends ARenderer
{
	private const MAX_LAYERS:int = 16;
 
        // a_renderSurface should be the stage, or any other display object on stage
	public function GameWorldRenderer( a_world:GameWorld, a_renderSurface:DisplayObjectContainer )
 
        // Use this function to get the a_canvas param for the ARenderer constructor
	public function getLayer( value:int ) : Sprite
 
        // If the canvas is not to be rendered at 0,0 then move it here.
	public function moveCanvas( x:int, y:int ) : void
 
	public override function update( timePassed:int ):void
 
	public override function dispose():void
 
}

Changes to preexisting code

I’ve made some slight modifications to the Input, Entity, and MovingEntity classes. I added a “worldMousePos” variable to the Input class, which can be activated once the GameWorld is created by calling:

public function activateWorldMouse( a_gameWorld:GameWorld, a_canvasX:int, a_canvasY:int ) : void

I added the “layer” and “isCollidable” variables to the Entity class, and fixed a problem with the MovingEntity’s rotation.

Flying Dogs!

For the example I just used some images from google to represent a background and some entities. Hold down the mouse to cause chaos! The camera will lock on and follow the last entity generated.

Be sure to take a look at the source code and the example to get a better understanding of how everything is working. You can download all of the files at the google project page here.

So what’s next?

Now that we have greatly simplified rendering and managing all of our game objects, the next thing for us to do is to centralize all of our object creation to factory classes. As of now, it is quite tedious to create our entities, and prone to errors and problems if later down the line we wish to change how objects are created. I will be discussing this in the next article.

Until then, be sure to comment with your thoughts and questions.