The Great 2D Framework Evaluation, Part 2

Filling up the Trash Bin

A bunch of the most popular frameworks didn't make the cut. If your favorite engine is one of them no need to get salty about it. Reiterating: just because they don't work for me doesn't mean they aren't great solutions for you or someone else. For some reason beyond my comprehension some people defend the game engine they use with fanatical pride. All the engines are pretty darn great and they all have flaws so let's just drop that whole thing here and find out why they got tossed:

  • GameMaker Studio: fantastic kit and probably the one I would recommend most for a new game developer who just wants to jump in and make something quick (see note in part 1 if you are new to game dev). For me, however, it doesn't fit the bill. GameMaker suffers from black-box syndrome (proprietary stack from top to bottom), does-everything-under-the-sun syndrome (level editor, code editor, store, image editor all included) and it uses a made-up programming language. And it's Windows only. Immediately tossed out for that infraction alone.
  • Unreal: another great piece of software. I love me some blueprints! And that shader editor. And that awesome behavior tree system. Tons to love about Unreal but it's just not well suited for 2D. It sure is a choice solution for 3D though especially if you've got a solid, experienced team to work with.
  • Unity: everyone under the sun is using Unity these days. It has become the go-to game engine. It's easy to jump into (hence all the newbs using it) and it outputs to everything including Samsung toasters. Unity tacked on some 2D features back in 2013 and pretty much called it a day after that. They finally remembered about 2D not too long ago and there are some new features coming in a few months. That being said, Unity seems to be having some issues fitting into their newfound top-of-the-charts shoes and ludicrous growth. I imagine that there are some long-time Unity employees that would love nothing more than to make some serious API-breaking changes to better the engine but they're too big for that kind of agility now. As MegaAAH SO SCARY Fox so eloquently put it:
  • Stencyl: it's got a pretty neat visual editor (basically MIT's Scratch) and would fit the bill for someone new to game dev (again, see note above) who just wants to see something on the screen fast. They sell themselves hard on code-free game dev which is a gigantic red flag for me. Installing it also borked my system PATH due to Stencyl deciding to change it without asking. FU and welcome to the trash bin.
  • Marmalade: the only C++ framework to make the list. Marmalade is a 7 gigabyte monster that has a mobile focus (perhaps too much so. It took hours to figure out how to output a desktop app). They have pretty good documentation and sample code but the API is just no fun to use. Bad class names and organization just makes my job not very fun so away it goes.
  • Godot: I really like Godot. It's basically an open source Unity. Lots to like in there but it uses a made-up programming language and it heavily favors 3D so it's out.
  • Cocos2D: I used Cocos2D a long time ago when it was iOS only. These days there seem to be a million variants of it (CocosSharp, Cocos2D-X, etc). It has a really odd API that I never really enjoyed and it's pretty rigid about it. Good tooling, crazy amounts of open source code in the wild and a great community are some pluses. Not for me though.
  • LÖVE: Lua-based 2D engine. It has a decent API, deploying to various platforms worked and it seems to have a good community. The font on the documentation page was a bit too small though so it got tossed.
  • Starling: uses the Flash API and Adobe AIR. Enough said.
  • Moai: couldn't get past the ugly website. Didn't download. Being honest.
  • Loom: I really dug that you can deploy to a pile of devices and live edit the code. Uses a made-up programming language though so here it dies.
  • Monkey X: this one was actually a pretty neat little kit. Solid foundation classes and a good editor. It outputs to every platform under the sun natively. The big downside is that you use the Monkey programming language (really) which then gets compiled to C++, C#, Java, etc. Made-up Monkey language meet the trash bin.
  • Defold: made by King (strike one since I expect to have to watch ads, wait for a timer to expire or suffer through a dual-currency transaction to compile or save in the future), built in Eclipse (strike two for being the worlds most bloated piece of software) and the editor crashes on launch (strike three). It is still in beta though and has a pile of really nice looking features so maybe keep an eye out for it in the future if you have a bunch of gold bars piled up waiting to be spent.
  • SFML/SDL: I should include these two here as well since they are popular but didn't fit the criteria. They are both excellent. In fact, many of the other frameworks use them under the covers to get at the underlying hardware (system, window, audio, etc). They get dumped here only because they are a bit too low level when used on their own.
  • Insert Game Engine Here: I'm certain I forgot at least 7 or 8 others that I tried. This bullet point is here as a reminder to fill them in if I do ever remember...

Special Section for my Favorite Framework in the Trash Bin

Oh, Kha how I love thee. So much to like in this one: automatic cross-compilation of shaders from GLSL to Metal/DirectX, runs on all of the platforms using the most efficient graphics API for each and per platform automatic asset optimization to name just a few. It is super fast and has some really clever API design. It can even export to XNA and it can spit out a Unity project. Insane! It doesn't try to run native builds directly and instead outputs proper Xcode/Visual Studio/Android Studio projects that make direct debugging a cinch. Why is it in the trash bin? Unfortunately, it has a large variety of downsides. Here are the first few that come to mind:

  • it's a bit too low level, more like SDL/SFML rather than a game framework
  • near zero documentation
  • near zero examples
  • near zero comments in the code
  • near zero community
  • crazy build system with no documentation and it just doesn't work sometimes. Best of luck debugging it.
  • the input API sends a char instead of the key code. wtf?
  • very basic audio support. No panning, pitch or anything remotely advanced.
  • the source feels really hacky and since there aren't many comments or documentation it's all you've got to work with

That rounds out the frameworks that didn't make the cut. It's now overflowing with some really capable software that just didn't happen to fit my personal needs. In part 3 we will take a look at the remaining bunch that someone avoided the axe.