What follows is technical mumbo-jumbo for licensed geeks. Meanwhile, the rest of you could play our beta! :-)
Technically, our game Together Alone has a bit of a weird history. “Normal” casual/web games usually start out as Flash. Then, if the game is succesful and the creator wants to target multiple platforms, she may port it to Haxe/NME. The language Haxe is very similar to ActionScript and NME reimplements the Flash API, so porting is relatively easy. Together, Haxe and NME allow you to target not only Flash but also HTML5, Windows, Mac, iOS or Android.
However, we started with a HTML5 game, mainly because I didn’t know Flash at the time and was interested to see how much of the HTML5 hype was true. Turns out, quite a lot, but not all of it. Yes, it’s pretty amazing what you can do in a plain old web browser these days (Mozilla recently issued some impressive WebGL demos, for example), but getting your game to run smoothly (in all browsers) is still a royal PITA, mainly because of garbage collection pauses. I’m sure it will continue to get better though.
So, I decided to go with Haxe and NME, for maximum platform-agnosticism. As I said, I did not have any experience developing with Flash, so I had to learn both Haxe and the Flash API. Haxe is documented pretty well. The NME site has some nice tutorials and samples to get you started. Of course, it’s basically the Flash API, so for reference documentation and other stuff, there’s heaps of information available on the web as well – just search for “ActionScript <classname>”, for example. Adobe’s official AS3 book helped me a lot too. All in all, finding information was not a problem for this project.
The first is not that hard, but a bit of work. You need a good text editor with regular expression search and replace, or a full-fledged IDE (FlashDevelop is highly recommended: Haxe is supported) with same. Search and replace will help a lot, but it can’t do everything.
The other big thing was going from canvas to the Flash API. This can be quite a lot of work, depending on how you work with canvas. I think many people use canvas in ‘immediate mode’: they have a render function that’s called every frame and explicitly draws each object. Flash is more a ‘retained mode’ library: you tell it what configuration of objects you want, where you want them, if you want translucency, rotation, etc. and Flash manages and draws all those objects for you. In other words, it’s more like the HTML DOM than like a big canvas you explicitly draw on. Fortunately, I already built a simple version of this ‘retained mode’ approach for the HTML5 canvas, so for our game the switch was not as big as it could have been, but this is definitely a different way of thinking about how your game is rendered.
Haxe/NME delivers on its cross-platform promise for, say, about 95%. You will always run into some slight differences between the HTML5 target, the Flash target, and the native targets. Of course, this means at some point you’ll have to start debugging generated code, which is a concept with high nightmare-potential. But in this case, it’s not that bad actually. The Flash target you can simply debug as normal in FlashDevelop (stepping through your Haxe code while the Flash runtime is executing it), and the code generated for the HTML5 and C++ targets, while not particularly pretty, is easy to match up to your Haxe original, so you won’t get lost in an unintelligable sea of spaghetti.
The port is now done and the game is running great under Flash. The Windows target is pretty close behind, but the HTML5 target still needs work to get the game to run perfectly. That’ll take some fiddling, but I’m sure I’ll figure it out.
Trackback from your site.