Optimize Bevy Game Logic with ECS Patterns

This skill builds high-performance game logic using Bevy's data-oriented Entity-Component-System (ECS) architecture in Rust. Components are defined as simple structs deriving Component (and often Reflect for editor/inspector support), such as a Velocity { x, y } or a marker struct Player. Systems are plain Rust functions that query components - a movement_system example takes Res<Time> and a Query<(&mut Transform, &Velocity), With<Player>>, iterating matched entities to update position by velocity scaled by delta time. Global data like score or game state lives in a Resource-derived struct, mutated via ResMut inside a system (e.g. a score_system incrementing game_state.score). Systems are registered on the App builder with add_systems(Update, (system_a, system_b).chain()), where .chain() enforces a specific execution order between systems that would otherwise run in parallel. A required-component pattern (#[require(Velocity, Sprite)] on the Player component) ensures dependent components are always present when an entity is spawned with Player, and entities are spawned atomically as a tuple bundle via commands.spawn((Player, Velocity { .. }, Sprite::from_image(..))). Query filters With<T>/Without<T> narrow which entities a system iterates without manually checking inside the loop - e.g. an enemy_behavior system querying Query<&Transform, (With<Enemy>, Without<Dead>)> to skip already-dead enemies entirely. Best practices: use query filters (With, Without, Changed) to reduce iteration count, prefer Res over ResMut when read-only access suffices (since read-only access allows more systems to run in parallel), use Bundle to spawn complex multi-component entities atomically, keep components as pure data rather than embedding heavy logic in them, and avoid RefCell/interior mutability inside components since the ECS itself already handles borrowing safely. A troubleshooting note addresses the common "Conflict" panic - it occurs when two systems try to mutably access the same component while running in parallel, and the fix is either to .chain() them into a defined order or split the conflicting logic apart.

Use this skill when developing games with the Bevy engine in Rust, designing game systems that need to run in parallel for performance, optimizing game performance by minimizing cache misses through data-oriented design, or refactoring object-oriented game logic into ECS patterns. It is not for object-oriented game architectures outside Bevy, or for game logic that doesn't need Bevy's parallel scheduling - simpler patterns may suffice for small, single-threaded prototypes.

Input is game entities, their data (components), and the logic that operates on them (systems). Output is Bevy Component/Resource/System definitions registered on an App, structured for parallel execution with query filters minimizing unnecessary iteration.

Built on the Bevy game engine's ECS (bevy::prelude), using its Component/Resource/Reflect derive macros, Query/Res/ResMut system parameters, and App/Commands/Bundle APIs.

#[derive(Component, Reflect, Default)]
#[reflect(Component)]
struct Velocity {
    x: f32,
    y: f32,
}

Rust developers building games with the Bevy engine who need to structure components, systems, and resources for correct, parallel-safe, cache-friendly ECS execution.