I’ve updated my coding conventions slightly.

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

This is the 4th 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.

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

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

This is the second post in the series “Programming Tidbits.” These articles consist of useful bits of information or code that I would like to share, but may not be considered a full article.

Sometimes your game may consist of a very large amount of entities that must be checked for collision with each other. In order to increase the speed of your collision tests there are a few methods that you can employ. This is no way an all inclusive article on this subject because there are MANY different methods for improving collision performance, however hopefully this can get you started.

The easiest thing to do is to eliminate as many collision checks as possible, as well as keep the collision checks as simple as you can. I’ll try to explain a few different methods which you can combine to speed up your testing.

The Bad Way

Generally you will be storing multiple entities in some type of array or map. The most common way of checking for collision is to loop through this array and check each entity against one another.

var entity1:Entity;
var entity2:Entity;

for ( var i:int = 0; i < entities.length; i++ )
{
 	entity1 = entities[ i ];

 	for ( var j:int = 0; j < entities.length; j++ )
 	{
 		entity2 = entities[ j ];

 		if( entity1.isOverlapping( entity2 ) )
 		{
 			// Handle Collision
 		}
 	}
}

Reduce Redundancy

Using this method will work, however the more entities you add to the array the slower it will become. The main problem here is that many of your checks are redundant. The more efficient method would be to make sure that you only check each entity once by making a small change to the inner loop:

for ( var j:int = i + 1; j < entities.length; j++ )

Collision Groups

Another way of increasing the speed is to give your entities flags or collision groups. For example, you may flag some entities as “collidable” and you may also decide that some entities cannot collide with each other so you might give them a “group” variable. This eliminates the need for actually running checks against this entity at all.

var entity1:Entity;
var entity2:Entity;

for ( var i:int = 0; i < entities.length; i++ )
{
 	entity1 = entities[ i ];	

 	if( !entity1.isCollidable )
 	{
 		continue;
 	}

 	for ( var j:int = i + 1; j < entities.length; j++ )
 	{
 		entity2 = entities[ j ];

 		if( !entity2.isCollidable || entity1.group == entity2.group )
 		{
 			continue;
 		}

 		if( entity1.isOverlapping( entity2 ) )
 		{
 			// Handle Collision
 		}
 	}
}

Simplify First

The last trick would apply when you are using complex collision such as pixel perfect / polygon collision. Instead of checking each object with the complex collision algorithm, use a simple bounding circle collision test first, and if that test returns true then proceed with the more detailed collision test.

if( entity1.isOverlapping( entity2 ) )
{
	if( entity1.detailedCollisionTest( entity2 )
	{
		// Handle Collision
	}
}

Final Words

Other methods of increasing collision testing speed would be to implement some sort of “broad phase” algorithm, however that is beyond the scope of this article. The methods discussed here should be sufficient for most flash games.

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 »

This article is part 1 of a series: The Structure of a Game. Read the Introduction here.

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

This is the first post in the series “Programming Tidbits.” These articles consist of useful bits of information or code that I would like to share, but may not be considered a full article.

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
• Game Entities and Objects
• Managing Game Objects and Rendering a Game World
  
• The Game Factory - How You Should REALLY be creating objects
• Artificial Intelligence - Boids / Steering Behaviors ( Coming Soon )
• Data Driven Development
• And more…

Programming Libraries used in the Series:

• Actionscript 3 Math Library
• Input Manager

Conventions that I follow:

• Coding Conventions - Sloppy Code Sucks!
• Organized Trace Commands
• Eliminate Magic Numbers

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.