Drone Defence Postmortem

It is a new month so time for my postmortem of my Blazing Games release for this month. The game is my first game created with OpenFl which is the flash-like library for Haxe. I am not sure why I decided to try doing a similar game to what I did as my Game Maker test game, but I did. The game needs a lot of polish yet, but for the limited time I put into it worked out great.

What Went Right

OpenFL is a flash-like library for Haxe. While Haxe already supports the Flash API for projects exporting to Flash, OpenFL expands this to all the other platforms that programs can be exported to. At least in theory. As I have done a lot of work using the Flash API, this is a great feature for me as it makes getting up to speed with Haxe much easier. If you are not familiar with Flash, this is probably not that big of a deal but it is still a decent library. I have tried a number of different Flash-like libraries for a variety of languages to various results. This library, from what I did with it, worked exactly like I expected (at least until I exported for HTML5) which was nice considering the learning curve that Haxe gave me.

Mixed Blessings

Haxe is a rather interesting language as instead of compiling to machine-language (or a virtual machine-language) it compiles to a number of different programming languages for a variety of different platforms. The idea here is that different platforms have different key languages for development. Windows is C++, IOS/OSX was Objective-C, Android is Java, the internet is HTML5 or Flash. The idea here is that you code in Haxe then fine-tune for each platform in it’s preferred language. It is, however, it’s own language with it’s own way of doing things. While similar to ActionScript, it is different enough to occasionally throw a wrench in the works. One of the nice things it does, which I wish C and all its decedents did, is automatically break switch statements unless you explicitly tell it not to. One thing I didn’t like is the requirement of iterators in for loops.

What Went Wrong

Unfortunately, as is often the case with projects still in development, there are issues with OpenFL. In my case, the HitTestObject method did not work in the HTML5 export. As this is essentially just a bounding box test, I replaced my hit test code with calls to check for rectangle intersections between the bounding boxes for the objects. The problem here then became there always being a collision. After checking the results of the getBounds function, I discovered to my dismay that the width and height of the object were the canvas size and not the size of the sprites. Worse, requesting the width and height of the sprite also returned the canvas width and height. These bugs don’t exist in the other export formats I tried so I ended up releasing the Flash build of the game instead of a HTML5 build like I was originally planning to. I will have to look into this issue a bit more as I really liked OpenFL and think if issues like this can be fixed this would be a great platform to develop for.