Bevy 0.12 - Un moteur de jeu data-driven écrit en Rust

 (bevyengine.org)
2 points par GN⁺ 2023-11-05 | 1 commentaires | Partager sur WhatsApp
  • Le moteur de rendu prend en charge le Deferred Rendering en option, avec la possibilité de choisir un pipeline forward ou deferred par matériau et de définir une valeur par défaut globale via DefaultOpaqueRendererMethod
  • Les applications ou plugins Bevy existants doivent vérifier la procédure de migration via le guide de migration 0.11 vers 0.12
  • Bevy Asset V2 prend en charge le prétraitement des assets, la configuration basée sur des fichiers .meta, plusieurs AssetSource, les événements de chargement de dépendances récursives, l’I/O d’assets asynchrone et des handles améliorés
  • Le prétraitement des assets s’active avec AssetPlugin { mode: AssetMode::Processed } et la fonctionnalité Cargo bevy/asset_processor, mais il n’est pas encore recommandé pour la plupart des cas d’usage à l’heure actuelle
  • Sur Android, l’application ne plante plus lors de la suspension, interrompt l’exécution des systèmes jusqu’à la reprise et fournit les événements ApplicationLifetime::Suspended et ApplicationLifetime::Resumed
  • StandardMaterial ajoute specular_transmission, diffuse_transmission, thickness, ior, attenuation_color, attenuation_distance pour prendre en charge le rendu de matériaux transmissifs comme le verre, l’eau, le plastique, les feuilles et le papier
  • Le chargeur glTF prend en charge les extensions KHR_materials_transmission, KHR_materials_ior, KHR_materials_volume, KHR_materials_emissive_strength, et peut importer une seconde UV map TEXCOORD1 ou UV1
  • Le batching/instancing automatique des draw commands est désormais possible, avec la possibilité de batcher les entités partageant le même matériau et le même mesh, et de les exclure via le composant NoAutomaticBatching
  • Les ombres adoptent le PCF Shadow Filtering, avec des ombres plus douces pour DirectionalLight et SpotLight, et une méthode par défaut ShadowMapFilter::Castano13
  • L’ECS ajoute les one-shot systems, qui peuvent être enregistrés puis exécutés à la demande via SystemId, sans prise en charge des exclusive systems, des systems pour le piping de systems, de l’auto-appel ni de l’évaluation parallèle
  • FixedTime est supprimé et Time renvoie désormais des valeurs adaptées au contexte même dans FixedUpdate, ce qui évite la « death spiral » où l’application se fige à cause d’une accumulation excessive de FixedUpdate
  • Dans AnimationPlayer, set_elapsed est remplacé par seek_to, stop_repeating par set_repeat(RepeatAnimation::Never), et elapsed renvoie le temps écoulé réel non affecté par la vitesse d’animation
  • Le système d’import de shaders Bevy adopte une syntaxe de style Rust, avec prise en charge de #import bevy_pbr::forward_io::VertexOutput, des imports multiples avec accolades, des imports de chemins partiels et des chemins pleinement qualifiés
  • Côté UI, UiMaterial permet d’utiliser des shaders de matériau personnalisés sur les nœuds d’interface, et le composant Outline ajoute des contours de nœuds qui n’occupent pas d’espace dans le layout
  • L’intégration de l’accessibilité ajoute la ressource ManageAccessibilityUpdates, qui permet de désactiver la mise à jour automatique de l’arbre d’accessibilité du moteur lorsque sa valeur est false

À lire aussi

1 commentaires

 
GN⁺ 2023-11-05
Avis sur Hacker News

  • Comparé aux moteurs traditionnels comme Unity ou Godot, Bevy propose une manière de créer des jeux complètement différente.
    Sans UI ni scripting, tout se fait en code Rust, ce qui le rapproche davantage de libGDX ou Cocos2D-x. Mais comme il utilise l’ECS et Rust, la façon de coder change aussi beaucoup ; on a en fait l’impression qu’il est sur sa propre île.
    J’aimerais voir un jeu indé à succès fait avec Bevy, mais la plupart des développeurs de jeux préféreront probablement des outils traditionnels qu’ils ont déjà appris et que leur entourage utilise aussi. L’intersection entre les gens qui veulent créer des jeux et ceux qui préfèrent aussi Rust n’est pas très grande, et même dans ce groupe, beaucoup choisiront sans doute des outils éprouvés, avec de la confiance et des ressources accumulées, plutôt que d’investir beaucoup de temps et d’efforts dans l’apprentissage d’un nouveau moteur expérimental.
    Personnellement, je pense que Bevy a besoin d’un IDE et d’un langage de scripting basés sur Bevy et Rust. Cela ne supprimera pas la barrière que représente l’investissement important nécessaire pour un nouveau projet, mais ce serait bien plus accueillant pour les nouveaux utilisateurs qui n’ont pas d’expérience avec Rust et trouvent intimidant de commencer face à un mur de code. C’est à comparer avec Unity ou Godot, où l’on peut créer un prototype très basique sur un canevas en quelques heures.
    Je crois savoir que le développeur est opposé à un langage de scripting, mais il faut du hot reload et un débogage plus poussé, et je pense que c’est difficile à faire efficacement avec Rust seul. Beaucoup de développeurs de jeux pourraient aussi se sentir dépassés par Rust et son vérificateur d’emprunts. Cela dit, pour l’instant, il n’y a pas le temps, les ressources ni la volonté de l’implémenter directement.

    • De par sa structure, Bevy oblige rarement à se confronter directement au vérificateur d’emprunts. Les composants et les ressources utilisent généralement des types possédés, et on peut les manipuler via Query et Ref sans trop s’inquiéter.
      J’ai un peu essayé Bevy et vérifié le dépôt : je n’y ai trouvé aucune annotation de durée de vie.
    • Dans le développement de jeux, ce qui prenait le plus de temps était souvent la gestion des assets, puis la programmation. Un moteur comme Bevy cherche à réduire le temps passé à corriger des bugs, mais si le pipeline d’assets est insuffisant, on perd ce gain du côté des assets.
      Un langage de scripting aiderait un peu, mais les utilisateurs actuels de Bevy semblent très techniques et ne sont pas toujours des designers à temps plein, donc la demande pressante ne paraît pas énorme.
      J’attends avec intérêt l’impact que la communauté Rust pourrait avoir sur le développement de jeux, et j’aimerais y contribuer un jour, mais pour les raisons évoquées, je compte conserver pour l’instant un pipeline C++/C#. J’apprendrai correctement Rust à côté, et quand les outils auront mûri, je pourrai l’envisager pour des projets ultérieurs.
      Le hot reload est souvent une solution de secours quand les temps de compilation deviennent difficiles à supporter. Si la moyenne est d’environ 4 secondes, et une recompilation complète d’environ 20 secondes, il devient moins nécessaire de consacrer beaucoup de ressources à éviter les compilations complètes.
      Cela dit, j’ai entendu dire que Rust a globalement des temps de compilation plus longs, donc le besoin de scripting ou de hot reload pourrait arriver plus vite que prévu. Malgré tout, les projets indés en cours n’atteindront probablement pas encore cette barrière.
    • L’IDE est prévu depuis assez longtemps, et je crois savoir que c’est la priorité absolue après cette version.
      Cart, le créateur de Bevy, estime que Bevy doit être Rust-first, et je suis personnellement d’accord. Cela ne veut pas dire qu’il est impossible de créer des plugins pour plusieurs langages de scripting ; en fait, il en existe déjà quelques-uns.

  • Je suis le créateur de Bevy et le responsable du projet. Vous pouvez me poser n’importe quelle question.

    • Nous développons avec Bevy une application WASM assez importante pour la taille de notre entreprise, et l’expérience d’utilisation du moteur a été excellente.
      Bevy et sa communauté sont formidables. Nous avons dû travailler sur quelques tickets, et il a été très facile de trouver l’un des contributeurs principaux, de le sponsoriser et de pousser la demande jusqu’au bout. Les morph targets en sont un exemple.
      Carter construit quelque chose de vraiment important, avec une excellente dynamique derrière. Bevy rend le déploiement web très facile et mérite que davantage de gens s’y intéressent. La communauté est aussi très bonne, et il est facile d’obtenir de l’aide.
    • La documentation limitée me freine à l’entrée. Le livre Bevy se lit en quelques minutes, et quand on bloque, on manque vite de ressources de référence.
      Quand la documentation va-t-elle s’améliorer ? À la lecture des notes de version, idéalement chaque fonctionnalité aurait plusieurs pages de documentation. Je comprends que c’est beaucoup de travail, et qu’une documentation complète ne sera peut-être possible qu’après stabilisation.
    • En tant que développeur de jeux amateur, si je lançais un nouveau projet, je pense que je le ferais avec Bevy. Il me semble bien se placer quelque part entre Love et Godot : plus robuste que Love, mais pas aussi orienté débutants que Godot.
      À quel point Bevy est-il un moteur opinionated ? Je me demande s’il vous est déjà arrivé de devoir faire des compromis entre les fonctionnalités et l’accessibilité pour les développeurs.
      Quel type de projet est aujourd’hui le plus idéal pour Bevy ?
    • Je me demande quels sont les avantages et les inconvénients d’écrire un jeu en Rust et Bevy par rapport à d’autres langages. J’aimerais particulièrement entendre parler de performance, sécurité et vitesse de développement.
    • Quand verra-t-on les fonctionnalités permettant des systèmes dynamiques et du scripting Bevy de première classe ?
      Il existe quelques plugins de scripting, et l’attention semble aujourd’hui surtout portée sur rhai, mais on a l’impression que cela reste bloqué par le manque de prise en charge adéquate côté Bevy.
      Que Bevy se concentre actuellement sur les jeux exclusivement en Rust ou non, il existe une demande pour le scripting, et certaines personnes sont déjà occupées à chercher des solutions tierces. Je ne m’attends pas à un scripting Bevy officiel dans l’immédiat, mais je pense que Bevy devrait accepter les bases nécessaires pour que des crates tierces puissent fonctionner.

  • L’article dit que le rendu différé ne prend pas en charge le MSAA, mais ce n’est vrai que pour une implémentation naïve.
    Par exemple, on peut créer dans une pré-passe un masque de stencil pour les pixels complexes, puis utiliser un rejet stencil précoce hiérarchique pour exécuter une passe par échantillon sur les pixels complexes, et une passe par pixel sur les autres. L’utilisation des lanes SIMD ne sera pas parfaite.
    On peut aussi ajouter une passe qui traite le masque des pixels complexes et collecte un buffer de coordonnées (x, y, sample), puis obtenir ensuite une utilisation parfaite des lanes SIMD dans une unique passe de compute shader hybride par pixel/par échantillon.

    • Intéressant. J’y avais pensé autrefois, mais j’avais supposé que ce serait trop lent. Je me demande si vous connaissez des titres sortis qui utilisent cette technique.

  • Je développe un jeu avec Bevy depuis quelque temps. Vous pouvez aussi consulter le code et me poser des questions
    https://ant.care/
    https://github.com/MeoMix/symbiants
    Jusqu’ici, les difficultés viennent du fait que le système d’UI est trop verbeux pour créer confortablement des widgets, donc je suis passé à egui, même si je pense revenir à Bevy natif d’ici un an. egui a aussi de grosses limitations
    La prise en charge des relations parent/enfant est limitée, et l’ECS est conçu d’une manière qui s’en méfie quelque peu. Ajouter une étiquette à un sprite, puis déplacer/faire pivoter le sprite tout en faisant en sorte que l’étiquette suive seulement sa position, sans suivre sa rotation, s’est avéré plus difficile que prévu
    La persistance des entités entre les sessions n’est pas prise en charge par défaut. Entity sert à garantir l’unicité côté client, et recréer facilement des relations parent/enfant enregistrées ne se fait pas automatiquement non plus
    La prise en charge de la parallélisation WASM n’existe pas encore, mais l’architecture de Bevy est largement conçue pour garder l’ordre des systèmes flexible afin de tirer des gains de performance de la parallélisation des tâches
    Les requêtes spatiales donnent l’impression d’entrer en conflit avec les objectifs de l’ECS. Dès qu’on veut chercher par valeur de Position plutôt que par type, c’est-à-dire selon qu’une entité possède Position, on finit avec beaucoup de caches auxiliaires à synchroniser avec le moteur de requêtes
    Quand on modifie le monde via commands, les changements sont différés pour être traités par lots pour des raisons de performance ; mais quand il y a beaucoup de comportements différés, il devient difficile de construire des systèmes qui modifient activement le monde. On finit donc par appeler souvent apply_deferred et par utiliser des commandes personnalisées pour résoudre les conditions de concurrence
    WASM sur Android, en particulier avec la combinaison Pixel 6 et Chrome, ne fonctionne pas actuellement, mais c’est dû à un problème de dépendance en aval et cela devrait être corrigé dans Bevy 13
    Les points forts, c’est que la combinaison moteur en Rust + jeu en Rust est très agréable à utiliser, et que Rust+WASM donne rarement l’impression que la technologie vous freine. Une fois que votre cerveau commence à penser façon ECS, il est difficile de revenir en arrière, et c’est très flexible. Peut-être même trop flexible
    La communauté est active, il est donc facile de trouver des gens avec qui parler des problèmes ; la documentation n’est pas très abondante, mais il y a beaucoup d’exemples. L’optimisme pour l’avenir est fort, le rythme de développement est rapide, et chaque version fait nettement avancer les principales préoccupations

    • À noter : ant.care ne fonctionne pas sur iPhone. Je l’ai testé dans Safari et Firefox ; au bout d’un moment, le site se recharge en boucle indéfiniment

  • Les notes de version sont excellentes
    Pour des développeurs de jeux/moteurs expérimentés, certaines parties seront peut-être trop introductives, mais pour quelqu’un qui n’évolue pas en permanence dans cet univers, l’équilibre entre l’explication des changements et la présentation des sujets était très bon

  • J’ai vu une blague disant qu’il y avait 5 jeux écrits en Rust, mais 50 moteurs de jeu
    Existe-t-il vraiment une liste de jeux écrits avec Bevy ?

  • Tous les frameworks commencent avec l’idée d’implémenter quelque chose de plus classique de manière simple, propre et rapide, mais il leur manque des fonctionnalités sophistiquées.
    Puis, en rattrapant leur retard fonctionnel, ils deviennent à leur tour des monstres tout aussi complexes, et le cycle se répète.

    • C’est valable si l’on considère le cycle de vie des projets logiciels dans son ensemble, mais comme cela peut s’appliquer tel quel à n’importe quelle affirmation sur la simplicité ou la facilité d’utilisation d’un logiciel, je ne trouve pas que ce soit une critique particulièrement utile.
      La conclusion ressemble à « tout logiciel facile à utiliser qui ajoute des fonctionnalités est condamné », ce qui est un peu dramatique.
      Je serais curieux de savoir si vous avez des réflexions ou des inquiétudes concrètes sur l’architecture de Bevy ou sur sa manière d’ajouter des fonctionnalités. Nous faisons de notre mieux pour éviter ce destin.
    • Je ne suis pas forcément en désaccord, mais Bevy a un atout que la plupart des frameworks n’ont pas : la modularité. Pas seulement un concept, mais une modularité dont le bon fonctionnement a été démontré en pratique.
      Tiny Glade utilise bevy_ecs, mais n’utilise pas du tout les crates de rendu de Bevy. Personnellement, j’ai aussi quelques PR en cours pour implémenter des chemins de rendu alternatifs, par exemple du ray tracing ou un rendu meshlet piloté par le GPU avec visibility buffer, et l’intérieur de Bevy change très peu.
      Pour l’utilisateur, cela ne change pas grand-chose non plus. On ajoute FeatureFooPlugin à l’application, on utilise quelque chose comme FooComponent, et ça fonctionne.
      Certains crates ou plugins individuels peuvent grossir, mais Bevy dans son ensemble devrait rester correct. Les utilisateurs peuvent simplement ignorer ces plugins et utiliser autre chose qui leur convient mieux.
      Par ailleurs, c’est un moteur de jeu. Par définition, c’est un monstre volumineux et complexe, et il finit par absorber toutes sortes de fonctionnalités parce qu’elles peuvent être utiles à certains jeux. Le point clé est l’impact de cette inflation fonctionnelle sur l’utilisabilité. Même avec 1 000 fonctionnalités, si l’on n’a pas besoin d’interagir avec la plupart d’entre elles, ce n’est pas du tout un problème.
    • À mon avis, l’enjeu est de savoir si le projet est prêt à rompre avec le passé pour garder l’API simple, propre et rapide.
      Il est vrai que c’est plus facile pour un nouveau projet qui n’a pas à se soucier de la rétrocompatibilité. D’après ce que j’ai vu de Bevy, il y a une forte culture qui exige une bonne expérience utilisateur et cherche à réduire la surface de l’API. C’est peut-être dû au packaging de Rust, mais j’apprécie le fait qu’ils soient assez disposés à rompre avec le passé pour y parvenir.
      Ce qui est bien avec cargo, c’est que même si l’on décide de dépendre de Bevy, on n’est pas obligé de courir après une cible mouvante si une future version introduit des changements cassants. On peut simplement rester sur sa version. Ils fournissent quand même des guides pour faciliter la migration vers les versions récentes. C’est en tout cas l’expérience que j’ai eue après avoir un peu utilisé Bevy.

  • Lors du passage de 0.10 à 0.11, mon appli avait nécessité pas mal de changements, mais cette fois elle a compilé directement.

  • Bevy est l’un de mes moteurs de jeu préférés, surtout pour les gros projets. Le prétraitement Asset V2 et les fichiers .meta ont l’air très utiles.
    J’attends aussi avec impatience la prise en charge des lightmaps dans de futures versions.

  • En regardant les exemples web, je suis tombé sur la section UI, et tout semble être géré dans le canvas.
    Est-il possible de construire l’UI avec le DOM à la place et de la connecter au WASM ?

    • Oui, c’est possible, et j’ai déjà vu des cas où cela a été fait. Il faut mettre en place une façon d’échanger des informations entre l’UI et Bevy.
      Côté Rust, donc WASM, il existe des options comme web_sys, et côté JavaScript, on peut aussi appeler des fonctions WASM, donc il y a beaucoup de possibilités.