English for Bevy Game Developers

Bevy conversations usually involve explaining the entity-component-system (ECS) pattern to developers coming from object-oriented game engines, so the vocabulary covers entities, components, systems, and the scheduling model that governs how they interact.

Key Vocabulary

Entity-component-system (ECS) — Bevy’s architectural pattern where game objects (entities) are just IDs, behavior-defining data is attached as components, and logic lives in separate systems that operate on entities matching a given set of components. “There’s no Player class here — in the entity-component-system model, a player is just an entity with a Health, Position, and PlayerControlled component attached.”

Component — a plain data struct attached to an entity, holding state but no behavior, which systems query for when deciding which entities to act on. “Add a Stunned component to the entity instead of a boolean field on some monolithic struct — then any system that should skip stunned entities can just query for its absence.”

System — a function that queries for entities with specific components and operates on them each frame, representing a single piece of game logic decoupled from any particular entity type. “Write this as its own system that queries for Velocity and Position — don’t bury movement logic inside the system that’s supposed to handle combat.”

Query — the mechanism systems use to request the set of entities matching a component signature, optionally filtered further, giving type-safe, efficient access to exactly the data a system needs. “This query should filter on With<Enemy> and exclude With<Dead> — right now it’s iterating over dead enemies too, which is why they keep attacking after they die.”

Schedule / system ordering — Bevy’s mechanism for controlling when systems run relative to each other within a frame, including explicit ordering constraints to avoid race conditions between systems that read and write the same data. “These two systems both mutate Position — add an explicit ordering constraint in the schedule so we’re not relying on registration order to avoid a race.”

Common Phrases

• “Should this be its own component, or is it just a field that belongs on an existing one?”
• “Is this logic in the right system, or is it bleeding responsibilities that belong somewhere else?”
• “Does this query need an additional filter, or is that why dead entities are still being processed?”
• “Is the ordering between these two systems explicit in the schedule, or are we relying on registration order?”

Example Sentences

Explaining the architecture to someone from an OOP background: “There’s no inheritance hierarchy here — behavior comes from which components an entity has, and systems just query for the components they care about, regardless of what the entity ‘is’.”

Debugging unexpected behavior: “Check this query’s filters — if it’s not excluding entities with the Dead component, that explains why defeated enemies are still taking their turn.”

Reviewing a race condition: “These two systems write to the same component without an explicit ordering constraint — add one to the schedule so we’re not depending on registration order for correctness.”

Professional Tips

• Introduce entity-component-system by contrasting it directly with class hierarchies — it’s the fastest way to reorient developers coming from traditional OOP engines.
• Encourage small, focused components over large structs with many optional fields — it keeps queries precise and avoids systems processing irrelevant data.
• Keep each system doing one thing — a system handling movement, damage, and animation together is a common refactor target flagged in review.
• Flag missing explicit ordering in the schedule whenever two systems mutate the same component — implicit ordering is a frequent source of hard-to-reproduce bugs.

Practice Exercise

1. Explain the entity-component-system model to someone used to class-based inheritance in game engines.
2. Describe why a query might need an additional filter, using a dead-entity example.
3. Write a sentence explaining to a teammate why two systems need an explicit ordering constraint in the schedule.