Hoe Roblox het maken van games beoordeelt

Met Build, onze nieuwe mobielgerichte creatietool, kunnen Roblox-gebruikers een spel maken aan de hand van tekstprompts en dit publiceren voor spelers over de hele wereld. Het genereren van een holistisch spel vereist een end-to-end agentisch systeem voor spelgeneratie: een systeem dat code, visuele elementen, gameplay-systemen, gebruikersinterface en besturing coördineert tot één samengesteld geheel. Dit systeem moet de verschillende scenario's die ontstaan door spelersinvoer en multiplayer-interacties op robuuste wijze kunnen verwerken. Sinds de alfa-lancering in Nieuw-Zeeland hebben meer dan 100.000 spelers Build gebruikt om een spel te maken, en zijn er ongeveer 9.000 Build-spellen gepubliceerd.¹ Van de duizenden die Build hebben gebruikt om een spel te maken, had 71% nog nooit eerder Roblox Studio gebruikt,¹ wat aantoont dat ze met Build iets nieuws proberen.

Maar makers zullen deze nieuwe tool alleen gebruiken als deze gebruiksvriendelijk is en de kwaliteit van de games die ermee worden gegenereerd hoog genoeg is om op voort te bouwen. Om inzicht te krijgen in de kwaliteit van de games die met Build worden gemaakt, evalueren we het volledige creatieproces en gebruiken we die evaluaties, samen met feedback van makers, om het product te verbeteren. Ons evaluatiekader heeft ons geholpen prioriteiten te stellen en het begrip van de intentie, de 3D-speelbaarheid en de afwerking te verbeteren. Sinds de alfa-lancering van Build in Nieuw-Zeeland is de tevredenheid onder makers met 10% gestegen, is het aantal onbedoelde resultaten gedaald van 18% naar 3%, en wordt ongeveer 14% van de gestimuleerde sessies en 19% van de playtests gepubliceerd^.² Dit zijn beschrijvende indicatoren van vooruitgang, geen causale schattingen van de impact van de evaluatie op zich.

Waarom het evalueren van gamecreatie anders is

Games hebben te maken met een aantal van dezelfde evaluatie-uitdagingen als andere systemen die samengestelde artefacten genereren, zoals apps, video’s en wereldmodellen. De kwaliteit hangt bijvoorbeeld af van hoe meerdere componenten samenwerken, en geen enkele afzonderlijke componentenscore geeft een volledig beeld van het eindresultaat. 

Wat games onderscheidt, is dat het artefact een uitvoerbaar, realtime systeem is dat door spelers wordt aangestuurd. Eigenschappen zoals reactievermogen, zeggenschap, voortgang en spelgevoel komen tot uiting door interactie en kunnen niet volledig worden beoordeeld door alleen de code of assets te inspecteren. Een game moet daarom voldoen aan een uitzonderlijk hoge lat wat betreft correctheid op laag niveau (foutloos en speelbaar), evenals een hoogwaardige spelerservaring op hoog niveau (een game die aanvoelt als voltooid, niet als een prototype). 

De vraag die we via evaluatie willen beantwoorden, is niet of een afzonderlijk onderdeel correct is, maar of het artefact als geheel overeenkomt met de intentie van de maker en of spelers de hele ervaring kunnen doorlopen. Om die vraag te beantwoorden, is meer dan één maatstaf nodig.

Vier signalen, één raamwerk

Ons evaluatiekader voor de creatie van Builds combineert vier signalen. Elk beantwoordt een andere vraag, detecteert een andere categorie van fouten en levert een concrete kwantitatieve score op:

1. Kwaliteit van de spelspecificatie (score 0 - 100): Build is de end-to-end-creatieagent: deze vertaalt de opdracht van de maker naar een specificatie en gebruikt die vervolgens om het spel te genereren. De beoordelaar evalueert of de specificatie belangrijke beslissingen expliciet vastlegt, de intentie van de maker behoudt, rekening houdt met de haalbaarheid binnen de runtime van Roblox en vermijdt het bedenken van vereisten die nooit zijn geformuleerd.

2. Kwaliteit van de statische game (score 0 - 100): De beoordelaar van de statische game inspecteert de gegenereerde game in de bewerkingsmodus van Roblox Studio. Dit omvat de gamestructuur, scripts, assets, eigenschappen, verbindingen en client/server-grenzen. In deze fase proberen we twee vragen te beantwoorden. De eerste is of het spel correct is gebouwd: implementatie van vereiste systemen, keuzes met betrekking tot de engine-API en netwerken, aanwezigheid van verwachte besturingselementen en UI-componenten, robuustheid en samenhang van de spelarchitectuur. 

De tweede vraag is of het spel is ontworpen om leuk te zijn: de diepgang van de kernloop, de variatie en opbouw van de inhoud, de voortgang, de herspeelbaarheid en innovatie die verder gaat dan wat gebruikelijk is binnen het genre. Een spel kan architectonisch strak in elkaar zitten maar geen inhoudelijke diepgang hebben, of juist vol ideeën zitten maar slecht in elkaar zitten. 

Door deze twee invalshoeken te scheiden en te toetsen aan best practices, krijgen we een gedetailleerder beeld van waar de game tekortschiet.

3. Speltest (0 - 100% slagingspercentage): De speltestbeoordelaar start het spel en voert een testplan uit met echte, spelerachtige invoer, waaronder tikken, klikken, toetsaanslagen en navigatie, in plaats van gebeurtenissen vanuit de code te activeren. Een testplan per geval controleert of het spel start, reageert, vordert, herstelt van fouten en vrij blijft van runtime-fouten. Elk item is een binaire goed/fout-beoordeling, gerapporteerd als een naar niveau gewichtse slagingspercentage naast een eenvoudig oordeel van speelbaar/niet-speelbaar. We herhalen de testruns om de consistentie te meten.

4. Visuele en ervaringskwaliteit (score 0 - 100): Sommige aspecten die het belangrijkst zijn voor de uitstraling en beleving van een spel, zijn niet af te lezen uit de code. Daarom beoordeelt de visuele evaluator de presentatie afzonderlijk aan de hand van opgenomen gameplay op viewports die verschillende apparaten vertegenwoordigen. Deze rubriek kijkt uitsluitend naar hoe een spel eruitziet en klinkt, op basis van de kwaliteit van de assets, de afwerking van de gebruikersinterface, bewegingen, belichting en audio. De kernvraag is: komt de game over als een product dat klaar is voor release, of als een prototype? Door de visuele aspecten los te houden van de spelmechanica wordt voorkomen dat „de code werkt“ en „de game ziet er af uit“ worden samengevoegd tot één misleidende score.

Naast de gescoorde signalen worden bij elke run ook statistieken vastgelegd die louter informatief zijn, zoals het gebruik van tokens, tool-aanroepen, geactiveerde vaardigheden en latentie. Deze statistieken beïnvloeden de evaluatiescore niet, maar ze kunnen wel verklaren hoe een resultaat tot stand is gekomen en regressies opsporen die de rubrieken missen, zoals een build die twee keer zo duur is geworden voor hetzelfde spel.

De signalen worden gekoppeld aan de fouten die ze opsporen:

Een 3D-obby-parcours met aanwijzingen doorlopen

De signalen zijn het duidelijkst te zien bij een echte prompt. Bijvoorbeeld: “Een echt 3D-obby-spel, met een startplatform, bewegende obstakels, checkpoints en een finishlijn.” Obby’s zijn een populair type platformspel op Roblox. De bedoeling van de maker is duidelijk, ook al worden niet alle implementatiedetails voorgeschreven. De bouwer moet de details invullen op basis van redelijke aannames.

Plan en specificatie

Build heeft een specificatiedocument opgesteld voor een nieuwe game, genaamd Skyforge Ascent, waarin een parcours van vijf secties met checkpoints en drie soorten gevaren gedetailleerd wordt beschreven. Hierin werden de kernloop, de moeilijkheidscurve, de art direction, de schermen, de overlays en de besturing gedefinieerd. De specificatiebeoordeling scoorde 91/100, waarmee het de volledige score behaalde op volledigheid, naleving van de opdracht, haalbaarheid en interne consistentie. De aftrek kwam voort uit twee specifieke aspecten: implementatiedetails en de dekking van de acceptatiecriteria. 

In de specificatie zijn numerieke constanten, zoals draaisnelheden, glijafstanden, tegel-timings, platformafmetingen of de hoogte van het resetvlak, nooit vastgelegd, dus een engineer moet deze nog steeds zelf bedenken. Bovendien zijn enkele acceptatiecriteria (zoals „ongeveer 24 platforms“ of „het kleurenpalet van Celestial Forge“) niet strikt falsifieerbaar. Een hoge specificatiescore bewijst alleen dat het document klaar is om te worden gebouwd. Of die toezeggingen de confrontatie met de daadwerkelijke game-ontwikkeling doorstaan, is wat de volgende drie fasen meten.

Statische controles: codekwaliteit en inhoudskwaliteit

De virtuele beoordelaar inspecteerde het placefile van Skyforge Ascent zonder het te spelen, en de twee beoordelingsperspectieven kwamen tot verschillende conclusies.

De technische lens, die hetzelfde placefile las, gaf een score van 98/100. Deze lens constateerde een voorbeeldige opbouw met vijf secties en drie bewegende gevaren, die volledig voldeed aan de bedoeling van de maker door gebruik te maken van door de server bepaalde opeenvolgende checkpoints, val-reset-systemen en een gebruikersinterface gebouwd op het StyleSheet-framework. Alles wat in de specificatie was uiteengezet, werd geleverd. Het enige probleem waren twee ongebruikte exports van helperfuncties.

De ontwerper gaf het een score van 31/100. Alles werkte, maar het spel scoorde nul op voortgang, herspeelbaarheid, spelersinvloed en originele aantrekkingskracht. De kernloop was eenvoudig en lineair – elk controlepunt bereiken, de finish halen – met weinig variatie tussen de runs en geen reden om terug te komen voor een tweede poging. Het is een standaardelement binnen het obby-genre, geen spel met een eigen aantrekkingskracht.

Die kloof is de conclusie. Codekwaliteit en inhoudskwaliteit zijn fundamenteel verschillende dimensies, en een build kan op het ene vlak bijna perfect zijn terwijl hij op het andere faalt. Een enkele samengestelde kwaliteitsscore zou deze twee hebben gemiddeld tot iets zinloos.

Speltest

De playtest-agent speelde het run-spel met input die leek op die van een echte speler en slaagde voor alle negen punten op het testplan: een personage spawnen op het startplatform, door 3D-geometrie navigeren over kloven, klappen van gevaren incasseren, checkpoints en automatisch herstel na vallen activeren, de run voltooien en opnieuw starten, allemaal zonder runtime-fouten. In deze specifieke run scoorde Skyforge Ascent 100/100 op de playtest.

Een perfecte playtestscore bewijst alleen maar dat de spelmechanismen werken en dat het spel technisch gezien van begin tot eind speelbaar is. Het zegt niets over de vraag of het spel daadwerkelijk boeiend of leuk is om te spelen – dat onderscheid is precies de reden waarom de ontwerpperspectiefscore op 31 uitkwam.

Visuele kwaliteit

Ten slotte beoordeelde het evaluatiesysteem de opgenomen sessie op een weergavegebied ter grootte van een telefoon voor de visuele presentatie. Skyforge Ascent scoorde 86/100: strak, samenhangend en comfortabel in lijn met de beelden van een typische obstakelrace; duidelijk herkenbare platformgeometrie; goed zichtbare gevaren; en een moderne, onopdringerige HUD. Kleine visuele beperkingen houden het spel van perfectie af, maar er is niets kapot en ook niets dat een speler zou doen stoppen met scrollen.

Trace-statistieken

Tijdens dezelfde run werden ook processtatistieken geregistreerd. Het duurde ongeveer acht minuten om de game te bouwen, er waren geen toolfouten en de build maakte gebruik van de vaardigheden op het gebied van 3D, UI, scriptbewerking, het invoegen van assets en game-audio. Deze statistieken hebben geen directe invloed op de evaluatiescore, maar ze vertellen ons hoe de game is gemaakt en zouden een toekomstige build signaleren die langzamer of duurder zou worden zonder dat dit voordelen oplevert.

Over vijf fasen heen scoorde Skyforge Ascent verschillend op het gebied van gamespecificaties, codekwaliteit, inhoudskwaliteit, playtest en visuele kwaliteit. Vier van die dimensies geven aan dat Build in staat is om van één enkele prompt een complete, correcte, speelbare en presentabele Roblox-ervaring te maken. Eén dimensie geeft aan dat het geen spel is dat iemand zou kiezen om nog een keer te spelen. Het meten van die kloof, in plaats van deze weg te middelen, is juist het hele punt van de Build-evaluatie.

Hoe vroege evaluatie Build heeft verbeterd 

Evaluatieresultaten doen meer dan alleen scores genereren; ze bieden ook bruikbare aanwijzingen voor productverbeteringen. Door het opsporen van fouten in afzonderlijke componenten te combineren met holistische tests op systeemniveau, hebben offline batch-evaluaties van gestandaardiseerde reeksen prompts de ontwikkeling van Build direct vormgegeven. 

1. Snelle oplossing van pijnpunten voor alfa-makers: Bij onze alfa-lancering in Nieuw-Zeeland gaven gebruikers aan dat Build soms een 2D-spel creëerde terwijl ze een 3D-spel wilden. Het evaluatiekader hielp ons team om de 3D-mogelijkheden van Build snel te verbeteren. Binnen twee weken verbeterden we het vermogen van Build om de intentie van een gebruiker om een 3D-spel te maken te begrijpen – zelfs als ze dat niet expliciet aangaven. We hebben ook de speelbaarheid en afwerking van 3D-games verfijnd door veelvoorkomende problemen met objectpositionering, belichting enz. op te lossen. Sindsdien is het aandeel van klachten van het type ‘dit is niet wat ik wil’ gedaald van 18% naar 3% van alle klachten; de algehele ontevredenheid na playtests daalde met 10 procentpunten. We hebben ook kennis opgedaan tijdens het itereren op het framework zelf. 
2. Vergelijkende benchmarking tussen modellen en architecturen: we gebruiken ons evaluatieframework om configuraties van het Build-systeem grondig te benchmarken tegen gestandaardiseerde reeksen prompts. Voordat wijzigingen naar productie worden doorgevoerd, vergelijken offline A/B-evaluatierapporten kandidaat-releases met onze productiebaselines op alle vier de dimensies: 

Met deze offline diffs kunnen we bijvoorbeeld in kaart brengen hoe verschillende modelupgrades en routeringsbeslissingen van agents van invloed zijn op individuele kwaliteitssignalen:

• Prestaties van het basismodel: het upgraden van ons basismodel leverde consistente verbeteringen op voor elk signaal — wat resulteerde in minder mislukte builds bij de eerste poging, een superieure visuele afwerking en diepgaandere gameplay-inhoud.
• Agent-routeringsarchitectuur: Omgekeerd zorgde het delegeren van specifieke subtaken aan een lichtgewicht model in een opstelling met twee agents weliswaar voor behoud van de diepgang en diversiteit van de inhoud, maar leidde dit tot scherpe achteruitgang in de speelbaarheid en visuele afwerking.

1. Kwaliteitsreferenties bijhouden voor verschillende ontwikkelingsparadigma's: We gebruiken het raamwerk ook om inzicht te krijgen in de huidige kwaliteit van de build op verschillende momenten met de meest relevante evaluatieset. Deze sets bieden momentopnames van steeds bredere, complexere ontwikkelingstaken.
   De vroegste set bestaat volledig uit 2D-games met relatief eenvoudige mechanismen. De spellogica was eenvoudig te bouwen, waardoor de playtest-score doorgaans hoger uitviel; aan de andere kant bleef de inhoudsscore om precies dezelfde reden laag.
   Naarmate we de focus verleggen naar 3D-games, verschuift de scoreverdeling op natuurlijke wijze: bugvrij spelen wordt uitdagender, waardoor de playtestscores dalen. De visuele scores blijven stabiel vanwege een gebrek aan afwerking van de assets, waardoor de games een prototypisch gevoel geven. De inhoudsscores zijn hoger omdat 3D-games het potentieel hebben om diepgaander te zijn – maar de totale scores blijven doorgaans laag, aangezien prompts voor één beurt beperkte ruimte bieden voor uitbreiding van de inhoud.

1. Genrespecifieke knelpunten blootgelegd: Uit de evaluatiegegevens blijkt ook dat er aanzienlijke prestatieverschillen bestaan tussen de verschillende genres. Genres waarin de spelmechanismen een grote rol spelen (bijv. RPG's, shooters en racegames) kampen doorgaans vaker met problemen op het gebied van speelbaarheid. Genres met relatief eenvoudige logica (bijv. survival- en tycoon-games) presteren vaak beter in playtests, waardoor visuele afwerking en UI-ontwerp de volgende mijlpaal zijn die moet worden aangepakt. Het inzicht in het verschil tussen genres stimuleert ons om onze evaluatieset uit te breiden met een evenwichtiger steekproef uit de Build-games.
2. Lessen die zijn geleerd bij het ontwerpen van evaluatie-harnassen: Door het framework zelf te herzien, hebben we cruciale lessen geleerd over de betrouwbaarheid van harnassen:

• Systeemstatistieken versus componentstatistieken: een schone codestructuur of API-gebruik garandeert nog geen speelbare game. We houden correctheid, ontwerp en presentatie gescheiden om te voorkomen dat er actiegerichte bugs verborgen blijven.
• Zwakke punten van het evaluatieframework en menselijke kalibratie: Statische controles kunnen runtime-blokkers die de game laten crashen over het hoofd zien, terwijl geautomatiseerde playtests moeite hebben met complexe fysica. Virtuele beoordelaars worden voortdurend gekalibreerd aan de hand van professionele gameontwikkelaars en ervaren community-recensenten.
• Uitbreiding naar multiturn en real traffic: Omdat echte makers voortdurend itereren (systemen toevoegen, moeilijkheidsgraad aanpassen, bugs verhelpen), breiden we ons evaluatieharnas uit om multiturn-bewerkingen en real-world promptdistributies te evalueren.

Wat volgt

We richten ons momenteel op het uitbreiden van ons evaluatiesysteem voor Build-creaties in vijf richtingen:

1. Breder bereik over genres, 2D/2,5D/3D-ervaringen, multiplayer-scenario’s en complexiteitsniveaus
2. Betere ondersteuning voor bewerkingen met meerdere beurtcycli
3. Betrouwbaarder bewijsmateriaal uit playtests, screenshots, video's en audio
4. Afstemming op menselijke beoordelingen op grote schaal en door makers aangestuurde benchmarkgevallen
5. Betere integratie tussen offline evaluatie, online productsignalen en regressietesten

Ons langetermijndoel is een transparant, voortdurend verbeterend evaluatiesysteem dat Build meet op het niveau dat voor makers belangrijk is: de kwaliteit van de ervaringen die ze kunnen maken, testen, delen en verder ontwikkelen. Vandaag de dag worden deze signalen gebruikt om door Build gegenereerde games te evalueren. Naarmate we ze in de loop van de tijd verder verfijnen en afstemmen op menselijk oordeel, kunnen ze mogelijk worden toegepast op andere creatieworkflows en bijdragen aan een gemeenschappelijke taal voor het begrijpen van gamekwaliteit binnen het bredere Roblox-ecosysteem.

Voor een gerelateerd artikel over het evalueren van agentische systemen voor Roblox Assistant, zie ‘Using OpenGameEval to Benchmark Agentic AI Assistants for Roblox Studio’.