DEV Community: Sébastien Belzile

Making Games in Rust - Part 13 - Monster AI

Sébastien Belzile — Mon, 07 Feb 2022 11:22:10 +0000

Our monsters currently are boring inanimate red square. It would be great if they could somewhat be more aggressive. This article will implement a Super Mario type of monster AI: they will move from left to right, and change direction as they meet obstacles. To that, we will learn how to make them jump and shoot.

Monster AI Plugin

Let's start by creating a monster_ai module into the game folder.
Declare and publish the module into the src/game/mod.rs file:
```
mod monster_ai;
pub use monster_ai::*;
```

In the monster_ai.rs file, declare a Bevy MonsterAiPlugin:

pub struct MonsterAiPlugin;

impl Plugin for MonsterAiPlugin {
    fn build(&self, app: &mut AppBuilder) {}
}

In the game module, register the plugin:
```
.add_plugin(MonsterAiPlugin)
```

Monsters are Walkers

The first thing our monsters should do is walk. To do so:

Edit the Monster struct in components.rs to provide a speed and a facing_direction:

pub struct Monster {
    pub speed: f32,
    pub facing_direction: GameDirection,
}

In, monsters.rs, add values to this component to the monster entity:

.insert(Monster { speed: 3., facing_direction: GameDirection::Right })

In monster_ai, add a monster walking system. The code sets the velocity of the monster to their speed in the direction they are facing:

fn monster_walking_system(mut monsters: Query<(&Monster, &mut RigidBodyVelocity)>) {
    for (monster, mut velocity) in monsters.iter_mut() {
        let speed = match monster.facing_direction {
            GameDirection::Left => -monster.speed,
            GameDirection::Right => monster.speed,
        };

        velocity.linvel = Vec2::new(speed, velocity.linvel.y).into();
    }
}

impl Plugin for MonsterAiPlugin {
    fn build(&self, app: &mut AppBuilder) {
        app.add_event::<MonsterWalkedIntoWallEvent>()
            .add_system_set(SystemSet::on_update(AppState::InGame).with_system(monster_walking_system.system())
        )
    }
}

If you run the game now, the monsters should all walk right until they get stuck.

Monsters Change Direction on Contacts:

To make the monsters change their direction, we will trigger an event when monsters get in contact with with something, and react to this event to change the direction of our monsters.

Declare an event for when your monsters hit a wall:

struct MonsterWalkedIntoWallEvent {
    entity: Entity,
}

Add a system to trigger an event when the contact actually happens:

fn monster_wall_contact_detection(
    monsters: Query<Entity, With<Monster>>,
    mut contact_events: EventReader<ContactEvent>,
    mut send_monster_walked_into_wall: EventWriter<MonsterWalkedIntoWallEvent>
) {
    for contact_event in contact_events.iter() {
        if let ContactEvent::Started(h1, h2) = contact_event {
            for monster in monsters.iter() {
                if h1.entity() == monster || h2.entity() == monster {
                    send_monster_walked_into_wall.send(MonsterWalkedIntoWallEvent { entity: monster })
                }
            }
        }
    }
}

Add another system to handle the direction change:

fn monster_change_direction_on_contact(mut events: EventReader<MonsterWalkedIntoWallEvent>, mut monster_query: Query<&mut Monster>) {
    for event in events.iter() {
        // bullet contacts may destroy monster before running this system.
        if let Ok(mut monster) = monster_query.get_mut(event.entity) {
            monster.facing_direction = match monster.facing_direction {
                GameDirection::Left => GameDirection::Right,
                GameDirection::Right => GameDirection::Left
            }
        }
    }
}

New thing here: query.get_mut(entity) allows us to query a specific entity by ID.

Note that since event reaction may be caused by a bullet, monster destruction may happen before the change of direction. This is why we ignore monsters that are not found.

.with_system(monster_wall_contact_detection.system())
.with_system(monster_change_direction_on_contact.system())

Running the game now should show that the monsters change their direction when they get in contact with a wall or another monster.

Ramdom Jumps

This section shows how to make the monsters jump from time to time. The same logic can be used to make the monsters shoot bullets to our player.

In monsters.rs, add a jumper component to our monster:

.insert(Jumper {
    jump_impulse: 14.,
    is_jumping: false,
})

Add a jump system for our monsters in monster_ai.rs:

fn monster_jumps(mut monsters: Query<(&mut Jumper, &mut RigidBodyVelocity), With<Monster>>,) {
    for (monster, mut velocity) in monsters.iter_mut() {
        if should_jump() {
            velocity.linvel = Vec2::new(0., monster.jump_impulse).into();
        }
    }
}

fn should_jump() -> bool {
    let mut rng = thread_rng();
    rng.gen_bool(0.1)
}

This system has a 10% chance of making our monster jump.

.add_system_set(
    SystemSet::new()
        .with_run_criteria(FixedTimestep::step(2.0))
        .with_system(monster_jumps.system())
);

Running the game now should show that our monsters jump randomly from time to time.

Final Thoughts

In this tutorial, we learned the basis for implementing a Mario Bros like type of monster AI. There are still a few issues with our current implementations: floor collisions are detected as wall contacts, and our monsters may get stuck on walls after they jumped or fall.

We also learned how to make our player do some actions at random. As mentioned, we could make our monster shoot random bullets this way.

The final code is available here.

A fully playable version of the game is available here.

Making Games in Rust - Part 12 - Better Code with Events

Sébastien Belzile — Mon, 31 Jan 2022 12:35:22 +0000

Up until now, we have been killing monsters and players by despawning their entity. This works fine, but we might want more than that: adding an explosion, render blood, play a death sound, etc.

This can easily be done by adding more code to our current "death" systems, but this would also mean more dependencies to our system's function, and a bigger code block that will keep growing as we add more "reactions".

Furthermore, we might also want to add more "causes of death": our player can die from touching a monster, but monsters could shoot bullets too. Those bullets could kill our player as well. Implementing this would mean that we should include all the death reactions dependencies to a system that detects bullet collisions with our player.

I hope you see where this is going: the way we coded the death of our player and of our monsters do not scale very well... Our code would be better if we could separate an event occurrence (bullet hitting a monster or a player) from an event reaction (despawning the monster or the player).

In Bevy, events are there for this reason. This article explains the basis of events and refactors part of our code to include them in the design.

Events in Bevy

You can trigger an event in a system with an EventWriter:

mut my_event_writter: EventWriter<MyEvent>,
// ...
my_event_writter.send(event);

You can react to events in your systems with an EventReader:

fn on_my_event(
    mut my_event_reader: EventReader<MyEvent>
) {
    for event in my_event_reader.iter() {
        // do something
    }
}

An event in Bevy is a plain old rust struct:

pub struct MyEvent {
    entity: Entity,
    some_other_prop: f32,
}

It is important to note that events must be registered on your AppBuilder:

.add_event::<MyEvent>()

Now, let's see them in action.

Monsters Should Shoot Bullets Too

If monsters were to shoot bullet as well, it would be a good idea to isolate bullet creation to it's own system. One way to do this, would be to add a "bullet fired" event:

pub struct BulletFiredEvent {
    pub position: Vec2,
    pub direction: GameDirection,
}

A bullet fired event needs to have a position attribute (where the bullet is shot from), and a direction (left or right).

To shoot our bullet, we could rewrite our fire controller to trigger the event:

pub fn fire_controller(
    keyboard_input: Res<Input<KeyCode>>,
    mut send_fire_event: EventWriter<BulletFiredEvent>,
    players: Query<(&Player, &RigidBodyPosition), With<Player>>,
) {
    if keyboard_input.just_pressed(KeyCode::Space) {
        for (player, position) in players.iter() {
            let event = BulletFiredEvent {
                position: Vec2::new(position.position.translation.x, position.position.translation.y),
                direction: player.facing_direction,
            };
            send_fire_event.send(event);
        }
    }
}

And react to it via an on_bullet_fired system:

pub fn on_bullet_fired(
    mut commands: Commands,
    materials: Res<Materials>,
    mut bullet_fired_events: EventReader<BulletFiredEvent>,
) {
    for event in bullet_fired_events.iter() {
        insert_bullet_at(&mut commands, &materials, event)
    }
}

Don't forget to register the event before trying it:

.add_event::<BulletFiredEvent>()

A Player could have Multiple Lives

Players and monsters could have multiple lives.

We could easily add this behaviour with new events:

pub struct PlayerHitEvent {
    entity: Entity,
}

pub struct PlayerDeathEvent {
    entity: Entity,
}

We may then rewrite our death_by_height system to trigger a death event:

fn death_by_height(
    mut send_player_death: EventWriter<PlayerDeathEvent>,
    players: Query<(Entity, &RigidBodyPosition), With<Player>>,
) {
    for (entity, position) in players.iter() {
        if position.position.translation.y < -1. {
            send_player_death.send(PlayerDeathEvent { entity })
        }
    }
}

And the death_by_enemy system to trigger a player hit event:

pub fn death_by_enemy(
    mut send_player_hit: EventWriter<PlayerHitEvent>,
    players: Query<Entity, With<Player>>,
    enemies: Query<Entity, With<Enemy>>,
    mut contact_events: EventReader<ContactEvent>,
) {
    for contact_event in contact_events.iter() {
        if let ContactEvent::Started(h1, h2) = contact_event {
            for player in players.iter() {
                for enemy in enemies.iter() {
                    if (h1.entity() == player && h2.entity() == enemy)
                        || (h1.entity() == enemy && h2.entity() == player)
                    {
                        send_player_hit.send(PlayerHitEvent { entity: player })
                    }
                }
            }
        }
    }
}

Finally, we can implement the reactions:

fn on_player_hit(
    mut player_hit_events: EventReader<PlayerHitEvent>,
    mut send_player_death: EventWriter<PlayerDeathEvent>,
) {
    for event in player_hit_events.iter() {
        send_player_death.send(PlayerDeathEvent {
            entity: event.entity,
        })
    }
}

fn on_player_dead(mut player_death_events: EventReader<PlayerDeathEvent>, mut commands: Commands) {
    for event in player_death_events.iter() {
        commands.entity(event.entity).despawn_recursive()
    }
}

Here, we added a on_player_hit event, which triggers a player death event (multiple lives would be handled in there), and a on_player_dead which contain our reaction code to despawn our player.

Don't forget to register the events:

.add_event::<PlayerHitEvent>()
.add_event::<PlayerDeathEvent>()

The same can be done for monsters:

pub struct MonsterHitEvent {
    pub entity: Entity,
}

pub struct MonsterDeathEvent {
    entity: Entity,
}

Living Being Component

A monster loosing a life is no different from a player loosing a life. A monster dying is no different from a player dying. A bullet could kill a monster or a player. Falling into a hole could kill a monster just like it kills a player.

We could simplify our code even more if we could extract what is common to both.

Let's create a living_being module, and move our Player events to it, along with the systems that trigger or react to these events. Then, let's replace the word player by the word living_being:

use bevy::prelude::*;
use bevy_rapier2d::prelude::RigidBodyPosition;

pub struct LivingBeing;

pub struct LivingBeingHitEvent {
    pub entity: Entity,
}

pub struct LivingBeingDeathEvent {
    pub entity: Entity,
}

pub fn on_living_being_hit(
    mut living_being_hit_events: EventReader<LivingBeingHitEvent>,
    mut send_living_being_death: EventWriter<LivingBeingDeathEvent>,
) {
    for event in living_being_hit_events.iter() {
        send_living_being_death.send(LivingBeingDeathEvent {
            entity: event.entity,
        })
    }
}

pub fn on_living_being_dead(
    mut living_being_death_events: EventReader<LivingBeingDeathEvent>,
    mut commands: Commands,
) {
    for event in living_being_death_events.iter() {
        commands.entity(event.entity).despawn_recursive()
    }
}

pub fn death_by_height(
    mut send_death_event: EventWriter<LivingBeingDeathEvent>,
    living_being: Query<(Entity, &RigidBodyPosition), With<LivingBeing>>,
) {
    for (entity, position) in living_being.iter() {
        if position.position.translation.y < -1. {
            send_death_event.send(LivingBeingDeathEvent { entity })
        }
    }
}

Then, where a MonsterHitEvent or a PlayerHitEvent is triggered, replace the event by a LivingBeingHitEvent. Do the same with reactions, and with Death events.

Finally, remove any duplicated code, and remove the specific event definitions (MonsterHitEvent, PlayerHitEvent, etc).

Do not forget to register the new events:

.add_event::<LivingBeingHitEvent>()
.add_event::<LivingBeingDeathEvent>()

and to add the LivingBeing component to your player and monsters:

// player.rs
.insert(LivingBeing)
.insert(Player {

// monsters.rs
.insert(LivingBeing)
.insert(Enemy)
.insert(Monster);

Running the game should confirm that everything still works the same.

The final code is available here.

Making Games in Rust - Part 11 - Killing Monsters with Bullets

Sébastien Belzile — Mon, 24 Jan 2022 12:06:31 +0000

Getting killed is not cool. On the other hand, killing monsters is. This article will implement shooting bullets and make them kill monsters on contact.

Components

Let's start by adding the required components:

#[derive(Copy, Clone)]
pub enum GameDirection {
    Left,
    Right
}

pub struct Bullet;

The Bullet component will be used to identify our bullets entities.

The GameDirection will be used to fire our bullets in the right direction.

Drawing Bullets

Let's create a file called bullets.rs that will contain the required code to create a new bullet:

pub struct BulletOptions {
    pub x: f32,
    pub y: f32,
    pub direction: GameDirection,
}

pub fn insert_bullet_at(
    commands: &mut Commands,
    materials: &Res<Materials>,
    options: BulletOptions,
) {
    let speed = match options.direction {
        GameDirection::Left => -14.0,
        _ => 14.0,
    };

    let x = match options.direction {
        GameDirection::Left => options.x - 1.,
        _ => options.x + 1.,
    };
    let rigid_body = RigidBodyBundle {
        position: Vec2::new(x, options.y).into(),
        velocity: RigidBodyVelocity {
            linvel: Vec2::new(speed, 0.0).into(),
            ..Default::default()
        },
        mass_properties: RigidBodyMassPropsFlags::ROTATION_LOCKED.into(),
        activation: RigidBodyActivation::cannot_sleep(),
        forces: RigidBodyForces {
            gravity_scale: 0.,
            ..Default::default()
        },
        ..Default::default()
    };

    let collider = ColliderBundle {
        shape: ColliderShape::cuboid(0.25, 0.05),
        flags: ColliderFlags {
            active_events: ActiveEvents::CONTACT_EVENTS,
            ..Default::default()
        },
        ..Default::default()
    };

    let sprite = SpriteBundle {
        material: materials.bullet_material.clone(),
        sprite: Sprite::new(Vec2::new(0.5, 0.1)),
        ..Default::default()
    };

    commands
        .spawn_bundle(sprite)
        .insert_bundle(rigid_body)
        .insert_bundle(collider)
        .insert(RigidBodyPositionSync::Discrete)
        .insert(Bullet);
}

This code contains the usual boilerplate to create a new entity. It creates a rigid body, a collider and a sprite. The collider must enable the CONTACT_EVENTS flag. The color of our bullets will be yellow. Here is the code to declare the bullet material:

// src/game/mod.rs
bullet_material: materials.add(Color::rgb(0.8, 0.8, 0.).into()),

// src/game/components.rs
pub struct Materials {
    pub player_material: Handle<ColorMaterial>,
    pub floor_material: Handle<ColorMaterial>,
    pub monster_material: Handle<ColorMaterial>,
    pub bullet_material: Handle<ColorMaterial>,
}

Shooting Bullets

In our player.rs file, we can add a system that will create a new bullet whenever the space bar is pressed:

// in build method of PlayerPlugin
SystemSet::on_update(AppState::InGame)
    .with_system(fire_controller.system())

// system implementation
pub fn fire_controller(
    keyboard_input: Res<Input<KeyCode>>,
    mut commands: Commands,
    materials: Res<Materials>,
    players: Query<(&Player, &RigidBodyPosition), With<Player>>,
) {
    if keyboard_input.just_pressed(KeyCode::Space) {
        for (player, position) in players.iter() {
            let options = BulletOptions {
                x: position.position.translation.x,
                y: position.position.translation.y,
                direction: GameDirection::Right,
            };
            insert_bullet_at(&mut commands, &materials, options)
        }
    }
}

Compiling and running the game should show that pressing space shoots useless bullets. Useless since they do not kill monsters...

Killing Monsters

To kill monsters, we can add a system that detects contacts between monsters and bullets:

// in build method of PlayerPlugin
SystemSet::on_update(AppState::InGame)
    .with_system(kill_on_contact.system())

// system implementation
pub fn kill_on_contact(
    mut commands: Commands,
    bullets: Query<Entity, With<Bullet>>,
    enemies: Query<Entity, With<Enemy>>,
    mut contact_events: EventReader<ContactEvent>,
) {
    for contact_event in contact_events.iter() {
        if let ContactEvent::Started(h1, h2) = contact_event {
            for bullet in bullets.iter() {
                for enemy in enemies.iter() {
                    if (h1.entity() == bullet && h2.entity() == enemy)
                        || (h1.entity() == enemy && h2.entity() == bullet)
                    {
                        commands.entity(enemy).despawn_recursive();
                    }
                }
            }
        }
    }
}

Try running the game and try shooting at monsters. Monsters should now disappear when they are hit by a bullet.

Destroying Bullets

Our bullets are currently eternal. They do not disappear after hitting a monster, and they get stuck on walls. We should despawn them whenever they hit something:

// in build method of PlayerPlugin
SystemSet::on_update(AppState::InGame)
    .with_system(destroy_bullet_on_contact.system())

// system implementation
pub fn destroy_bullet_on_contact(
    mut commands: Commands,
    bullets: Query<Entity, With<Bullet>>,
    mut contact_events: EventReader<ContactEvent>,
) {
    for contact_event in contact_events.iter() {
        if let ContactEvent::Started(h1, h2) = contact_event {
            for bullet in bullets.iter() {
                if h1.entity() == bullet || h2.entity() == bullet {
                    commands.entity(bullet).despawn_recursive();
                }
            }
        }
    }
}

Shooting Left

Our player always shoots in a single direction... It would be better if we could select the direction we shoot to. To do so, we will add a facing direction to our player:

// src/game/components.rs
pub struct Player {
    pub speed: f32,
    pub facing_direction: GameDirection,
}

And initialize it on our player:

.insert(Player {
    speed: 7.,
    facing_direction: GameDirection::Right,
})

Then, we will update our player_controller system to update this facing direction when our player moves:

pub fn player_controller(
    keyboard_input: Res<Input<KeyCode>>,
    mut players: Query<(&mut Player, &mut RigidBodyVelocity)>,
) {
    for (mut player, mut velocity) in players.iter_mut() {
        if keyboard_input.pressed(KeyCode::Left) {
            velocity.linvel = Vec2::new(-player.speed, velocity.linvel.y).into();
            player.facing_direction = GameDirection::Left
        }
        if keyboard_input.pressed(KeyCode::Right) {
            velocity.linvel = Vec2::new(player.speed, velocity.linvel.y).into();
            player.facing_direction = GameDirection::Right
        }
    }
}

Finally, we will pass this direction to our bullet creation function to fire the bullet in the right direction:

pub fn fire_controller(
    keyboard_input: Res<Input<KeyCode>>,
    mut commands: Commands,
    materials: Res<Materials>,
    players: Query<(&Player, &RigidBodyPosition), With<Player>>,
) {
    if keyboard_input.just_pressed(KeyCode::Space) {
        for (player, position) in players.iter() {
            let options = BulletOptions {
                x: position.position.translation.x,
                y: position.position.translation.y,
                direction: player.facing_direction,
            };
            insert_bullet_at(&mut commands, &materials, options)
        }
    }
}

Running the game should confirm that you can shoot bullets left and right.

The final code is available here.

Making Games in Rust - Part 10 - Death & Enemies

Sébastien Belzile — Mon, 17 Jan 2022 12:57:57 +0000

We can start and stop our game, we have a map to explore, but our player cannot win or lose.

This article will allow our player to die, and will add enemies to the game.

Death By Falling Down

The easiest way to die to implement is death by falling down. If our player falls below some level, he dies.

fn death_by_height(
    mut commands: Commands,
    players: Query<(Entity, &RigidBodyPosition), With<Player>>,
) {
    for (entity, position) in players.iter() {
        if position.position.translation.y < -1. {
            commands.entity(entity).despawn_recursive();
        }
    }
}

If you add this system, register it, and run the game, you should be able to kill our player by jumping into a pit.

You should notice one problem though: this death also destroy our camera since it is defined as a child of our player...

To fix this, let's render the camera on the same level as our player:

// player.rs
struct PlayerData {
    player_entity: Entity,
    camera_entity: Entity,
}

// in spawn_player, to remove
- .with_children(|parent| {
-     parent.spawn_bundle(new_camera_2d());
- })

// in spawn_player, to add
let camera_entity = commands.spawn_bundle(new_camera_2d()).id();
    commands.insert_resource(PlayerData {
        player_entity,
        camera_entity,
    });

// in cleanup_player
commands
    .entity(player_data.camera_entity)
    .despawn_recursive();

And let's re-implement the camera should follow player requirement with a system:

fn camera_follow_player(
    mut cameras: Query<&mut Transform, With<Camera>>,
    players: Query<&RigidBodyPosition, With<Player>>,
) {
    for player in players.iter() {
        for mut camera in cameras.iter_mut() {
            camera.translation.x = player.position.translation.x;
            camera.translation.y = player.position.translation.y;
        }
    }
}

Now, running the game and falling into a pit should kill our player:

Monsters

To add monsters:

Add an Enemy and a Monster component:

pub struct Enemy;
pub struct Monster;

The Enemy component will be useful for everything "enemy" related, and the Monster component is the specific for monsters. This way we could easily implement a Trap entity and have it automatically catch up every Enemy related functionalities such as death by contact, but not things like a monster artificial intelligence.

Add a monster material to the materials:

pub struct Materials {
    pub player_material: Handle<ColorMaterial>,
    pub floor_material: Handle<ColorMaterial>,
    pub monster_material: Handle<ColorMaterial>,
}

fn setup(mut commands: Commands, mut materials: ResMut<Assets<ColorMaterial>>) {
    commands.insert_resource(Materials {
        player_material: materials.add(Color::rgb(0.969, 0.769, 0.784).into()),
        floor_material: materials.add(Color::rgb(0.7, 0.7, 0.7).into()),
        monster_material: materials.add(Color::rgb(0.8, 0., 0.).into()),
    });
}

In monster.rs, we will add a function to add our monsters to the scene:

pub fn insert_monster_at(commands: &mut Commands, x: usize, y: usize, materials: &Res<Materials>) {
    let rigid_body = RigidBodyBundle {
        position: Vec2::new(x as f32, y as f32).into(),
        mass_properties: RigidBodyMassPropsFlags::ROTATION_LOCKED.into(),
        activation: RigidBodyActivation::cannot_sleep(),
        forces: RigidBodyForces {
            gravity_scale: 3.,
            ..Default::default()
        },
        ..Default::default()
    };

    let collider = ColliderBundle {
        shape: ColliderShape::round_cuboid(0.35, 0.35, 0.1),
        flags: ColliderFlags {
            active_events: ActiveEvents::CONTACT_EVENTS,
            ..Default::default()
        },
        ..Default::default()
    };

    let sprite = SpriteBundle {
        material: materials.monster_material.clone(),
        sprite: Sprite::new(Vec2::new(0.9, 0.9)),
        ..Default::default()
    };

    commands
        .spawn_bundle(sprite)
        .insert_bundle(rigid_body)
        .insert_bundle(collider)
        .insert(RigidBodyPositionSync::Discrete)
        .insert(Enemy)
        .insert(Monster);
}

Here, our monster gets a rigid body, a collider, a red sprite and the Enemy and Monster components.

Add a step to the map generation script to randomly add monsters to our world:

// In map.rs
// in the spawn_floor method
add_enemies(&mut commands, &world, &materials);

// Function to insert monsters
fn add_enemies(commands: &mut Commands, world: &Vec<usize>, materials: &Res<Materials>) {
    world.iter().enumerate().for_each(|(x, height)| {
        if should_add_enemy(x) {
            insert_monster_at(commands, x, *height + 1, materials)
        }
    })
}

// Determines whether we should add a monster or not
fn should_add_enemy(x: usize) -> bool {
    if x <= 5 {
        return false;
    }
    let mut rng = thread_rng();
    let random_number: u32 = rng.gen_range(0..100);
    match random_number {
        0..=90 => false,
        _ => true,
    }
}

If you run the game now, monsters should be visible:

Dying to the Hand of your Enemies

Enemies should kill the player on contact. We learned how to implement something similar in a previous chapter with contact events.

Let's create a new system:

pub fn death_by_enemy(
    mut commands: Commands,
    mut players: Query<Entity, With<Player>>,
    enemies: Query<Entity, With<Enemy>>,
    mut contact_events: EventReader<ContactEvent>,
) {
    for contact_event in contact_events.iter() {
        if let ContactEvent::Started(h1, h2) = contact_event {
            for player in players.iter_mut() {
                for enemy in enemies.iter() {
                    if (h1.entity() == player && h2.entity() == enemy) || (h1.entity() == enemy && h2.entity() == player) {
                        commands.entity(player).despawn_recursive();
                    }
                }
            }
        }
    }
}

And let's register it:

.with_system(death_by_enemy.system())

If you run the game, your player should die when it touches a monster:

The final code is available here.

No More Services, No More Repositories

Sébastien Belzile — Fri, 14 Jan 2022 20:14:35 +0000

I recently read Modern Software Engineering: Doing What Works to Build Better Software Faster by David Farley. This article explains, technically, one way, described in the book, that will make your code better.

What is great code?

All the example provided will revolve around a cart in which you can add or remove some items.

Great code is easy to understand, testable, has minimum coupling, etc. One of the qualities that we will often hear is that it does one thing only.

The very bad

In some codebases, we will see code like this one:

def add_to_cart(self, item):
    self.cart.add(item)
 
    conn = sqlite3.connect('my_db.sqlite')
    cur = conn.cursor()
    cur.execute('INSERT INTO cart (name, price) values (item.name, item.price)')
    conn.commit()
    conn.close()
 
    return self.calculate_cart_total()

This code is (not exactly) from "Modern Software Engineering: Doing What Works to Build Better Software Faster" by David Farley, page 240

In the above example, our code is highly coupled. This is often considered to be bad code since everything is bound together, it is "hard" to read, and is hard to test.

A Bit Better

In a lot of teams I joined through my career, most organize their code around services. As an example, the code will contain a CartService class which might contain multiple methods. An example implementation might look like this:

class CartService
    def __init__(self, repository):
        self.repository = repository

    def add(item: Item):
        ...

    def get_items():
        ...

    ...

This is arguably a better alternative to our above function as the access to our database has been abstracted away behind a repository. This way:

our add method will be easier to read,
our service is testable,
our implementation is not coupled to sqlite: we could easily inject a different repository implementation.

Even if the above code is better, I tend to push the teams I join away from it:

The service approach often grows in a bad way. You will always have more than 2 or 3 methods per service and these methods all have different dependencies. In the end, you are still getting highly coupled code, since all your Cart related code is shipped together.

One Step Further

I tend to organize my code around use cases. Use cases are a great way of organizing code as it isolates your processes independently from one another.

“One class, one thing. One method, one thing.”

This motto is great when you wish to reduce cohesion. If we use the same cart example as above, our add_to_cart use case would look like this:

class AddToCart:
    def add_to_cart(self, item):
        self.cart.add(item)
        self.repository.add(item)
        return self.calculate_cart_total()

In this case, our "service" contains only one function: "add_to_cart", and is responsible for one process: the one of adding items to our cart. This "use case" can be injected anywhere and will not pull a lot of useless dependencies as the "service" approach will.

This said, there is still one caveat: the repository.

The repository has the same problem our service had... It contains all the logic responsible for interaction with the persistence part of our code...

Best Approach

In his book, David Farley does not even mention repositories. Instead, he shares 2 alternative implementations:

def add_to_cart2(self, item):
    self.cart.add(item)
    self.store.store_item(item)
    return self.calculate_cart_total();
 
def add_to_cart3(self, item, listener):
    self.cart.add(item)
    listener.on_item_added(self, item)

Code from "Modern Software Engineering: Doing What Works to Build Better Software Faster" by David Farley, page 240

His book discusses the advantages of using one version versus the other, but this is not what I want to discuss here (I encourage you to read the book to find out).

What is great here is that the "repository" concept:

is abstracted: either completely hidden from the implementation (add_to_cart3) or replaced by a store (add_to_cart2).
requires an implementation that does one thing only.

In add_to_cart2, our "repository" is reduced to another use case the one of storing the item via the store.

One of the examples shown in the book is the following:

public interface WordSource
{
    String[] words();
}

This is a perfect "repository" abstraction that does only one thing.

Summary

“One class, one thing. One method, one thing.”

Making Games in Rust - Deploying a Bevy App to the Web

Sébastien Belzile — Thu, 13 Jan 2022 19:42:47 +0000

This article was first written for Bevy 0.5. The release of Bevy 0.6, on the actual day I wrote this article, made it obsolete. Those b******** keep making their product better...

Bevy 0.6 added out of the box support for running their application for the web.

The first part of the article will describe how to deploy an application to the web with Bevy 0.6, the second part is what I originally wrote for Bevy 0.5.

Bevy 0.6

Originally, this article was part 14 of my Bevy Platformer tutorial. This time, I will use a simple Tic-Tac-Toe game example that can be found here. With a working web deployment here.

Prerequesites

First, you need to be able to compile to web assembly:

rustup target add wasm32-unknown-unknown

Second, you will need the wasm-bindgen-cli:

cargo install -f wasm-bindgen-cli

Building the code

cargo build --release --target wasm32-unknown-unknown
wasm-bindgen --out-dir ./out/ --target web ./target/wasm32-unknown-unknown/release/tic-tac-toe.wasm

Running on the Web

First you will need an index.html file:

<html>
  <head>
    <meta charset="UTF-8" />
    <style>
      body {
        margin: 0;
        background: linear-gradient(-45deg, #a6a6a6, #5ac05a, #262626, #a6a6a6);
        background-size: 400% 400%;
        animation: gradient 15s ease infinite;
        height: 100vh;
        display: flex;
        justify-content: center;
        align-items: center;
      }
      canvas {
        background-color: white;
      }

      @keyframes gradient {
        0% {
          background-position: 0% 50%;
        }
        50% {
          background-position: 100% 50%;
        }
        100% {
          background-position: 0% 50%;
        }
      }
    </style>
  </head>
  <script type="module">
    import init from './out/tic-tac-toe.js'
    init()
  </script>
</html>

Finally, you need to serve this HTML file:

npx serve .

And then visit http://localhost:3000 to confirm everything works fine.

Note that npx serve . requires to have Node JS installed on your machine.

Original Content (with Bevy 0.5)

If you did not read the previous articles, you can start here.

This article will show how to deploy our project as a web application.

Most of the things covered here are explained in greater details in Bevy's Unofficial Cheat Book.

Prerequesites

First, you need to be able to compile to web assembly:

rustup target add wasm32-unknown-unknown

Second, you need to install wasm-pack:

cargo install wasm-pack

Cargo Configuration

[package]
name = "platformer"
version = "0.1.0"
edition = "2021"
resolver = "2"

[lib]
crate-type = ["cdylib", "rlib"]

[dependencies]
wasm-bindgen = "0.2"
bevy_rapier2d = { version = "0.11.0", features = [ "wasm-bindgen" ] }
rand = "0.8.4"
getrandom = { version = "0.2", features = ["js"] }

# Dependencies for native only.
[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
bevy = {version = "0.5", default-features = false, features = ["bevy_wgpu", "bevy_winit", "render", "x11"]}

# Dependencies for WASM only.
[target.'cfg(target_arch = "wasm32")'.dependencies]
bevy = {version = "0.5", default-features = false, features = ["bevy_winit", "render"]}
bevy_webgl2 = "0.5"

What was done here:

Set the cargo resolver to version 2.
Added [lib] tag with the cdylib and rlib types.
Added wasm-bindgen as a dependency. This is the crate responsible for the interoperability between JS and Rust.
Added the wasm-bindgen feature flag to rapier.
Splitted the bevy dependency in 2. One for the web, the other for native development. In both cases, the required feature flags are set.
Added bevy_webgl2 to the wasm dependencies. This crate provides webgl2 rendering support to Bevy.

Code Changes

Add a src/lib.rs file that contains the following:

use bevy::prelude::*;
use wasm_bindgen::prelude::*;

mod game;
use game::GamePlugin;

mod main_menu;
use main_menu::MainMenuPlugin;

#[derive(Debug, Clone, Eq, PartialEq, Hash)]
enum AppState {
    MainMenu,
    InGame,
}

#[wasm_bindgen]
pub fn run() {
    let mut app = App::build();

    app.add_plugins(DefaultPlugins);

    #[cfg(target_arch = "wasm32")]
    app.add_plugin(bevy_webgl2::WebGL2Plugin);

    app.insert_resource(WindowDescriptor {
        title: "Platformer!".to_string(),
        width: 640.0,
        height: 400.0,
        vsync: true,
        ..Default::default()
    })
    .insert_resource(ClearColor(Color::rgb(0.04, 0.04, 0.04)))
    .add_state(AppState::MainMenu)
    .add_plugin(MainMenuPlugin)
    .add_plugin(GamePlugin)
    .run();
}

This is the same code we had in our main.rs, except that the main function was renamed to run and adapted for the web.

Next step is to replace the content of src/main.rs to:

use platformer::run;

fn main() {
    run();
}

The code should now compile and run. To run locally on your machine, run:

cargo run

as usual, and to run for the web:

wasm-pack build --target web --release
npx serve .

And then visit http://localhost:3000 to confirm everything works fine.

Note that npx serve . requires to have Node JS installed on your machine.

Possible Issues

You may encounter the following error:

the trait `__tracing_subscriber_Layer<Layered<EnvFilter, Registry>>` is not implemented for `WASMLayer`

To fix it, run the following command:

cargo update -p tracing-wasm --precise 0.2.0

The final code is available here. The most recent version of the game can be played here.

Making Games in Rust - Part 9 - Main Menu Screen

Sébastien Belzile — Mon, 10 Jan 2022 12:58:07 +0000

Today, we are going to learn about UIs in Bevy. Our main goal is to end up with a main menu that contains 2 buttons, one to launch our game, and another to exit the application. This article will explain how to render UI elements to the screen, and how to listen to button events.

Nodes and Styles

We could easily compare Bevy's UI to HTML: you create a hierarchy of elements / nodes, apply some styles to them, and Bevy's engine takes care of rendering what you asked for. A few "bundles" are exposed by Bevy to help you build your UI:

NodeBundle: a basic node

fn root(materials: &Res<MenuMaterials>) -> NodeBundle {
    NodeBundle {
        style: Style {
            size: Size::new(Val::Percent(100.0), Val::Percent(100.0)),
            justify_content: JustifyContent::Center,
            align_items: AlignItems::Center,
            ..Default::default()
        },
        material: materials.root.clone(),
        ..Default::default()
    }
}

ButtonBundle: to render a button

fn button(materials: &Res<MenuMaterials>) -> ButtonBundle {
    ButtonBundle {
        style: Style {
            size: Size::new(Val::Percent(100.0), Val::Percent(100.0)),
            justify_content: JustifyContent::Center,
            align_items: AlignItems::Center,
            ..Default::default()
        },
        material: materials.button.clone(),
        ..Default::default()
    }
}

TextBundle: to render text

fn button_text(asset_server: &Res<AssetServer>, materials: &Res<MenuMaterials>, label: &str) -> TextBundle {
    return TextBundle {
        style: Style {
            margin: Rect::all(Val::Px(10.0)),
            ..Default::default()
        },
        text: Text::with_section(
            label,
            TextStyle {
                font: asset_server.load("fonts/FiraSans-Bold.ttf"),
                font_size: 30.0,
                color: materials.button_text.clone(),
            },
            Default::default(),
        ),
        ..Default::default()
    };
}

Each of these element have a style property used to express how to render the node.

This style property is a Rust struct that contains a subset of the usual properties found in CSS. Among others, you should find:

margin and padding: to add space around our UI elements
position_type: for relative or absolute positioning
most of the flexbox properties: Bevy's rendering engine implements flexbox for positioning

Our menu also includes these two nodes:

fn border(materials: &Res<MenuMaterials>) -> NodeBundle {
    NodeBundle {
        style: Style {
            size: Size::new(Val::Px(400.0), Val::Auto),
            border: Rect::all(Val::Px(8.0)),
            ..Default::default()
        },
        material: materials.border.clone(),
        ..Default::default()
    }
}

fn menu_background(materials: &Res<MenuMaterials>) -> NodeBundle {
    NodeBundle {
        style: Style {
            size: Size::new(Val::Percent(100.0), Val::Percent(100.0)),
            align_items: AlignItems::Center,
            justify_content: JustifyContent::Center,
            flex_direction: FlexDirection::ColumnReverse,
            padding: Rect::all(Val::Px(5.0)),
            ..Default::default()
        },
        material: materials.menu.clone(),
        ..Default::default()
    }
}

Text Styles

The TextBundle, in addition to the style property, specifies a property called text which also has a style property. This one exposes the possibility to modify the text font size, color and font.

If you take a look to the text node above, you should notice the use of a Res<AssetServer>. This utility allows us to load non Rust resources such as images or fonts.

To use it, we creates a new folder to the root of our project and named it assets. When using the asset server to load a resource, give it the path of your resource relative to this folder. Ex:

asset_server.load("fonts/FiraSans-Bold.ttf")

Colors

Nodes and Buttons also contain a material property. This property works the same as the materials we previously added to our player and maps. To ease the development of our menu, we can centralize the definition of these colors into a resource:

struct MenuMaterials {
    root: Handle<ColorMaterial>,
    border: Handle<ColorMaterial>,
    menu: Handle<ColorMaterial>,
    button: Handle<ColorMaterial>,
    button_hovered: Handle<ColorMaterial>,
    button_pressed: Handle<ColorMaterial>,
    button_text: Color,
}

impl FromWorld for MenuMaterials {
    fn from_world(world: &mut World) -> Self {
        let mut materials = world.get_resource_mut::<Assets<ColorMaterial>>().unwrap();
        MenuMaterials {
            root: materials.add(Color::NONE.into()),
            border: materials.add(Color::rgb(0.65, 0.65, 0.65).into()),
            menu: materials.add(Color::rgb(0.15, 0.15, 0.15).into()),
            button: materials.add(Color::rgb(0.15, 0.15, 0.15).into()),
            button_hovered: materials.add(Color::rgb(0.25, 0.25, 0.25).into()),
            button_pressed: materials.add(Color::rgb(0.35, 0.75, 0.35).into()),
            button_text: Color::WHITE,
        }
    }
}

We still need to tell Bevy to instantiate this resource:

// on our AppBuilder
.init_resource::<MenuMaterials>()

Defining the Node Hierarchy

We can add UI elements the same way we register other Bevy entities: we call AppBuilder.spawn_bundle and register children nodes with the with_children method:

enum MenuButton {
    Play,
    Quit,
}

fn setup(
    mut commands: Commands,
    asset_server: Res<AssetServer>,
    materials: Res<MenuMaterials>,
) {
    commands.spawn_bundle(UiCameraBundle::default());

    commands
        .spawn_bundle(root(&materials))
        .with_children(|parent| {
            // left vertical fill (border)
            parent
                .spawn_bundle(border(&materials))
                .with_children(|parent| {
                    // left vertical fill (content)
                    parent
                        .spawn_bundle(menu_background(&materials))
                        .with_children(|parent| {
                            parent.spawn_bundle(button(&materials))
                                .with_children(|parent| {
                                    parent.spawn_bundle(button_text(&asset_server, &materials, "New Game"));
                                })
                                .insert(MenuButton::Play);
                            parent.spawn_bundle(button(&materials))
                                .with_children(|parent| {
                                    parent.spawn_bundle(button_text(&asset_server, &materials, "Quit"));
                                })
                                .insert(MenuButton::Quit);
                        });
                });
        });
}

Wiring it up

To wire everything up, we created a new Rust module called main_menu, which contains a MainMenuPlugin.

pub struct MainMenuPlugin;

impl Plugin for MainMenuPlugin {
    fn build(&self, app: &mut AppBuilder) {
        app.init_resource::<MenuMaterials>()
            .add_system_set(
                SystemSet::on_enter(AppState::MainMenu)
                    .with_system(cleanup.system())
                    .with_system(setup.system()),
            )
            .add_system_set(SystemSet::on_exit(AppState::MainMenu).with_system(cleanup.system()));
    }
}

// main.rs
mod main_menu;
use main_menu::MainMenuPlugin;

// ...

.add_plugin(MainMenuPlugin)

Running the game:

Apply Different Styles on Interactions

It is possible to modify the button look with a system:

// MainMenuPlugin
.add_system(button_system.system())

// system implementation
fn button_system(
    materials: Res<MenuMaterials>,
    mut buttons: Query<
        (&Interaction, &mut Handle<ColorMaterial>),
        (Changed<Interaction>, With<Button>),
    >
) {
    for (interaction, mut material) in buttons.iter_mut() {
        match *interaction {
            Interaction::Clicked => *material = materials.button_pressed.clone(),
            Interaction::Hovered => *material = materials.button_hovered.clone(),
            Interaction::None => *material = materials.button.clone(),
        }
    }
}

This way, our buttons should change color when hovered, and turn to green when pressed.

Runnig Actions on Button Click

The same way we changed button styles, we can react to button click with a system triggered on clicks:

// main menu plugin
.add_system(button_press_system.system())

// System implementation
fn button_press_system(
    buttons: Query<(&Interaction, &MenuButton), (Changed<Interaction>, With<Button>)>,
    mut state: ResMut<State<AppState>>,
    mut exit: EventWriter<AppExit>
) {
    for (interaction, button) in buttons.iter() {
        if *interaction == Interaction::Clicked {
            match button {
                MenuButton::Play => state
                    .set(AppState::InGame)
                    .expect("Couldn't switch state to InGame"),
                MenuButton::Quit => exit.send(AppExit),
            };
        }
    }
}

In order for this system to run, we need to ensure that a MenuButton component is added to our button. This system will run the action linked to the type of MenuButton that was added to our entity.

Here, pressing Play Game should start a new game, and pressing Quit should exit the game.

Final Bits of Code

Since we now have a menu that handles starting a new game, we can remove the main_menu_controls system that was defined in main.rs. Instead, we can add a new back_to_main_menu_controls in our game module:

// GamePlugin
.add_system_set(SystemSet::on_update(AppState::InGame).with_system(back_to_main_menu_controls.system()))

// System implementation
fn back_to_main_menu_controls(mut keys: ResMut<Input<KeyCode>>, mut app_state: ResMut<State<AppState>>) {
    if *app_state.current() == AppState::InGame {
        if keys.just_pressed(KeyCode::Escape) {
            app_state.set(AppState::MainMenu).unwrap();
            keys.reset(KeyCode::Escape);
        }
    }
}

All the code is available here. The most recent version of the game can be played here.

Making Games in Rust - Part 8 - Towards adding a Main Menu

Sébastien Belzile — Wed, 05 Jan 2022 14:14:38 +0000

Our focus in this part of the tutorial is to refactor the code in a way that allows us to include a good looking start up screen to our game.

The notions explained in this tutorial:

Bevy's States
Bevy's System Sets

Refactor to Add a Main Menu Screen

Since we wish to add a main menu screen, we need a way to:

Split our game in 2: the main menu and the game
Allow our user to control this state.
Register and remove resources as we go from one game state to the other.

Game State

If we translate our need to code, the game state is an enum like this one:

// main.rs
#[derive(Debug, Clone, Eq, PartialEq, Hash)]
enum AppState {
    MainMenu,
    InGame,
}

Bevy allows us to register a state as follow:

// main.rs
.add_state(AppState::MainMenu)

Controlling the State

Our user could control the game state with the keyboard, as we learned in part 4. The state can be updated by modifying the state resource using Bevy's API.

// main.rs
// main function
.add_system(main_menu_controls.system())

// system
fn main_menu_controls(mut keys: ResMut<Input<KeyCode>>, mut app_state: ResMut<State<AppState>>) {
    if *app_state.current() == AppState::MainMenu {
        if keys.just_pressed(KeyCode::Return) {
            app_state.set(AppState::InGame).unwrap();
            keys.reset(KeyCode::Return);
        }
    } else {
        if keys.just_pressed(KeyCode::Escape) {
            app_state.set(AppState::MainMenu).unwrap();
            keys.reset(KeyCode::Escape);
        }
    }
}

The state of our game can now be controlled with the Return and Esc keys. The .reset call is because of this current Bevy issue.

Register and Remove Resources

The final step is to register and remove resources when the state of our game changes. Bevy's system sets allows us do just that. If you take a look at our player.rs file:

app.add_system_set(
        SystemSet::on_enter(AppState::InGame).with_system(spawn_player.system()),
    )
    .add_system_set(
        SystemSet::on_update(AppState::InGame)
            .with_system(player_jumps.system())
            .with_system(player_movement.system())
            .with_system(jump_reset.system()),
    )
    .add_system_set(SystemSet::on_enter(AppState::MainMenu).with_system(cleanup.system()))
    .add_system_set(SystemSet::on_exit(AppState::MainMenu).with_system(cleanup.system()));

A set of system can be run for a given state. Sets of systems can also run once when exiting or entering a state. The code above registers a system set that spawns the player when the app enters the AppState::InGame state.
It also registers a cleanup system when the app enters and exists the AppState::MainMenu state.
Finally, the code adds systems to run on update when the AppState::InGame state is active.

The cleanup systems code is the following:

fn cleanup(mut commands: Commands, query: Query<Entity>) {
    for entity in query.iter() {
        commands.entity(entity).despawn_recursive();
    }
}

Final Code

My final code is available here. I am not taking the time to go over the details here. Mostly, I moved the code to end up with a game and a main_menu module.

Making Games in Rust - Part 7 - Fixing the Player Randomly Stuck Issue

Sébastien Belzile — Wed, 29 Dec 2021 13:28:07 +0000

If you played with the code from part 6 of this tutorial, you probably noticed that our player often gets randomly stuck on the ground. You may also have gotten stuck in that way:

Solution 1

We could make our player smaller:

// player.rs
shape: ColliderShape::cuboid(0.45, 0.45),
// ...
sprite: Sprite::new(Vec2::new(0.9, 0.9)),

This fixes the hole issue:

But our player still randomly gets stuck on a flat surface.

Solution 2

What about a round corners on our character?

shape: ColliderShape::round_cuboid(0.35, 0.35, 0.1),

This way, our character is no longer stuck, but it looks like it bumps on the corner of the colliders...

Solution 3

We could modify our drawing strategy to only have flat colliders. Instead of one collider per square, we could layer colliders one on top of the other:

The code to do this adds some complexity though:

We will split world creation in 3 steps.

pub fn spawn_floor(mut commands: Commands, materials: Res<Materials>) {
    let world = create_world(150);
    add_sprites(&mut commands, materials, &world);
    add_colliders(&world, &mut commands);
}

First step is to generate our height map, second step is to add our sprites, and finally we add our colliders.

World creation:

fn create_world(width: usize) -> Vec<usize> {
    let mut heights: Vec<usize> = Vec::with_capacity(width);
    let mut height = 1;
    (0..width).for_each(|_| {
        heights.push(height);
        height = get_next_height(height)
    });
    heights
}

Code is similar to what we previously had, we fill a vector with our heights.

Adding the sprites:

fn add_sprites(commands: &mut Commands, materials: Res<Materials>, world: &Vec<usize>) {
    world.iter().enumerate().for_each(|(x, height)| {
        add_tile(commands, &materials, x as f32, *height);
    });
}

fn add_tile(commands: &mut Commands, materials: &Res<Materials>, x: f32, height: usize) {
    commands
        .spawn_bundle(SpriteBundle {
            material: materials.floor_material.clone(),
            sprite: Sprite::new(Vec2::new(1., height as f32)),
            transform: Transform::from_translation(Vec3::new(x, height as f32 / 2., 0.)),
            ..Default::default()
        });
}

Also similar to what we previously had. Our entity no longer includes the rigid bodies and colliders components. The code iterates on our vector, and prints our world.

Add the colliders:

fn add_colliders(world: &Vec<usize>, commands: &mut Commands) {
    let max = match world.iter().max() {
        Some(m) => m,
        _ => panic!("add_colliders: World is empty")
    };
    (1..=*max).for_each(|floor_height| {
        let mut start: Option<usize> = None;
        world.iter().enumerate().for_each(|(index, height_at_index)| {
            if  *height_at_index >= floor_height && start.is_none() {
                start = Some(index);
            } else if *height_at_index < floor_height && start.is_some() {
                add_collider(commands, floor_height, *start.get_or_insert(0), index);
                start = None
            }
        });

        if start.is_some() {
            add_collider(commands, floor_height, *start.get_or_insert(0), world.len());
        }
    })
}

fn add_collider(commands: &mut Commands, height: usize, from: usize, to: usize) {
    let width = to - from;
    let half_width = width as f32 / 2.;
    let rigid_body = RigidBodyBundle {
        position: Vec2::new(from as f32 + half_width - 0.5, height as f32 - 0.5).into(),
        body_type: RigidBodyType::Static,
        ..Default::default()
    };
    let collider = ColliderBundle {
        shape: ColliderShape::cuboid(half_width, 0.5),
        ..Default::default()
    };
    commands
        .spawn_bundle(rigid_body)
        .insert_bundle(collider)
        .insert(RigidBodyPositionSync::Discrete);
}

This code renders our world layer by layer. It adds a rigid body and a collider for every continuous length of floor on the layer.

The final code is available here.

Making Games in Rust - Part 6 - Generating a Map

Sébastien Belzile — Sun, 26 Dec 2021 19:16:40 +0000

For future features, we will need a bigger world to move our player in. We need a bigger map.

This article builds on top of our previous code (the code I started with can be found here) and adds an automatically generated map to our world.

Flat Floor

In map.rs, let's replace our spawn_floor method with the following code:



pub fn spawn_floor(mut commands: Commands, materials: Res<Materials>) {
    for x in 0..50 {
        add_tile(&mut commands, &materials, x as f32)
    }
}

fn add_tile(commands: &mut Commands, materials: &Res<Materials>, x: f32) {
    let rigid_body = RigidBodyBundle {
        position: Vec2::new(x, -2.).into(),
        body_type: RigidBodyType::Static,
        ..Default::default()
    };
    let collider = ColliderBundle {
        shape: ColliderShape::cuboid(0.5, 0.5),
        ..Default::default()
    };
    commands
        .spawn_bundle(SpriteBundle {
            material: materials.floor_material.clone(),
            sprite: Sprite::new(Vec2::new(1., 1.)),
            ..Default::default()
        })
        .insert_bundle(rigid_body)
        .insert_bundle(collider)
        .insert(RigidBodyPositionSync::Discrete);
}

Compared to our previous code, we:

Moved the content of the spawn_floor function to an add_tile function.
Modify the input of the add_tile function so that it receives an x coordinate as well.
Modify the width of our tiles from 10 to 1 world unit.
Set the x component of our rigid body to the x coordinate provided as input.

The new spawn_floor function now contains a loop which calls our add_tile function with a coordinate going from 0 to 50.

Running the game will display a flat floor of length 50.

(Ha! Yeah! our player is also pink now)

Going Up or Down

To make this more interesting, our map should go up or down. Let's modify our add_tile function so that it takes a height as input:



fn add_tile(commands: &mut Commands, materials: &Res<Materials>, x: f32, height: u8) {
    let half_height = height as f32 / 2.;
    let rigid_body = RigidBodyBundle {
        position: Vec2::new(x, -2. + half_height).into(),
        body_type: RigidBodyType::Static,
        ..Default::default()
    };
    let collider = ColliderBundle {
        shape: ColliderShape::cuboid(0.5, half_height),
        ..Default::default()
    };
    commands
        .spawn_bundle(SpriteBundle {
            material: materials.floor_material.clone(),
            sprite: Sprite::new(Vec2::new(1., height as f32)),
            ..Default::default()
        })
        .insert_bundle(rigid_body)
        .insert_bundle(collider)
        .insert(RigidBodyPositionSync::Discrete);
}

We will randomly determine the height to provide:

Add the rand crate to your cargo.toml:



[dependencies]
rand = "0.8.4"

Add a function to randomly pick an height variation:



use rand::prelude::*;
// ...
fn get_random_height_delta() -> i8 {
    let mut rng = thread_rng();
    let random_number: u32 = rng.gen_range(0..100);
    let delta = match random_number {
        0..=70 => 0,
        71..=80 => -1,
        81..=90 => 1,
        _ => 2,
    };
    delta
}

Add a function to calculate the next height from the current height:



fn get_next_height(current_height: u8) -> u8 {
    let next_height = current_height as i8 + get_random_height_delta();
    return if next_height > 0 {
        next_height as u8
    } else {
        1
    };
}

Finally, modify the spawn_floor function to send a random height to the add_tile function:



pub fn spawn_floor(mut commands: Commands, materials: Res<Materials>) {
    let mut height = 1;
    for x in 0..150 {
        add_tile(&mut commands, &materials, x as f32, height);
        height = get_next_height(height)
    }
}

Running the game should render a prettier map:

The final code is available here.

Making Games in Rust - Part 5 - Movement

Sébastien Belzile — Mon, 20 Dec 2021 10:40:54 +0000

The previous part was about jumps. In there, we learned how to get player inputs and convert it to a vertical movement. This time, let's leverage what we learned to move our player from left to right.

Movement System

Let's start by adding a new system responsible for moving our player.

fn player_movement(
    keyboard_input: Res<Input<KeyCode>>,
    mut players: Query<(&Player, &mut RigidBodyVelocity)>
) {
    for (player, mut velocity) in players.iter_mut() {
        if keyboard_input.pressed(KeyCode::Left) {
            velocity.linvel = Vec2::new(-player.speed, velocity.linvel.y).into();
        }
        if keyboard_input.pressed(KeyCode::Right) {
            velocity.linvel = Vec2::new(player.speed, velocity.linvel.y).into();
        }
    }
}

This system listens to the left and right keys on our keyboard. When one of these keys is pressed, our system will set our player's linear velocity to + or - the player speed property in the x-axis, and set the y component of the player's velocity to, well, its current y velocity. This ensures that pressing left or right will not have the effect of stopping an ongoing jump.

For our system to work, we still need:

To register it:

.add_system(player_movement.system())

To add a speed property to our player's component:

struct Player {
    speed: f32
}

To set the speed of our player:

.insert(Player { speed: 3.5 })

Meanwhile, I lowered our player's jump_impulse to 7.

If you rung the game, you should be able to make our player move from left or right by pressing the left or right key on your keyboard.

Going Further

Bevy supports multiple types of user input methods. We learned one way of dealing with keyboard events, but the same thing may be done with the mouse, with touchscreens and/or with gamepads.

We also learned to deal with user inputs by looking at the current state of our keyboard. There is another way of doing this: via events. It is important to know that some types of inputs are only provided as events.

You can read Bevy's unofficial cheat book to learn more about the supported input methods and the ways of dealing with them.

Following the Player with the Camera

The player can now move, but the camera will lose sight if the player goes off screen. It would be nice if the camera would follow our player as it moves. One way to do this is to declare the camera as a child of our player:

.with_children(|parent| {
    parent.spawn_bundle(new_camera_2d());
})

We must also remove the old camera from the setup system, and remove the setup system, now that it's empty.

This approach works, but has some caveats. We will learn about a better alternative in part 10 of this tutorial.

The final code is available here.

Making Games in Rust - Part 4 - Jumps

Sébastien Belzile — Fri, 17 Dec 2021 14:42:23 +0000

Part 3 of this tutorial added gravity and collision detection to our game. This part will explain how to implement jumps.

Jump Basis

We will start by defining a Jumper component. This will allow us to centralize all jumping logic.



struct Jumper {
    jump_impulse: f32,
}

In the spawn_player method, we will add this new component to our player.



.insert(Jumper { jump_impulse: 10. });

We will then add a player jumps system and register it with our application.



// In main, register a player movement system
.add_system(player_jumps.system())

// Define a player movement system
fn player_jumps(
    keyboard_input: Res<Input<KeyCode>>,
    mut players: Query<(&Jumper, &mut RigidBodyVelocity), With<Player>>
) {
    for (jumper, mut velocity) in players.iter_mut() {
        if keyboard_input.pressed(KeyCode::Up) {
            velocity.linvel = Vec2::new(0., jumper.jump_impulse).into();
        }
    }
}

The keyboard_input: Res<Input<KeyCode>> parameter of our method allows us to detect key pressed.

Our mut players: Query<(&Jumper, &mut RigidBodyVelocity), With<Player>> parameter returns all the entities with a Jumper, a RigidBodyVelocity and a Player component. The With tells Bevy that we don't need the Player component.

The code in the method sets the upward speed of our player to the jump impulse that is defined on the component.

If you run cargo run, and press the up key, you should see our player go up, and then come back down until it reaches the floor.

Disable Multiple Jumps

With our current code, if you keep the up key pressed, the player will keep going up and will not stop until the is released. We need a way to disable jumps when the player is in the air.

One way to do this is to add a is_jumping boolean property to our Jumper component.



struct Jumper {
    jump_impulse: f32,
    is_jumping: bool
}
// ...
.insert(Jumper { jump_impulse: 10., is_jumping: false })

Then, we can allow jumps only when this boolean flag is false, and set this flag to true when the player is in the air.



fn player_jumps(
    keyboard_input: Res<Input<KeyCode>>,
    mut players: Query<(&mut Jumper, &mut RigidBodyVelocity), With<Player>>
) {
    for (mut jumper, mut velocity) in players.iter_mut() {
        if keyboard_input.pressed(KeyCode::Up) && !jumper.is_jumping {
            velocity.linvel = Vec2::new(0., jumper.jump_impulse).into();
            jumper.is_jumping = true
        }
    }
}

If you run the application, the player can no longer jump while it's in the air. The only issue we have is that it can only jump once...

We need a way reset the is_jumping flag when the player is not jumping.

Reset the Flag

To do this kind of things, Rapier has an event system that triggers whenever a contact occurs between 2 colliders. We will leverage that to reset our flag.

Add a new jump_reset system and register it with our application:



// In main
.add_system(jump_reset.system())

// ...
pub fn jump_reset(
    mut query: Query<(Entity, &mut Jumper)>,
    mut contact_events: EventReader<ContactEvent>,
) {
    for contact_event in contact_events.iter() {
        for (entity, mut jumper) in query.iter_mut() {
            set_jumping_false_if_touching_floor(entity, &mut jumper, contact_event);
        }
    }
}

fn set_jumping_false_if_touching_floor(entity: Entity, jumper: &mut Jumper, event: &ContactEvent) {
    if let ContactEvent::Started(h1, h2) = event {
        if h1.entity() == entity || h2.entity() == entity {
            jumper.is_jumping = false
        }
    }
}

This system retrieves all the Jumper components and all the contact events that occurred. It then looks at whether one of the contact events involves a given jumper. If it's the case, it sets the is_jumping to false flag on our jumper.

If we want this to work, we need to activate contact events for our player collider:



flags: ColliderFlags {
    active_events: ActiveEvents::CONTACT_EVENTS,
    ..Default::default()
},

Run cargo run and play with the up key. Our player can no longer double jump, and it can re-jump after touching the floor.

Part 1:

Making Games in Rust - Part 1 - Bevy and ECS

Sébastien Belzile ・ Dec 7 '21

#rust #bevy #rapier #tutorial