Slow Rush Studios logo,
    depicting an apprehensive-looking snail rushing forward

Slow Rush Studios

◂  The Game So Far
News index
Making Platforming Feel Good  ▸

Choosing an Engine


This week, I ported my "game" to two different Rust game engines. Why two engines? Why Rust? Let's dive in!

As a reminder, I'm aiming for a 2D game with "pixel physics for PC", which means it has some high level requirements from any engine...

So what are my options?

Big name engines

When it comes to game engines used by indie developers, there are 2 3 engines that come to mind.

Epic's Unreal Engine

The case for: Unreal Engine is the only freely available engine that can reasonably be considered "state of the art" - particularly when it comes to graphics. It costs 5% after you hit $1M in gross revenue" (calculated before the app store/publisher cut is subtracted), which is an insanely good bargain given the quality of the engine. Epic is also competing with Steam by creating its own online store and "online services" (friends list, chat, matchmaking, etc), and competition is good & worth supporting. Source code for the engine is available, which helps immensely with debugging. Epic makes a highly popular game with its own engine (Fortnite).

The case against: The power of unreal comes at a significant complexity cost: it's a behemoth, and consequently it is mostly used by bigger studios who have whole teams of artists, programmers and designers. You are more or less required to write your game logic in either C++ or use their custom Blueprints visual scripting language; C++ is a notoriously complex language which I have only a bare grasp of, and Blueprints suffers from being difficult to maintain as it gets complicated. Theoretically it has support for 2D, but as I researched it I found far more people recommending to stay away from it than people singing its praises.

Unreal's heavyweight nature is just too much for me as a solo developer: I don't have a single dedicated artist, let alone a team of artists who can set up an art pipeline. The complexity more or less rules it out, and its half-hearted support for 2D is the nail in the coffin.


The case for: Unity is the undisputed king of indie games. Originally it made a name for itself in the early 2010s in the mobile gaming space, but it has since moved upmarket: it doesn't quite compete with Unreal in graphical quality, but it's getting there. At least 50% of the top selling games on Steam are made with Unity, both 2D and 3D, usually by medium or small teams, or even solo developers like myself. Making games is helped significantly by being able to buy third-party premade components from their Asset Store (e.g. water that looks realistic and ripples when your character moves through it), which has a truly impressive amount of content on it. You write your code using C# (a much more forgiving language than C++!), and they compile it to C++ under the hood to make your game work on the web and on consoles (Xbox, Playstation, etc).

The case against: Unity the company went public a few years ago, hired a ton of people and thoroughly lost its focus - or at least, its focus does not seem to be on helping game developers succeed anymore. They merged with IronSource, an ads company, and now have twice as many staff as Epic despite their own engine being considerably less state of the art than Unreal. They bought half of a movie visual FX studio then laid them almost all off 2 years later. They are making a net loss of hundreds of millions a year. They tried to retroactively change licensing terms of their engine to significantly increase its price, then only partially walked it back. Almost every aspect of the engine (rendering, networking, UI, input, etc) has an unfinished replacement available (each of which tends to have weird incompatibilities with new versions of other aspects), which is made worse by the fact that the old version of each aspect is usually deprecated & not receiving bug fixes. Unity does not make games with Unity, only tech demos. Source code is not available, though in some cases you can use a third party IDE to decompile and get the gist of some of the code.

I just can't get over the apparent misalignment between Unity and game developers. Epic wants developers to succeed otherwise Epic doesn't get paid; meanwhile Unity wants to push developers into selling ads using its own adtech, and make its stock price go up? Apparently making a good game engine stopped being a core focus about 5 years ago. I used Unity for a few game experiments in the last 1-2 years and the "deprecated, replacement not ready yet", no source code and lots of little paper cuts piling up made it frustrating. I suspect that Unity isn't going away, but its golden age is over, and it will have to do a lot of work to raise its quality again.


The case for: Godot (pronounced "ge-doh") is 100% free and open source, so no licensing issues and source code is available for debugging. It has great 2D support and okay 3D support. It has a strong focus on being easy to use. Documentation is pretty good, at least for an open source project. It has some reasonable funding from donations, including from Epic. When Unity's shot itself in the foot with its own licensing kerfuffle, a good chunk of small and solo developers jumped ship to Godot (and some developers started funding it too). It supports a python-like scripting language called GDScript and C#, plus with some hoop-jumping you can use other languages such as Rust too.

The case against: you can count the number of "feature length" released games that use the engine on one hand - I almost left it out of this section for that reason. The focus on ease of use seems to often come at the cost of performance - which is okay for simple 2D games but a problem for non-trivial games. For example, GDScript is easier to learn but slower than C#, but if you use C# (or any other language) then you still pay the performance cost of GDScript due to how the engine is designed. The leader of the open source project is extremely adamant that ease of use beats all other considerations, so this is unlikely to change. C# support exists but anecdotally I have heard that there are many rough edges compared to GDScript. Version 4.0 was released last year after several years of development but was apparently rushed out with many critical bugs. There's no official support for consoles (though this is true of all open source options due to NDAs and console manufacturer licensing terms).

Godot is an impressive creation! The fact that the #3 game engine is open source is remarkable and a testament to everyone who has worked on it. However, for my use case, GDScript isn't going to perform well enough to implement pixel physics, so I would need to implement at least that portion in another language. I am also wary of using GDScript in general: it's a dynamically typed language that they created for (IMO) dubious reasons, and so support for it outside of their own editor is quite minimal. If I had to pick one of the big 3 engines, I would pick this one, but I decided to keep looking for a better fit.

Exploring other options

Once you get outside those big 3, you're looking at more niche options: you can get a better fit for your needs, at the cost of a smaller community (which means having to solve more things yourself).

So what would be the perfect fit for my needs?

Rust game engine options

Well, first off, not needing an editor is great, because basically no (2D) game engine in Rust offers an editor!

The major 2D-compatible options available are:

EngineElevator pitchStatus
Bevy"Let's build a state of the art engine in Rust, using the ECS paradigm for absolutely everything!"✅ Very active development, but usable
Tetra"Let's build Monogame using SDL"❌ Unmaintained
GGEZ"Let's build LOVE 2D but in Rust!"〜 Maintained on and off
Macroquad"Let's make a basic-as-can-be abstraction layer over old graphics APIs"✅ Maintained
Comfy"Macroquad, but over new graphics APIs, and slightly more batteries included!"〜 Active development, unstable

Here's how they stack up with platform support:


(* GGEZ says it both supports and does not support MacOS)

GGEZ and Tetra don't support web and also don't seem to be maintained much anymore (Tetra even suggests going elsewhere). Neither thing is the end of the world (one reasonably successful game was released using Tetra recently), but it's enough to make them not the first choice.

So that leaves Bevy, Macroquad, and Comfy.


Bevy is well known in the Rust community for having a significant ecosystem around it, and I had played with it a bit before, so I ported my little pixel simulation to it first.

I used the Bevy game template as a starting point, and the Bevy Pixel Buffer plugin for rendering my pixels. Bevy operates by having you register functions ("systems"), which then operate on a mix of global variables ("resources") and your game objects ("entities"), so I set up my pixel world state as a resource and registered various systems to handle input, progress the simulation, update the render state, etc. After about an hour of messing around, I had my simulation ported, though (as you can see) the pixels texture isn't resized to properly cover the available window yet:

Screenshot of the game running in Bevy

How I felt about using Bevy:

Overall, I like Bevy, but it seems like a poor fit for prototyping.


To compare, I went with the polar opposite of Bevy: Macroquad, a library so minimalist that the author first created their own minimalist window & graphics management, random number generation, and audio libraries! I admire the dedication.

This time I had to implement my pixel rendering from scratch; turning my pixel data into an image texture that could be rendered was straightforward, but it took a bit of digging and a fair bit of experimentation to figure out how to ensure my pixels were never stretched, squashed or blurry at various different window sizes! As part of fixing that, I also made the pixel simulation resize itself to the available window space; of course in the longer term it'll be necessary to have the window act as, well, a window onto the game world, such that the pixel simulation can be of arbitrary size.

Screenshot of the game running in Macroquad

How I felt about using Macroquad:

Overall, I think Macroquad is good enough for this early phase of prototyping: it's simple and basic, like my "game".

Playable web build‎

Both Bevy and Macroquad support web builds, so I got them both working. Bevy's performance seemed to be slightly better, and Macroquad's performance on Firefox was particularly awful, at least until I worked out that sending 16MB of pixel data to the graphics card each frame was maybe not optimal.

Anyway, here's a build of the "game":

Click to focus, then play with keyboard and mouse. No mobile support! Give feedback.


As you can see, there's not much there! The white & red pixels in the corners are markers to show me that the texture isn't getting cut off. And yes, sand and bricks stack on top of water still.

But, it's better to share early and often, and I figure I can't possibly be more embarrassed about the state of this thing than I am now, when it doesn't even have a player character to control yet. Still, if you have feedback, shoot me an email.

Anyway, that's all for now!

Appendix: Non-rust options

If I were to drop the "programming language must be Rust" constraint, there are some more non-Rust options worth considering:

All 3 options have successful commercial games using them, and they support consoles (again, once you're a registered developer etc). If Rust ends up being too painful, those are what I think I'd try next.

◂  The Game So Far
News index
Making Platforming Feel Good  ▸