Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases
September 1, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Flash is dead, long live OpenFL!
by Lars Doucet on 03/18/14 12:26:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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:
 

<a class=


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.
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. 
 
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.

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.
 

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:
  1. OpenFL had a lot of boilerplate stuff that wasn't related to the Flash API, which was confusing
  2. 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 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 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 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:

var image = Assets.getBitmapData("filename.png");       

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


Many game developers will want to stop at this layer -- at the OpenFL stage, you have the same amount of functionality as you'd have using the FlexSDK to make a flash game. But some of us like fancy game frameworks like Flixel, FlashPunk, and Starling that handle cool stuff like collisions, states, controls, cameras, etc. These and many others have been ported to Haxe as HaxeFlixel, HaxePunk, and HaxeStarling.

HaxeFlixel (my personal favorite), is the most popular, and I can't recommend it highly enough. The others I've never used so I can't vouch for them directly, but I have heard many good things about HaxePunk.

 

HaxeFlixel - game framework layer

HaxeFlixel is the Haxe project that I use most. Not only is it the #1 most-starred Haxe repo on all of github, it's simple, easy-to-use, and comes chock-full-of documentation and examples. Contrary to what many of the pixel-tastic example games might imply, it handles HD-style graphics just fine.

HaxeFlixel has built-in support Nape Physics, Gamepad support, Collision & Grouping, Cameras, Tweening, User Interface, and much more! Some of these features (physics, gamepad, etc) come from separate libraries (Nape) or emanate from lime/OpenFL (Gamepads), but HaxeFlixel wraps them up and makes them easy to use in games. Do keep in mind all those web demos use the flash target -- the native targets are so much faster.

Obviously, I'm biased since I'm now part of the core HaxeFlixel team --  I maintain the flixel-ui and flixel-editors add-on repositories.  Some other Haxe projects I've contributed to include my open-source localization framework firetongue (as seen at GDC 2014 localization summit!), and my economic simulator, bazaarBot.

If you want to get started making a nice 2D game in Haxe right now, and you want to deploy to Flash, Mac/Windows/Linux, Android, iOS, or OUYA, HaxeFlixel has got your back.

 

What about HTML5?

So, HTML5 is a buzzword these days -- how does Haxe/OpenFL stack up in that regards?

Well, at the lowest level you can just write JavaScript in Haxe, and it will generate JS just fine, with the added benefit of enforcing type-safety and other niceties that make JavaScript development more palatable.

If you don't want to reinvent the wheel, you can use OpenFL. Now, OpenFL's HTML5 target, as of this writing, is the least mature of all its supported platforms. However, it's been getting a lot of love recently and in the last few weeks has made some amazing strides. I predict we'll have a fully mature HTML5 target very soon.

How cool will it be when you can natively compile your game not just for mac/windows/linux, iOS, Android, and flash, but ALSO HTML5, all from the same source code base?

UPDATE:
Just a few hours after I posted this, OpenFL just posted this on their website:
Flash AND HTML5, Unicorns exist!

Nice!

What about consoles?

Okay, so Haxe/OpenFL can target all these amazing platforms. What about consoles?

First of all, Haxe/OpenFL already has great support for the first wave of "Microconsoles," such as the OUYA, Gamestick, Nvidia Shield, MOJO, etc. Also, Grapefrukt Games' Rymdkapsel uses Haxe/OpenFL and some crazy black magic to somehow run on a PlayStation Vita. As for Valve's Steam Machines, those run SteamOS, which is just linux, so that's already in the bag.  Theoretically, there's no reason the community couldn't get Haxe up and running on any arbitrary platform, even your toaster. Heck, it's already running on a Raspberry Pi!

"Fine, fine, fine, but what about Next-Gen Consoles!?"

In practice, adding support for tightly-controlled proprietary consoles is tricky -- the biggest problem being the "NDA veil." The good thing is the whole Haxe/OpenFL stack is MIT-licensed, so there's no skittishness from console partners the way there is with GPL code. However, if OpenFL were to build a, say, native PS4 target, any proprietary bits could only be shared with other developers also under NDA's, which makes code hosting and collaboration difficult -- you can't just stick it on a public Github repo. There's currently a lot of community interest in WiiU, 3DS, PS4, and PSVita, but this will probably take some time (and paperwork!).

I think we will eventually make headway here as Haxe/OpenFL continues to gain adoption, but in the meantime we have an unexpected secret weapon:

 HTML5.

It's public knowledge that the WiiU has Nintendo Web Framework, a first-class HTML5 target for making games and apps.  It's also public knowledge that the PS4 uses WebGL and HTML5, though I don't know if any games actually use it just yet. And I've heard credible rumors that XBOX One might eventually have the same functionality -- it's in IE 11, after all, and they pushed it hard on their phones and tablets.

Based on some preliminary results, openfl-html5 has been able to push a pretty large amount of 2D sprites in HD resolutions when running on PC web browsers. That's more than enough for a 2D game like Defender's Quest, and it seems like a good way to get our foot in the door. Native console development would be way more powerful (and way more expensive) but if we don't need the horsepower, why not take the easy road for now?

Even better, on consoles, one of the big limitations of HTML5 goes away - cross-browser compatibility. Whatever HTML5 support they have on a console is a non-moving target, so you can just create a specific configuration optimized for Nintendo Web Framework, and whatever hypothetical things Sony and MS may or may not announce.

There's also another alternative HTML5 backend in the works, openfl-bitfive, which seems promising and should let us do similar things.

 

Limitations

Okay, so what's the catch? Haxe/OpenFL can't be all roses and sunshine, right? I'd be remiss not to mention some of the downsides.

Documentation is a bit thin
Haxe hasn't been well documented in the past. The community is steadily improving this, but the go-to way to learn Haxe still remains: "Find someone who knows Haxe and ask them lots of questions." Now that we've finally got actual organizations like the Haxe Foundation and OpenFL Technologies driving things forward, things are gradually getting better.

Here's some good starting points:
Haxe Reference Guide 
Haxe Manual (Work In Progress)
Haxe API
OpenFL's getting started guide
HaxeFlixel's getting started guide

One thing to keep in mind is that the OpenFL API mirrors the Flash API -- so 90% of the time, you can just use the Flash API docs and the behavior should be the same. This isn't a perfect replacement for in-house docs, but it's still quite handy.

Also, I highly recommend looking at code samples. HaxeFlixel in particular has a large demo section, all with code samples and links to the relevant Github pages.

The best way to learn Haxe is to get involved with the community. There's a lot of really smart people there, even if it's a bit small. The best places to find Haxers:

#haxe IRC channel on freenode
Haxe forums
OpenFL forums
#haxe and #openfl tags on twitter
Haxe Foundation on Github
OpenFL Technologies, LLC on Github
Haxe and OpenFL google+ communities

Open Source Be Crazy
You can get by just fine by using only the latest releases of OpenFL and Flixel, etc, but if you really want to dive deep you have to learn how to work with the flow of Open Source development. This means getting friendly with Git and Github, and interacting with people in the community. You'll want to get really good at using the "haxelib" tool that serves as a sort-of package manager for haxe libraries. It's crazy powerful, but it's not as simple as just opening Unity or GameMaker and having your legos all in one box.

Haxe Doesn't Hold Your Hand
One of the chief draws of GameMaker, Unity, and Flash (back in the day) is that they're easy to get started with, well-documented, and come in one monolithic box. Haxe is more of a constellation of little tools all working together, not unlike Git. It's fiddly, and it's not intuitive from the get-go. We're getting better at improving the early-user experience, but I'm not going to lie to you -- if you want to get started with Haxe, find someone who knows it already.

It's Not Magic
This is the most important caveat. Haxe/OpenFL is not some magical pixie dust you can sprinkle over your code and have everything Just Work on every platform. There are minor differences in visual output between C++ and flash targets, for instance ((the exact way rounded rectangles rasterize, etc).

Furthermore, you need to know where and how the abstractions leak, and shift your mindset to the meta-programming model. Most of you probably won't have to ever roll up your sleeves and add raw C++ code to one of OpenFL's native backends, but it's definitely possible. You also need to learn the subtle differences between the targets. It's also advisable to get good at understanding how haxe generates code for different platforms. That said, as long as you don't overload on premature optimization, you should mostly be fine.

The easiest way to start is to just use Haxe to keep making flash games -- that requires *very* little additional effort, and it will get you the same exact results as coding in ActionScript. You can even package swf files created in Haxe as AIR games if you want! (That's what Monster Loves You! did -- it's written in haxe, compiled to SWF, packaged in AIR).

C++ Debugging is still a WIP
Technically, nothing's stopping you from running a command-line debugger like gdb on the generated C++ code Haxe outputs, or trying to run it inside Visual Studio, but that's not exactly easy. You can, however, very easily use an IDE like FlashDevelop to debug your flash code, and if there's an error on flash, there will likely be an error in the other targets as well. That said, we really want 1st-class, integrated, easy-to-use, FlashDevelop-supported debugging for C++ targets.

Don't worry, it's coming:
 


That's a screenshot I took the other day of native Haxe C++ debugging in FlashDevelop. It's an experimental feature for now, but hopefully it will be ready for release soon.

To be clear, you really pretty much *never* need to directly touch your C++ code. The feature I'm alluding to above is being able to step through your original Haxe code line-by-line while running your generated C++ program in debug mode, to see where the errors are in your original source. And we're almost there!

Other Important things of Note

There's a bunch of other little things I want to mention before we go.

What's NME? What's Neko?

If you've looked into Haxe/OpenFL before, you've probably heard about "NME" and "Neko" and wondering what those are. First of all, Neko is Haxe's own interpreted virtual machine, not unlike the Java VM or the Flash player; Haxe can output to Neko bytecode that will run in the Neko VM. Entry-level haxe developers can safely ignore Neko -- it's a cool little cross-platform VM, but it's usefulness is mostly relegated to command-line tools, server-side programming, etc. I will mention one useful fact -- Neko uses the exact same rendering logic as the C++ targets, but compiles much, much, faster, so it's useful for testing your C++ visuals when you're impatient.
 
NME, which you'll see tons of references to still, is the predecessor to OpenFL. Basically, NME was created back in the day, then it got re-branded as OpenFL, then lime was spun off of OpenFL, and for a while NME was basically obsolete. Now that OpenFL has taken over NME's original mission of mirroring the Flash API, NME's original creator has revived the project to take it in another direction. 
 
Confusing, I know. Basically, NME gave birth to OpenFL, OpenFL took over the Flash API business, and now NME has slimmed down into something very similar to lime that is now forking off to do its own, different thing.

What's Flambe?

 
 

I'd be remiss if I didn't quickly mention Flambe. Flambe is an alternative Haxe media engine to OpenFL/lime, with a focus on web and mobile. Its chief targets are Flash, HTML5, iOS, and Android, and also lets you you render SWF content in the non-flash targets. For its mobile targets, Flambe exports your game as a SWF uses Adobe AIR to package it.

Flambe has attracted a lot of attention from the commercial sector, notably from Nickelodeon and Disney. The top priority seems to be 1st-class HTML5 support across all platforms.

The biggest difference between OpenFL and Flambe seems to be that Flambe has more high-level stuff. So in Flambe-land, functionality that would normally be supplied by 3rd-party libraries like HaxeFlixel and HaxePunk in OpenFL-land, are built right into the core of Flambe.

Flambe is more monolithic, as it were. So if you're more of a "I want all my legos in one box" type person, check it out. Flambe also supports the new Firefox OS, and just hours ago OpenFL announced the same thing. Go Firefox!

Other Cool Stuff

OpenFL supports the new fully-open source Tizen mobile OS, which some are speculating might be replacing Android on mobile devices

There's also Reach3DX, from the creators of Gamebryo, which is built on the Haxe/OpenFL tech stack.

And if you're really interested in making 3D games with Haxe, you might be interested in these Haxe 3D libraries:

Away3D
BabylonHx
OpenFL-stage3d
H3D (as seen in Evoland)

Other miscellaneous tools include:

Spinehx (skeletal animations)
haxe-openfl-ffmpeg (playing video)

And much, much more!
 

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. 
 
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 client and the 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)

 


Related Jobs

InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[09.01.14]

Software Developer JavaScript (m/f)
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[09.01.14]

Backend Developer Marketing / CRM (m/f)
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[09.01.14]

Software Developer Flash (m/f)
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[09.01.14]

Mobile Developer iOS (m/f)






Comments


Nicolas Mommaerts
profile image
Nice article! I have been playing around with a few languages/platforms the last years in my spare time, I just started using HaxeFlixel (indeed, after reading about Haxe and Papers, Please), and so far it looks like I can finally settle on this platform. I haven't finished one game yet in all those years but maybe this time will be different ;)

Ryan Walker
profile image
Lar's whole premise for not using the industry standard HTML5 or WebGL doesn't make sense though - all you need is an excecutable to run on steam which open Node.js can fairly easily provide. Look - HTML5 Game Dev Tycoons already provided it and is on steam

https://github.com/greenheartgames/greenworks

Lars Doucet
profile image
That's a great technology, and I'm glad it exists. I stand corrected about HTML5 not being deployable as an executable. It does not, however, address these specific niches:

1) People who are already using the Flash workflow and don't want to throw away 10+ years of experience and start from scratch

2) People who want to use HTML5 but want to write in a statically typed language

3) People who want to target HTML5 (javascript) platforms, but also other platforms, that require/enforce a specific language, all from the same high-level language. Node.js doesn't run on everything. (Though as you pointed out, I suppose it would be a decent solution for steam.)

4) People who don't want to be locked into a specific platform when the tides inevitably shift to whatever-the-next-hot-thing is. Haxe can output to any other language (in theory) and indeed many new targets have been added since it was first created.

There's also no reason you couldn't write in Haxe to get static typing and then use Node.js as your deployment strategy.

E Zachary Knight
profile image
This is great write-up and primer on what to expect from Haxe. I have been using it for a while now and am using it exclusively as I make one game a month this year. Haxe and all its libraries are a great way to quickly prototype a game idea out and then flesh the game out at a later date. The ease of adding global information, images, sounds etc is awesome.

I honestly can't see myself using anything else at least until I maybe one day possibly start doing work on proprietary console platforms.

Christian Kulenkampff
profile image
Thank you for the article!

My biggest concerns with Haxe are debugging on mobile platforms, long-term support and that there is a new language I don't want to get used to. Why the hell they didn't use an existing language like C# or Java as basis :(? First level source compatibility with such a language would bring much more long-term viability... The fact that Disney and other companies seem to use Haxe makes me happy, the games listed at the Flambe page run flawless.

Sjors Jansen
profile image
Haxe is like Actionscript, so that means basically all Flash coders can code Haxe. And since Flash is dying that means there's likely to be a huge flock of people who might suddenly be very interested in Haxe.
If you know C# or Java you should be able to pick up Haxe very quickly anyway. Give it a try..
There was also a C# to haxe converter: http://cs2hx.codeplex.com/ but I never tried it.

Christian Kulenkampff
profile image
I see. Game development is my dear hobby, Java is my bread and butter. I am biased, but nevertheless I think yet another language wasn't an ideal choice. Of course it would be just a subset of a language and its standard library, probably with some special additions, but it would decrease platform lock-in even further. Of course this is not a real problem for me, because I am a hobbyist. Being a hobbyist brings a privilege of choice, that probably propels these thoughts.

Since Java is my language of choice I would be interested in Java bytecode to HaXe translation. Maybe one can tinker something with Soot... I guess I will give HaXe's Java translation a try and code client/common stuff in HaXe.

Bryson Whiteman
profile image
Right on man! Thanks for covering it from front to back!

Rob Graeber
profile image
Great writeup! I've never seriously considered haxe/openfl before this point. Some questions that came to mind:

How much debugging does it usually take to compile to a new platform? Is it easy to write native plugins in obj-c, java or otherwise access native APIs? Can you setup layouts with OpenFL using the Flash IDE, and also export that to other languages, or is it just for asset creation?

Lars Doucet
profile image
"How much debugging does it usually take to compile to a new platform?"

Do you mean:
1) How much work is it to compile to an already-supported platform like, say, windows desktop, if I've only been targeting, say, flash so far?
OR:
2) How much work is it for OpenFL to add a BRAND NEW PLATFORM, like WiiU/PS4?

Answers to both:
1) Depends on how exotic your feature set is. If you're sticking to the core flash API routines, pretty easy. I will mention the AIR API is *not* mirrored, so that's only available on flash target. If you have an AIR app that's making lots of, say, file system calls, you'll have to add little conditional tags in your code to do things the way the other platform wants to:

#if flash
doItTheFlashWay();
#elseif cpp
doItTheCPPWay();
#elseif js
doItTheJSWay();
#else
doItTheSafeFallbackWay();
#end

You don't have to do stuff like the above very often, only for implementing stuff that ONLY works on one platform because of that platform's inherent limitations/design.

2) A lot of work, but not too bad. They've added new targets (like Tizen) surprisingly fast. Depends how close they are to existing targets. (Tizen is basically just Linux).

Don't know much about native extensions, haven't touched that myself.

What do you mean by "layouts"?

Rob Graeber
profile image
Hey Lars, by layout I meant laying out gui and levels via code like Flixel or Cocos2d, vs laying out everything in a graphic IDE like Flash or Unity.

E Zachary Knight
profile image
I probably can't answer as well as Lars can, but on compiling your games to new platforms is pretty easy. I just compiled one of my Flash games to Windows with no trouble at all. It was as simple as replacing the word "flash" with the word "windows" in my compile command. Once you get one version working bug free, there is usually no problems with other platforms, unless as Lars stated you are using platform specific functionality.

Lars Doucet
profile image
Okay I see!

The answer is *probably* I'd have to look into more stuff about the SWF library. It renders SWF content, and apparently really well, so I'm pretty sure that would include whatever contents you stick inside a movieclip/sprite, such as an entire UI layout or level design.

You'd have to check with someone who uses the SWF library more than me for sure. Joshua Granick (@SingMajesty on twitter) would know more.

Sjors Jansen
profile image
Thanks for the overview!

Anybody interested in more free open source Haxe games can also take a look at some of my experiments: http://dromedarydreams.com/blog/experiments/1-0-2

There's one with Box2d and Balon Greyjoy.
I've been coding Haxe for about a year now.. it's getting pretty solid.

E Zachary Knight
profile image
One thing I would like to start working on is getting full Spriter support up and running in HaxeFlixel. I really like that animation tool and want to use it in my games. I just need to make the time to do it.

Something else that I would love to have is an IDE like FlashDevelop for Linux. I currently use Genie and work alright, but it does not work as well as FlashDevelop on Windows.

Chris Melby
profile image
I use InteliJ IDEA for all of my development and it's hands down my favorite IDE. I found it when looking into HAXE last year. It rocks for AIR/Flash development.

IDEA is available for Linux:
http://www.jetbrains.com/idea/download/

Olivier Besson
profile image
+10
Spriter is a great tool:
- Few rules, but a lot of expressive power.
- Deep understanding of graphics and animation (pivots, bones,...)
- Deep understanding of how it relates to gameplay programming (events, collision boxes, ...)

Spriter should be a source of inspiration for every "game framework developer"...

Brendon Smith
profile image
Loved the article! Thanks Lars Doucet. By the way if anyone happens to have a copious amount of time on their hands they can feel free to help me port over threeJS over to haXe fully. I will be spending my future time off on this class https://github.com/seacloud9/ThreeHX/blob/master/renderers/GlRenderer.hx . I recently plugged the openFL at the last SF WebGL meetup along other technologies like Ludei here are my notes http://i-create.org/webgl_notes/index.html#/

Andreas Ronning
profile image
Excellent post. I've been pretty much a complete convert for the past few years, after drunkenly meeting Nicolas Cannasse and being given the pitch on how you could write an AIR app and its native extensions with the same codebase. Jumped all my Flash dev over to Haxe instantly (It's important, I think, to know that Haxe was originally built as a Flash-specific alternative to the ActionScript/Adobe language/compiler set) and avoid writing AS3 (the only *truly* dead part of the Flash platform as far as I'm concerned) wherever humanly possible. Haxe is, for all intents and purposes, AS4.

My engagement with NME/OpenFL has been mixed, but mostly because of the nature of open source and how fast things have been moving. It's honestly been hard to keep up. For me, my focus is currently on Lime, which is an incredibly exciting platform to work on.

One more thing I think is important to know about Haxe is that the language is an absolute *powerhouse* at pattern matching, meaning writing your own domain-specific languages is a joy. Because of this ability, a popular library for Haxe is hscript, a dynamic runtime scripting language using a broad subset of Haxe, in essence offering a js-style eval function. AS3 has no real alternative for such a thing, and today I don't really know how to approach any kind of game project without it.

Anybody wondering why Haxe rather than C# or Java or JS or any other language, the answer is simply that Haxe is better. It's one of the best things to happen to me over 15 years of dev.

Lars Doucet
profile image
Man I love hscript!

Ian Harrigan
profile image
Great post! Informative, separated and with all the salient information there. Nice one!

Cheers,
Ian

JoseArias NikanoruS
profile image
Damn!
Hey, I have a situation and I would like to hear your opinion.

I've been working for a while in a Visual Novel engine for Flash. Right now I'm trying to port it to AS3 but reading your article makes me wonder about this.

+So, what do I want to do?
A Visual Novel Engine in Flash.

+Why in Flash?
Because I want to use Flash animation capabilities, like the animation editor and vector drawing tools, and also including some "dynamic content" like changing lighting or adding/removing elements from a scene.

+How far am I?
I have the basic stuff and you can see the results here:
(This is a prototype I made to get my Philosophy Degree, it's in Spanish and is meant to show how the complete game would be)

https://sites.google.com/site/pandedemonias/videos/home/ElMecanismo01.swf?attredirects =0


The SWF loads TXT files with the dialogs and the instructions for each scene. Like what background is shown, what music and animations are playing, etc. I made this so you can easily make and edit scenes. Here's one of my TXT files: https://sites.google.com/site/pandedemonias/videos/home/ElMecanismo01-1.txt


Now, the questions:

What do you recommend?
+Do I keep migrating to AS3?
+Do I quit the project as it is, forget about animations and stick to Ren'py or something like that?
+Do you think my project has a future in OpenFL?

Any helps or advice is welcome!


PS: If you want to know more about my project: my thesis was a proposal for a Philosophic Visual Novel that would use the interactive possibilities of the medium to teach some philosophical principles, not by quoting philosophical books but by putting the player in a situation where she needs to actually ponder what's happening (that's what Philosophy is about, not about quoting dead people). My project is focused in Nietzsche's Philosophy and I've been trying to advance the project on my own for a while now.

Joaquin Bello
profile image
The workflow you have in flash is not the same workflow you have in OpenFL. The swfis great but the rendering is not 100% accurate in all platforms. OpenFL has a more prosper future than AS3, but working with OpenFL currently its not as smooth as working with AS3. If you want to support linux or html5 then change, if you are happy with AS3 stick with AS3. The flash player is a grate platform and its still the largest platform in the world.
I use AS3 and I'm switching to OpenFL, slowly because I'm porting my tools.

You can't find a lot of info about OpenFL on the web, but amazingly you can find a free e-book in Spanish about OpenFL! http://www.openflbook.com/
The book great at showing you the basic things like how to add a lib, how to use assets, etc. In the end of the book it explains how to use swc(AS3 lib) in haxe.

JoseArias NikanoruS
profile image
Thanks a lot Joaquin!

Alan Rawkins
profile image
Thanks for the great article! I went through a similar experience with Adobe but ended up moving to Monkey. I didn't know about Haxe/NME/OpenFL at the time; if I had I probably would've used it instead. This is a great overview and gives me an idea of how this stacks up to Monkey. After reading this I think I will try porting one of my existing Flash games to OpenFL and see how it goes.

John Trauger
profile image
Poor Flash.

He saved every one of us.

Travis Brown-John
profile image
Sounds very interesting. Does Haxe support coroutines/greenthreads? That's one programming paradigm I just couldn't leave behind (from Unity).

Google turned up a few results:
http://haxe.org/forum/thread/3395#nabble-td5241871

but nothing definitive.

Lars Doucet
profile image
I'm not 100% sure, you'd have to ask a way smarter Haxe coder than me.

Here's the search results for "thread" on the Haxe github tho, if it helps:
https://github.com/HaxeFoundation/haxe/search?q=thread&ref=cmdform

Seems like something's there?

Ryan Walker
profile image
Lars, on HTML5 or WebGl - You simply need a wrapper to make it excecutable so while I love the Haxe guys and they totally have heart it's much safer to develop for the industry standard open source cross platform solutions which will only continue to gain support - HTML5 and WebGL. Game Dev Tycoon is on steam and is an HTML5 game and they were kind enough to put their API here. It uses node to wrap into an excecutable (node is the typical solution for server side JavaScript, another open source technology.

So when you say HTML5 does not work on steam that is fortunately for developers, incorrect. Any executable can theoretically work on steam.

https://github.com/greenheartgames/greenworks - what the game dev tycoon devs used to put their HTML5 game on steam.

Tyler Koske
profile image
Great article, just one comment:

You do not need to pay for each platform to publish from Unity, unless you need the pro features. The free version of Unity supports publishing to Windows, Mac, Linux, Web, iOS, Android, Windows Phone, and Windows Store out of the box, without purchasing anything additional. If you want pro features, you will need to purchase Unity Pro, and the Pro version of the platform plugins for your desired platforms. So, this makes it not too different from other free/open source platforms in that you only need to purchase the developer license for your desired platform in order to publish to it.

Dmitry Komarov
profile image
Hi!
What's about gui libraries such as AsWing?
Are they supported on Haxe?

Lars Doucet
profile image
Apparently so:
http://haxe.org/doc/flash/aswingas3

There's also these native haxe UI libraries:
https://github.com/ianharrigan/haxeui
https://github.com/RealyUniqueName/StablexUI
https://github.com/nmehost/waxe


none
 
Comment: