Happy (belated) New Year 2016! And now on to updates.

It seems I have abandoned HaxeFlixel almost completely in favour for Kha. Two months ago, I was in a limbo between using HaxeFlixel or Kha. Here is my list of pros-and-cons of using them. Note that these are my opinions after all, and YMMV (your mileage may vary):

• HaxeFlixel pros
  • Very matured game framework
  • Has a lot of convenient libraries, e.g. Tiled parser, Nape integration, Quadtree collisions
  • One of the Haxe frameworks with large use-base (compared to OpenFL or HaxePunk)
  • Battle-tested to work and compile with minimal issues, since it originates from the Flixel framework.
  • Actively updated by the HaxeFlixel team, all of whom are very experienced.
  • Very, very easy to prototype platformers and other common 2D games.
• HaxeFlixel cons
  • Bloated features – I doubt anyone uses about 80% of the library for prototyping purposes
  • Bloated classes – Too many properties; While this may not be significant, it can still be an issue for performance (CrossCode developers’ article on their experience with composite vs inherited classes) in the long run.
  • Bloated size – An empty HaxeFlixel game in HTML5 is a whopping 2MB, which is unacceptable for bite-sized games. Using minifiers reduces the size by half, but it still includes a lot of unnecessary code.
  • Difficult to find support – This is an anecdote — It’s tough to give and receive help when the only people who know their stuff are too busy fixing the core HaxeFlixel features, and the others are simply too busy working on their own games.
  • Experimental HTML5 support, with no WebGL support.
  • Attempting to tinker with HaxeFlixel’s code requires thorough knowledge of the underlying flow of Lime, OpenFL -and- HaxeFlixel. That’s a lot to stomach for me.
  • Doesn’t support shaders out of the box.
  • Doesn’t support 3D out of the box.
• Kha pros
  • It’s an SDK similar to SDL for C++
  • One API for all targets
  • Almost native speed
  • Supports HTML5, WebGL with fallback on Canvas
  • Supports 2D and 3D.
  • Easier to dive into the code to tweak and make minor changes for custom builds.
  • Robert (the author of Kha) is super duper responsive, very helpful on the IRC channel, and knows his stuff.
• Kha cons
  • The codebase is pretty volatile every now and then. This causes a lot of stuff to break frequently. Although, it’s somewhat stable now at version 16.1.
  • Kha is a work-in-progress, so expect some things to not be working yet, e.g. (anecdote, again) Audio on Chrome mobile is pretty bad.
  • Because Kha is an SDK rather than a game framework, you have to roll your own game engine or framework. On the positive side, this means you get full flexibility for how your app/game is written.
  • Since most of the work is done by Robert alone, updates may not come as fast as you’d expect. However, Robert looks at every single Pull Request and merges frequently, so contributions are greatly appreciated.
  • Lack of documentation. Although, you could always ask Robert directly (via twitter, IRC, or his forum) and he’ll get back to you pretty quick.

The comparison above may not seem fair, considering that Kha is more likened to Lime or OpenFL than HaxeFlixel, but even when I tried using Lime or OpenFL, Kha still feels a whole lot easier. I’m not exactly a great programmer, so if I can feel comfortable about Kha than I do with Lime or OpenFL, then it should speak volume.

Over the past two months of experimenting back and forth with Kha, and eventually rolling out my own game framework for Kha, Wyngine, I am quite content to say, I’m happy enough with my own lightweight component-based game framework. It’s missing a lot of the fancy stuff like Quadtrees (I removed it due to performance issues on mobile), Nape, animation, or Tiled parsers, but when I need them, I’ll definitely add those in.