I’m going to discuss how different objects should be represented in your games and do my best to explain the idea behind my reasoning. I’ll provide the code I am using for my entities, and explain that a bit as well. So let’s get started. First of all, I feel that it is best to categorize your game objects into two categories: Entities and Game Objects. Let’s talk about Entities first.

What is an Entity?

An entity can represent any physical object in your gameworld. Entities are generally things that can be interacted with in some way, or just anything that holds a position in the world. This could include: A barrel, door, powerup, player, enemy, trigger area, wall, etc.

All entities will use the update/dispose interface. Entities may contain other entities and game objects in a hierarchical structure as well. They contain the basic data to represent themselves in game space such as position, rotation, size, scale. Each has a unique ID associated with it for debug and storage purposes.

Ideally Entities will replace the need for multiple class types for each different enemy by providing somewhat of a “template.” In order to provide more functionality we do things such as extend the basic Entity class with “MovingEntity” which provides movement data, and in a later article I’ll discuss a “Vehicle” class which provides AI to the entity. Each individual game will extend those basic classes further with a general “Unit” class that can provide more specialized data such as health, damage, etc.

To make the Entity classes as reusable as possible we will provide basic hook functions that can be used or overrided by subclasses. We want to make it as easy as possible to centralize the creation of these entities within a factory class, and even create a way that these can be built using external data. Rather than having a long list of constructor parameters, we create an “EntityParameters” class that holds the basic startup variables to be passed through to each entity on creation. This will make it very easy to do the things we just discussed.

Why Use Entities?

One question some may ask is why we create a class to represent our objects rather than simply extending MovieClip. Well, the answer is that it is quite inflexible to extend MovieClip because you may wish to represent your object with several different types of graphical data. This approach I am preaching is more along the Model View Controller design pattern, which allows for the greatest of expandability. Also, there are some things that make using entities extremely faster than dealing with Display Objects directly.

What is a game object?

Now that we are clear on what an Entity is, and the idea behind it…isn’t that what a game object is? Well, yes and no. A game object can be any of the following: A Sprite which graphically represents an entity, an AI routine which must be calculated each frame, any sort of game GUI such as menus etc. A game object’s definition is really quite broad, but we will consider anything to be a game object which needs to be updated and disposed of properly and does not have an actual “Game World” representation. I suppose that leaves the question of…

What is the “Game World”?

The Game World is simply the area in which the entities reside. What would be displayed to the screen can be considered as what is visible in the “camera.” The Game World is in fact an entity itself. I don’t want to go into any more detail on this right now, because it will be discussed in detail with another article.

Let’s build our Entity

Note: This version of the Entity class has a small bit of it’s final functionality taken out. What you see below is the core of it, however we will build upon it slightly in future articles to allow for greater usefulness within our greater game structure.

I’m going to list out the interface of the Entities and Game Objects. I’ve commented the interface here. To see the full code you may download the files from the google project page.

This is used for anything that will be considered a Game Object

public interface IGameObject extends IEventDispatcher
{
	function update( timePassed:int ):void;
	function dispose():void;
}

These are for the construction of our entities.

public class EntityParams
{
	public var parent:Entity;
	public var radius:Number;
	public var id:String;
	public var rotation:Number;
	public var scale:Number;
 
	public function EntityParams()
}

public class MovingEntityParams extends EntityParams
{
	public var maxSpeed:Number;
	public var doesRotMatchHeading:Boolean;
	public var boundsBehavior:String;
        public var friction:Number;
	public function MovingEntityParams()
}

The basic Entity class which can represent any stationary object.

public class Entity extends EventDispatcher
 {
 	public function get scale():Number
 	public function set scale( a_value:Number ):void
 	public function get id():String
 	public function get parent():Entity
 	public function set parent( a_value:Entity ) : void	
 
 	/**
 	 * NOTES: The following variables are left open rather than using getter/setters because they are accessed
 	 * 	often and thus this VASTLY improves performance.
 	 *
 	 * 	newPos and actualPos ( have to use these since we don't do getter/setter )
 	 * 	newPos var should be what you change if you wish to change pos externally.
 	 */
 	public var newPos:Vector2D;
 	public var actualPos:Vector2D;
 	public var rotation:Number;
 	public var radius:Number;
 	public var bounds:AABBox; 	
 
 	/**
 	 * ID's are assigned automatically. If it is necessary to force an ID then set it
 	 * in the parameter file passed through the constructor.
 	 *
 	 */
 	public function Entity( a_params:EntityParams )	
 
        // The basic interface
 	public function update( a_timePassed:int ):void
 
        public function dispose():void
 
        // Each entity may inherit the basic hit detection functions or create it's own specialized version.
 	public function isOverlapping( a_entity:Entity ):Boolean
 
 	public function isOverlappingCircle( a_pos:Vector2D, a_radius:Number ) : Boolean 	
 
        // The following is the interface for handling child entities and game objects
 	public function addChild( a_entity:Entity ):void
 
 	public function removeChild( a_id:String ):void
 
 	public function clearChildren() : void
 
 	public function getChildByID( a_id:String ):Entity
 
 	public function getChildren() : Array
 
 	public function addGameObject( a_gameObject:IGameObject ):void
 
 	public function removeGameObject( a_object:IGameObject ):void
 
 	override public function toString():String
 
  	// -- PRIVATE --
 
        // These are hook functions to be used or overrided by subclasses. They are used within the update function.
  	protected function updateChildren( timePassed:Number ):void
 
  	protected function setInitialValues( timePassed:int ):void
 
  	protected var _stepSize:Number;
        protected var _parent:Entity;
 
 }

Now our Moving Entity which handles any movement data. Keep in mind that the movement logic used by this Class may be changed slightly depending on the game you are creating. Things such as rotation speed constraints etc may be applied, however this is a basic moving entity example.

public class MovingEntity extends Entity
{
	public static const BOUNDS_BOUNCE:String = "bounce";
	public static const BOUNDS_WRAP:String = "wrap";
	public static const BOUNDS_REMOVE:String = "remove";
	public static const BOUNDS_NONE:String = "none";
 
        public function get friction() : Number { return _friction; }
	public function set friction( a_value:Number ) : void { _friction = a_value; }
 
	/** CAUTION!
	 * The heading variable is left open for speed purposes, however it should only be set externally
	 * using the setHeading function! The side variable should never be set externally.
	 */
	public var heading:Vector2D;
	public var side:Vector2D;
	public function setHeading( a_value:Vector2D ):void		
 
	public var speed:Number;
  	public var maxSpeed:Number;
  	public var boundsBehavior:String;
  	public var doesRotMatchHeading:Boolean;
 
	public function MovingEntity( a_params:MovingEntityParams )
 
        // a simple way to get the entity to face a target position.
	public function rotateToPosition( a_target:Vector2D ) : void
 
        // apply a one time force to the entity. It will be removed after it is calculated.
	public function applyForce( a_force:Vector2D ) : void
 
        // add a constant force such as gravity to the entity.
	public function addConstantForce( a_force:Vector2D, a_id:String ) : void
 
	public function removeForce( a_id:String ) : void
 
 	public override function update( a_timePassed:int ) : void
 
 	override public function dispose() : void
 
 	// -- PRIVATE --
 
        // Some new hooks are added
 	override protected function setInitialValues( a_timePassed:int ):void 	
 
 	protected function calculateForces():void
 
        protected function calculateFinalVelocity():void
 
        protected function updatePosition():void
 
 	protected function updateHeading():void 	
 
 	protected function wrapOnBounds():void
 
 	protected function bounceOnBounds():void
 
 	protected function removeOnBounds():void
 
 	protected var _forces:Array;
 	protected var _constantForces:Dictionary;
 	protected var _newVel:Vector2D;
 	protected var _velocity:Vector2D;
        protected var _friction:Number;
}

Wrapping Up

We now have a way to easily represent entities and thier associated objects in our games. The next steps would be to to create a class to manage all of our objects and entities effectively, as well as a generalized graphical representation class for our entities. Then we will want to centralize creation of entities and objects to a factory class, and ideally support external data driven creation.

In the next article, we will discuss game object management and we will create some renderers for our entities. For now, be sure to check out the example code on the google project page.

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.