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.
2 hours later
Whoa, Saltsman updated Flixel already? That's surprising. Integrating his latest changes breaks the background-color functionality in my code. It takes me a long time to figure out what happened, and why he'd want to do that. It does give me a good reason to peruse his github and read his release notes. Apparently there's some new pre-processing and post-processing functionality in Flixel 1.45 (e.g. for blurs, bloom) but that mandated a different way of treating background colors. You couldn't just set the Flash file to have a fixed color and give every FlxState a transparent background, for instance. In the last couple of hours, Saltsman added a bug fix that set the initial background color of FlxState to opaque black, so even though the SWF is supposed to be blue, Flixel draws black on top of that.
Understanding this sheds some new light on directory structure. If Flixel changes this rapidly, I can imagine an old project breaking severely with every new release. That's okay for a project in progress, since you're assumedly reaping the benefits of bugfixes and new features at the same time. However, if Saltsman is going to be touching Flixel every couple of days, sharing a Flixel directory for all Flixel-based projects, old or new, is a bad idea. Giving Flixel its own "org" subdirectory for every project seems to be the way to go.
Still, that's two hours lost just trying to understand why he made the change. On the plus side, I have a much better idea of how FlxGame and FlxState operate now, since I had to dig into his changelogs. (Flixel used to have a setBackgroundColor method. Now you just change a static variable called bgColor.) On the minus side, this forces the Flixel logo to have a black background, since I don't get to touch bgColor until the logo disappears. This makes it more likely that I'd remove the logo entirely (black backgrounds may not be appropriate with the aesthetic of whatever game I'm making) or manually editing FlxState's default background color for every Flixel game I make. The latter seems kludgey to me, and makes it harder for me to integrate new updates of Flixel.