No tea no shade 17 Mar 2026

I've been playing around with the Bevy game engine off and on since I was first introduced to it. My experiences over the years have been both extremely positive and extremely frustrating, in equal measure, but in past attempts I've gotten bogged down in problems (of my own design) such that I was not able to get very far into development of actual game play.

This time around, I'm tackling a much more ambitious game scope, but with less ambiguous game mechanics. This post won't go too deeply into the technical details, or even the game itself, but will be an overview of my experiences as well as why it's going better this time around.

Quick overview: Bevy is an open source, data-driven game engine built in Rust. It includes a very solid ECS (Entity Component System) framework, feature-gated 2d and 3d renderers, and an extensible plugin architecture. There are many freely available plugins, allowing you to add deep functionality at the cost of a new crate added to your Cargo.toml.

Bevy is self-declared as unstable, and follows a quarterly release cycle. Around every three months, a new release will include a set of breaking changes… sometimes a larger set than others.

My experience of Bevy is that it feels less like an engine, and more of a framework to build an engine. It's an engine engine. This may also be the case for game engines at large, but in my (admittedly cursory) forays into things like Unity I found that they provided specific tools and biases that got much quicker into making game logic, with minimal required hooks into the engine internals to make a game work in more like how you wanted it. Bevy feels lower-level than that, excepting that the various tools available in bevy or in the plugin ecosystem can provide those higher-level abstractions if you learn how to compose them into something larger. Rather than hooking into the engine to tweak behaviors, you compose components and systems into larger behaviors that make your engine.

I've had the idea for a particular 2d platformer since late 2020. It involves cats, and it involves aliens. It was my last foray into Bevy, and it quickly stymied me. Two big issues:

1. I am doing this in bits of bits of spare time apart from my billable work.
2. I am an idiot. I dove head-first into a rabbit warren trying to create perfect hand-drawn cat animations.
3. While I have the shell of a story, the core mechanics are still… wishy-washy.
4. Bevy breaks almost all 3rd-party plugins every 3 months.

Every time I got into the codebase, I'd get distracted by little animation problems that don't really matter at this stage of development, and could never find the time to explore the actual game mechanics. After putting it down for a month and finally finding time to open up the project, I'd find that trying to updating crates would lead to a different rabbit warren of code and version incompatibilities. Updates to the physics plugin crate might fix the problem I was seeing, but I couldn't update without updating Bevy. I couldn't update Bevy without updating all the other crates, half of which would require debugging breaking changes and filing PRs.

This means that, in my experience, trying to use plugins not directly supported by the core Bevy team is extremely frustrating. Plugins are abandoned. Many are mutually exclusive. Some are pinned to older versions of Bevy, with notices in their README stating that they'll only be maintained again once Bevy becomes more stable.

I don't fault any of the maintainers. If I was 80% done with a game, and updating my open-source crates required days or weeks of upgrading other people's repos, I'd eventually just pin to an old version and wait it out… or just leave the code inside my game, and stop publishing open-source plgins. It was just frustrating to try to start building a game, learning a new and very complicated ecosystem, when it seemed like some of the hard work could be sidestepped by combining existing open source crates, when in fact I should have just treated those as interesting examples. It also meant that I wasted a lot of time trying new plugins, when I should have instead spent the time writing my own code.

This time around it's been different.

1. Bevy 0.17 and 0.18 brought in a lot of features previously requiring custom code or 3rd-party plugins.
2. The 3rd-party crates I'm using do have Bevy plugins available, but were built with their core logic separated from Bevy-specific code in different crates. I'm just using the core crates.
3. I am starting a different game, with different mechanics that are very clear in my head. This game is an RTT inspired by one of my favorite game series from the late 1990s.
4. I'm developing each mechanic in an iterative fashion.
5. I'm starting with free open-licensed or cheaply-generated 3d assets to prove out the engine and gameplay. Mixamo yay!
6. Procedural shaders! Why have I never played around with shaders before???

The scene running at the top of this post is a quick project I threw together from some of the modules and shaders I've been developing in the game, heavily inspired by Ghost of Tsushima and the Procedural grass talk given by Eric Wohllaib at GDC a few years ago. This is massive overkill for the type of game I'm making, but is giving me the experience needed to eventually render hundreds to thousands to tens of thousands of units.

As I add more mechanics, I'll try to remember to put together more examples/proofs of concept that I can post.

If/when my game gets far enough along to really seem viable, I'll find and pay an artist to work with me on creating the real game assets from scratch. This will very likely be expensive, so I want to put that off until I have higher confidence that I will be able to get this into a game store like Steam.

If you see this and see me at a conference, in Oakland or SF, or on the internet, chat me up. I am currently very into Rust, Bevy, Elixir, and various ways of connecting the Rust and Elixir ecosystems.