Cross-posted on FortressOfDoors, my personal blog.

I've been a stalwart Flash developer for 15 years, so nothing bothers me more than greatly exaggerated reports of Flash's premature demise. Even today, Flash remains a very viable platform with a large install base and a relatively healthy commercial ecosystem. Many awesome games have been written in Flash and/or Adobe AIR, including our own Defender's Quest, which to date has sold over 125,000 copies.

But even a long-time Flash booster like myself can read the signs of the time. Flash may not be dead, but it is certainly dying, and the killer is not Steve Jobs, mobile devices, or HTML5, but Adobe. They are slowly neglecting Flash to death.



They dropped support for the mobile flash player as well as AIR on Linux, handed Flex over to Apache, and cancelled the long-awaited ActionScript 4 standard. Although right this minute the flash player still has a big install base, and AIR remains a great way to reach mobile devices, there's no signs of strong future support. Flash just doesn't seem like a priority for Adobe any more. And MochiMedia's recent shutdown is the canary in the coal mine. As a developer, I don't give a damn whether this is a good financial decision for Adobe -- they yanked the rug out from under me after 15 years of loyal support. "Sorry you invested in our platform and tools, you suckers! But hey, you can totally trust us to support you next time! Subscribe to Creative Cloud!"



So where do we go from here? Unity3D is a popular answer, but it's got major downsides - I have to pay for each platform I want to support, and the web browser target depends on a clunky plugin with a low install base. But worst of all, it's just another proprietary platform. Sure, Unity is the bee's knees now, but who's to say it'll always be that way? Just ask all the loyal XNA developers who Microsoft left hanging out to dry. And if there's a bug or missing feature, I have to wait for Unity to get around to fixing it. This works for some people -- and I wish them all the best -- but it's just not for me.



I've learned my lesson -- whatever my next platform is, no-one should be able to take it away from me.



I could try HTML5, but that precludes releasing high-performance desktop-ready games for Steam.



I could try going with a custom engine in raw C++, or something like Java or C#, but it'll be a lot of manual work to get true cross-platform support, especially if I want a unified code base to compile it all from.



I need something open-source, so I don't have to wait months or years for basic features or bugfixes. And shucks, it'd be nice to have the same API as Flash so porting my old code isn't a nightmare.



What's that you say? This magical chocolate pony of dreams exists? Why yes, it's called OpenFL!

OpenFL is an implementation of the Flash API written in the Haxe programming language. Never heard of it? Maybe you've heard of a certain BAFTA-award-winning game that makes use of it:





Basically, you write your code in Haxe, then you link against the OpenFL library to get the functionality of the Flash API. This means:



You just keep making flash games, but you also get mac, windows, linux, and mobile targets, all at native speed!



Even better, you can keep using a lot of the same tools. The FlashDevelop IDE, very popular with Actionscript coders, has excellent support for Haxe. "Fine, fine, I can port my code over easily enough. But what about all my flash art stuff?" Not to worry - you can keep using the Flash authoring tool and its native flash vector animations if you like. That's because OpenFL recently released their swf library for free, which lets you use SWF animations and assets in both your flash and C++ targets.



Don't believe me?

That's an animated gif recording of a C++ build I made in Haxe/OpenFL about 20 minutes ago.

Here it is in flash SWF format

Here is is in windows EXE format





Many of you might have heard of Haxe and/or OpenFL before, and I admit it can be really confusing to get started, so let me break everything down real easy. Here's the original source code Many of you might have heard of Haxe and/or OpenFL before, and I admit it can be really confusing to get started, so let me break everything down real easy.

Our particular tech stack for Defender's Quest II: Mist of Ruin looks like this, with the highest-level abstractions on top, and lowest-level stuff on bottom:

(Don't try googling TD-RPG, that's my own proprietary engine. The rest of it is all online and free, though!)

Haxe - the language layer

At the very bottom you have Haxe itself, the language you're using to write code in. Basically, you write code in Haxe, and the special Haxe compiler turns your high-level Haxe code into source code from other languages depending on what flags you pass in. Using Haxe by itself requires little more than a command line and a text editor.





I should mention that I'm simplifying things a bit here. Before we get to lime/OpenFL, there's some crazy magical bootstrapping that happens in the background, with the Haxe compiler using the hxlibc and/or hxcpp libraries, but I'm trying to make this as friendly as possible for newcomers without getting lost in all the details. Just keep in mind that I'm giving you a broad-strokes overview. You can certainly write cross-platform games using nothing but Haxe, but that's kind of hard-core. The haxe compiler will just spit out a bunch of c++ code, or javascript, or whatever, which for idiots like me isn't very useful. This is where OpenFL and lime come in.

Lime - low-level graphics layer One step up from bare-metal haxe programming is lime, which stands for "Lightweight Media Engine." Lime is part of the OpenFL project, and provides a simple, lightweight, and cross-platform drawing API. This handles things like windowing, asset loading, blitting pixels, drawing routines, and interfacing with OpenGL, OpenGL ES, and SDL stuff.



Also, lime makes cross-platform support a bit easier. Whereas Haxe has output targets like "c++", "javascript", "c#", etc, lime has output targets like "mac", "windows", "linux", "android", "ios", and so forth. Mac, Windows, and Linux targets all use C++ code, but they need special tweaks to properly handle file i/o, windowing, etc. The Haxe compiler and hxlibc/hxcpp libraries bootstrap your native targets, and lime sets up all the input/output/display boilerplate for you.



You can totally make games just with lime, without ever touching OpenFL. In fact, having lime as a separate library is a recent development -- before all of those routines were just part of OpenFL. This caused two problems: OpenFL had a lot of boilerplate stuff that wasn't related to the Flash API, which was confusing Some Haxe developers wanted cross-platform support, but didn't want the Flash API Splitting lime off into its own lower-level thing solved both problems. Now all the basic drawing guts are in lime, and if you hate the Flash API and wish it would to die in a fire, you never have to touch it -- just use lime and be happy!

OpenFL - high-level graphics layer + Flash API On top of lime is OpenFL itself. Here we have higher-level graphics calls, with abstraction layers and a flash-style display list. In fact, we even have the same package structure. In Flash Actionscript, you could always do stuff like this:



import flash.display.Sprite;

var mySprite:Sprite = new Sprite();

addChild(mySprite);



In OpenFL, you can do the same exact thing. Sprites, MovieClips, the display list, the stage, events, etc, are all handled just like in Flash.



Some minor differences include audio -- it works fine on different platforms, but since OpenFL is a fully open-source project, they can't cover the



One thing to drive home -- if you use OpenFL, you can create exactly the same flash content you can create right now in ActionScript. That's because in the Flash target, you're making an actual swf file, and all you have to do to access the Flash API is use it -- the flash player has all that functionality built-in. On native targets, the OpenFL developers had to actually re-build the same functionality with C++ code, etc. So far there's feature parity for pretty much everything except for some of the less-common features (filters and shaders, as well as right-to-left font support for Hebrew/Arabic text, for instance). It's open-source of course, so those little gaps can always be filled later. At the moment, mirroring the Stage3D API on non-flash targets requires some special libraries, and there are many alternative 3D engines for Haxe (see below).



OpenFL also tacks on a few quality-of-life features that the Flash pipeline doesn't have. Chiefly, asset libraries. In the old days, if I wanted to embed audio or image assets into my swf file, I had to add them all line by line, and set up individual class names to instantiate them with in my code. With OpenFL, thanks to the crazy black magic of



var image = Assets.getBitmapData("filename.png"); One step up from bare-metal haxe programming is lime, which stands for "Lightweight Media Engine." Lime is part of the OpenFL project, and provides a simple, lightweight, and cross-platform drawing API. This handles things like windowing, asset loading, blitting pixels, drawing routines, and interfacing with OpenGL, OpenGL ES, and SDL stuff.Also, lime makes cross-platform support a bit easier. Whereas Haxe has output targets like "c++", "javascript", "c#", etc, lime has output targets like "mac", "windows", "linux", "android", "ios", and so forth. Mac, Windows, and Linux targets all use C++ code, but they need special tweaks to properly handle file i/o, windowing, etc. The Haxe compiler and hxlibc/hxcpp libraries bootstrap your native targets, and lime sets up all the input/output/display boilerplate for you.You can totally make games just with lime, without ever touching OpenFL. In fact, having lime as a separate library is a recent development -- before all of those routines were just part of OpenFL. This caused two problems:Splitting lime off into its own lower-level thing solved both problems. Now all the basic drawing guts are in lime, and if you hate the Flash API and wish it would to die in a fire, you never have to touch it -- just use lime and be happy!On top of lime is OpenFL itself. Here we have higher-level graphics calls, with abstraction layers and a flash-style display list. In fact, we even have the same package structure. In Flash Actionscript, you could always do stuff like this:In OpenFL, you can do the same exact thing. Sprites, MovieClips, the display list, the stage, events, etc, are all handled just like in Flash.Some minor differences include audio -- it works fine on different platforms, but since OpenFL is a fully open-source project, they can't cover the draconian world of mp3 licensing the way Adobe can, so mp3 playback only works on flash target. For everything else, you use ogg or wav files. In my experience, this isn't a huge downside since I really hate the limitations of the mp3 format (every Flash dev who's ever tried to get seamless mp3 looping to work knows what I'm talking about!)One thing to drive home -- if you use OpenFL, you can createthe same flash content you can create right now in ActionScript. That's because in the Flash target, you're making an actual swf file, and all you have to do to access the Flash API is-- the flash player has all that functionality built-in. On native targets, the OpenFL developers had to actually re-build the same functionality with C++ code, etc. So far there's feature parity for pretty much everything except for some of the less-common features (filters and shaders, as well as right-to-left font support for Hebrew/Arabic text, for instance). It's open-source of course, so those little gaps can always be filled later. At the moment, mirroring the Stage3D API on non-flash targets requires some special libraries, and there are many alternative 3D engines for Haxe (see below).OpenFL also tacks on a few quality-of-life features that the Flash pipelinehave. Chiefly, asset libraries. In the old days, if I wanted to embed audio or image assets into my swf file, I had to add them all line by line, and set up individual class names to instantiate them with in my code. With OpenFL, thanks to the crazy black magic of Haxe Macros , OpenFL scans your game's asset folder at compile time and automatically generates all the necessary embedding boilerplate. All you have to do is put assets in the folder, then fetch by filename with one line of code:



Whereas embedding hundreds of images in Flash games is a huge chore, in OpenFL it's as easy as hitting "compile!"



Server-Side Fun



Whether you use OpenFL or note, Haxe has one last really cool trick up its sleeve - server-side code. Haxe code targets include PHP, Java, JavaScript, C++, and Neko. All of these can be used for server-side code. A common problem in game development is having to write your gameplay code twice -- once for the client, and once for the server, so you can do proper client-side prediction (or whatever). This usually means writing in two different languages, one optimized for desktop, and one optimized for the server, which can be a nightmare keeping them coordinated.

and the server. Or... you could just use Haxe, and output whatever pair of client/server languages you happen to need. That way, when you update or bugfix your Haxe code, the changes can propagate to both the clientthe server. This is exactly what Proletariat Sloth did in their game World Zombination . Even crazier, in the process they created a Haxe-->Unity library called HUGS (Haxe + Unity Glue... Stuff!)

Signing Off

Okay that's what Haxe/OpenFL is and why it's cool. If you think it's cool you should check it out.



The end.

Thanks to these fine folks for providing useful information:

Joshua Granick, Nicolas Cannasse, Hugh Sanderson, Nilsen Filc, Bruno Garcia, Jesse Kurlancheek, Philippe Elsass, Damjan Cvetko.

Haxe, OpenFL, HaxeFlixel, HaxePunk, and Flambe communities.

(And anyone I left out)