
elle corrige des bogues et apporte de nouvelles fonctionnalités
L’équipe en charge de Bevy a annoncé la sortie de la version 0.10 de Bevy, un moteur de jeu basé sur les données et construit en Rust. « Grâce à 173 contributeurs, 689 pull requests, les évaluateurs de la communauté, et nos généreux sponsors, je suis heureux d'annoncer la sortie de Bevy 0.10 sur crates.io », ont écrit les contributeurs.
Bevy est un moteur de jeu basé sur les données et construit en Rust. Il est gratuit et open source. Le code source complet est sur GitHub. Le langage de programmation Rust est un projet ambitieux de la Fondation Mozilla - un langage qui prétend être la prochaine étape de l'évolution du C et du C++.
Rust est un langage de programmation compilé multiparadigme, conçu par Graydon Hore alors employé chez Mozilla Research. Utilisé par plusieurs grandes entreprises et par de nombreux développeurs dans le monde, Rust est devenu le langage de base pour certaines des fonctionnalités indispensables du navigateur Firefox et de son moteur Gecko, ainsi que pour le moteur Servo de Mozilla.
Depuis la dernière version il y a quelques mois, l’équipe a ajouté une tonne de nouvelles fonctionnalités et corrigé des bugs. Voici, ci-dessous, quelques points forts :
Schedule ECS v3
Schedule v3 est l'aboutissement d'un important travail de conception et d'implémentation. Les API de programmation sont une partie centrale et déterminante de l'expérience des développeurs Bevy. Jetons un coup d'œil à ce qui a été livré dans la version 0.10.
Un calendrier unique et unifié
Avez-vous déjà voulu spécifier que le système_a s'exécute avant le système_b, pour vous heurter à des avertissements déroutants indiquant que le système_b n'est pas trouvé parce qu'il se trouve dans une étape différente ?
Ce n'est plus le cas ! Tous les systèmes d'un même programme sont désormais stockés dans une structure de données unique, avec une perception globale de ce qui se passe.
Cela simplifie la logique interne, rend le code plus robuste à la refonte, et permet aux auteurs de plugins de spécifier des invariants de haut niveau (par exemple, « le mouvement doit se produire avant la vérification des collisions ») sans s'enfermer dans un emplacement exact de l'agenda.
Ajout des fonctions Rust
Les systèmes (qui sont juste des fonctions Rust normales !) sont la façon de définir la logique du jeu dans Bevy ECS. Avec Schedule v3, vous pouvez ajouter des systèmes à votre application comme vous le faisiez dans les versions précédentes :
Code : | Sélectionner tout |
app.add_system(gravity)
Cependant, Schedule v3 a de nouveaux atouts dans sa manche ! Vous pouvez désormais ajouter plusieurs systèmes à la fois :
app.add_systems((apply_acceleration, apply_velocity))
Par défaut, Bevy fait fonctionner les systèmes en parallèle. Dans les versions précédentes de Bevy, vous ordonniez les systèmes comme suit :
Code : | Sélectionner tout |
1 2 3 4 | app .add_system(walk.before(jump)) .add_system(jump)) .add_system(collide.after(jump)) |
Vous pouvez toujours le faire ! Mais vous pouvez maintenant le compresser en utilisant add_systems :
Code : | Sélectionner tout |
1 2 3 4 5 6 | // much cleaner! app.add_systems(( walk.before(jump), jump, collide.after(jump), )) |
before() et after() sont des outils très utiles ! Toutefois, grâce à la nouvelle fonction chain(), il est désormais beaucoup plus facile d'exécuter des systèmes dans un ordre spécifique :
Code : | Sélectionner tout |
1 2 | // This is equivalent to the previous example app.add_systems((walk, jump, collide).chain()) |
chain() exécutera les systèmes dans l'ordre où ils ont été définis. Le chaînage est également associé à la configuration par système :
Code : | Sélectionner tout |
app.add_systems((walk.after(input), jump, collide).chain())
Ensembles de systèmes configurables
Dans Schedule v3, l'idée d'« ensemble de systèmes » a été redéfinie pour permettre un contrôle plus naturel et plus souple de la manière dont les systèmes sont exécutés et programmés. L'ancien concept d'"étiquette système" a été combiné avec celui d'"ensemble", ce qui donne une abstraction simple mais puissante.
Les ensembles de systèmes sont des collections nommées de systèmes qui partagent la configuration du système entre tous leurs membres. Le fait d'ordonner des systèmes par rapport à un ensemble de systèmes applique cet ordre à tous les systèmes de cet ensemble, en plus de la configuration de chaque système individuel.
Voyons tout de suite à quoi cela ressemblerait. Vous définissez les ensembles de systèmes comme suit :
Code : | Sélectionner tout |
1 2 3 4 5 | #[derive(SystemSet, Debug, Hash, PartialEq, Eq, Clone)] enum PhysicsSet { Movement, CollisionDetection, } |
Code : | Sélectionner tout |
app.add_system(gravity.in_set(PhysicsSet::Movement))
Vous pouvez combiner cela avec les nouvelles fonctionnalités du système mentionnées ci-dessus :
Code : | Sélectionner tout |
1 2 3 4 5 | app.add_systems( (apply_acceleration, apply_velocity) .chain() .in_set(PhysicsSet::Movement) ) |
Les systèmes peuvent appartenir à un nombre quelconque d'ensembles :
Code : | Sélectionner tout |
1 2 3 4 5 | app.add_system( move_player .in_set(MoveSet::Player) .in_set(PhysicsSet::Movement) ) |
La configuration est ajoutée à des ensembles comme celui-ci :
Code : | Sélectionner tout |
1 2 3 4 | app.configure_set( // Run systems in the Movement set before systems in the CollisionDetection set PhysicsSet::Movement.before(PhysicsSet::CollisionDetection) ) |
Les ensembles peuvent être imbriqués dans d'autres ensembles, ce qui leur permet d'hériter de la configuration de l'ensemble parent :
Code : | Sélectionner tout |
app.configure_set(MoveSet::Enemy.in_set(PhysicsSet::Movement))
Les ensembles peuvent être configurés plusieurs fois :
Code : | Sélectionner tout |
1 2 3 4 5 | // In PlayerPlugin: app.configure_set(MoveSet::Player.before(MoveSet::Enemy)) // In PlayerTeleportPlugin app.configure_set(MoveSet::Player.after(PortalSet::Teleport)) |
Il est essentiel que la configuration du système soit strictement incremental : il n'est pas possible de supprimer les règles ajoutées ailleurs. Lorsque cette règle est combinée avec les règles robustes de confidentialité des types de Rust, les auteurs de plugins peuvent prendre des décisions prudentes sur les invariants exacts qui doivent être respectés, et réorganiser le code et les systèmes en interne sans briser les consommateurs.
Les règles de configuration doivent être compatibles entre elles : tout paradoxe (comme un système défini à l'intérieur de lui-même, un système qui doit fonctionner avant et après un ensemble, des cycles d'ordre, etc) entraînera une panique à l'exécution avec un message d'erreur utile.
Programmer directement des systèmes exclusifs
Les « systèmes exclusifs » sont des systèmes qui ont un accès direct et mutable à l'ensemble du monde ECS. Pour cette raison, ils ne peuvent pas être exécutés en parallèle avec d'autres systèmes. Depuis la création de Bevy, les développeurs de Bevy ont voulu programmer les systèmes exclusifs (et les commandes de nettoyage) par rapport aux systèmes normaux. Maintenant, c'est possible ! Les systèmes exclusifs peuvent maintenant être programmés et ordonnés comme n'importe quel autre système.
Code : | Sélectionner tout |
1 2 3 4 | app .add_system(ordinary_system) // This works! .add_system(exclusive_system.after(ordinary_system)) |
Ceci est particulièrement puissant, car les vidanges de commandes (qui appliquent les commandes en file d'attente ajoutées dans les systèmes pour faire des choses comme créer et supprimer des entités) sont maintenant simplement exécutées dans le système exclusif apply_system_buffers.
[CODE...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.