This is the 2nd article in the series Building a Game Structure. Be sure to read the introduction and article 1 which discusses building a foundation for your games.

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. Read the rest of this entry »

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.