Développement de jeux en Rust : Bevy, Macroquad et plus

Beaucoup de gens apprennent Rust parce qu’ils veulent créer un jeu. C’est une excellente raison ! Un jeu a besoin de vitesse, d’une gestion soignée de la mémoire et d’un code qui ne plante pas en plein combat contre le boss : c’est exactement ce que Rust sait bien faire.

Cette page vous donne une image honnête : ce que les gens construisent déjà en Rust, quel moteur ou quelle bibliothèque choisir, et les deux idées que presque tous les jeux utilisent, la boucle de jeu (game loop) et l’ECS. Ensuite, vous verrez un premier programme avec Bevy et avec Macroquad.

Quels exemples tournent où ? La boucle de jeu, le petit monde ECS et l’exercice sont en Rust pur : ils ont donc un bouton « Essayez vous-même » pour le Rust Playground. Bevy et Macroquad ouvrent une fenêtre : ces exemples-là sont pour votre propre ordinateur, avec cargo run. L’exemple Macroquad a été compilé (aussi pour le web) pendant l’écriture de cette page ; l’exemple Bevy suit les exemples officiels de Bevy.

L’état réel du jeu vidéo en Rust

Le site communautaire Are We Game Yet? (en anglais) suit l’écosystème du jeu vidéo en Rust. Sa réponse à sa propre question : « Presque. Nous avons les briques, apportez votre propre colle. » C’est un bon résumé.

Ce qui marche bien aujourd’hui :

De vrais jeux sortent. Tiny Glade, un jeu paisible de construction de châteaux sur Steam, et Veloren, un RPG voxel open source, sont tous deux listés sur Are We Game Yet comme jeux écrits en Rust.
Un moteur solide. Bevy a une communauté grande et active, et une nouvelle version sort tous les quelques mois.
Beaucoup de briques. Are We Game Yet liste des crates pour la physique, le son, les entrées, le réseau, l’interface et bien plus.
Votre jeu peut tourner sur le web. Rust compile vers WebAssembly, donc beaucoup de jeux Rust tournent aussi dans un navigateur.

Ce qui reste difficile :

Pas encore de « Unity de Rust ». La plupart des moteurs Rust se pilotent par le code. Des éditeurs visuels existent (Fyrox en a un, et Godot peut utiliser Rust), mais ils sont plus jeunes que les grands outils commerciaux.
Ça bouge. Bevy n’est pas encore en 1.0, et chaque version apporte des changements incompatibles. Un tutoriel de l’an dernier peut ne plus compiler.
Les temps de compilation. Les gros moteurs mettent plusieurs minutes à compiler la première fois. Vous verrez les astuces pour ça plus bas.

Si votre but est de sortir un jeu 3D commercial l’an prochain avec une équipe d’artistes, Unity, Unreal ou Godot sont plus sûrs. Si vous voulez apprendre, faire des jeux 2D, des game jams, des outils ou des simulations, ou si vous aimez tout simplement Rust, c’est un terrain de jeu très amusant. 🦀

Quel moteur ou quelle bibliothèque ?

Il existe deux sortes d’outils. Un moteur vous donne toute une structure : comment fonctionnent les objets du jeu, les scènes et les ressources. Une bibliothèque (ou framework) vous donne une fenêtre, le dessin, le son et les entrées, et vous organisez le reste vous-même.

Crate	Ce que c’est	Idéal pour	Bon à savoir
`bevy` (0.20)	Un moteur 2D et 3D complet, construit autour de l’ECS	Les projets plus gros, la 3D, comprendre comment marchent les moteurs modernes	Le moteur Rust le plus connu. Changements incompatibles à chaque version ; première compilation longue
`macroquad` (0.4)	Une bibliothèque 2D simple, inspirée de raylib	Votre premier jeu, les game jams, les jeux web	Très peu de dépendances, compile vite. Vous appelez des fonctions de dessin dans une boucle
`ggez` (0.10)	Un framework 2D léger, inspiré de LÖVE	Les jeux 2D avec une structure claire	Vous implémentez un trait `EventHandler` avec `update` et `draw`
`fyrox` (1.0)	Un moteur 2D et 3D avec un éditeur de scènes	Ceux qui veulent un éditeur, comme dans Godot ou Unity	Version 1.0 atteinte en 2026. Communauté plus petite que celle de Bevy
`raylib` (6.0)	Des bindings Rust pour la bibliothèque C raylib	Ceux qui connaissent raylib en C	Demande CMake et des outils de compilation C, car il compile la bibliothèque C (voir FFI)
`godot` (0.5, « gdext »)	Des bindings Rust pour le moteur Godot 4	Utiliser l’éditeur de Godot avec la logique du jeu en Rust	Vous écrivez des classes Rust que Godot charge comme une GDExtension

Une règle simple : commencez avec Macroquad pour votre premier jeu 2D. Choisissez Bevy quand vous voulez un moteur complet et que vous êtes prêt à apprendre l’ECS. Choisissez Godot avec gdext ou Fyrox si vous voulez un éditeur pour placer les éléments visuellement.

La boucle de jeu

Presque tous les jeux sont une grande boucle qui tourne encore et encore jusqu’à ce que vous quittiez :

Lire les entrées (clavier, souris, manette).
Mettre à jour le jeu : déplacer les objets, vérifier les collisions, compter les points.
Dessiner la nouvelle image à l’écran.

Un tour de boucle s’appelle une image (frame). À 60 images par seconde (FPS), chaque image dispose d’environ 16 millisecondes. Mais les images ne durent pas toutes le même temps. Votre ordinateur peut être occupé, ou une image peut avoir besoin de charger un fichier.

Si votre jeu déplace le joueur de « 2 unités par image », il va plus vite sur un ordinateur rapide et plus lentement sur un ordinateur lent. Une solution populaire est le pas de temps fixe (fixed timestep) : la logique du jeu avance toujours par pas égaux (ici 10 ms), et chaque image exécute autant de pas qu’il en tient dans le temps écoulé. Le temps restant attend dans un accumulateur jusqu’à l’image suivante.

const STEP_MS: u32 = 10; // la logique du jeu avance toujours de 10 ms à la fois
const SPEED: i32 = 2; // le joueur avance de 2 unités par mise à jour

fn main() {
    // La durée réelle de chaque image. Un vrai jeu la mesure avec une horloge.
    let frame_times = [16, 16, 45, 5, 16, 33];

    let mut accumulator = 0; // le temps écoulé mais pas encore simulé
    let mut position = 0;

    for (frame, elapsed) in frame_times.into_iter().enumerate() {
        accumulator += elapsed;

        // Exécuter autant de pas fixes qu'il en tient dans le temps disponible
        let mut updates = 0;
        while accumulator >= STEP_MS {
            position += SPEED; // update() : la logique du jeu
            accumulator -= STEP_MS;
            updates += 1;
        }

        // render() : dessiner une fois par image, quoi qu'il se soit passé
        println!("image {frame} : {elapsed:>2} ms, {updates} mise(s) à jour, joueur en {position:>2}, reste {accumulator} ms");
    }
}

Sortie :

image 0 : 16 ms, 1 mise(s) à jour, joueur en  2, reste 6 ms
image 1 : 16 ms, 2 mise(s) à jour, joueur en  6, reste 2 ms
image 2 : 45 ms, 4 mise(s) à jour, joueur en 14, reste 7 ms
image 3 :  5 ms, 1 mise(s) à jour, joueur en 16, reste 2 ms
image 4 : 16 ms, 1 mise(s) à jour, joueur en 18, reste 8 ms
image 5 : 33 ms, 4 mise(s) à jour, joueur en 26, reste 1 ms

▶ Essayez par vous-même

Regardez l’image 2 : elle était lente (45 ms), alors le jeu a fait 4 mises à jour pour rattraper son retard. Au total, 131 ms se sont écoulées, et le jeu a fait 13 mises à jour de 10 ms. Le joueur finit en 26, quelle que soit la façon dont le temps a été découpé en images. Cela rend la physique stable et identique sur tous les ordinateurs, ce qui compte aussi pour les replays et les jeux en ligne. Un danger : si une image est très lente, le jeu enchaîne beaucoup de mises à jour pour rattraper, ce qui ralentit aussi l’image suivante. Les vraies boucles limitent donc aussi le nombre de mises à jour par image (l’horloge de jeu de Bevy, par exemple, avance d’au plus 250 ms par image par défaut).

L’autre méthode courante est le delta time : vous mesurez les secondes écoulées depuis l’image précédente et vous multipliez les vitesses par cette valeur (x += speed * dt). C’est plus simple, et c’est ce que font les exemples Bevy et Macroquad plus bas. Beaucoup de moteurs utilisent les deux : le delta time pour l’animation, un pas fixe pour la physique.

Qu’est-ce que l’ECS : entités, composants, systèmes

Dans beaucoup de langages, vous feriez une classe Player, une classe Enemy qui hérite de Character, et ainsi de suite. Ça devient vite compliqué : et un ennemi qu’on peut aussi ramasser ? La plupart des moteurs de jeu Rust utilisent plutôt l’ECS (Entity Component System, système entité-composant) :

Une entité n’est qu’un identifiant, comme un numéro. Elle n’a ni données ni comportement propres.
Un composant est un morceau de données simples que vous attachez à une entité : Position, Velocity, Health. En Rust, ce sont des structs ou des enums ordinaires.
Un système est une fonction qui s’exécute sur chaque entité possédant certains composants. Un système de déplacement, par exemple, travaille sur tout ce qui a à la fois une Position et une Velocity.

Un arbre a une Position mais pas de Velocity : le système de déplacement l’ignore donc. Vous voulez que l’arbre bouge ? Donnez-lui une Velocity. Vous ne modifiez aucune classe. Les données et le comportement restent séparés, ce qui s’accorde aussi très bien avec les règles de borrowing (emprunt) de Rust.

Voici un minuscule monde ECS en Rust pur. Chaque type de composant vit dans son propre vecteur, et l’identifiant de l’entité est l’indice. None veut dire « cette entité n’a pas ce composant » (voir Option). Les noms des entités restent en anglais ici, car l’affichage les aligne sur 6 caractères avec {:<6}.

struct Position { x: i32, y: i32 }
struct Velocity { dx: i32, dy: i32 }

// Une entité n'est qu'un identifiant : un indice dans chaque liste de composants
type Entity = usize;

#[derive(Default)]
struct World {
    names: Vec<&'static str>,
    positions: Vec<Option<Position>>,
    velocities: Vec<Option<Velocity>>,
}

impl World {
    fn spawn(&mut self, name: &'static str, pos: Option<Position>, vel: Option<Velocity>) -> Entity {
        self.names.push(name);
        self.positions.push(pos);
        self.velocities.push(vel);
        self.names.len() - 1
    }
}

// Un système : travaille sur chaque entité qui a À LA FOIS une Position et une Velocity
fn movement_system(world: &mut World) {
    for (pos, vel) in world.positions.iter_mut().zip(&world.velocities) {
        if let (Some(pos), Some(vel)) = (pos, vel) {
            pos.x += vel.dx;
            pos.y += vel.dy;
        }
    }
}

// Un autre système : affiche chaque entité qui a une Position
fn print_system(world: &World, tick: u32) {
    println!("tick {tick}:");
    for (id, pos) in world.positions.iter().enumerate() {
        if let Some(pos) = pos {
            println!("  #{id} {:<6} at ({}, {})", world.names[id], pos.x, pos.y);
        }
    }
}

fn main() {
    let mut world = World::default();
    world.spawn("player", Some(Position { x: 0, y: 0 }), Some(Velocity { dx: 1, dy: 0 }));
    world.spawn("tree", Some(Position { x: 5, y: 2 }), None); // pas de Velocity : il ne bouge jamais
    world.spawn("arrow", Some(Position { x: 0, y: 3 }), Some(Velocity { dx: 3, dy: -1 }));

    for tick in 1..=2 {
        movement_system(&mut world);
        print_system(&world, tick);
    }
}

Sortie :

tick 1:
  #0 player at (1, 0)
  #1 tree   at (5, 2)
  #2 arrow  at (3, 2)
tick 2:
  #0 player at (2, 0)
  #1 tree   at (5, 2)
  #2 arrow  at (6, 1)

▶ Essayez par vous-même

L’arbre (tree) reste en (5, 2) parce qu’il n’a pas de Velocity. Personne n’a écrit « les arbres ne bougent pas » : cela découle simplement des données. Les vraies bibliothèques ECS sont bien plus rapides et plus malignes que ça (elles rangent les composants pour que le processeur les lise vite, et exécutent les systèmes en parallèle), mais l’idée est la même.

Votre première application Bevy

Bevy est le moteur Rust le plus connu, et tout y est ECS. La version 0.20 est sortie en octobre 2026. Bevy demande la dernière version stable de Rust : mettez donc Rust à jour d’abord, puis créez un projet :

rustup update
cargo new my_bevy_game
cd my_bevy_game
cargo add bevy

Sous Linux, il vous faut aussi quelques bibliothèques système (son, entrées, graphismes). Le guide d’installation de Bevy (en anglais) les liste pour chaque distribution. Sous Windows, il vous faut les Visual Studio C++ Build Tools, et sous macOS les outils en ligne de commande Xcode.

Ce programme s’inspire de l’exemple officiel 2d/move_sprite de Bevy. Il dessine un carré orange qui glisse de gauche à droite. (L’exemple officiel charge une image ; ici, on utilise un simple carré de couleur, donc vous n’avez besoin d’aucun fichier image.)

use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins) // fenêtre, rendu, entrées, son...
        .add_systems(Startup, setup) // s'exécute une fois au démarrage
        .add_systems(Update, sprite_movement) // s'exécute à chaque image
        .run();
}

// Un composant : dans quelle direction cette entité se déplace
#[derive(Component)]
enum Direction {
    Left,
    Right,
}

fn setup(mut commands: Commands) {
    commands.spawn(Camera2d);

    // Créer une entité avec trois composants
    commands.spawn((
        Sprite::from_color(Color::srgb(1.0, 0.5, 0.2), Vec2::new(50.0, 50.0)),
        Transform::from_xyz(0.0, 0.0, 0.0),
        Direction::Right,
    ));
}

// Un système : s'exécute sur chaque entité qui a une Direction ET un Transform
fn sprite_movement(time: Res<Time>, mut sprite_position: Query<(&mut Direction, &mut Transform)>) {
    for (mut logo, mut transform) in &mut sprite_position {
        match *logo {
            Direction::Right => transform.translation.x += 150. * time.delta_secs(),
            Direction::Left => transform.translation.x -= 150. * time.delta_secs(),
        }

        if transform.translation.x > 200. {
            *logo = Direction::Left;
        } else if transform.translation.x < -200. {
            *logo = Direction::Right;
        }
    }
}

Comparez avec le petit monde ECS plus haut. #[derive(Component)] transforme un enum ordinaire en composant. commands.spawn((...)) crée une entité à partir d’un tuple de composants. Et Query<(&mut Direction, &mut Transform)> demande à Bevy « chaque entité qui a les deux », exactement comme notre movement_system le faisait avec zip. time.delta_secs() est le delta time de la section sur la boucle de jeu : le carré avance donc de 150 pixels par seconde sur n’importe quel ordinateur.

Lancez-le avec cargo run. La première compilation compile des centaines de crates et peut prendre plusieurs minutes : soyez patient. Ensuite, les recompilations sont bien plus rapides.

Compiler (et exécuter) Bevy plus vite

Le guide d’installation de Bevy recommande deux choses. D’abord, ajoutez ceci à Cargo.toml. Cela optimise Bevy et vos autres dépendances, tout en gardant votre propre code rapide à compiler :

[dependencies]
bevy = "0.20"

# Un peu d'optimisation dans le profil dev.
[profile.dev]
opt-level = 1

# Beaucoup d'optimisation dans le profil dev pour les dépendances.
[profile.dev.package."*"]
opt-level = 3

Sans cela, une version debug d’un jeu peut être très lente : peu d’images par seconde et de longs temps de chargement. Les dépendances ne sont compilées qu’une fois, donc vous ne payez l’optimisation qu’à la première compilation. (Les profils sont expliqués dans Performance.)

Ensuite, pendant le développement, activez la feature dynamic_linking. Bevy est alors compilé comme une bibliothèque partagée séparée : Cargo n’a plus besoin de relier tout Bevy à votre programme à chaque modification :

cargo run --features bevy/dynamic_linking

Deux avertissements du guide de Bevy : sous Windows, dynamic_linking ne fonctionne qu’avec les réglages opt-level ci-dessus. Et ne publiez pas votre jeu avec : il aurait besoin d’un fichier de bibliothèque supplémentaire à côté de lui. Compilez votre version finale sans cette feature. Le guide montre aussi comment utiliser un éditeur de liens plus rapide (lld ou mold), ce qui aide beaucoup sous Linux.

Une fenêtre Macroquad

Macroquad donne une impression très différente. Pas d’ECS, pas de constructeur d’application : vous écrivez la boucle de jeu vous-même, et vous dessinez avec des fonctions simples comme draw_circle. Il a très peu de dépendances, donc une compilation à partir de zéro prend des secondes, pas des minutes.

cargo new move_the_ball
cd move_the_ball
cargo add macroquad

[dependencies]
macroquad = "0.4"

Ce petit jeu affiche une balle que vous déplacez avec les flèches du clavier :

use macroquad::prelude::*;

#[macroquad::main("Move the Ball")]
async fn main() {
    let mut player = vec2(screen_width() / 2.0, screen_height() / 2.0);
    let speed = 250.0; // pixels par seconde

    loop {
        // 1. Entrées : les flèches déplacent le joueur
        let dt = get_frame_time(); // secondes écoulées depuis l'image précédente
        if is_key_down(KeyCode::Right) {
            player.x += speed * dt;
        }
        if is_key_down(KeyCode::Left) {
            player.x -= speed * dt;
        }
        if is_key_down(KeyCode::Down) {
            player.y += speed * dt;
        }
        if is_key_down(KeyCode::Up) {
            player.y -= speed * dt;
        }
        if is_key_pressed(KeyCode::Escape) {
            break;
        }

        // 2. Garder le joueur à l'écran
        player.x = player.x.clamp(0.0, screen_width());
        player.y = player.y.clamp(0.0, screen_height());

        // 3. Tout dessiner pour cette image
        clear_background(DARKBLUE);
        draw_circle(player.x, player.y, 20.0, ORANGE);
        draw_text("Arrow keys to move, Esc to quit", 20.0, 30.0, 28.0, WHITE);

        next_frame().await
    }
}

On y retrouve les trois étapes de la boucle de jeu : entrées, mise à jour, dessin. #[macroquad::main("Move the Ball")] ouvre une fenêtre avec ce titre. main est async, mais vous n’avez besoin ni de Tokio ni de connaître l’async : next_frame().await veut simplement dire « affiche cette image et attends la suivante ». Sous Linux, le README de Macroquad liste quelques paquets système à installer d’abord (pkg-config libx11-dev libxi-dev libgl1-mesa-dev libasound2-dev sous Ubuntu).

Des jeux sur le web (WebAssembly)

Macroquad comme Bevy peuvent compiler votre jeu pour le navigateur, en WebAssembly. Si Wasm est nouveau pour vous, lisez d’abord Rust et WebAssembly. On commence toujours par ajouter la cible Wasm :

rustup target add wasm32-unknown-unknown

Macroquad rend cela très facile. Une seule commande produit un fichier .wasm :

cargo build --release --target wasm32-unknown-unknown

Le fichier arrive dans target/wasm32-unknown-unknown/release/move_the_ball.wasm (pour l’exemple ci-dessus, il faisait environ 600 Ko). Le README de Macroquad donne un court index.html qui le charge avec un petit fichier JavaScript, mq_js_bundle.js. Mettez les deux fichiers dans un même dossier et servez-le avec n’importe quel serveur web local, par exemple basic-http-server . (installez-le avec cargo install basic-http-server). Un simple double-clic sur le fichier HTML ne marche généralement pas, car les navigateurs bloquent le chargement du fichier .wasm directement depuis le disque.

Bevy utilise wasm-bindgen pour créer le code de liaison JavaScript. Ces étapes sont adaptées du README des exemples de Bevy (pour le projet my_bevy_game ci-dessus) :

cargo install wasm-bindgen-cli
cargo build --release --target wasm32-unknown-unknown
wasm-bindgen --out-dir web --target web target/wasm32-unknown-unknown/release/my_bevy_game.wasm

Cela écrit un fichier .js et un fichier _bg.wasm dans le dossier web ; une petite page HTML importe le fichier .js et lance le jeu. Le guide d’installation de Bevy suggère aussi un profil wasm-release avec opt-level = "s" pour réduire la taille du téléchargement. Les versions web sont un excellent moyen de partager vos jeux de game jam : on y joue en un clic, sans rien installer.

Erreurs courantes

Avancer d’une quantité fixe à chaque image. x += 5.0 à chaque image veut dire que le jeu va deux fois plus vite à 120 FPS qu’à 60 FPS. Multipliez par le delta time (x += speed * dt) ou utilisez un pas de temps fixe.

Suivre un vieux tutoriel Bevy. Bevy change son API à chaque version, donc un article de blog écrit pour la 0.12 ne compilera souvent pas avec la 0.20. Vérifiez quelle version utilise un tutoriel, et préférez les exemples officiels de votre version. Chaque version a aussi un guide de migration sur le site de Bevy.

Des versions debug très lentes. Si votre jeu Bevy tourne à quelques images par seconde, vous avez probablement oublié les réglages opt-level dans Cargo.toml.

Voir trop grand dès le départ. Un RPG en monde ouvert est un premier projet difficile, dans n’importe quel langage. Commencez par Pong, Snake, Breakout ou Flappy Bird. Terminez-le, puis faites le suivant un peu plus grand.

Exercices

1. Les états du jeu avec un enum

Chaque jeu a des écrans : un menu, le jeu lui-même, un écran de pause, « game over ». Créez un enum GameState avec Menu, Playing, Paused et GameOver, et un enum Input avec Enter, Escape et PlayerDied. Écrivez fn next_state(state: GameState, input: Input) -> GameState : Entrée lance le jeu depuis le menu, Échap met en pause et reprend, mourir termine la partie, et Entrée sur « game over » ramène au menu. Toute autre entrée ne change rien. Donnez-lui une liste fixe d’entrées et affichez chaque changement. Indice : faites un match sur le tuple (state, input), et terminez par (same, _) => same.

Voir la solution

#[derive(Debug, Clone, Copy)]
enum GameState {
    Menu,
    Playing,
    Paused,
    GameOver,
}

#[derive(Debug, Clone, Copy)]
enum Input {
    Enter,
    Escape,
    PlayerDied,
}

fn next_state(state: GameState, input: Input) -> GameState {
    match (state, input) {
        (GameState::Menu, Input::Enter) => GameState::Playing,
        (GameState::Playing, Input::Escape) => GameState::Paused,
        (GameState::Paused, Input::Escape) => GameState::Playing,
        (GameState::Playing, Input::PlayerDied) => GameState::GameOver,
        (GameState::GameOver, Input::Enter) => GameState::Menu,
        // Tout le reste : ignorer l'entrée et rester où l'on est
        (same, _) => same,
    }
}

fn main() {
    use Input::*; // permet d'écrire Enter au lieu de Input::Enter
    let inputs = [Escape, Enter, Escape, PlayerDied, Escape, PlayerDied, Enter];

    let mut state = GameState::Menu;
    for input in inputs {
        let new_state = next_state(state, input);
        println!("{state:?} + {input:?} -> {new_state:?}");
        state = new_state;
    }
}

Sortie :

Menu + Escape -> Menu
Menu + Enter -> Playing
Playing + Escape -> Paused
Paused + PlayerDied -> Paused
Paused + Escape -> Playing
Playing + PlayerDied -> GameOver
GameOver + Enter -> Menu

▶ Essayez par vous-même

Un match sur un tuple liste tous les changements autorisés au même endroit, et la dernière branche rend toutes les autres entrées inoffensives. Un joueur en pause ne peut pas mourir, car (Paused, PlayerDied) tombe dans (same, _). Bevy intègre la même idée, sous le nom de States.

Récapitulatif

Rust est une vraie option pour les jeux : « presque prêt », avec un moteur solide (Bevy), des bibliothèques simples (Macroquad, ggez), des options avec éditeur (Fyrox, Godot avec gdext) et beaucoup de briques.
Chaque jeu fait tourner une boucle : entrées, mise à jour, dessin. Utilisez le delta time ou un pas de temps fixe pour que la vitesse ne dépende pas du nombre d’images par seconde.
L’ECS découpe un jeu en entités (des identifiants), composants (des données simples) et systèmes (des fonctions qui s’exécutent sur les entités ayant certains composants).
Bevy est entièrement ECS. Ajoutez les réglages de profil opt-level, et n’utilisez dynamic_linking que pendant le développement.
Macroquad est le démarrage le plus rapide en 2D : vous écrivez la boucle vous-même et dessinez avec des fonctions simples.
Les deux peuvent compiler pour le navigateur avec la cible wasm32-unknown-unknown.

Petit quiz

1. Dans un ECS, qu'est-ce qu'une entité ?

2. Pourquoi un pas de temps fixe fait-il qu'un jeu se comporte pareil sur tous les ordinateurs ?

3. Avec quel réglage de Bevy ne faut-il PAS publier votre jeu terminé ?

4. Vous voulez créer votre premier petit jeu 2D avec des compilations très courtes. Quelle crate cette page conseille-t-elle ?

Score : 0 / 4

Pour aller plus loin

Are We Game Yet? (en anglais) : le panorama communautaire des moteurs de jeu Rust, des bibliothèques pour la physique, le son et le réseau, et des jeux écrits en Rust.
Bevy Quick Start: Setup (en anglais) : le guide officiel pour installer Bevy, les réglages de compilation rapide et les profils release et Wasm.
Game development in Rust with Macroquad (en anglais) : un livre gratuit en ligne qui construit pas à pas un shoot’em up spatial complet avec Macroquad.
The godot-rust book (en anglais) : comment écrire la logique d’un jeu Godot 4 en Rust avec gdext.
Game Loop — Game Programming Patterns (en anglais) : une explication accessible et détaillée des boucles de jeu, du delta time et des pas de temps fixes.