bevy_ecs

Module system

Source
Expand description

Tools for controlling behavior in an ECS application.

Systems define how an ECS based application behaves. Systems are added to a Schedule, which is then run. A system is usually written as a normal function, which is automatically converted into a system.

System functions can have parameters, through which one can query and mutate Bevy ECS state. Only types that implement SystemParam can be used, automatically fetching data from the World.

System functions often look like this:

fn update_score_system(
    mut query: Query<(&Player, &mut Score)>,
    mut round: ResMut<Round>,
) {
    for (player, mut score) in &mut query {
        if player.alive {
            score.0 += round.0;
        }
    }
    round.0 += 1;
}

§System ordering

By default, the execution of systems is parallel and not deterministic. Not all systems can run together: if a system mutably accesses data, no other system that reads or writes that data can be run at the same time. These systems are said to be incompatible.

The relative order in which incompatible systems are run matters. When this is not specified, a system order ambiguity exists in your schedule. You can explicitly order systems:

  • by calling the .before(this_system) or .after(that_system) methods when adding them to your schedule
  • by adding them to a SystemSet, and then using .configure_sets(ThisSet.before(ThatSet)) syntax to configure many systems at once
  • through the use of .add_systems((system_a, system_b, system_c).chain())

§Example

// Configure these systems to run in order using `chain()`.
schedule.add_systems((print_first, print_last).chain());
// Prints "HelloWorld!"
schedule.run(&mut world);

// Configure this system to run in between the other two systems
// using explicit dependencies.
schedule.add_systems(print_mid.after(print_first).before(print_last));
// Prints "Hello, World!"
schedule.run(&mut world);

fn print_first() {
    print!("Hello");
}
fn print_mid() {
    print!(", ");
}
fn print_last() {
    println!("World!");
}

§System parameter list

Following is the complete list of accepted types as system parameters:

In addition, the following parameters can be used when constructing a dynamic system with SystemParamBuilder, but will only provide an empty value when used with an ordinary system:

Re-exports§

  • pub use crate::change_detection::NonSendMut;
  • pub use crate::change_detection::Res;
  • pub use crate::change_detection::ResMut;

Modules§

  • lifetimeless
    Contains type aliases for built-in SystemParams with 'static lifetimes. This makes it more convenient to refer to these types in contexts where explicit lifetime annotations are required.

Structs§

Enums§

Traits§

Functions§

Type Aliases§

Derive Macros§