We’re finally here at the end of the experiment. Nearly 3 months after the original announcement, I’ve tried 9 different open-source engines and frameworks and written my thoughts on each. Now it’s time to step back, do some comparisons on the group, and work out what I want to do going forward.

First, just to jog your memory I’ve assembled the complete list of posts:

  1. DFGame
  2. Godot
  3. HaxeFlixel
  4. LÖVE
  5. Monogame
  6. PyGame (immediately and unceremoniously disqualified)
  7. Raylib
  8. SFML
  9. Heaps.io

The Predictions

In my first post, I talked a little about each lap and what I was expecting out of them (except Heaps.io, which was added to the list later on). Let’s look back and see how they bore out.

DFGame fared about how I expected it to. This is no surprise, it’s the one item on this list that I made myself so naturally it wouldn’t really deviate from my expectations. Still, of note is the ‘wordiness’ that I mentioned in my write-up. DFGame’s lap is the largest codebase by far, with the other (completed) games ranging from ~400-600LoC, 25-50% smaller. It’s not entirely C’s fault either–raylib’s demo is only 547LoC. If I was planning to keep it, I think a high-level API would be a must to remain agile.

Godot was probably the biggest upset of the bunch. I had only really heard praise for the engine, and several people I know and trust recommended it… but in the end I found it kinda awful. On thing I feel obliged to note is that I’ve spoken to some Godot users after writing this article–for the most part, they don’t really seem bothered by the issues I brought up. As a professional Tools Programmer with a (mild) UX background, it could be that I’m extra-sensitive to these sorts of issues. If you’re unsure about Godot after reading my post, consider giving it a whirl to decide for yourself. It’s free, so you have only time to lose.

HaxeFlixel is an odd one, because despite a very positive review I’ve since soured on it a little. I think as the first “good” lap, I overreacted to it a bit. The iteration times are really annoying, particularly paired with the logo that pops up at every launch, and there’s something to be said for being the only engine on the list with physics issues that aren’t clearly traceable to my code. Still, it’s not a bad engine and it had easily the best documentation of the lot! I think the other projects could improve a lot by copying HaxeFlixel’s example site.

LÖVE is pretty clearly the “winner” of the bunch, hands-down. I was hoping that it would be good, since I remembered liking it, and it was. I have very few negative things that I could say, so here’s a link to a post from 2012 where you can envision current me shouting “NO! YOU FOOL!” over an over.

Monogame was another big surprise for me. I was expecting to like it a lot more, but I bounced off of it pretty hard. For the record, it does seem to be a decent framework. Rather, I think it doesn’t work well in the conditions I tested and doesn’t really offer what I’m looking for. More on that in a later section.

Raylib was not what I expected at all. I was expecting something a little like DFGame (but, y’know, better), instead it was much closer to LÖVE. In the end, I think it mainly suffered from the language it was based on and the lack of a proper API. It could be interesting to check out the language bindings it has sometime in the future…

SFML was kind of a filler option when I put it on the list. I didn’t remember it being all that great (something that you can see from the fact that I didn’t bother using it when I was raving about C++, despite having tried it), and it turned out to not be all that great. I think there are better low-level options and better high-level options out there, so I don’t plan to ever revisit this one.

Overall, there were a lot of surprises. I think this speaks to the value of trying out software, rather than relying on just word-of-mouth.

A Note on Language

One thing that I noticed during this whole process was that the language being used does matter quite a bit. On average, it seems like the full-blown OO languages under-performed a lot in this 6-day test. This doesn’t surprise me much, since building up those kinds of structures adds overhead to the development process. I’m curious to find out how true the reverse is… will a larger script-based project break over the weight of its complexity? Time will tell, but I think this is avoidable with good design.

Another big deciding factor was compile times. Stopping to rebuild files really becomes annoying when trying to tweak gameplay, and I think the noticeably-slow compile times of Haxe make it a lot less suitable for games than it first seemed.

Eliminations

One last thing to look at before we wrap up is what options will do what I really want. Some time after starting this project, I hit upon a couple of requirements that I really wanted out of an engine/framework:

Starting with the first requirement, we can eliminate everything based in C/C++. That leaves Godot, HaxeFlixel, LÖVE, Monogame, and Heaps.io

The second requirement is a lot more wishy-washy, since it’s about how easily some things can be done. As a graphical engine, Godot definitely makes it in. Due to how it handles assets, Monogame definitely doesn’t. The others are a little more up in the air… so for now, I’ll leave them in. That leaves me with a final list of 4:

Setting aside preferences for a moment, I think these 4 engines are the most suitable for my requirements. Unless someone can find a way to bring Monogame back in or I find new engines to try, these are the engines most likely to show up on this blog again.

Coming Up…

At this point, I think it’s clear that LÖVE is the engine that jives with me the most. Before I launch into anything big though, I have another project that needs some attention: this blog!

I have the next couple of weeks off, and my hope is to finally sit down and set up a unified site and blog on a new host. It’s going to start out very simple, but hopefully having everything working off the same base will make updates easier later on. Once that’s done, I think I’ll try to spend at least a few months experimenting, doing game jams, etc. before I start on any larger projects. I think it’s important to take time getting to know a new engine, and jumping directly into the deep end won’t get good results.

← Back to Blog