Which engine is right for me?

Investigating how best to create games

Before I start, I wanted to really look into the best game engine for me. It’s quite easy to invest time into something, only to hit limitation after limitation. This leads to a ‘technology envy’, then a full port and rewrite, only to realise that the new technology has a different set of limitations.

Ultimately you need to do something, not just read or watch something, to understand what works for you. To experiment, I’ve written the Scoundrels card game, see explanation video, in a couple of different engines.

I’m using the term engine here very loosely to include libraries, frameworks and full blown IDEs.

What am I looking for?

Over the years, I’ve come to work backwards. How easy will it be to get the thing to the player and then support it?

All the fancy features mean nothing, if people can’t play your game:

For me, distribution means desktop (Linux, Windows, and MacOS), Web and Mobile (Android and iOS). VR headsets, such as the Quest, are also interesting. Console support is fairly expensive and complex in terms of licencing and process, and porting the game itself is probably the easiest part of the console development journey.

Functionality wise, I don’t want to limited by the engine. The engine should support 2D and 3D, UI, audio, controller, etc. It should support or allow integrated physics, navigation, debug menus, etc.

What did I discount immediately?

There are certain programming languages which I don’t feel work well for games. These may be outdated takes, but:

Unreal is hugely impressive, but I don’t like it. I’m not a fan of the heavyweight editor, of blueprints, of C++, etc. Really though I don’t see myself creating games that work well in Unreal. I think Unreal excels at the handling complex, realistic assets and lighting, models, etc. To do that though, you need a big team. This is perhaps my lack of experience, but I felt doing anything ‘different to the tutorial’ in Unreal, was huge amount of work.

Unity was straight out due to the pricing fiasco. Whilst the idea of payment in some form is fine, I can’t start building on that foundation knowing there may be another rug pull.

GameMaker is a 2D only game engine.

GDevelop isn’t free, and whilst I appreciate the need to fund software, I really don’t want to have to read the table of what I can and can’t achieve in a game engine at different tiers.

Fyrox looks promising, and I get strong Godot vibes from it. That’s good thing, but I felt I might as well use Godot, as it’s more mature and has the established community.

Kaiju is a new Go based game engine, which is similar in the spirit of Fyrox (I feel). It’s under active development, and that’s not something I want to deal whilst currently, but one to watch.

Ebitengine is really nice and it’s impressive how many projects the author has to improve the ecosystem. The most recent being DebugUI. However, it’s 2D only.

What did I do?

I initially started building with Raylib. If you look through the Raylib offering, especially looking beyond the core into Raylib GUI, it covers a huge basis for game development, with minimal faff.

The Raylib code between different languages is basically the same.

The Rust with raylib-rs was the most elegant. I have found the ideas of borrowing and ownership tricky to apply in practice (e.g. in an actual business app, or for Advent of Code). In a game, ownership is clear. Who owns the card? The deck does when it’s discarded, the board does when it’s played, or the player does as they drag. My bigger concern with Rust is actually integration where Raylib is missing something, such as Physics. Here the community effort is clearly going into Bevy and Fyrox.

The Zig version using raylib-zig was the shortest. There was a fairly minimal amount of memory management, which might mean it wasn’t a fair test. However, setting up the build system to target both web and desktop was more painful - and this can be seen in the repo script. By chance, I wanted to add other dependencies to improve the project and I spend too much effort on many blockers getting web and desktop builds in place.

The Go version was the quickest to write and then change. There’s a bit of a dance to develop for desktop with raylib-go and then retarget for web. This is ugly but not disastrous, though there are some aspects of Raylib, such as Raylib GUI, which are not fully supported on Web.

The Godot version felt a little alien compared to the others, partly because it has a graphical editor and partly because the node based approach is not easy to do well (I feel). However, it was by far the easiest to polish (aka juice).

I also looked into:

Initial result

As a developer, using Go and Raylib was very productive to me. They seems a really strong combination to write a game from scratch. Raylib just stays out of the way, but saves you from all the low level hassle.

Go is fast, compiles quickly and has complete standard library. Though developers are concerned about Garbage Collection pauses this is a non-issue for most games and something which can be optimised away.

Reality sets in

I used this the Go and Raylib stack to iterate a prototype game.

One benefit I didn’t notice during to Scoundrel type.

However, after a number of iterations I found:

Final final conclusion

It was the realisation that I was writing more engine-esque code than game code, that lead me to reconsider. Although I might prefer to write all the code myself, that is not the objective - the objective is to ship a game.

So in the end Godot was the only sensible option left.

Thanks

I used Kenny’s assets to make the games.