bevy_new_2d

Instead of manually spawning multiple components every time, write functions that return impl Bundle. This allows you to define reusable entity templates and compose them into hierarchies.

Capabilities:

• Composition: Combine multiple components into one bundle.
• Extension: Create a new bundle function that calls an existing one and adds more components.
• Hierarchies: Use children![] within a bundle function to define complex entity trees.

Limitations:

• No Dependency Injection: You must pass required resources (like AssetServer) as arguments through the hierarchy.
• No Component Replacement: You cannot easily 'override' a component within a bundle function; you must either add it via .insert() after spawning or modify the function arguments.

pub fn monster(health: u32, transform: Transform) -> impl Bundle {
    (
        Name::new("Monster"),
        Health::new(health),
        transform,
    )
}

// Extending a bundle
pub fn boss_monster(transform: Transform) -> impl Bundle {
    (
        monster(1000, transform),
        Better,
        Faster,
        Stronger,
    )
}

// Composing hierarchies
pub fn dangerous_forest() -> impl Bundle {
    (
        Name::new("Dangerous Forest"),
        Transform::default(),
        children![
            monster(100, Transform::from_xyz(10.0, 0.0, 0.0)),
            boss_monster(Transform::from_xyz(0.0, 0.0, 0.0)),
        ],
    )
}

// Spawning
fn spawn_dangerous_forest(mut commands: Commands) {
    commands.spawn(dangerous_forest());
}

Use a dedicated States enum (e.g., Screen) to represent different logical phases of your game, such as Splash, Loading, Title, or Gameplay.

To implement a screen:

1. Define the State: Create an enum deriving States.
2. Setup/Teardown: Use OnEnter(Screen::Name) and OnExit(Screen::Name) schedules in a plugin to handle spawning and cleaning up entities.
3. Automatic Cleanup: Attach the DespawnOnExit(Screen::Name) component to entities spawned for a specific screen so they are automatically removed when transitioning away.
4. Transitions: Use the NextState<Screen> resource to trigger transitions (e.g., next_state.set(Screen::Title)).

#define the state
#[derive(States, Debug, Hash, PartialEq, Eq, Clone, Default)]
pub enum Screen {
    #[default]
    Splash,
    Loading,
    Title,
    Gameplay,
    // ...
}

# handle setup and teardown
pub(super) fn plugin(app: &mut App) {
    app.add_systems(OnEnter(Screen::Victory), spawn_victory_screen);
    app.add_systems(OnExit(Screen::Victory), reset_highscore);
}

fn spawn_victory_screen(mut commands: Commands) {
    commands.spawn((
        widget::ui_root("Victory Screen"),
        DespawnOnExit(Screen::Victory),
        children![
            // UI elements.
        ],
    ));
}

# transition
fn enter_title_screen(mut next_state: ResMut<NextState<Screen>>) {
    next_state.set(Screen::Title);
}

To avoid gameplay hitches, preload assets by defining a Resource that holds your asset Handles.

1. Define the Resource: Create a struct with Handle fields. Use the #[dependency] attribute on fields to ensure the resource is only considered 'loaded' once those specific assets are ready.
2. Implement FromWorld: Use FromWorld to initialize the handles using the AssetServer.
3. Trigger Loading: Use the app.load_resource::<YourResource>() extension method (provided by src/asset_tracking.rs) in your plugin setup to start the loading process at startup.

#define the collection
#[derive(Resource, Asset, Clone, Reflect)]
#[reflect(Resource)]
struct ActorAssets {
    #[dependency]
    player: Handle<Image>,
    #[dependency]
    enemies: Vec<Handle<Image>>,
}

impl FromWorld for ActorAssets {
    fn from_world(world: &mut World) -> Self {
        let assets = world.resource::<AssetServer>();
        Self {
            player: assets.load("images/player.png"),
            enemies: vec![assets.load("images/enemy1.png")],
        }
    }
}

# start preloading in a plugin
pub(super) fn plugin(app: &mut App) {
    app.load_resource::<ActorAssets>();
}