Today I stumbled over the NSZombieEnabled argument and HOLY CRAP WHY ISN’T THIS DEFAULT BEHAVIOR. After enabling the argument I found where my app crashed in about 1 minute. Turns out you should not do:

- (void)viewDidUnload {
    self.foo = nil;
    [super viewDidUnload];
}

but rather

- (void)viewDidUnload {
    foo = nil;
    [super viewDidUnload];
}

A fairly subtle difference I’ll grant myself but, apparently, an important one. In this particular case I am using the self.foo property as a typed copy of the UIViewController’s view property. In the wrong case setting self.foo to nil releases the property where the framework assumes it still exists, resulting in an app crash. Simply setting the foo instance variable to null, however, works great.

The game I’ve been working on at my day job has been released. The first issue of Exile is available today, and if you order now for $8 you get the remaining 3 issues delivered digitally when they are released.

Exile is unlike most games and most graphic novels, in that it offers first rate art and story with a compelling interface including interactivity, a soundtrack, and sound effects. We’ve also put a lot of effort into making the game as immersive as possible by providing unlockable elements within the game that give players a look at concept art, character sketches, and even minigames set in the Exile universe. The end result is a unique experience and the game succeeds in blurring the line between graphic novels and video games.

I’ve been lucky to work with a great team of artists and writers on this game, and I couldn’t be happier with the way this has turned out.

The minigame I’ve been working on at my day job has been released, play “Don’t Get Shot” free at Kongregate. This minigame is released in support of the release of the first issue of Exile.

The game is a reversal on the popular top down shmup genre, in that you are the one getting shot at. It is your goal to not get shot, or exploded, and progress through the levels. The level names I find entertaining and they typically give you a hint as to what to expect in the level.

The game was made with the excellent Flixel and Box2D libraries. It is a successful hybrid between the two, leveraging the Flixel framework for its great sprite animation, state management, and quick rendering, while using the accurate physics and collision features of the Box2D project. The integration was actually a great deal simpler than I thought it was going to be, which is like icing on the cake given all the features now available. These features coupled with a simple editor and an xml level format made it easy to turn out lots of great levels, which you can look forward to in future issue releases.

The game’s artwork was done by Dave Will, the original concept was created by Ran Flasterstein, and the levels were done by Jay Treuhaft and an unknown intern possibly named Brian Fred Dinovo.

The site is built on a CakePHP application and actually uses WordPress for the blog section of the site. It doesn’t use WordPress for any of the front end, but in the back end the standard WordPress Dashboard is used to manage, edit, and write blog posts that are then displayed in the front end blog section.

The site also utilizes my meta description and title components, that allow the application to manage those parts of the page independently of the page content. Basically it just ties a URL to a title or a description, matches them up when pages are requested, and if it finds a matching record it outputs it in the proper place. Otherwise it will output a sensible default text.

I did enjoy working with CakePHP again as it’s been some time. But all the things I liked about it still apply. It’s still lightening fast from prototype to finished site, and design modifications couldn’t be any simpler. All in all, good project, and I think the end result looks and works very well.

I’m just using the standard ImageMagick tools convert and montage to split and join the images, as well as some bash-fu to sort files properly. I am using Cygwin to get bash tools on my Windows machine.

The first command is used to split up the main image. The only constraints here are that the resulting tiles must be square, and that they don’t exceed the width limit for Flash BitmapData objects. So here we simply are cropping the image into square tiles.

convert full.png -crop 32x32 tiles.png

 
This will spit out a bunch of images in the current folder named tiles-%d.png where %d is the 0 based index of the tile. This also assumes that the width and height of the full.png image are divisible by 32 without remainder.

The next command we need is to stitch the images back together. For this we will use the handy montage tool to tile the images into one big sheet. We just pass it a sorted list of names and tell it to make 1 row with as many columns as it needs (the x1 parameter). Sorting is not entirely necessary but using the default bash globbed format will result in tiles that should be at the end of the image randomly at the beginning (try it before this step by noting the output of `ls tiles*.png`).

files=$(ls tiles*.png | sort -t '-' -n -k 2 | tr '\n' ' ')
montage $files -tile x1 -geometry 32x32+0+0 sheet.png

 
If all went well we should see, inside the current directory, an image with all of our separate tile sprites in a single row in order from the original image from left to right and top to bottom.

This technique is also useful for converting “liberated” sprite sheets that have more than one row, into single row sprite sheets that flixel can handle out of the box.

The class I developed is a simple override of the base FlxSprite class with some modifications to its collision detection system. It takes advantage of the fact that each sprite has its own set of BitmapData in its own coordinate space, which the framework uses to blit to the main screen BitmapData. BitmapData objects in Flash provide us with a native implementation (in the Player AFAIK) of per pixel collision detection, using the hitTest method.

The hitTest method takes 5 parameters, but we only really care about the first 4. The first parameter we pass it defines where the calling BitmapData object is in screen space, i.e. the sprite’s (x,y) coordinates. We then pass it a threshold alpha value, 0 being transparent and 255 being opaque. If you want semi-transparent regions of your sprite to collide then set this to something lower than 255 (0xFF is the hexadecimal representation of decimal 255). The third parameter is the colliding sprite’s BitmapData object. And the fourth is the colliding sprite’s (x,y) coordinates in screen space.

I have abstracted this into the class’s structure, so the overridden functions handle everything. You can use another alpha threshold by setting the sprite’s alphaThreshold value to something valid, as explained above. You can also disable this pixel perfect collision detection method per technique by either setting doPerfectCollide or doPerfectOverlap to false. Because there are two methods Flixel uses to detect collisions, the class implements enhanced versions of both, and allows you to disable either independently.

Note that, in order for the collision detection to be pixel perfect, either a) both colliding objects must subclass PPlxSprite or b) the sprite calling overlaps or collide must sublcass PPlxSprite and the colliding sprite must have a single frame. This is due to fact that the original FlxSprite class does not expose the _framePixels BitmapData object which is needed to collide the objects with the frame that is currently displayed. When a FlxSprite is collided with a PPlxSprite and the perfect collision is enabled, the exposed _pixels BitmapData is used, which contains the entire sprite sheet, so collisions are detected against all frames, not just the frame displayed. However, changing existing sprite’s to use this class is easy enough so as not to cause problems.

Note also that we only call the hitTest method when we know there is already a bounding box collision, so as not to waste CPU cycles. The native hitTest method is fast but probably not fast enough to call every frame, which would be wasteful in any case.

Below is the PPlxSprite class which override the collision methods to provide pixel perfect collisions.

import flash.display.BitmapData;
import flash.geom.Point;

import org.flixel.FlxCore;
import org.flixel.FlxSprite;

public class PPlxSprite extends FlxSprite {

    public var alphaThreshold:uint = 0xFF;
    public var doPerfectOverlap:Boolean = true;
    public var doPerfectCollide:Boolean = true;

    protected var _corePos:Point = new Point();
    protected var _thisPos:Point = new Point();

    public function PPlxSprite(X:int=0, Y:int=0, SimpleGraphic:Class=null) {
        super(X, Y, SimpleGraphic);
    }

    public function get framePixels():BitmapData { return this._framePixels; }

    override public function overlaps(Core:FlxCore):Boolean {
        var doesOverlap:Boolean = super.overlaps(Core);
        if (doesOverlap && this.doPerfectOverlap && Core is FlxSprite) {
            doesOverlap = this.perfectCollision(FlxSprite(Core));
        }
        return doesOverlap;
    }

    public function perfectCollision(Sprite:FlxSprite):Boolean {
        this._corePos = Sprite.getScreenXY(this._corePos);
        this._thisPos = this.getScreenXY(this._thisPos);

        var corePixels:BitmapData;
        if (Sprite is PPlxSprite) {
            corePixels = PPlxSprite(Sprite).framePixels;
        } else {
            // i guess other standard FlxSprites are boned if they are animted
            corePixels = Sprite.pixels;
        }

        return this._framePixels.hitTest(this._thisPos, this.alphaThreshold, corePixels, this._corePos);
    }

    override public function hitWall(Contact:FlxCore=null):Boolean { return this.hitSomething(Contact); }
    override public function hitFloor(Contact:FlxCore=null):Boolean { return this.hitSomething(Contact); }
    override public function hitCeiling(Contact:FlxCore=null):Boolean { return this.hitSomething(Contact); }

    public function hitSomething(Contact:FlxCore):Boolean {
        var didHit:Boolean = true;
        if (this.doPerfectCollide && Contact is FlxSprite) {
            didHit = this.perfectCollision(FlxSprite(Contact));
        }

        return didHit;
    }
}

 
Here I have overriden the core FlxSprite methods that are responsible for collision detection, those methods being overlaps and the hit family of methods. Overlaps gets called when you explicitly issue a sprite.overlaps(otherSprite); This is a simple override that adds functionality to the super overlaps method, namely, calling the pixel perfect detection method and returning its results.

The hit family of methods are called after calling the collide family of methods, including collideArray and the like. The collide methods, when they have detecting a bounding box collision, call the hit family of methods, depending on the location of the collision, which return a boolean. If the called hit method implemented by the sprite returns false, the collide method aborts and reports that it didn’t collide after all. This is the behavior on which the above hit methods rely, and return false when it detects that while a bounding box collision may have occurred, the pixels in either sprite have not collided.

A short usage class follows.

public class SomeSprite extends PPlxSprite {

    // Embed sprite image.

    public function SomeSprite(X:Number, Y:Number):void {
        super(X, Y);
        // Load sprite image, and other sprite stuff
    }

    override public function hitWall(Contact:FlxCore):Boolean {
        if (super.hitWall(Contact)) {
            this.hurt(1);
            return true;
        }
        return false;
    }
}

 
Here, all we do is simply extend the PPlxSprite class from above, and do what we normally do for sprites. We also decide to do something special when a character hits a wall, namely, get hut. To do this we override the hitWall method, call the super hitWall (which would be the PPlxSprite hitWall) method, and depending on its return value, we either get hurt or do nothing. We don’t need to do anything special for calling the overlaps method, as this will simply call PPlxSprite overlaps method.

So, hopefully this is helpful for someone looking to do this, or at least someone can find the ideas listed here useful. Let me know if you used it and if you find any bugs, improvements, or have any other suggestions.

As a category, top down and platformer games in general usually have some type of movement modification obstacles. These obstacles allow the player to pass through them, so they don’t stop the player from moving, but they somehow alter the player’s course by speeding up, slowing down, or sending the player in a different direction. In my case, these obstacles are oil slicks and water puddles, which speed up and slow down the player in whatever direction they are traveling. Here I will cover how I solved speeding up and slowing down the player when he crosses over such an obstacle.

Below is a skeleton of my main player class:

 package sprites {
	import org.flixel.FlxG;
	import org.flixel.FlxSprite;

	public class Player extends FlxSprite {

		[Embed(source="player.png")] private var Img:Class;

		protected var _runSpeed:Number = 100;

		public var velocityFactor:Number = 1;

		public function Girl(X:int=0, Y:int=0) {
			super(Img, X, Y, true, false, 58, 58);

			drag.x = this._runSpeed * 8;
			drag.y = this._runSpeed * 8;

			maxVelocity.x = this._runSpeed;
			maxVelocity.y = this._runSpeed;

			...
		}

		override public function update():void {
			// MOVEMENT
			acceleration.x = acceleration.y = 0;
			this.maxVelocity.x = this._runSpeed * this.velocityFactor;
			this.maxVelocity.y = this._runSpeed * this.velocityFactor;
			if (FlxG.keys.UP) {
				acceleration.y -= drag.y;
			}
			// And similarly for all 4 key directions
			...

			super.update();
		}
	}
}

Using this player class, we can see that by modifying the velocityFactor instance variable, we can effectively control how fast the player can move around the screen. By setting velocityFactor equal to a value less than one, we decrease the player speed, and by setting it equal to a value greater than one we increase the player speed. So what we need now is a way to modify this value externally in response to player interaction with the world, namely, the player stepping onto a puddle or an oil slick. We also need sprites that define how they should change the player movement when they are stepped over.

Below is a skeleton of one of my obstacle classes:

package sprites.obstacles {
	import org.flixel.FlxG;
	import org.flixel.FlxSprite;

	public class SpawnerObstacle extends FlxSprite {

		public function get playerVelocityFactor():Number { return 2; }

		[Embed(source="spawner.png")] private var SpawnerImg:Class;

		public function SpawnerObstacle(X:int=0, Y:int=0) {
			super(SpawnerImg, X, Y, true, false, 24, 24);

			this.fixed = true;
		}

	}
}

Here is just a simple implementation of a FlxSprite class where we define that this sprite, when stepped over, speeds up the player by a factor of 2.

Below are the relevant parts of the update() method in my main PlayState class.

this._player.velocityFactor = 1;
for each (sprite in this._obstacles) {
	if (this._player.overlaps(sprite)) {
		trace('modifying player velocity');
		this._player.velocityFactor = obstacle.playerVelocityFactor;
		break;
	}
}

Here we loop over the obstacle sprites in the _obstacles array. This array would be created whenever you initialize the obstacles for the game. The obstacles themselves, in this case, are instances like the above SpawnerObstacle class, which have a playerVelocityFactor getter attached. In the beginning, we make sure that we set the player’s velocityFactor to 1 so that the player moves at the default speed in the case that they are not on top of an obstacle sprite. We also break out of the loop when we collide with a single obstacle sprite to avoid any extra complexity. We could make it so that we average the velocity factors when multiple obstacle sprites are encountered, but I don’t have this use case so it would be unnecessary.

When all these parts are in place and working in conjunction, we have a game that satisfies our original goal. When the player collides with one of our obstacles sprites, he is either sped up or slowed down, depending on the velocity factor defined by the colliding sprite. If I get any less lazy (highly unlikely) I’ll post an example swf with source code.

Please take a moment to vote for Barbie to become a Computer Engineer. Future generations of computer engineers would really appreciate it if we could influence some girls to take up the profession.

So indeed, I did vote, and so should you….or else! From the Barbie site:

Computer engineers have lots of different specialties. They can do anything from building computers to making video games!

It’s true folks. Why would any young girl not want a computer engineer Barbie? It’s fun for the whole family! I certainly wish my toys could program an analog synthesizer.

Vote!

var bd:BitmapData = new BitmapData(w, h, true);

 
The third boolean argument to the function is a transparency flag, and here it is set to true. However, when creating a Bitmap object from this BitmapData object and adding it to the display list, it clearly has a white background instead of being transparent.
 
To remedy this, the solution is to pass along to the function a 32bit color value where the alpha value is zero. The following code illustrates this solution:

var bd:BitmapData = new BitmapData(w, h, true, 0x00000000);

 
This will create a totally transparent BitmapData object on which you can draw whatever you desire. In practice I use this to determine the alpha values of a given pixel in a given display object. The following function implements this technique:

public static function getAlphaAt(d:DisplayObject, x:Number, y:Number):Number {
	// Even though we set transparent to true, we still need to use a transparent color.
	// This is easily done by setting alpha to 0; the RGB octects after that don't matter.
	var bd:BitmapData = new BitmapData(d.width, d.height, true, 0x00000000);
	bd.draw(d);
	return (bd.getPixel32(x, y) >> 24 & 0xFF)/255;
}

public function scaleImageToMaxDimension(img:Image, maxWidth:Number, maxHeight:Number):void {
	var scaleH:Number=1, scaleV:Number=1;
	if (img.content.height > maxHeight) {
		scaleV = maxHeight / img.content.height;
	}
	if (img.content.width > maxWidth) {
		scaleH = maxWidth / img.width;
	}
	img.scaleX = img.scaleY = Math.min(scaleH, scaleV);
}

 
Flex doesn’t do a terribly good job of resizing images, however, but it works for images that just need to be tweaked to fit. If you have control over your images and your display size, it is always best to resize them as needed to save space/bandwidth and preserve quality. This approach works best when you have little or no control over either.

In application this code would be used after the image has finished loading. So for example I might do something like the following:

import flash.events.Event;
import mx.controls.Image;

public class Test {
	public var image:Image;

	// pretend scale function is here

	public function Test {
		image = new Image();
		image.addEventListener(Event.COMPLETE, imageComplete, false, 0, true);
		image.load('http://www.google.com/intl/en_ALL/images/logo.gif')
	}

	private function imageComplete(event:Event):void {
		scaleImageToMaxDimension(image, 100, 100);
	}
}