Wie Roblox die Erstellung von Build-Spielen bewertet

Build, unser neues „Mobile-First“-Entwicklungstool, ermöglicht es Roblox-Nutzern, mithilfe von Textanweisungen ein Spiel zu erstellen und es für Spieler auf der ganzen Welt zu veröffentlichen. Die Erstellung eines ganzheitlichen Spiels erfordert ein durchgängiges, agentenbasiertes System zur Spielgenerierung: eines, das Code, visuelle Elemente, Spielsysteme, Benutzeroberfläche und Steuerung zu einem einzigen, zusammenhängenden Artefakt koordiniert. Dieses System muss die verschiedenen Szenarien, die durch Spielereingaben und Multiplayer-Interaktionen entstehen, robust bewältigen. Seit dem Alpha-Start in Neuseeland haben über 100.000 Spieler Build genutzt, um sich im Erstellen eines Spiels zu versuchen, und es wurden etwa 9.000 Build-Spiele veröffentlicht.¹ Von den Tausenden, die Build zum Erstellen eines Spiels genutzt haben, hatten 71 % zuvor noch nie Roblox Studio verwendet,¹ was zeigt, dass sie mit Build etwas Neues ausprobieren.

Doch die Entwickler werden dieses neue Tool nur nutzen, wenn es einfach zu bedienen ist und die Qualität der damit erstellten Spiele hoch genug ist, um darauf aufzubauen. Um die Qualität der mit „Build“ erstellten Spiele zu verstehen, bewerten wir den gesamten Entstehungsprozess und nutzen diese Bewertungen sowie das Feedback der Entwickler, um das Produkt zu verbessern. Unser Bewertungsrahmen (Eval) hat uns dabei geholfen, das Verständnis der Absichten, die 3D-Spielbarkeit und die Ausarbeitung zu priorisieren und zu verbessern. Seit dem Alpha-Start von „Build“ in Neuseeland hat sich die Zufriedenheit der Entwickler um 10 % verbessert, ungewollte Ergebnisse sind von 18 % auf 3 % gesunken, und etwa 14 % der angestoßenen Sitzungen sowie 19 % der Spieltests werden veröffentlicht^.² Dies sind beschreibende Indikatoren für den Fortschritt, keine kausalen Schätzungen der Auswirkungen der Bewertung allein.

Warum die Bewertung der Spielentwicklung anders ist

Spiele weisen einige der gleichen Bewertungsherausforderungen auf wie andere Systeme, die komplexe Artefakte erzeugen, beispielsweise Apps, Videos und Weltmodelle. So hängt die Qualität beispielsweise davon ab, wie mehrere Komponenten zusammenwirken, und keine einzelne Komponentenbewertung beschreibt das Ergebnis vollständig. 

Was Spiele jedoch auszeichnet, ist, dass es sich bei dem Artefakt um ein ausführbares Echtzeitsystem handelt, das von den Spielern gesteuert wird. Eigenschaften wie Reaktionsfähigkeit, Handlungsspielraum, Spielfortschritt und Spielgefühl entstehen durch Interaktion und lassen sich nicht vollständig durch die alleinige Überprüfung von Code oder Assets beurteilen. Ein Spiel muss daher eine einzigartig hohe Messlatte sowohl hinsichtlich der Korrektheit auf niedriger Ebene (fehlerfrei und spielbar) als auch hinsichtlich des Spielerlebnisses auf hoher Ebene (ein Spiel, das sich wie ein fertiges Produkt anfühlt, nicht wie ein Prototyp) überwinden. 

Die Frage, die wir durch die Bewertung beantworten wollen, ist nicht, ob ein einzelnes Element korrekt ist, sondern ob das Artefakt als Ganzes der Absicht des Entwicklers entspricht und ob die Spieler das gesamte Spielerlebnis durchspielen können. Um diese Frage zu beantworten, bedarf es mehr als nur einer Metrik.

Vier Signale, ein Rahmenwerk

Unser Bewertungsrahmen für die Erstellung von Builds kombiniert vier Signale. Jedes beantwortet eine andere Frage, erfasst eine andere Art von Fehlern und liefert eine konkrete quantitative Bewertung:

1. Qualität der Spielspezifikation (0–100 Punkte): „Build“ ist der End-to-End-Erstellungsagent: Er übersetzt die Eingabe des Erstellers in eine Spezifikation und nutzt diese anschließend zur Generierung des Spiels. Der Bewerter beurteilt, ob die Spezifikation wichtige Entscheidungen explizit trifft, die Absicht des Erstellers beibehält, die Machbarkeit innerhalb der Roblox-Laufzeit berücksichtigt und vermeidet, Anforderungen zu erfinden, die nie geäußert wurden.

2. Statische Spielqualität (0–100 Punkte): Der statische Bewerter prüft das generierte Spiel im Bearbeitungsmodus von Roblox Studio. Dies umfasst die Spielstruktur, Skripte, Assets, Eigenschaften, Verbindungen sowie Client-/Server-Grenzen. In dieser Phase versuchen wir, zwei Fragen zu beantworten. Die erste lautet, ob das Spiel korrekt aufgebaut ist: Implementierung der erforderlichen Systeme, Auswahl der Engine-API und der Netzwerktechnologie, Vorhandensein der erwarteten Steuerelemente und UI-Komponenten sowie Robustheit und Kohärenz der Spielarchitektur. 

Die zweite Frage lautet, ob das Spiel so konzipiert ist, dass es Spaß macht: Tiefe des Kernspielablaufs, Vielfalt und Steigerung der Inhalte, Fortschritt, Wiederspielbarkeit und Innovation, die über die Standardmerkmale eines Genres hinausgeht. Ein Spiel kann architektonisch sauber sein, aber keine inhaltliche Tiefe aufweisen, oder voller Ideen sein, aber schlecht umgesetzt. 

Die Trennung dieser beiden Betrachtungsweisen und der Abgleich mit Best Practices geben uns ein detaillierteres Bild davon, wo das Spiel Schwächen aufweist.

3. Spieltest (0–100 % Bestehensquote): Der Spieltest-Prüfer führt das Spiel aus und setzt einen Testplan mit realistischen, spielerähnlichen Eingaben um, darunter Tippen, Klicken, Tastenanschläge und Navigation, anstatt Ereignisse per Code auszulösen. Ein fallbezogener Testplan überprüft, ob das Spiel startet, reagiert, voranschreitet, sich von Fehlern erholt und frei von Laufzeitfehlern bleibt. Jeder Punkt wird binär mit „bestanden“ oder „nicht bestanden“ bewertet und als stufenweise gewichtete Bestehensquote sowie als einfaches Urteil „spielbar“ oder „nicht spielbar“ ausgewiesen. Wir wiederholen die Durchläufe, um die Konsistenz zu messen.

4. Visuelle und erlebnisbezogene Qualität (Bewertung von 0 bis 100): Einige der wichtigsten Aspekte für das Erscheinungsbild und das Spielgefühl eines Spiels lassen sich nicht aus dem Code ablesen. Daher bewertet der visuelle Prüfer die Präsentation eigenständig anhand von aufgezeichnetem Gameplay auf Viewports, die verschiedene Geräte darstellen. Diese Bewertungsrubrik berücksichtigt ausschließlich, wie ein Spiel aufgrund der Gestaltung der Assets, der UI-Ausführung, der Bewegungen, der Beleuchtung und des Audios aussieht und klingt. Die Kernfrage lautet: Wirkt das Spiel wie ein marktreifes Produkt oder wie ein Prototyp? Die Trennung der visuellen Aspekte von der Spielmechanik stellt sicher, dass „der Code funktioniert“ und „das Spiel fertig aussieht“ nicht zu einer einzigen irreführenden Gesamtbewertung gemittelt werden.

Neben den bewerteten Signalen erfasst jeder Durchlauf rein informative Metriken wie Token-Verbrauch, Tool-Aufrufe, ausgelöste Fähigkeiten und Latenz. Diese Metriken beeinflussen die Bewertungsnote nicht, können jedoch erklären, wie ein Ergebnis zustande kam, und Regressionen aufdecken, die den Bewertungsrubriken entgehen – beispielsweise einen Build, dessen Ausführung für dasselbe Spiel doppelt so viel Ressourcen verbraucht.

Die Signale lassen sich den von ihnen erfassten Fehlern zuordnen:

Durchlaufen eines vorgegebenen 3D-Obby-Parcours

Die Hinweise lassen sich am besten anhand einer echten Vorgabe erkennen. Zum Beispiel: „Ein echtes 3D-Obby-Spiel mit Startplattform, sich bewegenden Hindernissen, Checkpoints und Ziellinie.“ Obbys sind ein beliebter Plattformspiel-Typ auf Roblox. Die Absicht des Erstellers ist klar, auch wenn nicht jedes Implementierungsdetail vorgeschrieben ist. Der Entwickler muss die Details mit vernünftigen Annahmen ausfüllen.

Plan und Spezifikation

Das Entwicklungsteam erstellte ein Spezifikationsdokument für ein neues Spiel namens „Skyforge Ascent“, in dem ein aus fünf Abschnitten bestehender Parcours mit Checkpoints und drei Gefahrenarten detailliert beschrieben wurde. Darin wurden der Kernablauf, die Schwierigkeitskurve, die künstlerische Ausrichtung, Bildschirme, Overlays und die Steuerung definiert. Bei der Bewertung der Spezifikation erhielt das Dokument 91 von 100 Punkten und erzielte die volle Punktzahl in den Bereichen Vollständigkeit, Einhaltung der Vorgaben, Machbarkeit und interne Konsistenz. Der Punktabzug ergab sich aus zwei spezifischen Aspekten: Implementierungsdetails und Abdeckung der Akzeptanzkriterien. 

In der Spezifikation wurden numerische Konstanten wie Drehgeschwindigkeiten, Gleitwege, Kachel-Timings, Plattformabmessungen oder die Höhe der Reset-Ebene nie festgelegt, sodass ein Entwickler diese noch festlegen muss. Zudem sind einige Akzeptanzkriterien (wie „etwa 24 Plattformen“ oder „Celestial-Forge-Farbpalette“) nicht streng falsifizierbar. Eine hohe Spezifikationsbewertung beweist lediglich, dass das Dokument bereit für die Umsetzung ist. Ob diese Vorgaben den Kontakt mit der tatsächlichen Spieleentwicklung überstehen, wird in den nächsten drei Phasen gemessen.

Statische Prüfungen: Codequalität und Inhaltsqualität

Der virtuelle Prüfer untersuchte die Placefile von „Skyforge Ascent“, ohne das Spiel zu spielen, und die beiden Bewertungsansätze kamen zu unterschiedlichen Ergebnissen.

Die technische Perspektive bewertete dieselbe „Placefile“-Datei mit 98 von 100 Punkten. Sie stellte einen vorbildlichen Aufbau mit fünf Abschnitten und drei sich bewegenden Gefahren fest, der die Absicht des Entwicklers durch serverseitig festgelegte sequenzielle Checkpoints, Fall-Reset-Systeme und eine auf dem StyleSheet-Framework basierende Benutzeroberfläche vollständig erfüllte. Alle in der Spezifikation festgelegten Punkte wurden umgesetzt. Das einzige Problem waren zwei ungenutzte Exporte von Hilfsfunktionen.

Die Design-Perspektive bewertete es mit 31/100. Alles funktionierte, aber das Spiel erhielt null Punkte in den Bereichen Spielfortschritt, Wiederspielbarkeit, Handlungsfreiheit des Spielers und origineller Aufhänger. Der Kernablauf war einfach und linear – jeden Checkpoint erreichen, die Ziellinie überqueren –, mit wenig Abwechslung zwischen den Durchläufen und keinem Grund, für einen zweiten Durchgang zurückzukehren. Es handelt sich um ein Standardelement des Obby-Genres, nicht um ein Spiel mit einem eigenen Aufhänger.

Genau diese Diskrepanz ist das Ergebnis. Codequalität und Inhaltsqualität sind grundlegend unterschiedliche Dimensionen, und eine Version kann in der einen nahezu perfekt sein, während sie in der anderen versagt. Eine einzige, zusammengefasste Qualitätsbewertung hätte diese beiden Aspekte zu einem bedeutungslosen Durchschnittswert gemischt.

Spieltest

Der Spieltest-Agent spielte das Laufspiel mit realistischen, spielerähnlichen Eingaben und bestand alle neun Punkte des Testplans: Erzeugen eines Charakters auf der Startplattform, Navigieren durch 3D-Geometrie über Abgründe hinweg, Einstecken von Treffern durch Gefahren, Auslösen von Checkpoints und automatischer Sturzrettung, Absolvieren des Laufs sowie Neustarten – alles ohne Laufzeitfehler. In diesem konkreten Durchlauf erzielte „Skyforge Ascent“ beim Spieltest 100 von 100 Punkten.

Ein perfektes Spieltest-Ergebnis beweist lediglich, dass die Spielmechaniken funktionieren und das Spiel von Anfang bis Ende technisch spielbar ist. Es sagt nichts darüber aus, ob das Spiel tatsächlich fesselnd ist oder Spaß macht – genau dieser Unterschied ist der Grund, warum es aus gestalterischer Sicht nur 31 Punkte erhielt.

Visuelle Qualität

Schließlich bewertete das Bewertungssystem die aufgezeichnete Sitzung hinsichtlich der visuellen Darstellung auf einem Bildschirm im Smartphone-Format. „Skyforge Ascent“ erzielte 86 von 100 Punkten: klar, stimmig und angenehm im Einklang mit der Optik eines typischen Obstacle-Course-Spiels; gut erkennbare Plattformgeometrie; deutlich erkennbare Gefahren; sowie ein modernes, unaufdringliches HUD. Geringfügige visuelle Einschränkungen verhindern zwar die Perfektion, aber es gibt keine Fehler und auch nichts, was einen Spieler dazu bringen würde, das Scrollen zu unterbrechen.

Prozessmetriken

Im selben Durchlauf wurden auch Prozesskennzahlen erfasst. Der Build des Spiels dauerte etwa acht Minuten, es gab keine Tool-Fehler, und der Build nutzte die Fähigkeiten in den Bereichen 3D, Benutzeroberfläche, Skriptbearbeitung, Einbindung von Assets und Spiel-Audio. Diese Kennzahlen wirken sich nicht direkt auf die Bewertungsnote aus, geben jedoch Aufschluss darüber, wie das Spiel erstellt wurde, und würden einen zukünftigen Build kennzeichnen, der langsamer oder ressourcenintensiver wird, ohne dass dadurch ein Gewinn erzielt wird.

Über fünf Stufen hinweg erzielte „Skyforge Ascent“ unterschiedliche Bewertungen in den Bereichen Spielspezifikationen, Codequalität, Inhaltsqualität, Spieltest und visuelle Qualität. Vier dieser Dimensionen zeigen, dass „Build“ aus einer einzigen Eingabeaufforderung ein vollständiges, korrektes, spielbares und präsentables Roblox-Erlebnis machen kann. Eine Dimension besagt, dass es kein Spiel ist, das jemand freiwillig ein zweites Mal spielen würde. Diese Lücke zu messen, anstatt sie durch Mittelwertbildung zu verwischen, ist der eigentliche Sinn der „Build“-Bewertung.

Wie die frühzeitige Bewertung „Build“ verbessert hat 

Bewertungsergebnisse liefern nicht nur Punktzahlen, sondern bieten auch umsetzbare Anhaltspunkte für Produktverbesserungen. Durch die Kombination von Debugging einzelner Komponenten mit ganzheitlichen Tests auf Systemebene haben Offline-Batch-Bewertungen anhand standardisierter Prompt-Suites die Entwicklung von „Build“ direkt geprägt. 

1. Schnelle Behebung von Problemen bei Alpha-Entwicklern: Bei unserem Alpha-Start in Neuseeland gaben uns Nutzer das Feedback, dass „Build“ manchmal ein 2D-Spiel erstellte, obwohl sie ein 3D-Spiel wollten. Das Evaluierungs-Framework half unserem Team, die 3D-Fähigkeiten von „Build“ schnell zu verbessern. Innerhalb von zwei Wochen verbesserten wir die Fähigkeit von „Build“, die Absicht eines Nutzers zu erkennen, ein 3D-Spiel zu erstellen – auch wenn dieser dies nicht ausdrücklich angab. Außerdem haben wir die Spielbarkeit und die optische Qualität der 3D-Spiele verfeinert, indem wir häufige Probleme bei der Objektpositionierung, der Beleuchtung usw. behoben haben. Seitdem sind die Beschwerden mit dem Inhalt „Nicht das, was ich will“ unter allen Beschwerden von 18 % auf 3 % gesunken; die allgemeine Unzufriedenheit nach dem Spieltest ging um 10 Prozentpunkte zurück. Auch bei der Weiterentwicklung des Frameworks selbst haben wir wertvolle Erkenntnisse gewonnen. 
2. Vergleichende Benchmark-Analysen verschiedener Modelle und Architekturen: Wir nutzen unser Evaluierungs-Framework, um Konfigurationen des Build-Systems anhand standardisierter Prompt-Sammlungen rigoros zu benchmarken. Bevor Änderungen in die Produktion übernommen werden, vergleichen Offline-A/B-Evaluierungsberichte potenzielle Releases mit unseren Produktions-Baselines in allen vier Dimensionen: 

Anhand dieser Offline-Diffs können wir beispielsweise isoliert untersuchen, wie sich verschiedene Modell-Upgrades und Entscheidungen zum Agenten-Routing auf einzelne Qualitätssignale auswirken:

• Leistung des Basismodells: Die Verbesserung unseres Basismodells führte zu konsistenten Verbesserungen bei allen Signalen – was zu weniger fehlerhaften Builds beim ersten Versuch, einer überragenden visuellen Qualität und tiefergehenden Spielinhalten führte.
• Agenten-Routing-Architektur: Umgekehrt bewahrte die Delegierung spezifischer Teilaufgaben an ein leichtgewichtiges Modell in einer Dual-Agenten-Konfiguration zwar die Tiefe und Vielfalt der Inhalte, führte jedoch zu starken Einbußen bei der Spielbarkeit und der visuellen Qualität.

1. Verfolgung von Qualitäts-Baselines über verschiedene Entwicklungsparadigmen hinweg: Wir nutzen das Framework auch, um die aktuelle Qualität der Builds zu unterschiedlichen Zeitpunkten anhand des relevantesten Bewertungssatzes zu verstehen. Diese Sätze liefern Momentaufnahmen von zunehmend umfangreichen und komplexen Entwicklungsaufgaben.
   Der früheste Satz besteht ausschließlich aus 2D-Spielen mit relativ einfachen Mechaniken. Die Spielelogik war einfach zu implementieren, weshalb die Spieltest-Bewertung tendenziell höher ausfiel; andererseits blieb die Inhaltsbewertung aus genau demselben Grund niedrig.
   Wenn wir den Fokus auf 3D-Spiele verlagern, verschiebt sich die Punktverteilung auf natürliche Weise: Ein fehlerfreies Spielerlebnis wird anspruchsvoller, was die Spieltest-Werte senkt. Die visuellen Werte bleiben aufgrund mangelnder Ausarbeitung der Assets unverändert, was den Spielen einen Prototyp-Charakter verleiht. Die Inhaltswerte sind höher, da 3D-Spiele das Potenzial für mehr Tiefe haben – doch die Gesamtwerte bleiben tendenziell niedrig, da Einzelturn-Aufforderungen nur begrenzten Spielraum für die Erweiterung der Inhalte bieten.

1. Aufdeckung genrespezifischer Engpässe: Die Auswertungsdaten zeigen zudem erhebliche Leistungsunterschiede zwischen den verschiedenen Genres auf. Genres mit komplexen Spielmechaniken (z. B. RPGs, Shooter, Rennspiele) weisen tendenziell mehr Probleme hinsichtlich der Spielbarkeit auf. Genres mit relativ einfacher Logik (z. B. Survival- und Tycoon-Spiele) schneiden in Spieltests oft besser ab, sodass die visuelle Ausarbeitung und das UI-Design die nächsten Meilensteine sind, die es zu lösen gilt. Das Wissen um die Unterschiede zwischen den Genres motiviert uns, unseren Evaluierungssatz durch eine ausgewogenere Stichprobe aus allen Build-Spielen zu erweitern.
2. Erkenntnisse aus der Entwicklung des Evaluierungs-Harness: Die iterative Weiterentwicklung des Frameworks selbst hat uns wichtige Erkenntnisse über die Zuverlässigkeit des Harness geliefert:

• Systemmetriken vs. Komponentenmetriken: Eine saubere Codestruktur oder die Nutzung von APIs garantieren noch kein spielbares Spiel. Wir unterscheiden klar zwischen Korrektheit, Design und Präsentation, um zu vermeiden, dass behebbare Fehler übersehen werden.
• Schwächen des Test-Frameworks und manuelle Kalibrierung: Statische Prüfungen können Laufzeitfehler übersehen, die zum Absturz des Spiels führen, während automatisierte Spieltests mit komplexer Physik zu kämpfen haben. Virtuelle Bewerter werden kontinuierlich anhand professioneller Spieleentwickler und erfahrener Community-Rezensenten kalibriert.
• Ausweitung auf Mehrrunden- und Echtverkehr: Da echte Entwickler kontinuierlich iterieren (Systeme hinzufügen, den Schwierigkeitsgrad anpassen, Fehler beheben), erweitern wir unseren Bewertungs-Harness, um Mehrrunden-Bearbeitungen und reale Prompt-Verteilungen zu bewerten.

Was als Nächstes kommt

Derzeit konzentrieren wir uns darauf, unser „Build“-Bewertungssystem in fünf Richtungen zu erweitern:

1. Breitere Abdeckung verschiedener Genres, 2D-/2,5D-/3D-Erlebnisse, Multiplayer-Szenarien und Komplexitätsstufen
2. Stärkere Unterstützung für Bearbeitungen über mehrere Runden
3. Zuverlässigere Spieltest-, Screenshot-, Video- und Audio-Nachweise
4. Kalibrierung anhand menschlicher Bewertungen in großem Maßstab und von Entwicklern vorangetriebener Benchmark-Fälle
5. Bessere Integration zwischen Offline-Bewertung, Online-Produktsignalen und Regressionstests

Unser langfristiges Ziel ist ein transparentes, sich kontinuierlich verbesserndes Bewertungssystem, das „Build“ auf der Ebene misst, die den Entwicklern wichtig ist: die Qualität der Erlebnisse, die sie erstellen, testen, teilen und weiterentwickeln können. Derzeit werden diese Signale zur Bewertung von mit „Build“ erstellten Spielen verwendet. Im Laufe der Zeit, wenn wir sie weiter verfeinern und anhand menschlicher Urteile kalibrieren, lassen sie sich möglicherweise auf andere Erstellungsworkflows übertragen und dazu beitragen, eine gemeinsame Sprache für das Verständnis von Spielqualität im gesamten Roblox-Ökosystem zu schaffen.

Einen verwandten Beitrag zur Bewertung agentischer Systeme für den Roblox Assistant finden Sie unter „Using OpenGameEval to Benchmark Agentic AI Assistants for Roblox Studio“.