5 points par GN⁺ 2025-04-29 | 3 commentaires | Partager sur WhatsApp
  • L’équipe de développement de Architect of Ruin a d’abord commencé avec le moteur Bevy et Rust, avant de basculer vers Unity et C# pour des raisons pratiques
  • Malgré les atouts de Rust et Bevy, des problèmes liés à la collaboration, au besoin d’abstractions de plus haut niveau, aux changements fréquents d’API, à la baisse d’efficacité de l’apprentissage avec l’IA et aux limites du modding se sont posés
  • L’équipe a porté à titre d’essai 3 fonctionnalités clés vers Unity, les a validées avec succès en 3 jours, puis a achevé le portage complet en 6 semaines
  • Après la transition, la quantité de code a diminué, la vitesse de développement s’est améliorée et l’usage des outils de l’écosystème est devenu possible, ce qui a nettement accru la satisfaction de développement
  • L’équipe souligne qu’elle reste très attachée à Rust et Bevy, mais qu’elle a fait un choix pragmatique pour répondre aux exigences du projet

Début du développement avec Bevy et Rust

  • En appréciant le modèle ECS de Bevy et les vérifications à la compilation propres à Rust, l’équipe a bénéficié de refactorings rapides et d’une bonne stabilité
  • Des éléments comme les tilemaps, les animations squelettiques et un pipeline de rendu personnalisé ont été implémentés directement dans Bevy
  • L’équipe a puisé beaucoup d’inspiration dans la passion de la communauté Bevy et sa culture de discussion active

Emergent Problems : des problèmes plus graves que prévu

  • Problèmes de collaboration : pour les membres de l’équipe débutants en Rust, la complexité de Rust a constitué une barrière à l’apprentissage, ralentissant le rythme des contributions
  • Manque d’abstractions de haut niveau
    • Il devenait difficile de traduire rapidement des idées de gameplay en code
    • La flexibilité nécessaire au prototypage rapide faisait défaut
  • Changements fréquents d’API : l’équipe s’est épuisée face à l’instabilité des API liée à l’évolution rapide de Bevy et aux bugs de régression à chaque mise à jour
  • Support insuffisant pour l’apprentissage avec l’IA : alors que C# et Unity bénéficiaient d’une bonne assistance, Rust et Bevy manquaient d’informations, ce qui a nui à la productivité
  • Limites du modding : l’équipe a jugé difficile de garantir un scripting stable et la compatibilité ABI dans l’environnement Rust/Bevy

La décision de changer : l’expérience Unity

  • L’équipe a comparé Unreal, Unity, Godot, le maintien de Bevy et le développement d’un moteur maison
  • Unity a obtenu la meilleure évaluation en matière de facilité d’apprentissage, de productivité, de collaboration et de possibilités de modding

Expérience des 10 %

  • Test de 3 tâches clés en moins de 3 semaines : tilemap, personnage (Spine) et construction de l’UI
  • Au final, les 3 tâches ont été achevées en 3 jours, ce qui a conduit à décider de la transition

Processus de portage et résultats

  • Tous les systèmes et contenus ont été réimplémentés dans Unity en 6 semaines
  • L’équipe a constaté une réduction du volume de code, la suppression du boilerplate et une hausse de la vitesse de développement
  • Le support d’apprentissage avec l’IA s’est amélioré et les outils de l’écosystème Unity (comme AStar Pathfinding) ont pu être exploités activement

La suite

  • Architect of Ruin est actuellement développé sur Unity et conserve une intégration rapide des idées et une forte productivité
  • L’équipe réaffirme son profond respect pour Rust et Bevy, tout en soulignant qu’il fallait faire un choix adapté au projet
  • Elle prévoit de partager plus tard davantage de détails sur l’implémentation sous Unity et l’expérience de portage

Conclusion

  • L’équipe reconnaît ne pas avoir évalué équitablement les options au départ
  • Elle estime que, même si ce changement de direction a demandé du temps, il lui en a finalement fait gagner davantage
  • Elle a compris que, pour concrétiser sa vision du développement, un jugement pragmatique au-delà de l’instinct était essentiel

3 commentaires

 
aer0700 2025-04-30

J’imagine qu’il existe peut-être un moteur GUI qui utilise Rust comme langage de script, mais je ne sais pas s’il y en a un qui soit utilisé en production. On voit parfois passer des cas d’échec ? à propos du développement de jeux en Rust, et bon… voir remonter des échecs, pourquoi pas, mais ce qui me gêne un peu, c’est qu’on n’entend pas vraiment parler de cas de réussite. Il doit pourtant bien y avoir des gens qui l’utilisent avec succès quelque part.

 
qwqwhs 2025-04-30

À l’inverse, ils se disent peut-être que si c’est bien utilisé, tout le monde en fait déjà autant, donc qu’il n’y a pas besoin de le publier ?

 
GN⁺ 2025-04-29
Commentaires sur Hacker News
  • Un nouvel exemple d’échec d’un projet de jeu mené en Rust. C’est regrettable

    • Je développe depuis presque 5 ans un client de métavers en Rust, et cela prend beaucoup trop de temps
    • D’autres ont mené un projet similaire en C#/Unity en moins de 2 ans
    • La base d’utilisateurs du développement de jeux 3D en Rust est très réduite
    • Il n’existe aucun exemple de titre AAA développé en Rust, ni de personne ayant résolu les problèmes de performance
    • La pile utilisée est Rend3/Egui/Winit/Wgpu/Vulkan, et à part Vulkan, tout comporte beaucoup de bugs
    • Il y a beaucoup trop de crates différentes qui veulent posséder la boucle d’événements
    • Les crates sont souvent refactorées tous les quelques mois, ce qui casse les API
    • Le déréférencement est difficile en Rust
    • Rust a besoin d’une méthode cohérente pour la propriété unique et le déréférencement
    • Les traits de Rust ne sont pas des objets et ne conviennent pas à la construction d’une hiérarchie d’objets
  • Cela ressemble à une bonne leçon sur les raisons pour lesquelles les moteurs de jeu commerciaux dominent le développement de jeux

    • Il y a énormément de choses à faire pour créer un jeu, mais ce sont en majorité des problèmes déjà résolus
  • J’aime Rust comme alternative au C++, mais je pense que le C++ ne convient pas à la plupart des projets

    • Beaucoup de gens semblent choisir Rust parce qu’ils pensent qu’il est plus efficace
  • Le développement de jeux en Rust ressemble à du développement de pionnier, et demande énormément de travail

    • Rust n’est pas encore prêt
  • J’aime Rust, mais il rend l’itération rapide difficile

    • J’ai essayé Bevy, mais je suis revenu à Godot
  • Sur un projet, nous sommes passés de Rust à Go, et la vitesse d’itération est devenue plus rapide

    • Le code est plus fragile, mais vu la nature du projet, je pense que c’était le bon choix
  • La forte volatilité de l’écosystème Rust est un inconvénient inattendu

    • Les crates sont souvent abandonnées, et je pense que c’est parce que les gens veulent surtout utiliser Rust
  • Un développeur crée le moteur de jeu en C et développe le jeu en Lua

    • Il y a une séparation nette entre le moteur de jeu et le jeu lui-même
    • Un jeu appelé Sapiens est sorti avec succès sur Steam
  • Travailler en Rust est presque toujours plus difficile

    • C’est un avis fondé sur une expérience personnelle
  • L’objectif du projet était de permettre à un frère qui ne code pas de contribuer

    • J’avais l’impression qu’il fallait continuer à mettre à niveau vers les versions les plus récentes
    • Les studios qui utilisent Unity ne mettent pas souvent de version à niveau, sauf si un bug précis est corrigé