Traversing the display list

A great HaXe feature is that you can define your own Iterator and execute it with the for-syntax.
It can be used in many different ways and drastically improves readability of your code. AS3 developers often need to look at the display list, so I wrote a basic DisplayListIterator to handle this task. Here is an example:

using de.polygonal.gl.DisplayListIterator;
...
for (i in Lib.current.stage) trace(i);

This will print out all display objects in the display list.

If you are not familiar with HaXe, Lib.current.stage points to the MovieClip of the Document class, and the using statement automatically creates a DisplayListIterator whenever it is called on a DisplayObjectContainer. So the statement ‘Class.method(arg)’ is transformed to ‘arg.method()’. Without ‘using’ I would have to write:

import de.polygonal.gl.DisplayListIterator;
...
for (i in new DisplayListIterator(Lib.current.stage)) trace(i);

Let’s finish with a simple example that changes the text color of all text fields to red inside a DisplayObjectContainer.

var container:Sprite = myTextFieldContainer;
for (i in container)
{
  if (Std.is(i, TextField))
  {
    cast(i, TextField).textColor = 0xff0000;
  }
}

Useful, isn’t it :)

Ace of Mace

Last year some guys started to work on a game called Ace of Mace built on top of my physics engine. It was officially released yesterday and won a price at the Europrix Multimedia Award before. Today it’s featured as the Adobe Site of the day. Great work!

Speaking about motor2, version 0.9 was released at the end of last year, and now I’m working on it to get a major release done.

Firefighter - The Mission

I just want to introduce a game called ‘Firefighter - The Mission‘ that can be played here. It’s somewhat a milestone for me because it’s the first game I coded as a freelancer. It was finished at the end of last year, but was just published now. The game is build upon an efficient isometric game (which you probably won’t notice that much because the animated fire and smoke effects are serious performance killer).

A unique game feature is the collision detection. All collisions are computed in 2d, so the game does not need coordinate space transformations (rotation about y and x axis). In fact, 90% of the code only uses additions, multiplications and bit shifting, so I think it should also run well on mobile devices.

Collision handling is divided into two parts, which are often referred to as broad phase and narrow phase. The broad phase step just checks if the 4 adjacent tiles on which the player stands are walkable and adjusts the player position accordingly. The narrow phase step uses a system I like to call ‘Micro Collision Cells’. Every tile has a fine grid of cells - much smaller than the player itself, and each cell can be turned on/off in the level editor. When the engine is fired up, all flagged cells are merged into the smallest possible amount of larger axially aligned bounding boxes (AABB). For example, if a tile has a resolution of 5×5 cells, and each cell is flagged, the engine would have to check 5×5 = 25 cells in total, but the simplification leads to one box covering the full tile.

Another feature I worked on was exact line-of-sight computation. This is used to get a valid range of tiles in front of the player that can be extinguished (very important for z-sorting the water particles). Scrolling is tile based and follows the principle of tonypa’s well known tutorial about tile based games.
Because there wasn’t much time to develop the game, I left out some advanced features like ‘line of sight’ for visibility determination (similar to a fog of war in strategy games), but I will definitely port and extend the engine to AS3, since it is easily adapted to other graphics sets or tile sizes which should come in handy if a similar project comes along.

How to debug fast-paced action games

During the development of my last game I took a different approach of debugging it which is especially useful for real time games. Because it’s so simple I’m wondering why I haven’t used this method before (perhaps too lazy ? ;-)) Usually you include a bunch of trace statements everywhere or create a logger system which prints out the information you need. But this is useless in games where many simultaneous events occur. Your logger will be flooded with messages so it’s hard to keep track of everything.

The idea is to include a simple playback control by using keys or invoking a custom breakpoint() method, so you can stop and resume the game at any time and trace out additional information with it. Here is how it’s done (again, basic stuff here):

var updateGame:Boolean = true;
var useBreakpoints:Boolean = false;

//main loop: update game logic, render scene..
function tick():Void
{
	if (!updateGame) return;

	update();
	render();
}

function update():Void
{
	//...
	if (player.collides(wall)) breakpoint("player-wall collision");
	//...
}

So whenever the player collides with the wall, the game stops and prints out the passed string. The breakpoint function itself can look like this:

function breakpoint(message:String, forced:Boolean):Void
{
    //just quit if breakpoints are disabled
    //this can be overridden by setting forced=true
    if (!useBreakpoints && !forced) return;

    //print out message and stop game
    trace("breakpoint:" + message);
    updateGame = false;
}

Obviously, when breakpoint() is called, ‘updateGame’ is set to false so the main loop stops doing anything. The function also checks if breakpoints are enabled so you can globally turn them on or off. Furthermore, you have the option to call breakpoint() with a forced flag, so even if breakpoints are entirely disabled, your game will stop at that point. This is useful to keep some breakpoints active for very rare events or stuff you aren’t sure is working at all and at the same time you can test the game without being constantly bothered by existing regular breakpoints. I have also defined some keys:

function onKeyDown()
{
    switch (String.fromCharCode(Key.getAscii()))
    {
        //stop/resume game
        case "u":

            updateGame = !updateGame;
            break;

        //toggle breakpoints
        case "b":

            useBreakpoints = !useBreakPoints;
            trace("breakpoints " + (useBreakpoints ? "on" : "off"));
            break;

        //step through game
        case "s": 

            if (!updateGame)
            {
                update();
                render();
            }
            break;
    }
}

Game playback is toggled with ‘u’, and when the game is frozen by a breakpoint call, you can advance frame-by-frame by pressing the ’s’ key or resume playing by pressing ‘u’. This makes debugging much easier because you actually now have the time to think about what’s going on when something goes wrong ;-).

Collision detection with Recursive Dimensional Clustering

I have written a tutorial about speeding up collision detection using a space partitioning algorithm called Recursive Dimensional Clustering. Watch a demo. You can find the full article and source code here.