The Great 2D Framework Evaluation Conclusion

Here we are in the final 2D framework evaluation post. It shouldn't come as too much of a surprise that I angered a bunch of people with this series. Even though several times it was stated that all of these posts were my personal opinion and that yours will vary, certain individuals still decided to send me hate mail because I didn't like their favorite game engine. My apologies for laughing at your ridiculous emails. Hate mail from a proper zealot always makes me chuckle.

Onward. In the first post in this series I said that the words engine and framework would be used interchangeably. As is the way in zen, those words were from the past and are no longer valid. In the present, engine and framework are no longer interchangeable. A framework is now just a collection of libraries that facilitates making a game. Frameworks usually abstract boring stuff like access to devices (keyboard, mouse, display, audio) and provide a foundation from which to build on. Engines on the other hand provide you with everything a framework does and a ton more. You often get a full entity/component system, graphics pipeline, visual editor and tons more with an engine. Unreal and Unity are game engines, MonoGame and libGDX are frameworks.

Some Background: Why the 2D framework search happened

One of the big reasons this whole 2D framework evaluation came about was due to the rigidity of game engines. I use Unity for most 3D projects and have been using it for 2D stuff as well. Unity being an engine has already made a ton of decisions for me. Lots of subsystems are fully off-limits black boxes. For 3D that is fantastic. The complexity difference between 2D and 3D is pretty huge (much larger than just the loss of a single dimension) and I have no desire whatsoever to learn the details of or modify the inner workings of most of those systems. I happily defer to Unity for all of those internals for 3D. It's a kickass tool for cross-platform 3D development. There is no arguing that fact.

2D on the other hand is simple in comparison. I had high hopes that Unity 4.3 (released way back in 2013) would provide a whole new system of 2D tools on par with Unity's 3D tools. In reality what it brought to the table was a bare minimum amount of 2D features tacked on top of the built-for-3D Unity editor. In 2015 we still don't have anywhere near the tooling for 2D that should be there.

On the horizon are tilemaps and 9-slice sprites. 2+ years later and these features are still not released. It takes all of a long weekend to make a basic tilemap editor using the Unity editor public API and 3 - 4 hours to make a fully-featured 9-slice sprite implementation. Why are they still not released 2 years after 2D support was added? I don't know the answer to that question. Maybe Unity is making decent $$$ from all the 2D assets in the Asset Store and they don't want that to end. Maybe 2D just isn't a priority with VR around the corner and such powerful mobile hardware out there. Maybe there just aren't that many Unity developers making 2D games anymore. Whatever the reason my confidence that Unity will have solid and comprehensive 2D support has deflated past the point of no return.

The Current State of the Search

In part 2 of the series you will notice that all the engines ended up getting scrapped. As it turns out that wasn't by accident. As I was evaluating all these 2D kits (some engines and some frameworks) I ended up writing and rewriting my own engine in several different languages on top of the different frameworks. Depending on the base framework and what it provided, the engine was sometimes pretty low level and other times higher level. Some frameworks are just cross-platform OpenGL wrappers while others hide the details of the actual graphics API completely. The two most mature versions of the engine (take the word mature with a grain of salt since they are all spare-time, 3 week old projects) are written in Haxe (on top of Kha, Snow and Lime) and C# (via MonoGame). On a side note, using a modern version of C# with a functional debugger is a fantastic experience.

It's been quite fun getting down and dirty with a new programming language, new toolchains, new frameworks, etc. I don't even remember the last time I wrote code that called glCreateShader and friends. I don't think I have ever written a spatial hashing system from scratch for physics lookups and now I have several in various languages. All the bits and pieces that you take for granted when using an engine become crystal clear. I went into this whole ordeal not really wanting to get that low level but here I am with two separate engines in two different languages.

At this point, the MonoGame version of the engine is a bit further along than the Haxe version. I was able to repurpose a lot of my Unity code for use with MonoGame and solid tooling (excellent debugger and all the C# tools) make development quicker. The next step is to make a small game with the engine to see how it fares and fill in any gaps with regard to missing features. Once all is said and done I will most likely open source all the code just in case there are people as picky as myself when it comes to what they use to make 2D games.