Bevy: a data-driven Rust game engine built on ECS

What Bevy is

Bevy describes itself as "a refreshingly simple data-driven game engine built in Rust," free and open source forever. The repository at bevyengine/bevy is a large Cargo workspace: 87 MB across roughly 3,200 files, with all official crates living under the crates/ folder. It is dual-licensed MIT or Apache-2.0, at your option.

The current main branch carries version 0.20.0-dev, while the latest release tag is v0.20.1. The project follows a train-release schedule: breaking changes arrive roughly every three months, with migration guides provided. The README warns plainly that Bevy is still early-stage — features are missing and documentation is sparse — so it suits developers willing to work in that environment.

The minimum supported Rust version is 1.97.1, and the workspace uses edition 2024. Bevy leans heavily on recent compiler improvements, so its MSRV tracks close to latest stable.

The ECS core

All app logic runs through the Entity Component System paradigm. Three concepts carry the design:

• Entities are unique identifiers that correlate to zero or more components.
• Components are plain Rust structs — ordinary data stored in a World.
• Systems process entities by querying their components.

Everything is held in a World, which exposes operations to insert, read, write, and remove the data it stores. The ECS crate's own README stresses that unlike other Rust ECS implementations, Bevy uses normal Rust types for all of these concepts — no complex lifetimes, builder patterns, or macros required.

use bevy_ecs::prelude::*;

#[derive(Component)]
struct Position { x: f32, y: f32 }

Systems declare their needs through typed parameters such as Query and Commands, whose types determine the data sent to them. The scheduler runs systems in parallel when their data access allows it.

Everything is a plugin

Modularity is a core principle: all engine features are implemented as plugins, including rendering. An application assembles itself from plugins and plugin groups:

use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .run();
}

The README's example starts from App::new() and adds plugins; the built-in plugin groups let you choose the feature set. The two built-in plugin groups are DefaultPlugins and MinimalPlugins. The README uses DefaultPlugins to draw a window with standard functionality enabled.

bevy_app/src/app.rs documents that plugins cannot be added after App::cleanup() or App::finish() has been called. The README's example calls .run(), which starts the app. The docs note that plugins cannot be added after App::cleanup() or App::finish() has been called.

How the frame is scheduled

Systems are added to a Schedule, which is then run. Bevy ECS uses each system's data access information to determine what can run in parallel; systems whose queries do not conflict execute concurrently.

Like all engine features, rendering itself is implemented as a plugin rather than built into the core.

A workspace of crates

The top-level bevy crate forwards its features to bevy_internal, and the feature list gates subsystems behind Cargo flags — for example, bevy_sprite = ["bevy_internal/bevy_sprite"]. The feature list gates subsystems behind Cargo flags, for example bevy_sprite = ["bevy_internal/bevy_sprite"]; the README links a cargo-features document listing the full set of supported options.

Feature flags give fine control over what gets compiled; the README links a cargo-features document listing the supported options. Users who want a lean build disable default features and enable only what they need.

The workspace also includes compile-fail test crates for several macro crates, verifying that their diagnostic output does not accidentally change, plus mobile example projects, no_std examples, large-scene demos like Bistro and Bevy City, benchmarks under benches/, internal tools, and an errors crate that documents Bevy's error codes.

Examples across platforms

The repository ships runnable examples, including stress tests, plus mobile and no_std example projects; the README points to the official examples tree and a getting-started setup guide.

The README's quick start is direct:

git checkout latest
cargo run --example breakout

For fast iterative compiles the project recommends a "fast compiles" setup documented in its getting-started guide. The repository's README notes that the assets included for its examples typically fall under different open licenses, are not included in your game unless copied in by you, and are not distributed in the published bevy crates.

Contributing

Contributors start with the Contributor's Guide; simple problems can be opened as issues or pull requests directly, while larger architecture decisions go to GitHub Discussions first. All contributions are dual-licensed MIT/Apache-2.0 per the Apache contribution terms. The project is tested with BrowserStack and maintains a code of conduct.

Bevy's value proposition rests on being data-driven, modular, and fast — app logic runs in parallel where possible, and changes compile quickly because features can be stripped out entirely. It is a large engine with regular breaking changes, which the README says plainly: use it only if you are willing to work in that environment.