Are We Game Yet: Playing around with Gamedev in Rust

I like prototyping games as hobby. I wouldn't classify myself as an "indiedev" because I'm rarely ever trying to create a final product; I just find building random ideas an enjoyable creative outlet. I also tend to focus less on gameplay and more on the underlying systems that support gameplay. I enjoy the optimization challenges of making for loops as fast as possible, or building out search trees or writing collision-handling systems.

I think for the above reasons, I tend to dislike using fully-featured game engines. I love that Godot exists, but I feel like unless I decide I'm going to work on a serious effort to make a final product, it isn't for me. I never really liked Unity... and that was before the company tried to destroy any goodwill it had with its community.

For a very long time, I've been using PixiJS for my prototyping efforts; I love the project, and have loved what the maintainers have been doing with it, ever since I started using it with version 4. I even have a starter template that has some opinionated boilerplate for how I like to build things. I also really like having the web as a target and playground, and with Vite and HMR, I feel like I am able to rapid-prototype things very effectively.

The problem with developing for the web is that you're still developing for the web. Sure, the browser now has access to some powerful local hardware (PixiJS supports WebGPU, and it is awesome), but at the end of the day... you're still in a browser. Sure, you can bundle your project up with Electron or Tauri, but you're still dealing with the overhead of a browser.

I like developing (and optimizing) for the tiny. The minimal.

What is the minimal runtime needed to have this software working on the computer? It should run as lightweight as possible; use as little RAM and CPU as possible. The browser is a whole lot of overhead I don't need and can't control.

So, recently, I've been doing a lot of prototyping outside of the browser, and with different languages, frameworks, and even targets; Things like: text-based adventure games and roguelikes that run in the terminal, some simple puzzle games for mobile OSes, and idle/incremental games built several different ways for different platforms.

I've been trying a bunch of different tools: Dart, Flutter, Flame, Rust, Ratatui and Egui. Wanting some tiny executables for the command line and desktop is actually what got me to take learning Rust seriously.

And that brings me to the state of game development in Rust, and the awesome website Are We Game Yet?. Sites like this one are something I love about the Rust community: passionate developers building, providing and maintaining valuable information.

After building some CLI tools in Rust (primarily using Ratatui), and then some desktop tools and game prototypes with Egui, I wanted to look into lightweight, 2D graphics wrappers. I knew Bevy was a thing, but I also knew I really didn't want a full "engine". I wanted a simple wrapper around windowing, input, etc., that would let me utilize the GPU. Years ago, I did a decent bit of SDL and SFML development; I saw that SDL2 had Rust bindings, as did SDL3, but it looked like it was still a "work in progress". So I began to peruse the Are We Game Yet site for options.

For the last few weeks, I've been playing around with ggez, and I've been enjoying it. I will probably need to follow up this post with another that has more details specific to what I've been messing with, but here are some things I like about ggez:

• It worked; this seems silly, but I am regularly amazed by how many libraries/frameworks/etc. have "examples" that don't even compile.
• I am able to run it on MacOS and Arch, the two OSes I am regularly on.
• I don't feel like it gets in my way; I was very quickly able to start building things.
• While not constantly getting updates, the project is still active enough for me to consider it "maintained".
• It is simple enough to use, that what I'm building with it could be transferred to another framework if ggez doesn't fully work out for me.

That last point is actually one of the most valuable lessons I think I have been learning while learning Rust: how to compartmentalize my code better. With the project I am focused on right now, the "game" state, logic, etc., are separated from the "rendering" / application pipeline of ggez. Again, this means I could switch to another framework if I needed to, without having to completely rewrite all of the game logic.

At this point, I think this post has gotten too long... I'll have to follow up with more about what I'm building and learning.