Comment Roblox évalue la création de jeux « Build »

Build, notre nouvel outil de création « mobile first », permet à un utilisateur de Roblox de créer un jeu à l’aide de consignes textuelles et de le publier à l’intention des joueurs du monde entier. La création d’un jeu complet nécessite un système agentique de bout en bout : un système qui coordonne le code, les ressources visuelles, les systèmes de gameplay, l’interface utilisateur et les commandes en un seul artefact composite. Ce système doit gérer de manière robuste les différents scénarios qui émergent à la suite des actions des joueurs et des interactions multijoueurs. Depuis le lancement de la version alpha en Nouvelle-Zélande, plus de 100 000 joueurs ont utilisé Build pour s’essayer à la création d’un jeu, et environ 9 000 jeux créés avec Build ont été publiés^.¹ Parmi les milliers de personnes ayant utilisé Build pour créer un jeu, 71 % n’avaient jamais utilisé Roblox Studio auparavant,^¹ ce qui montre qu’elles tentent une nouvelle expérience avec Build.

Mais les créateurs n’utiliseront ce nouvel outil que s’il est facile à prendre en main et si la qualité des jeux qu’il génère est suffisamment élevée pour servir de base à la suite du développement. Pour évaluer la qualité des jeux créés avec Build, nous analysons le parcours de création de bout en bout et nous nous appuyons sur ces évaluations ainsi que sur les retours des créateurs pour améliorer le produit. Notre cadre d’évaluation (eval) nous a aidés à hiérarchiser et à améliorer la compréhension de l’intention, la jouabilité en 3D et la finition. Depuis le lancement de la version alpha de Build en Nouvelle-Zélande, la satisfaction des créateurs a augmenté de 10 %, les résultats non souhaités sont passés de 18 % à 3 %, et environ 14 % des sessions guidées et 19 % des tests de jeu sont publiés^.² Il s’agit d’indicateurs descriptifs des progrès réalisés, et non d’estimations causales de l’impact de l’évaluation à lui seul.

Pourquoi l’évaluation de la création de jeux est différente

Les jeux présentent certains des mêmes défis d’évaluation que d’autres systèmes générant des artefacts composés, tels que les applications, les vidéos et les modèles du monde. Par exemple, la qualité dépend de la manière dont plusieurs composants fonctionnent ensemble, et aucune note attribuée à un composant isolé ne décrit pleinement le résultat. 

Ce qui distingue les jeux, c’est que l’artefact est un système exécutable en temps réel piloté par les joueurs. Des propriétés telles que la réactivité, l’autonomie, la progression et les sensations de jeu émergent de l’interaction et ne peuvent être pleinement évaluées en inspectant uniquement le code ou les ressources. Un jeu doit donc satisfaire à des critères particulièrement élevés : d’une part, une exactitude de bas niveau (absence de défauts et jouabilité), et d’autre part, une expérience joueur de haut niveau (un jeu qui donne l’impression d’être abouti, et non un prototype). 

La question à laquelle nous cherchons à répondre par le biais de l’évaluation n’est pas de savoir si un élément particulier est correct, mais si l’artefact dans son ensemble correspond à l’intention du créateur, et si les joueurs peuvent vivre l’expérience dans son intégralité. Pour y répondre, il faut plus d’un indicateur.

Quatre indicateurs, un cadre

Notre cadre d’évaluation de la création « Build » combine quatre indicateurs. Chacun répond à une question différente, détecte une catégorie distincte d’échecs et génère un score quantitatif concret :

1. Qualité des spécifications du jeu (note de 0 à 100) : Build est l’agent de création de bout en bout : il traduit les instructions du créateur en spécifications, puis s’en sert pour générer le jeu. L’évaluateur vérifie si les spécifications prennent explicitement les décisions importantes, respectent l’intention du créateur, tiennent compte de la faisabilité au sein de l’environnement d’exécution de Roblox et évitent d’inventer des exigences qui n’ont jamais été exprimées.

2. Qualité statique du jeu (note de 0 à 100) : l’évaluateur statique examine le jeu généré en mode édition de Roblox Studio. Cela inclut la structure du jeu, les scripts, les ressources, les propriétés, les connexions et les limites client/serveur. À ce stade, nous cherchons à répondre à deux questions. La première est de savoir si le jeu est correctement construit : implémentation des systèmes requis, choix de l’API du moteur et de la mise en réseau, présence des commandes et des composants d’interface utilisateur attendus, robustesse et cohérence de l’architecture du jeu. 

La seconde est de savoir s’il est conçu pour être divertissant : profondeur de la boucle principale, variété et progression du contenu, progression, rejouabilité et innovation au-delà des standards du genre. Un jeu peut présenter une architecture soignée mais manquer de profondeur de contenu, ou regorger d’idées mais être mal agencé. 

En distinguant ces deux aspects et en les évaluant à l’aune des meilleures pratiques, on obtient une vision plus précise des points faibles du jeu.

3. Test de jeu (taux de réussite de 0 à 100 %) : l’évaluateur lance le jeu et exécute un plan de test en simulant des interactions réelles de type joueur, notamment des tapotements, des clics, des frappes au clavier et des actions de navigation, plutôt que de déclencher des événements à partir du code. Un plan de test au cas par cas vérifie que le jeu démarre, répond aux interactions, progresse, se remet d’un échec et ne présente pas d’erreurs d’exécution. Chaque élément fait l’objet d’une évaluation binaire (réussite/échec), rapportée sous forme de taux de réussite pondéré par niveau, ainsi que d’un verdict simple « jouable » ou « non jouable ». Nous répétons les exécutions pour mesurer la cohérence.

4. Qualité visuelle et expérience utilisateur (note de 0 à 100) : Certains des aspects les plus importants de l’aspect et de la sensation d’un jeu ne peuvent pas être déduits du code ; c’est pourquoi l’évaluateur visuel note la présentation de manière indépendante à partir d’enregistrements de gameplay sur des fenêtres d’affichage représentant différents appareils. Cette grille d’évaluation se concentre uniquement sur l’aspect visuel et sonore du jeu, en se basant sur la qualité des ressources, la finition de l’interface utilisateur, les animations, l’éclairage et l’audio. La question centrale est la suivante : le jeu donne-t-il l’impression d’être un produit prêt à être commercialisé, ou plutôt un prototype ? En séparant les aspects visuels des mécanismes de jeu, on évite que les critères « le code fonctionne » et « le jeu a l’air abouti » ne soient fusionnés en une seule note trompeuse.

Parallèlement aux signaux notés, chaque exécution capture des métriques à titre informatif uniquement, telles que l’utilisation des jetons, les appels d’outils, les compétences déclenchées et la latence. Ces métriques n’influencent pas la note d’évaluation, mais elles peuvent expliquer comment un résultat a été obtenu et détecter des régressions que les grilles d’évaluation ne repèrent pas, comme une compilation dont le coût a doublé pour le même jeu.

Les signaux correspondent aux défaillances qu’ils détectent :

Parcours d’un circuit d’obstacles 3D guidé

Les indications sont plus faciles à repérer lorsqu’elles proviennent d’une consigne réelle. Par exemple : « Un véritable jeu d’obstacles en 3D, avec une plate-forme de départ, des obstacles mobiles, des points de contrôle et une ligne d’arrivée. » Les jeux d’obstacles sont un genre de jeu de plateforme très populaire sur Roblox. L’intention du créateur est claire, même si elle ne prescrit pas chaque détail de mise en œuvre. Le développeur doit compléter les détails en se basant sur des hypothèses raisonnables.

Plan et spécifications

L'équipe de développement a rédigé un cahier des charges pour un nouveau jeu, intitulé Skyforge Ascent, détaillant un parcours en cinq sections comportant des points de contrôle et trois types de dangers. Ce document définissait la boucle de jeu principale, la courbe de difficulté, la direction artistique, les écrans, les superpositions et les commandes. L'évaluation du cahier des charges lui a attribué une note de 91/100, avec la note maximale pour l'exhaustivité, le respect des délais, la faisabilité et la cohérence interne. La déduction provenait de deux aspects spécifiques : les détails de mise en œuvre et la couverture des critères d'acceptation. 

Le cahier des charges n’a jamais fixé de constantes numériques, telles que les vitesses de rotation, les distances de glissement, les durées des tuiles, les dimensions des plates-formes ou la hauteur du plan de réinitialisation ; un ingénieur doit donc encore les définir. De plus, certains critères d’acceptation (tels que « environ 24 plates-formes » ou « palette de couleurs de la forge céleste ») ne sont pas strictement vérifiables. Un score élevé pour le cahier des charges prouve uniquement que le document est prêt à être mis en œuvre. Les trois étapes suivantes visent à déterminer si ces engagements résistent à la réalité du développement du jeu.

Contrôles statiques : qualité du code et qualité du contenu

Le juge virtuel a inspecté le fichier de configuration de Skyforge Ascent sans y jouer, et les deux angles d’évaluation ont abouti à des conclusions différentes.

Le critère d’ingénierie, après analyse du même fichier de niveau, lui a attribué une note de 98/100. Il a constaté une construction exemplaire comprenant cinq sections et trois dangers mobiles, répondant pleinement à l’intention du créateur grâce à des points de contrôle séquentiels gérés par le serveur, des systèmes de réinitialisation en cas de chute et une interface utilisateur basée sur le framework StyleSheet. Tout ce qui était décrit dans le cahier des charges a été respecté. Le seul problème concernait deux exportations de fonctions d’aide inutilisées.

L’angle de conception lui a attribué une note de 31/100. Tout fonctionnait, mais le jeu a obtenu zéro en matière de progression, de rejouabilité, d’autonomie du joueur et d’attrait original. La boucle de jeu était simple et linéaire — atteindre chaque point de contrôle, franchir la ligne d’arrivée — avec peu de variété d’une partie à l’autre et aucune raison de revenir pour une deuxième partie. Il s’agit d’un classique du genre « obby », et non d’un jeu doté d’un attrait qui lui est propre.

C’est là que réside le constat. La qualité du code et celle du contenu sont des dimensions fondamentalement différentes, et une version peut être quasi parfaite sur l’une tout en échouant sur l’autre. Une note de qualité unique et combinée aurait fait la moyenne de ces deux aspects pour aboutir à un résultat dénué de sens.

Test de jeu

L’agent de test a joué au jeu en utilisant des commandes identiques à celles d’un vrai joueur et a réussi les neuf éléments du plan de test : faire apparaître un personnage sur la plate-forme de départ, se déplacer dans un environnement 3D en franchissant des fossés, subir des chocs avec des obstacles, déclencher des points de contrôle et la récupération automatique après une chute, terminer la partie et redémarrer, le tout sans aucune erreur d’exécution. Lors de cette session spécifique, Skyforge Ascent a obtenu un score de 100/100 au test de jouabilité.

Un score parfait au test de jouabilité prouve simplement que les mécanismes fonctionnent et que le jeu est techniquement jouable du début à la fin. Cela ne dit rien sur le fait que le jeu soit réellement captivant ou amusant à jouer — c’est précisément cette distinction qui explique pourquoi l’angle de conception lui a attribué un score de 31.

Qualité visuelle

Enfin, le système d’évaluation a noté la session enregistrée sur une fenêtre d’affichage de la taille d’un téléphone pour ce qui est de la présentation visuelle. Skyforge Ascent a obtenu un score de 86/100 : un rendu épuré, cohérent et parfaitement conforme aux visuels d’un « obby » classique ; une géométrie des plates-formes lisible ; des dangers clairement identifiables ; et un HUD moderne et discret. De légères limites visuelles l’empêchent d’atteindre la perfection, mais rien n’est défectueux, et rien ne pousserait un joueur à arrêter de faire défiler l’écran.

Métriques de trace

La même session a également permis d’enregistrer des métriques de processus. La compilation du jeu a pris environ huit minutes, aucune erreur d’outil n’a été détectée, et Build a utilisé les compétences en 3D, en interface utilisateur, en édition de scripts, en insertion de ressources et en audio de jeu. Ces métriques n’influencent pas directement la note d’évaluation, mais elles nous renseignent sur la manière dont le jeu a été développé et permettraient de signaler une future version qui deviendrait plus lente ou plus coûteuse sans apporter de gain.

Sur cinq critères, Skyforge Ascent a obtenu des notes variables en matière de spécifications du jeu, de qualité du code, de qualité du contenu, de test de jouabilité et de qualité visuelle. Quatre de ces critères indiquent que Build est capable de transformer une simple consigne en une expérience Roblox complète, correcte, jouable et présentable. Un critère indique en revanche qu’il ne s’agit pas d’un jeu auquel quiconque choisirait de rejouer. Mesurer cet écart, plutôt que de le gommer en calculant une moyenne, est l’objectif même de l’évaluation de Build.

Comment l’évaluation précoce a amélioré Build 

Les résultats d’évaluation ne se limitent pas à générer des notes ; ils fournissent également des orientations concrètes pour l’amélioration du produit. En combinant le débogage des composants individuels avec des tests holistiques au niveau du système, les évaluations par lots hors ligne sur des suites de consignes standardisées ont directement façonné le développement de Build. 

1. Résolution rapide des points faibles signalés par les créateurs de la version alpha : lors de notre lancement de la version alpha en Nouvelle-Zélande, les utilisateurs nous ont fait savoir que Build créait parfois un jeu en 2D alors qu’ils souhaitaient un jeu en 3D. Le cadre d’évaluation a aidé notre équipe à améliorer rapidement les capacités 3D de Build. En l’espace de deux semaines, nous avons amélioré la capacité de Build à comprendre l’intention d’un utilisateur de créer un jeu en 3D, même s’il ne l’avait pas explicitement indiqué. Nous avons également affiné la jouabilité et la finition en 3D en corrigeant des problèmes courants liés au positionnement des objets, à l’éclairage, etc. Depuis lors, les plaintes du type « ce n’est pas ce que je veux » sont passées de 18 % à 3 % parmi l’ensemble des plaintes ; le taux global d’insatisfaction après les tests de jeu a baissé de 10 points de pourcentage. Nous avons également tiré des enseignements lors des itérations sur le cadre d’évaluation lui-même. 
2. Évaluation comparative entre modèles et architectures : nous utilisons notre cadre d’évaluation pour comparer rigoureusement les configurations du système Build à des suites de prompts standardisées. Avant de déployer les modifications en production, des rapports d’évaluation A/B hors ligne comparent les versions candidates à nos références de production selon quatre dimensions : 

Par exemple, ces comparaisons hors ligne nous permettent d’isoler l’impact des différentes mises à niveau du modèle et des décisions de routage des agents sur les signaux de qualité individuels :

• Performances du modèle de base : la mise à niveau de notre modèle de base a généré des gains constants sur tous les indicateurs, ce qui s’est traduit par moins de builds défaillants dès le premier essai, un rendu visuel plus soigné et un contenu de jeu plus riche.
• Architecture de routage des agents : à l’inverse, la délégation de sous-tâches spécifiques à un modèle allégé dans une configuration à deux agents a préservé la profondeur et la diversité du contenu, mais a entraîné de fortes régressions en termes de jouabilité et de finition visuelle.

1. Suivi des références de qualité à travers les paradigmes de création : nous utilisons également ce cadre pour comprendre la qualité actuelle de la version à différents moments à l’aide de l’ensemble d’évaluation le plus pertinent. Ces ensembles fournissent des instantanés de tâches de création de plus en plus vastes et complexes.
   Le premier ensemble se compose exclusivement de jeux en 2D dotés de mécanismes relativement simples. La logique du jeu était facile à mettre en place, ce qui explique que le score des tests de jeu ait tendance à être plus élevé ; en revanche, le score du contenu est resté faible pour exactement la même raison.
   À mesure que nous nous concentrons sur les jeux en 3D, la répartition des notes évolue naturellement : il devient plus difficile d’obtenir un gameplay sans bug, ce qui fait baisser les notes des tests de jeu. Les notes visuelles restent stables en raison d’un manque de finition des ressources, ce qui donne aux jeux un aspect de prototype. Les notes de contenu sont plus élevées, car les jeux en 3D ont le potentiel d’être plus riches — mais les notes globales ont tendance à rester faibles, car les invites à tour unique offrent une marge limitée pour l’expansion du contenu.

1. Mise en évidence des goulots d’étranglement spécifiques à chaque genre : les données d’évaluation soulignent également d’importantes variations de performances d’un genre à l’autre. Les genres qui font la part belle aux mécanismes de jeu (par exemple, les RPG, les jeux de tir, les jeux de course) ont tendance à rencontrer davantage de problèmes de jouabilité. Les genres dont la logique est relativement simple (par exemple, les jeux de survie et de gestion) obtiennent souvent de meilleurs résultats lors des tests de jeu, ce qui fait du polissage visuel et de la conception de l’interface utilisateur les prochains défis à relever. Connaître ces différences entre les genres nous incite à élargir notre ensemble d’évaluation avec un échantillonnage plus équilibré parmi les jeux de Build.
2. Leçons tirées de la conception du harnais d’évaluation : les itérations sur le framework lui-même nous ont appris des leçons essentielles sur la fiabilité du harnais :

• Métrique système vs métrique composant : une structure de code propre ou une utilisation correcte des API ne garantissent pas un jeu jouable. Nous distinguons clairement la justesse, la conception et la présentation afin d’éviter de masquer des bugs exploitables.
• Faiblesses du harnais et calibrage humain : les vérifications statiques peuvent passer à côté de blocages d’exécution provoquant le plantage du jeu, tandis que les tests de jeu automatisés peinent à gérer une physique complexe. Les juges virtuels sont continuellement calibrés par rapport à des développeurs de jeux professionnels et à des testeurs expérimentés de la communauté.
• Extension aux multi-tours et au trafic réel : comme les véritables créateurs itèrent en continu (en ajoutant des systèmes, en ajustant la difficulté, en corrigeant des bugs), nous étendons notre harnais d’évaluation pour prendre en compte les modifications multi-tours et les distributions de prompts du monde réel.

Prochaines étapes

Nous nous concentrons actuellement sur l’extension de notre système d’évaluation de la création « Build » dans cinq directions :

1. Une couverture plus large des genres, des expériences en 2D/2,5D/3D, des scénarios multijoueurs et des niveaux de complexité
2. Un meilleur support des modifications en plusieurs itérations
3. Des preuves plus fiables issues de tests de jeu, de captures d’écran, de vidéos et d’enregistrements audio
4. Un calibrage à grande échelle par rapport aux évaluations humaines et aux cas de référence définis par les créateurs
5. Une meilleure intégration entre l’évaluation hors ligne, les signaux produit en ligne et les tests de régression

Notre objectif à long terme est de mettre en place un système d’évaluation transparent et en constante amélioration, qui mesure Build au niveau qui importe aux créateurs : la qualité des expériences qu’ils peuvent créer, tester, partager et continuer à développer. Aujourd’hui, ces signaux sont utilisés pour évaluer les jeux générés par Build. Au fil du temps, à mesure que nous les affinerons et les calibrerons par rapport au jugement humain, ils pourraient s’étendre à d’autres workflows de création et contribuer à établir un langage commun pour appréhender la qualité des jeux au sein de l’écosystème Roblox dans son ensemble.

Pour un aperçu connexe de l’évaluation des systèmes agentiques pour Roblox Assistant, consultez l’article « Utilisation d’OpenGameEval pour évaluer les assistants IA agentiques pour Roblox Studio ».