It hasn’t been an especially productive month for the project, but things are grinding forward. I decided I was still dissatisfied with the performance, even after all the improvements I made to the particle system a year or so ago, and so I’m working on getting the project running in OpenFL, an open-source project that emulates Flash/AIR’s API but builds in C++ and tends to be faster. This isn’t really a smooth process, since there are a few Flash features that didn’t get ported and the ways file i/o and multi-threading are approached are very different. The file system stuff is no big deal, and I believe I’ve fixed the issues emerging from that already, though since I’m still working on the other stuff I haven’t been able to build the game to test those fixes yet. The multi-threading thing is more difficult but I think I’ve got a handle on it now, and the challenging part is mostly sequestering my Flash multi-threading code away so that I can write the special cases that change from platform to platform without turning everything into a total spaghetti mess. The features that aren’t supported… might be an issue. The only one I’ve found so far that looks like a big deal is that OpenFL currently has no equivalent of the DisplacementMapFilter, the processing effect which I used to make that water effect I was so proud of and which I also would like to use for a few other special effects. I’m going to have to look into creating a replacement – which sucks, but might end up being a blessing in disguise, since this will be a fairly natural way to explore the wide worlds of shader programming and, indeed, of contributing to open source projects if my solution ends up being of sufficient quality to submit as an OpenFL component.
Aside from this, I mostly worked on building the behaviors for the Feral enemy type which I shared a few sprites for last week. These behaviors are mostly finished now, but haven’t been tested yet since I didn’t have a complete set of sprites to test with – not strictly necessary, but since most of the code is reused from existing enemy types I’m not worried about any major malfunctions. I also realized a substantial obstacle towards completing the first area of the game was that I just wasn’t really sure what the space was supposed to look like. I had some vague ideas, but I didn’t know what the area’s history was supposed to be, what really was going on there now, or what the symbolism of it was. I spent a bit of time writing out some notes on it, and I’m confident that when I get the game working again and return to develop this area I’ll have a lot to work with.
My work is basically cut out for me now. Get the game building in OpenFL, handle any new bugs, rewrite the display code as necessary to take advantage of the improved performance. It’s always a bit of a drag getting railroaded into one big task that has to be done before I can make more substantial progress, but in this case there’s no way around it – particular as, in the interim, something weird has happened with my development environment to make launching the AIR version seemingly impossible. While I’m sure that will all get ironed out eventually, in the meanwhile it leaves me no avenue to working on the AIR version of the game, so really all I can do is drill in on the OpenFL port. Soon, at least, I’ll be able to take advantage of this tedious chore to tackle a field of programming I’ve been wanting to study for a while: Shaders.