- 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
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.
À 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 ?
Commentaires sur Hacker News
Un nouvel exemple d’échec d’un projet de jeu mené en Rust. C’est regrettable
Cela ressemble à une bonne leçon sur les raisons pour lesquelles les moteurs de jeu commerciaux dominent le développement de jeux
J’aime Rust comme alternative au C++, mais je pense que le C++ ne convient pas à la plupart des projets
Le développement de jeux en Rust ressemble à du développement de pionnier, et demande énormément de travail
J’aime Rust, mais il rend l’itération rapide difficile
Sur un projet, nous sommes passés de Rust à Go, et la vitesse d’itération est devenue plus rapide
La forte volatilité de l’écosystème Rust est un inconvénient inattendu
Un développeur crée le moteur de jeu en C et développe le jeu en Lua
Sapiensest sorti avec succès sur SteamTravailler en Rust est presque toujours plus difficile
L’objectif du projet était de permettre à un frère qui ne code pas de contribuer