As a huge fan of Canabalt, the giant "F" that shows up at the beginning of the game repeatedly reminds me about the existence of Adam Saltsman's (a.k.a. "Adam Atomic") Flixel. Flixel is Saltsman's game engine that powers the spritely, blitty, pixelly goodness behind Adam Atomic and Danny B's masterpiece of one-button parkour. I'm using "game engine" loosely; Flixel is better described as a collection of ActionScript 3 classes. However, the combination of all those classes aims to give a game programmer the ability to create 2D games very quickly, with some long-standard features like volume control, framerate meter, and game pausing available by default. It's also optimized for a certain type of 2D game currently popular among the indie game scene... chunky pixels, lots of filmstripped sprites, rectangular collision boxes.

The Flixel download is just a zip file with an MIT license and uncompiled ActionScript 3 files. This suggests that if Saltsman's code does something you need done differently, you really could just go into the source and change it, which is comforting. I'm using Flex 3, Adobe's IDE and compiler for ActionScript projects, although you can apparently use FlashDevelop or mxmlc instead. I'm hoping to move my experiments to an automated build machine in the near future, so finding that the Flixel wiki features well-written tutorials on how to get started on all of these environments is a huge bonus.

One trick is that all the tutorials in the Wiki appear to be written by different people. This means that the tutorials all feature subtly different coding styles. Some aggressively choose to import all of Flixel's classes, fit the Actionscript files into a larger file structure, and override his methods by default. Saltsman's own step-by-step instructions takes a more conservative, change-only-what-needs-changing approach to Flixel, seemingly happy with many of the default behaviors in his base engine. It's nice to have different approaches to the same problem, but it takes a little effort to identify functional differences in the code examples that could produce different behavior, and purely stylistic deviations that work fine either way.

Figuring out how I should organize the Flixel files with respect to my own source files takes me the most time. Every tutorial has a different recommendation... some suggest creating a "com" directory for your source files and Flixel in an "org" directory inside "com". Some prefer to use the Flex Builder default of putting your project and Flixel as equal partners in your Documents folder. Knowing that I'm going to check everything into Perforce as soon as I get a clean build, I want it in my local Perforce workspace directory tree instead. I finally find a solution that I'm happy with: A HelloWorld project directory (created by Flex) next to a flixel directory, which holds the contents of the full Flixel download, complete with license text. (Note: This does create two nested directories called "flixel": e.g. [workspace tree]/flixel/org/flixel/data/FlxAnim.as) This should make it really easy for me to update Flixel when Adam releases new versions.

Two hours in and I'm switching game states, throwing text on the screen to tell me whether it's working. Part of my slow progress is due to the fact that I'm pretty much new to AS3; I had only worked with AS2 in the past, so I'm learning as I go. The Flixel wiki directs me to other sites that provide beginners' introductions to AS3, but I feel relatively confident in my ability to pick it up from the Flixel examples alone. (And what I can't figure out, I can ask Drew!) The other reason for the slowdown is that I'm insisting on typing everything in, without copying-and-pasting code from the tutorials. I feel I might miss a nuance or important step that I may have to repeat in the future.

I'm noticing that many of the Flixel tutorials (I should really just stick to one!) refer to older versions of Flixel. Screenshots of sample output look subtly different from mine, hinting that Flixel is actually a rather mature batch of code. It puts a little speedbump in reusing sample code, but it does boost my confidence in Flixel's robustness. Saltsman has tested, tweaked, and found better ways of doing things since its early days. For the record, I'm using version 1.45.

In fact, some tutorials describe getting the Flixel files by pulling it out of the file hierarchy of mode, the sample Flixel game that showcases many of Flixel's features and Saltsman's monochromatic pixel art stylings. It's a pretty ruthless game... like Bangai-O without the offensive capability. (Hmm, adding self-guided missiles or bouncing projectiles to mode seems like a decent weekend project.)

mode ate up quite a bit of time, though, so I'm wrapping up my initial exploration into Flixel after two hours and checking everything into Perforce. I've succeeded in making a Hello World that kills the player. Now to give the player a chance.