How to check for collisions in AS3

7 Aug, 2015 @ 15:09:25 by

Hi !
I am going to share another tip for all the as3 developers making games out there.
Today, we’re going to talk about collision detection in Actionscript 3.0
There are 3 different methods for testing the collision between two graphical objects (displayobject) in as3:
The first is using hitTestObject, a simple method that will test if the two objects hit each other. The main problem with this method is that it uses the DisplayObject bounding box which means that if the shape of your object is irregular, there will be empty spaces that will be considered to hit other objects even if they are graphically separated.

The second is using hitTestPoint. This is better because it allows you to test the collision of a DisplayObject with a specific point. It also has an option (boolean) to check for the actual pixels of the object and not the bounding box. This is a good option if you want to test smaller objects (like projectiles) against complex shapes.

The third is using the BitmapData of the object: BitmapData.hitTest.
However, this is much more complex and will require more CPU, probably impacting the performance of your game. There are ways to diminish this impact, such as first testing with a hitTestObject then using the bitmapdata, using quadtrees, etc.
But as those are rather complex and since most games don’t actually require pixel-perfect collisions, i won’t be talking about that.

The best way to do a somewhat accurate collision detection in AS3 i found was this:
Using hitTextObject!
“Wait…you said it wasn’t working with complex shape!” is what you’re probably thinking now…and you are correct. However, what if we were using several displayObjects instead of a single one ?
Here is a picture of how collision detection is used in my game:
AS3 hitboxes

In blue is the normal bounding box for the movieclip. In purple you can see the different hitboxes i will be using to check the collisions. It sure takes much more time to test all those but it is much faster than checking ALL the opaque points like the bitmapData.hitTest would do.
So here is what we do: test the collision with hitTestObject. If it is a hit, test it again but with each hitBox (you can stop the loop when it has hit one, that is a small optimization). Have an Array or Vector. in your objects containing the hitboxes (you can get them from the scenario using getChildAt in a loop).

Insert this in a game logic loop or as a collision method(assuming public properties…in your game, use getters instead):

if (object1.hitTestObject(object2))
for (var i:int = 0; i < object2.hitBoxes.length; ++i)
if (object1.hitTestObject(object2.hitBoxes[i])
break; //comment this if you want to test each hitbox even if one was hit)

And voilĂ  ! Collision detection that works with complex shapes. If you want to test 2 complex shapes, you will have to add another loop and test each hitbox against each hitbox which is obviously a bit more time consuming for the game but it will work and be faster than pixel-perfect tests anyway…
Here are 2 examples. In the first one, i use simple hitTestObject collision testing:

In this one, however, i use the multiple hitboxes method i described earlier:

As you can see, even if it is not pixel-perfect, it is much better! You could eventually come very close to pixel perfect collision testing if you added a lot of hitboxes but remember the more hitboxes you have, the more tests are done…

Download the source code

Hope this helps some of you, good luck on your game development!

Inheritance levels in OOP and the importance of planning ahead.

23 Jun, 2015 @ 16:02:24 by

For those that are new to object oriented programming or are unfamiliar with inheritance’s more complex concepts, i will share some tips from my game making experience.
When you make a game, you tend to forget about staying generic and allow for more possibilities. Because you have an immediate need, you want that object to behave that way and that could never change, surely. Except, it probably will!
For instance, say you are making a shoot’em’up game, like I am. You have your game logic set and you call an update method for each gameobject in your game loop. Your basic type for gameplay objects is gameobject.
Your enemies will fire bullets, so you made that update method return a bullet type object.
Pseudo code:
for all gameobjects
new bullet = return value of current gameobject update method
if bullet isn't null
add bullet to bulletList

However, what if you wanted to fire SEVERAL bullets ? Oh that’s simple, you just have to return an array / vector of bullets, then.
Yes, but what if you wanted to fire something else ?
If you instead use the basic “gameobject” type, that means you can return any type of gameobject instead of “just” a bullet.
Returning an array of gameobjects allows you to be free to do whatever you want.
Want to have an enemy shooting enemies ? You can (think of a launchbase for instance).
Want to use the update method to “shoot” coins when the enemy is dead ? You can.
Want to make an enemy that can replicate itself ? You can.

Well, it’s all cool and dandy, you think…but what about object specific method calls ? What if i need the returned object to be of a specific type ?
Thankfully, you can always typecast it and have access to all the objects functions.

Hope this helps some of you young programmers out there! Have fun coding…

FPS independent gameplay in Flash/Actionscript 3.0

12 May, 2013 @ 7:41:51 by

I’m currently developing a game for PC/MAC using Adobe Air and Actionscript 3.0 which has led me to test quite a few methods to achieve smooth gameplay. At first, i tried to use a timer instead of the enter_frame loop i often see because i’m more used to C / C++ and that is usually how you make a game loop in those languages. However, i soon found out that in Flash, the timers aren’t really fps independent. By testing my game in settings that lowered the frames per second (such as heavy population of hundreds of movieclips, software rendering, etc.), i discovered than even if i wasn’t relying on the ENTER_FRAME event for my updates, the gameplay would slow down to the point of being almost synchronized with the fps. That was a big issue and even though i managed to have the game really smooth at 60fps by using the GPU scaling (stage.fullScreenSourceRect), if a fps drop occured you would feel it gameplay wise.

For a video game, gameplay updates are what is really important. Smooth framerates are nice but hard to achieve because of the variety of configurations of the pc market. What should never be different on any computer is of course the gameplay, and this is why in other languages you usually update the screen and gameplay asynchronously. In Flash, there is no way to do this the way you would do it in…say, C++ for exemple. The best way to ensure the gameplay will be smooth is actually to use the ENTER_FRAME event listener and, inside the function called, check the time elapsed between updates. Once you’ve checked that time, you need to see if enough time has passed to allow for one or more updates to the gameplay. Or you can use the delta time (time difference between previous call and the current one) and pass it to your game objects to update them accordingly.

import flash.display.MovieClip;
import flash.utils.getTimer;

public class GameLoop extends MovieClip
  private var oldTime, newTime: int;
  private var frequency:int = 16;

  public function GameLoop()
   addEventListener(Event.ADDED_TO_STAGE, initok);

  private function initok(e:Event):void
   newTime = 0;
   oldTime = getTimer();

   addEventListener(Event.ENTER_FRAME, loop);

  private function loop(e:Event):void
    newTime = getTimer();
    while (newTime >= oldTime + frequency)
      oldTime += frequency;

      /* Gameplay logic */


  private function loop(e:Event):void
    newTime = getTimer();
    if (newTime >= oldTime + frequency)
      var deltaTime:int = newTime - oldTime;

      /* Gameplay logic exemple */

      oldTime = getTimer();



And there you have it. It’s as simple as that. You can test it with a crappy fps set in your flash file and a better one. Gameplay wise, your game won’t be any different (unless you’re playing on a very old machine or doing intense computing inside the gameplay logic, but in that case you should probably try to optimize that anyway). Of course, since we’re relying on the ENTER_FRAME event, if you get less than 10fps the game will probably feel a bit choppy…but at least the gameplay will stay the same and it won’t change your game.

Hope this helps someone avoid the struggles i’ve been fighting against during this development.
Stay tuned for more and probably some game making tutorials in AS3, C++/SFML and other languages!

Blog operational…

12 May, 2013 @ 6:37:30 by

First real post will arrive after some tweaking!