Développer des jeux en Rust : état des lieux un an plus tard

• Il y a un an, l’auteur avait écrit sur le développement d’un jeu 3D en Rust, et livre ici son retour après avoir observé l’évolution du sujet pendant un an
• Il utilise toujours la pile graphique Rend3, WGPU et Vulkan, qui fonctionne désormais plutôt bien
• En 2024, plusieurs grands projets de jeux menés en Rust ont été abandonnés
  • Certaines équipes ont jugé les contraintes d’ownership trop lourdes
  • D’autres se sont plaintes, notamment, des temps de compilation
• arewegameyet.rs est peu mis à jour depuis juillet 2024, ce qui fait que les informations associées ont tendance à prendre du retard
• Rend3 n’est plus développé, et l’auteur maintient lui-même un fork, rend3-hp
  • Il l’a mis à jour pour suivre les versions récentes de wgpu, winit, egui, etc., et a corrigé un ancien bug de race condition
  • Un problème de goulot d’étranglement CPU subsiste quand on pousse au maximum les performances GPU. Sur une NVidia 3070, le temps CPU devient insuffisant avec une charge GPU de 25 %
  • Il faudrait le bindless de Vulkan ainsi que plusieurs files Vulkan, et il est possible que wgpu les prenne en charge en 2025
  • Si des performances maximales ne sont pas nécessaires, cette pile fonctionne correctement
• D’autres projets de rendu, comme Orbit ou Renderling, existent, mais ne sont pas activement maintenus
  • Renderling reste le plus prometteur, mais n’est pas encore prêt à l’emploi et n’a qu’un seul développeur
• Pour faire de la 3D en Rust, la maintenance directe des couches basses de la pile graphique prend énormément de temps
  • À chaque changement d’API de winit, wgpu ou egui, il faut s’adapter et réparer tout ce qui casse
  • Quand l’un évolue, il faut ensuite 1 à 2 mois aux autres pour rattraper le mouvement
• Autre problème fréquent dans l’écosystème Rust : lorsqu’on remplace les patterns sûrs de Rust par des mécanismes d’allocation maison, il devient difficile de traquer les bugs en multithread
• Limites de l’architecture de rendu
  • La plupart des renderers ne gèrent pas séparément les informations spatiales et utilisent souvent une structure qui calcule tous les objets pour chaque source lumineuse (O(N*M))
  • Pour gérer de grandes scènes, il faut un concept de partitionnement spatial (scene graph), ce qui mène vite à une architecture de niveau moteur de jeu (par ex. Bevy)
  • Bevy, avec son propre système ECS, n’exploite pas fortement le modèle d’ownership de Rust et a l’inconvénient d’imposer sa propre façon de faire
• En conclusion, il est possible de faire de la 3D complexe en Rust, mais cela demande beaucoup d’efforts

[ahwjdekf]

Il existe des règles de propriété restrictives, mais comme il y a diverses structures de données permettant de les contourner, ça donne une impression de bricolage un peu provisoire : c’est ça, exactement. On nous dit que c’est safe mais il faut de l’unsafe, on dit que c’est immuable mais ça finit quand même par être mutable, c’est le bazar total. Bien fait. Rust ne peut pas réussir.

[dreamexist]

Et pour les jeux 2D ?

[aer0700]

Il faudrait qu’un moteur de jeu basé sur Rust voie le jour...

[bbulbum]

J’imagine que développer un jeu sans moteur donne ce genre de sensation, quelle que soit la langue utilisée... haha

[coremaker]

Rust est bien adapté à la création de moteurs, de cœurs et de frameworks robustes,

mais je ne le recommanderais pas vraiment pour construire la couche applicative.

[bbulbum]

Vu le pseudo, ça inspire davantage confiance.

[winterjung]

• GN⁺ : Quitter le développement de jeux en Rust après 3 ans

[gurugio]

J’ai moi aussi brièvement travaillé avec Rust dans le cadre professionnel, et j’avais fait quelques recherches en vue d’écrire un livre, mais ces derniers temps j’ai l’impression que ma conviction s’effrite de plus en plus.
Je crois fermement au principe de Simple is best, mais j’ai l’impression d’avoir affaire à un langage qui dit le contraire.
Cela dit, maintenant qu’il a même fait son entrée dans le noyau, il ne semble pas près de disparaître.

[GN⁺]

Commentaires Hacker News

• Tiny Glade est un exemple impressionnant de jeu écrit en Rust

  • Le développement de jeux en Rust semble davantage centré sur la publication de crates inachevées que sur de vrais jeux

• En train d’apprendre Rust et sur le point de rejoindre une nouvelle équipe

  • Rust est amusant, mais pas encore assez à l’aise pour avoir des opinions tranchées sur le langage
  • Le design du langage ne semble pas si élégant
  • Il y a des règles de propriété restrictives, mais aussi diverses structures de données pour les contourner, ce qui donne une impression un peu bricolée

• Le pattern matching et les types énumérés peuvent impressionner les programmeurs C++, mais beaucoup moins les programmeurs OCaml/Haskell

• Le C++ est difficile et complexe, mais il est rafraîchissant de pouvoir utiliser un langage plus moderne

  • Si l’on ne peut pas supporter le surcoût de performance d’un GC, Rust comble cet espace, mais ce n’est pas la fin de l’histoire
  • On peut se demander si c’est forcément un meilleur choix que le C++ moderne pour quelqu’un qui démarre un nouveau projet

• Surprise que Godot ne soit pas mentionné

  • Godot prend en charge plusieurs langages, dont Rust, via GDExtension
  • Le C++ est pris en charge officiellement, et D, Go, Haxe, Rust et Swift bénéficient d’un support communautaire

• Souhait de recréer son moteur de ray-caster 2.5D en Rust

  • L’implémentation actuelle est en C et fait environ 500 lignes de code
  • Une tentative de refactorisation a cassé le ray-caster
  • Le C est amusant, mais comporte de nombreux pièges
  • Lien vers le dépôt associé fourni