The state of gamedev in Haxe

Posted on September 15, 2016

Preamble: I posted this on reddit half a year ago, so it’s slightly outdated, but I want to keep a copy of it in case my server outlives reddit (a man can always dream).

Hey fellow devs, I’ve been making games non-stop for like four years now. I tried PyGame, ActionScript 3 (rip), raw JS, Unity, Unreal, Godot, and generally try out new tech (Superpowers is really cool). At the end of the day I always go back to Haxe because I think it rocks. What saddens me though is that it remains sort of underground, so I decided to write an overview of Haxe gamedev in hopes of giving it some exposure.

I wrote this for gamedevs who aren’t familiar with Haxe, but who would like to know how it can be relevant to them, and where to start. Consider this a brief tour of the world of Haxe gamedev (last updated 28/02/2016).

What is Haxe?

Haxe is an open source toolkit based on a modern, high level, strictly typed programming language, a cross-compiler, a complete cross-platform standard library and ways to access each platform’s native capabilities. -Haxe website

This means I can deploy a game on mobile, desktop, and web, sharing 99% of my code across targets. The other 1% consists of target-specific things like touch input handling, AdMob/Steam integration, HTML5 fullscreen API, you get the idea.

This is made possible through cross-compilation. When I compile for Windows, for example, my Haxe code is translated into C++ and compiled using MSVC. When I compile for HTML5 my source code is translated to JS. So on and so forth. This allows my code to run natively on its targets.

Note about open-source: Haxe is open-source, and so are all the engines, frameworks, and libraries mentioned here.

Note about cross-platform support: all the engines and frameworks below compile to Windows, Linux, Mac, Flash, HTML5, iOS, and Android, specifics are notes in {} brackets.

Engines

  • HaxeFlixel {Also supports BlackBerry and Ouya, console support is in the works}: Originally a port of the popular 2D ActionScript3 Flixel engine, it has since superseded its parent in more than a thousand ways. This is an “all batteries included and a few spare ones too” engine. On top of rendering, asset management, input handling, etc. it provides physics, tweening, UI, and if anything’s missing it’s probably already in its separately maintained flixel-addons repository. Its only shortcoming is its roots as a blitting engine - the rendering isn’t very customizable. If you’re looking to experiment with shaders for example, try Luxe instead. Games showcase: http://haxeflixel.com/showcase
  • Luxe {Doesn’t support Flash, but the HTML5 support is excellent}: In many ways a much less bloated and opinionated engine than HaxeFlixel. It’s minimalistic in core and design, giving you freedom to do everything your own way. The rendering is very customizable. Games showcase:
  • The Westport Independant
  • Threes HTML5 web port
  • Heavier than Air
  • More
  • Other engines: OpenFL (see below), HaxeFlixel, and Luxe have the most active communities. There’s plenty of other game engines out there, but I wouldn’t recommend beginners to start out with them. Stick to the most popular ones.

Frameworks

  • OpenFL {Also compiles to BlackBerry, Firefox OS, and Tizen. Console support is in the works.}: HaxeFlixel is actually built on top of OpenFL, which stands for “open Flash library”, which in turn means “we ported the entire Flash codebase to Haxe and we don’t need to put up with Adobe’s shit anymore”. This is in my opinion Haxe’s flagship library, its biggest community, its pillar. It provides rendering, input management, asset management, and just about everything else except for physics. Games showcase: http://www.openfl.org/showcase
  • Lime {Same compilation targets as OpenFL}: OpenFL is in turn built on top of Lime. Think of lime as a supercharged mix of OpenGL, OpenAL, SDL, and it’s also a build and packaging tool. If you want to make your own game engine without having to bother with the boredom of window management, asset loading, and other similar aggravations you’ll find it absolutely marvelous. Since the HaxeFlixel and OpenFL projects depend on Lime you can expect decent community support and loads of examples in the form of OpenFL’s source code.
  • Snow {Doesn’t support Flash}: Luxe is built on top of snow. Snow is very similar to lime so everything I just said about lime is applicable to snow. I tried both and they’re really not much different.
  • Kha {Also compiles to Tizen, PlayStation Vita, Xbox360, and Unity 3D}: It’s amazing but it doesn’t have nearly as many users as it deserves. Judge for yourself. It’s like a version of lime/snow that’s closer to the metal. It’s doing really bleeding-edge stuff, Vulkan support is in the works for example.

What about 3D?

  • You can make your own engine with lime, snow, or Kha. All three of them provide OpenGL bindings, the sky’s the limit. Kha actually provides a 3D API that wraps around OpenGL, DirectX, and soon Vulkan.
  • The creator of Haxe launched Evoland 2 on Steam, and open-sourced its engine, heaps. It also has an OpenFL/Lime backend.
  • Away3D ported its Flash engine to Haxe: https://github.com/away3d/away3d-core-openfl
  • Here’s a few more off the top of my head, but none have a decent amount of users (yet):
  • Luxe has a 3D renderer, but is focused on 2D at the moment. Here’s a sample of a 3D game prototype built with Luxe.
  • http://babylonhx.gamestudiohx.com
  • http://www.haxor.xyz
  • http://lue3d.org and its successor http://cyclesgame.org and its successor http://armory3d.org
  • Haxe has extern definitions for the Atomic Game engine, and someone made it possible to use Haxe for the Unreal Engine, no less: https://github.com/proletariatgames/unreal.hx

But sir, I wanna use raw OpenGL!

  • As you wish. Use lime/snow/Kha, they have full OpenGL ES 2.0 bindings (Kha actually has a higher-level rendering API which supports DirectX or OpenGL). They would also provide you with the essentials like window management, input handling, asset management, audio playback, and will automate the build process AND also make sure everything works on different platforms (OpenGL bindings will transform into desktop GL, WebGL, or ES, depending on the platform). All while giving you access to the lowest-level things. If you must really relinquish all of that and inflict yourself lifetimes of pain, read the next bullet point.
  • linc is a new initiative providing cpp bindings for the most essential gamedev libraries. There’s bindings for SDL and OpenAL already for example, but the OpenGL ones are still a work in progress.
  • You can make your own bindings. Make sure you know how cpp is compiled, and then head on to this page: http://old.haxe.org/doc/cpp/ffi
  • That was actually the old-ish way to do cpp bindings. Nowadays the https://github.com/HaxeFoundation/hxcpp project allows you to add arbitrary header files and source files to your build process, effectively building them along with your executable (no more ndll required). That’s what linc does, I believe. More details here: https://github.com/snowkit/hxcpp-guide and here: https://wighawag.com/blog/2014/12/hxcpp-externs and here: https://matttuttle.com/2015/07/hxcpp-build-xml.
  • Just use lime/snow/Kha, okay?

Physics engines

  • Nape: The ultimate Haxe 2D physics engine.
  • Box2D: A port of the Box2D engine, which needs no further introduction.
  • haxebullet: The 3D realm offers some interesting picks, but I like this one the most. It’s direct bindings to the famous Bullet engine, and to its JS ammo.js port.

Miscellanous

  • If you’d like to see what the Haxe community is up to nowadays then browse a few roundups from https://haxe.io
  • ENet: Bindings for the legendary UDP messaging library (for multiplayer games).
  • haxe-glm: A port of the essential GLM library. There are other Haxe math libraries out there but I like this one the most.
  • Over the years I’ve starred a ton of Haxe projects I found useful or just cool: https://github.com/stars/Ohmnivore?language=haxe