The ECS Mindset
Entities, components, and systems.
The ECS Mindset is a free Learn Rust Coding lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Learn Rust Coding learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
What ECS Solves
Bevy is built on the Entity Component System (ECS) pattern. Instead of deep inheritance hierarchies, you compose behavior from small, independent pieces of data.
This data-oriented design keeps memory layout cache-friendly and lets the engine parallelize work across CPU cores almost for free.
Entities Are Just IDs
An entity is nothing but a lightweight identifier — a generational index. It owns no data and has no behavior on its own.
Think of it as a key in a database row. Components attached to that key give the entity meaning, like "Player" or "Bullet".
// An Entity is a tiny handle
struct Entity {
index: u32,
generation: u32,
}Components Are Pure Data
Components are plain Rust structs that derive Component. They carry state but contain no logic.
Keep them small and focused. A position, a velocity, and a health value are three separate components rather than one monolithic struct.
use bevy::prelude::*;
#[derive(Component)]
struct Position { x: f32, y: f32 }
#[derive(Component)]
struct Velocity { x: f32, y: f32 }Systems Hold the Logic
Systems are ordinary functions that operate on components. They are where all your game logic lives.
Bevy inspects each system's parameters to figure out what data it touches, then schedules systems that don't conflict to run in parallel.
fn move_system(mut query: Query<(&mut Position, &Velocity)>) {
for (mut pos, vel) in &mut query {
pos.x += vel.x;
pos.y += vel.y;
}
}Queries: Asking for Data
A Query declaratively requests entities that have a specific set of components. Bevy returns only matching entities.
You can request shared access with &T or exclusive access with &mut T. This borrow information drives the parallel scheduler.
// Entities with BOTH Position and Velocity
fn report(query: Query<(&Position, &Velocity)>) {
for (pos, vel) in &query {
info!("at {},{} moving {},{}", pos.x, pos.y, vel.x, vel.y);
}
}Filtering Queries
The second type parameter of a Query is a filter. Use With and Without to narrow results without borrowing that component's data.
This is ideal for tag components — empty structs that mark an entity's role.
#[derive(Component)]
struct Player;
fn player_only(query: Query<&Position, With<Player>>) {
for pos in &query {
info!("player at {},{}", pos.x, pos.y);
}
}Resources: Global State
Some data is unique to the whole game — a score, the elapsed time, or game settings. These live as resources rather than components.
Access them in systems with Res<T> for read access or ResMut<T> for write access.
#[derive(Resource)]
struct Score(u32);
fn show_score(score: Res<Score>) {
info!("Score: {}", score.0);
}The App Builder
Everything is wired together in the App. You add plugins, insert resources, and register systems against a schedule.
DefaultPlugins brings windowing, rendering, input, and time so you can focus on gameplay.
fn main() {
App::new()
.add_plugins(DefaultPlugins)
.insert_resource(Score(0))
.add_systems(Update, show_score)
.run();
}Schedules: Startup vs Update
Systems run inside schedules. Startup runs once when the app launches — perfect for spawning the world.
Update runs every frame and is where movement, input, and logic belong. Bevy also offers FixedUpdate for deterministic physics steps.
App::new()
.add_plugins(DefaultPlugins)
.add_systems(Startup, setup)
.add_systems(Update, move_system)
.run();Why Composition Wins
Want a flying enemy that can be poisoned? Just attach Flying and Poisoned components. No new class, no inheritance chain.
Behavior emerges from which systems match which component combinations. This makes features additive and refactors cheap.
// Same systems, new combinations
commands.spawn((Position{x:0.0,y:0.0}, Velocity{x:1.0,y:0.0}, Flying, Poisoned));Parallelism for Free
Because each system declares its data access, Bevy's scheduler knows which systems conflict. Non-conflicting systems run on different threads automatically.
You write single-threaded-looking code, and the engine extracts parallelism from your borrow declarations. No locks, no manual threading.
Quick Check
Test your understanding of ECS roles.
Recap: The ECS Mindset
Entities are IDs, components are data, systems are logic, and resources are global state. The App ties them together through schedules.
By composing small components and letting systems match them, you get flexible, parallel, cache-friendly games. Next we'll spawn entities and make them move.
Frequently asked questions
Is the “The ECS Mindset” lesson free?
Yes — the full text of “The ECS Mindset” is free to read here on the web, and the Learn Rust Coding course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Learn Rust Coding course, upgrade to CoddyKit PRO.
What will I learn in “The ECS Mindset”?
Entities, components, and systems. You practise Learn Rust Coding with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Learn Rust Coding?
No prior experience is required. Learn Rust Coding on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “The ECS Mindset” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Learn Rust Coding lesson?
Yes. Every Learn Rust Coding lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.