Bevy 0.15 Review: The Rust Game Engine That Refuses to Compromise

Every few years, a game engine shows up that makes you rethink how engines should work. Bevy is that engine right now. It's written in Rust, uses an Entity Component System architecture by default, compiles to native code, and has no visual editor. It breaks almost every convention that Unity and Godot established. And I think it might be building the future of game development, even if it's not quite ready to ship your next game.

I spent three months building a 2D action roguelike with Bevy 0.15. Not a tutorial project, not a demo. A real game with enemy AI, procedural generation, particle effects, save/load, and controller support. Here's what I found.

What Bevy Actually Is

Bevy is an open-source game engine written in Rust by Carter Anderson, with a growing team of contributors. It launched in 2020 and has been iterating rapidly since then. Version 0.15, released in late 2025, is the most complete version yet.

The two things that define Bevy are Rust and ECS. If you don't care about either, you can stop reading. Bevy isn't trying to be a better Unity. It's trying to be something fundamentally different.

ECS stands for Entity Component System. Instead of inheriting from a GameObject or Node base class, you create entities (just IDs), attach components to them (plain data structs), and write systems (functions) that operate on entities matching specific component queries. There's no class hierarchy. No inheritance. No scene tree. Your game is a database of components, and your logic is a set of queries against that database.

This sounds academic until you use it. Then it clicks.

The ECS Advantage: Not Just Architecture Astronautics

I was skeptical. I've shipped games with Unity's MonoBehaviour pattern and Godot's node tree. Both work. The ECS pitch, "better data locality, automatic parallelism, cleaner composition", always felt like something that mattered more in conference talks than in actual game code.

Then I built enemy AI in Bevy, and I changed my mind.

In Unity, my enemy scripts tend to become god objects. The EnemyController grows methods for movement, combat, pathfinding, animation state, and death. You can break these into separate components, but Unity's architecture fights you when you try. In Bevy, these concerns are naturally separate because that's how ECS works:

// Each concern is its own system operating on its own components
fn enemy_movement_system(
    mut query: Query<(&mut Transform, &Velocity, &EnemyState)>,
    time: Res,
) {
    for (mut transform, velocity, state) in &mut query {
        if *state == EnemyState::Pursuing {
            transform.translation += velocity.0 * time.delta_secs();
        }
    }
}

fn enemy_combat_system(
    enemies: Query<(&Transform, &AttackRange, &Damage), With>,
    players: Query<(&Transform, &Health), With>,
    mut damage_events: EventWriter,
) {
    // Clean separation. This system doesn't know about movement.
}

When I had 200 enemies on screen, Bevy's scheduler automatically parallelized these systems across CPU cores. I didn't write any threading code. I didn't manage any mutexes. Bevy looked at my system signatures, figured out which ones could safely run in parallel, and did it. On my M2 MacBook Pro, the enemy AI tick went from 4.2ms (single-threaded equivalent) to 1.1ms.

That's not a synthetic benchmark. That's my actual game.

Rust: The Price of Admission

You can't use Bevy without learning Rust. There's no scripting layer, no visual scripting, no "easy mode." This is both Bevy's greatest strength and its biggest barrier.

Rust's ownership model prevents entire categories of bugs that plague game development. Use-after-free, data races, null pointer dereferences. These don't exist in safe Rust. When your Bevy game compiles, you know with mathematical certainty that you don't have memory corruption bugs. After years of chasing mysterious crashes in C++ game code, this feels like a superpower.

The cost is the learning curve. Rust's borrow checker is notorious for a reason. I've been writing Rust for two years, and I still occasionally fight with lifetimes. If you're coming from GDScript or C#, expect four to six weeks of frustration before you're productive. Not "slightly slower." Genuinely frustrated, staring at compiler errors that feel adversarial.

The compiler errors are excellent, though. Rustc tells you what went wrong and usually suggests a fix. It's the most helpful compiler I've ever used. The friction isn't that the errors are cryptic. It's that there are so many new concepts to internalize: ownership, borrowing, lifetimes, traits, generics, the orphan rule.

If you already know Rust, Bevy is a joy. If you don't, budget real learning time. This is not a "learn as you go" language.

Developer Experience: The Editor-Shaped Hole

Here's where Bevy's idealism collides with reality. There is no visual editor. No scene tree you can click through. No inspector panel to tweak values at runtime. No drag-and-drop asset pipeline. Everything is code.

Want to position a sprite? Write code. Want to set up a collision shape? Write code. Want to adjust the tint of a light? Recompile. (Or use bevy-inspector-egui, which gives you a runtime inspector, but it's a third-party plugin, not a first-class experience.)

For programmers who live in their text editors, this is fine. I use Neovim with rust-analyzer, and my iteration workflow is genuinely fast. Bevy supports hot reloading of assets (textures, audio, scenes defined in .ron files), and the bevy_mod_hot_reload crate adds hot reloading for Rust code in some cases. Incremental compile times on 0.15 are around 2-4 seconds for small changes on Apple Silicon. That's workable.

But level design without a visual editor is painful. I built my roguelike's rooms using procedural generation partly because hand-crafting levels in code is tedious. If your game needs hand-designed levels, detailed tilemaps, or careful visual composition, the lack of an editor is a real problem, not a minor inconvenience.

The Bevy Editor is in development. The team has been working on it since 2024, and there are screenshots and early builds floating around. But it's not shipped in 0.15, and I'm reviewing what exists today, not what's promised.

The Bevy Ecosystem in 2026

Bevy's plugin ecosystem has grown significantly. The community maintains a curated list at bevyengine.org/assets, and the quality of popular crates is high. Here's what I used in my project:

The problem isn't quality. It's compatibility. When Bevy 0.15 released, most of these crates took two to eight weeks to update. During that window, you're either pinned to the old Bevy version or patching crates yourself. This is the tax you pay for a pre-1.0 engine with no stability guarantees.

Leafwing-input-manager deserves a specific callout. It's an input abstraction layer that lets you define input actions declaratively and bind them to keyboard, mouse, or gamepad inputs. It handles input buffering, chords, and virtual dpads. I've used Unity's Input System and Godot's InputMap, and leafwing is better than both. The Bevy community builds excellent libraries when they have a clear problem to solve.

Performance: Where Bevy Flexes

Bevy is fast. Not "fast for a game engine written in a memory-safe language" fast. Actually fast.

My roguelike runs at a locked 120fps on an M2 MacBook Pro with 200+ enemies, hundreds of particle effects, and a procedurally generated tilemap. The same game logic ported to Godot 4.4 (which I did as an experiment) ran at around 85fps under identical conditions. That's not a knock on Godot. It's an indication of what Rust's zero-cost abstractions and Bevy's data-oriented architecture actually deliver.

Bevy's renderer uses wgpu, a Rust implementation of the WebGPU API. This means it runs on Vulkan, Metal, DX12, and WebGPU depending on the platform. The render graph in 0.15 is flexible and well-designed. You can add custom render passes without fighting the engine.

For 3D, Bevy 0.15 supports PBR materials, cascaded shadow maps, screen-space ambient occlusion, bloom, and TAA. It's not at Unreal's level, obviously. But for stylized 3D (think Valheim or Hollow Knight's 2.5D approach), it's capable. Several Bevy community members have built impressive 3D demos, including voxel engines and terrain systems that handle millions of triangles.

The area where performance matters most is iteration speed. Fresh compile times are rough: 3-5 minutes on my M2 for a clean build of a medium project. Incremental compiles are 2-4 seconds. Dynamic linking (a Bevy feature flag) can cut incremental times further, but it adds complexity to your build setup. This is better than it was in 0.13, where incremental compiles regularly hit 8-10 seconds.

What's New in 0.15 Specifically

Bevy 0.15 brought several changes that matter for practical development:

• Required Components: You can now mark components as required, so spawning a Sprite automatically includes Transform and Visibility. This eliminates an entire class of "forgot to add a component" bugs that plagued earlier versions.
• Improved Scene System: The new BSN (Bevy Scene Notation) format is more readable and supports composition better than the old .ron scene files.
• Entity Relationships: First-class support for parent-child and custom relationships between entities. This replaces the old Parent/Children components with a more flexible system.
• Better Error Messages: System parameter validation now gives clear errors when you write a query that can't work, instead of silently returning no results.
• Animation Improvements: The animation system got a significant rework. Animation graphs, blend trees, and transitions actually work now. In 0.13, animation was something you worked around. In 0.15, it's usable.

The migration from 0.14 to 0.15 was not trivial. I spent about two days updating my project. The Required Components change alone touched almost every spawn call in my codebase. Bevy publishes migration guides, and they're thorough, but "thorough migration guide" still means "your code breaks every release."

Who Should Use Bevy in 2026

I think Bevy is the right choice for a specific kind of developer, and genuinely wrong for others. Here's my honest breakdown:

Use Bevy if:

• You already know Rust and want to make games in a language you love
• You're building a simulation-heavy game where ECS parallelism matters (colony sims, strategy games, anything with lots of entities)
• You care more about code architecture than visual editing workflows
• You're comfortable with an engine that's still evolving and will break your code periodically
• You're targeting desktop and web (WASM export works well)

Don't use Bevy if:

• You need to ship a commercial game in the next 6 months
• Your game requires console exports (Switch, PlayStation, Xbox)
• You're learning to program for the first time
• You need a visual editor for level design or UI layout
• Plugin ecosystem stability matters more to you than architectural purity

Bevy vs The Establishment

If I'm being honest, Godot is the better choice for most indie developers today. It has the editor. It has the stability. It has the gentler learning curve. If you want to make a game and ship it this year, use Godot.

But Bevy is solving problems that Godot and Unity haven't. Automatic parallelism that actually works. Compile-time safety that prevents runtime bugs. An architecture that scales cleanly from 10 entities to 100,000. These aren't theoretical advantages. I measured them in my own project.

Games Built With Bevy

The "but has anyone shipped a real game?" question is fair. Bevy's shipped game list is short but growing. Tiny Glade, the relaxing castle-building game by Pounce Light, started as a Bevy project before the studio moved to a custom engine (though they've credited Bevy's influence on their architecture). Several game jam entries place well regularly, including entries in GMTK Game Jam and Ludum Dare.

Molecoole, a co-op action game, shipped on Steam using Bevy. Okhlos-style games with large entity counts are where Bevy projects tend to gravitate. The engine naturally rewards designs that play to ECS strengths: lots of similar entities, emergent behavior from system interactions, simulation-heavy mechanics.

Nobody has shipped a Bevy game that broke into mainstream visibility yet. That's an honest assessment. The engine's commercial track record is thin. Whether that's because Bevy isn't ready, or because the developers using it haven't shipped yet, is an open question.

The Compile Time Question

I need to address this directly because it comes up in every Bevy discussion. Yes, Rust compile times are long. A clean build of my project takes about 4 minutes. Incremental builds take 2-4 seconds. In practice, the incremental time is what matters during development, and 2-4 seconds is acceptable. Not great. Acceptable.

For comparison, my Godot project reloads scripts in under a second. Unity's domain reload after a C# change takes 3-7 seconds depending on project size. Bevy's incremental compile is in the same ballpark as Unity's reload, which surprised me.

The strategies that help: use dynamic linking during development (add the "dynamic_linking" feature flag), keep your crate dependency tree shallow, and split your game into multiple crates so Rust only recompiles what changed. The Bevy community has good documentation on optimizing compile times, and it's improved significantly since 0.12.

The Verdict