One step forward, two steps back (at the same time)
Today’s post on the spaceship game (which already has a name but I’m keeping it under wraps for now) is on porting. After numerous run-ins with HaxeFlixel, I decided to port the game to Cocos2d-HTML5 (aka Cocos2d-JS). I’m unconvinced by the state of JS game engines for the web, but if I want the spaceship game to be available on web-browsers, I need to compile for web as well.
So, as we leave HaxeFlixel for greener pastures (actually, the complete oposite…) let’s analyze why I went with it in the first place:
Fast
HaxeFlixel is a really good engine for prototyping. It’s very simple to instantiate sprites and move them around the screen as well as detecting collisions, keyboard events and movement.
Flash
Despite having it’s flaws, Flash is still the best “build once, deploy on any webbrowser” option (maybe Java applets are better, but there isn’t much development on multimedia for these). Flash objects also are self contained and make (somewhat) more difficult for others to steal your code.
Haxe
Haxe is a multiplatform wonder programming language. It’s the only one I know which will compile to C++, Javascript and PHP (among others) with the same code base (although your app might not be suited for these). Not only that, but Haxelib is a huge repository of addons made and maintained by the community, making adding functionality a simple task.
Now… why not HaxeFlixel?
Maturity
HaxeFlixel is based off of Flixel, a really old AS3 game engine. And it copies all of it’s functionality perfectly. Unfortunately, this works only on Flash. For Mobile targets, not so much. And this extends to the “official” addons: Flixel-UI can’t compile on mobile unless you leave mouse defines enabled. And on Neko (the VM-Desktop-Like target), it won’t work correctly.
Debugging
When compiling for Flash, things usually go without a hiccup (all gifs uploaded where compiled and run on the Flash Debugger)- but when exporting to neko (when not using Flixel-UI) errors started to pop up and traces where less than ideal. On mobile, these where non existing. This makes fixing a simple error take a whole day or a week. And to rely on printf debugging techniques.
Haxe
It’s amazing that a language can be used for so many platforms without changing the codebase. However, the antics of the compiler wizards makes it so that when things go south, you have no clue of how it was “translated”. My worst nightmare was being unable to find a variable that was initialized, but HaxeFlixel on Android didn’t like it initialized in the declaration (Flash, as you can imagine, didn’t complain at all).
So after spending two weeks with minor bugs, I decided to move on and switch the engine. Don’t get me wrong, Haxe is an amazing language. I really like what they are doing with it and can deploy to mobile, web, js, flash and console natively. I want it to progress.
But right now it lacks support. There are other engines, but most are developed by a small number of people. And all of them suffer from the maturity issue, be it they by lacking features or platform specific problems.
So I’m left with two options: Go for a JS engine or have two different code bases.
Having two different code bases
No. Beats the purpose of the experiment.
JS Engine
Meh… Yuck… Javascript. But doesn’t seem like I have much of an option. Well actually…
Unity
Unity is cool and all, but I don’t like how the scenes are handled. I don’t like dragging and dropping elements rather than coding them, but I can see a lot of cases where this makes sense. Unity is also a CRAZY mature engine, with a huge developer base AND user base, market addons (and so on… The market place is AMAZING).
So why Cocos2d-HTML5 and not another one? Since I’m porting and basically throwing away a lot of work, I rather go with an Engine that I know well (or has the most similarities with one I know). Cocos2d-HTML5 also has Javascript Bindings, which make it so that when you compile to mobile and desktop, the core runs as native. As long as you don’t have expensive logic, it should improve performance a lot vs non-native frameworks.
And last, but not least, Cocos2d-JS (like any other multiplatform engine) has things that will work on a platform and yet crash on another. But it has a ton of asserts and error messages (albeit some cryptic ones). It also lets you keep the XCode and Android project (unlike Haxe which would just tear it down on every compile): this is useful if you want to add your libraries as well (or say, Crashlytics).
Yesterday I did a simple test on mobile and went rather good, so I’m hoping it won’t take me as long to get to the current state of the game. I’m working part time, so I can’t spend as much time tho.
