Jak Roblox ocenia tworzenie gier typu „Build Game”

Build, nasze nowe narzędzie do tworzenia gier zorientowane na urządzenia mobilne, pozwala użytkownikom Roblox tworzyć gry za pomocą podpowiedzi tekstowych i publikować je dla graczy na całym świecie. Stworzenie kompleksowej gry wymaga kompleksowego systemu generowania gier: takiego, który koordynuje kod, zasoby wizualne, systemy rozgrywki, interfejs użytkownika i sterowanie w jeden złożony artefakt. System ten musi niezawodnie radzić sobie z różnymi scenariuszami wynikającymi z działań graczy i interakcji w trybie wieloosobowym. Od momentu premiery wersji alfa w Nowej Zelandii ponad 100 000 graczy skorzystało z Build, aby spróbować stworzyć grę, a opublikowano około 9 000 gier stworzonych za pomocą Build.¹ Spośród tysięcy osób, które użyły Build do stworzenia gry, 71% nigdy wcześniej nie korzystało z Roblox Studio,¹ co pokazuje, że dzięki Build próbują czegoś nowego.

Twórcy będą jednak korzystać z tego nowego narzędzia tylko wtedy, gdy będzie ono łatwe w obsłudze, a jakość generowanych przez nie gier będzie wystarczająco wysoka, by można było na nich dalej budować. Aby zrozumieć jakość gier tworzonych za pomocą Build, oceniamy cały proces tworzenia od początku do końca i wykorzystujemy te oceny, a także opinie twórców, do ulepszania produktu. Nasze ramy oceny (eval) pomogły nam ustalić priorytety i poprawić rozumienie intencji, grywalność w 3D oraz dopracowanie. Od czasu premiery wersji alfa Build w Nowej Zelandii zadowolenie twórców wzrosło o 10%, liczba niezamierzonych wyników spadła z 18% do 3%, a około 14% sesji z podpowiedziami i 19% testów rozgrywki zostało opublikowanych.² Są to opisowe wskaźniki postępu, a nie wyłącznie szacunki przyczynowo-skutkowe wpływu oceny.

Dlaczego ocena tworzenia gier jest inna

Gry borykają się z podobnymi wyzwaniami ewaluacyjnymi, jakie występują w innych systemach generujących złożone artefakty, takich jak aplikacje, filmy i modele świata. Na przykład jakość zależy od tego, jak wiele elementów współdziała ze sobą, a wynik nie da się w pełni opisać na podstawie oceny pojedynczego elementu. 

To, co wyróżnia gry, to fakt, że artefakt jest uruchamialnym systemem działającym w czasie rzeczywistym, sterowanym przez graczy. Właściwości takie jak responsywność, poczucie sprawczości, postęp w grze i wrażenia z rozgrywki wyłaniają się w trakcie interakcji i nie można ich w pełni ocenić wyłącznie poprzez analizę kodu lub zasobów. Gra musi zatem spełnić wyjątkowo wysokie wymagania zarówno w zakresie poprawności na niskim poziomie (brak błędów i możliwość rozgrywki), jak i wrażeń gracza na wysokim poziomie (gra, która sprawia wrażenie ukończonej, a nie prototypu). 

Pytanie, na które staramy się odpowiedzieć poprzez ocenę, nie dotyczy tego, czy którykolwiek element jest poprawny, ale czy całościowy produkt odpowiada zamierzeniom twórcy oraz czy gracze mogą przejść całą rozgrywkę. Odpowiedź na to pytanie wymaga więcej niż jednego wskaźnika.

Cztery sygnały, jedna struktura

Nasze ramy oceny tworzenia w Build łączą cztery sygnały. Każdy z nich odpowiada na inne pytanie, wykrywa inną kategorię błędów i daje konkretny wynik ilościowy:

1. Jakość specyfikacji gry (wynik w skali 0–100): Build jest narzędziem do kompleksowego tworzenia gier: przekształca polecenie twórcy w specyfikację, a następnie wykorzystuje ją do wygenerowania gry. Oceniający sprawdza, czy specyfikacja w sposób wyraźny określa istotne decyzje, zachowuje intencje twórcy, uwzględnia wykonalność w środowisku uruchomieniowym Roblox oraz unika wymyślania wymagań, które nigdy nie zostały wyrażone.

2. Jakość statyczna gry (wynik 0–100): Oceniający w trybie statycznym sprawdza wygenerowaną grę w trybie edycji Roblox Studio. Obejmuje to strukturę gry, skrypty, zasoby, właściwości, połączenia oraz granice między klientem a serwerem. Na tym etapie staramy się odpowiedzieć na dwa pytania. Pierwsze dotyczy tego, czy gra została zbudowana poprawnie: implementacja wymaganych systemów, wybór API silnika i rozwiązań sieciowych, obecność oczekiwanych elementów sterujących i komponentów interfejsu użytkownika, solidność i spójność architektury gry. 

Drugi dotyczy tego, czy gra została zaprojektowana tak, by zapewniać rozrywkę: głębia pętli głównej, różnorodność i eskalacja treści, postęp w grze, możliwość ponownego grania oraz innowacyjność wykraczająca poza standardy danego gatunku. Gra może mieć przejrzystą architekturę, ale nie mieć głębi treści, lub być pełna pomysłów, ale źle skonstruowana. 

Rozdzielenie tych dwóch perspektyw i porównanie z najlepszymi praktykami daje nam bardziej szczegółowy obraz tego, w jakich obszarach gra zawodzi.

3. Test gry (wskaźnik zdawalności 0–100%): Osoba oceniająca test gry uruchamia grę i realizuje plan testowy przy użyciu rzeczywistych interakcji gracza, w tym dotknięć, kliknięć, naciśnięć klawiszy i nawigacji, zamiast wyzwalania zdarzeń z poziomu kodu. Plan testowy oparty na poszczególnych przypadkach sprawdza, czy gra się uruchamia, reaguje, postępuje, odzyskuje działanie po awarii oraz czy nie występują w niej błędy wykonania. Każdy element jest oceniany binarnie jako zaliczony/niezaliczony, co jest przedstawiane jako wskaźnik zdawalności ważony według poziomów wraz z prostym werdyktem: gra się da grać/nie da się grać. Powtarzamy przebiegi, aby zmierzyć spójność.

4. Jakość wizualna i wrażenia z gry (ocena w skali 0–100): Niektórych z najważniejszych aspektów wyglądu i wrażeń z gry nie da się odczytać z kodu, dlatego oceniający wizualizację samodzielnie ocenia prezentację na podstawie zarejestrowanego przebiegu rozgrywki w okienkach reprezentujących różne urządzenia. Ta rubryka skupia się wyłącznie na tym, jak gra wygląda i brzmi, biorąc pod uwagę jakość zasobów graficznych, dopracowanie interfejsu użytkownika, ruch, oświetlenie i dźwięk. Najważniejsze pytanie brzmi: czy gra sprawia wrażenie produktu gotowego do wydania, czy raczej prototypu? Oddzielenie aspektów wizualnych od mechaniki oznacza, że stwierdzenia „kod działa” i „gra wygląda na ukończoną” nie są uśredniane w jedną mylącą ocenę.

Oprócz sygnałów podlegających ocenie, każde uruchomienie rejestruje wskaźniki o charakterze wyłącznie informacyjnym, takie jak wykorzystanie tokenów, wywołania narzędzi, uruchomione umiejętności i opóźnienia. Wskaźniki te nie mają wpływu na wynik oceny, ale mogą wyjaśnić, w jaki sposób uzyskano dany wynik, oraz wykryć regresje, które umykają uwadze rubryk, na przykład kompilację, która stała się dwukrotnie bardziej kosztowna dla tej samej gry.

Sygnały odnoszą się do wykrytych błędów:

Przechodzenie przez wygenerowany losowo tor przeszkód 3D typu „obby”

Sygnały najłatwiej dostrzec na prawdziwym opisie zadania. Na przykład: „Prawdziwa gra typu 3D obby z platformą startową, ruchomymi przeszkodami, punktami kontrolnymi i linią mety”. Gry typu obby to popularny rodzaj gier platformowych na Robloxie. Intencja twórcy jest jasna, nawet jeśli nie określa ona wszystkich szczegółów implementacji. Twórca musi uzupełnić szczegóły, opierając się na rozsądnych założeniach.

Plan i specyfikacja

Zespół Build opracował dokument specyfikacji dla nowej gry o nazwie Skyforge Ascent, szczegółowo opisujący pięcioczęściowy tor z punktami kontrolnymi i trzema rodzajami zagrożeń. Określono w nim podstawową pętlę rozgrywki, krzywą trudności, kierunek artystyczny, ekrany, nakładki oraz sterowanie. Ocena specyfikacji wyniosła 91/100, uzyskując maksymalną liczbę punktów za kompletność, terminowość, wykonalność i spójność wewnętrzną. Punkty zostały odjęte w dwóch konkretnych obszarach: szczegółów implementacji oraz zakresu kryteriów akceptacji. 

W specyfikacji nie określono stałych liczbowych, takich jak prędkości obrotowe, odległości poślizgu, czasy wyświetlania kafelków, wymiary platform czy wysokość płaszczyzny resetowania, więc inżynier nadal musi je ustalić samodzielnie. Ponadto niektóre kryteria akceptacji (takie jak „około 24 platform” lub „paleta barw Celestial Forge”) nie są ściśle falsyfikowalne. Wysoki wynik specyfikacji dowodzi jedynie, że dokument jest gotowy do wdrożenia. To, czy te założenia przetrwają kontakt z rzeczywistym procesem tworzenia gry, jest przedmiotem oceny w kolejnych trzech etapach.

Sprawdzenia statyczne: jakość kodu i jakość treści

Wirtualny sędzia sprawdził plik „placefile” gry Skyforge Ascent bez uruchamiania jej, a dwa kryteria oceny doprowadziły do różnych wniosków.

Perspektywa inżynieryjna, analizując ten sam plik lokacji, przyznała mu 98/100 punktów. Stwierdziła, że jest to wzorcowa konstrukcja składająca się z pięciu sekcji i trzech ruchomych przeszkód, w pełni spełniająca zamierzenia twórcy dzięki wykorzystaniu sekwencyjnych punktów kontrolnych nadzorowanych przez serwer, systemów resetowania po upadku oraz interfejsu użytkownika opartego na frameworku StyleSheet. Zrealizowano wszystko, co zostało określone w specyfikacji. Jedynym problemem były dwie nieużywane eksportowane funkcje pomocnicze.

Perspektywa projektowa przyznała mu 31/100 punktów. Wszystko działało, ale gra uzyskała zero punktów w kategoriach postępów, powtarzalności rozgrywki, swobody działania gracza oraz oryginalnego pomysłu. Podstawowa pętla rozgrywki była prosta i liniowa – dotrzeć do każdego punktu kontrolnego, przekroczyć linię mety – z niewielką różnorodnością w poszczególnych przejściach i brakiem powodu, by wrócić do gry po raz drugi. Jest to standardowy element gatunku gier typu „obby”, a nie gra z własnym, charakterystycznym pomysłem.

Ta rozbieżność stanowi sedno wniosku. Jakość kodu i jakość treści to zasadniczo różne wymiary, a wersja gry może być niemal idealna pod jednym względem, a jednocześnie zawodzić pod innym. Pojedyncza, łączna ocena jakości uśredniłaby te wyniki, tworząc wynik pozbawiony znaczenia.

Test gry

Agent testujący rozegrał rozgrywkę, używając prawdziwych, podobnych do gracza poleceń i zaliczył wszystkie dziewięć punktów z planu testowego: pojawienie się postaci na platformie startowej, poruszanie się po trójwymiarowej geometrii przez szczeliny, otrzymywanie obrażeń od zagrożeń, uruchamianie punktów kontrolnych i automatycznego odzyskiwania po upadku, ukończenie biegu oraz ponowne rozpoczęcie – wszystko to bez żadnych błędów wykonania. W tej konkretnej rozgrywce Skyforge Ascent uzyskało wynik 100/100 w teście gry.

Idealny wynik testu gry dowodzi jedynie, że mechanika działa, a gra jest technicznie grywalna od początku do końca. Nie mówi to jednak nic o tym, czy gra jest rzeczywiście wciągająca lub przyjemna w graniu – właśnie to rozróżnienie sprawiło, że w kategorii projektowej otrzymała ocenę 31.

Jakość wizualna

Na koniec system oceny przyznał nagranej sesji punkty za prezentację wizualną na ekranie wielkości telefonu. Gra „Skyforge Ascent” uzyskała wynik 86/100: czysta, spójna grafika, dobrze wpisująca się w styl typowej gry typu „obby”; czytelna geometria platform; wyraźnie widoczne zagrożenia; oraz nowoczesny, dyskretny interfejs użytkownika (HUD). Drobne ograniczenia wizualne uniemożliwiają osiągnięcie perfekcji, ale nie ma żadnych błędów ani elementów, które mogłyby skłonić gracza do zaprzestania przewijania ekranu.

Wskaźniki śledzenia

W tym samym przebiegu zarejestrowano również wskaźniki procesu. Kompilacja gry zajęła około ośmiu minut, nie wystąpiły żadne błędy narzędzi, a proces kompilacji wykorzystał umiejętności w zakresie grafiki 3D, interfejsu użytkownika, edycji skryptów, wstawiania zasobów oraz dźwięku w grze. Wskaźniki te nie wpływają bezpośrednio na wynik oceny, ale informują nas o tym, jak gra została stworzona, i pozwoliłyby zidentyfikować przyszłą kompilację, która byłaby wolniejsza lub bardziej kosztowna bez żadnych korzyści.

W pięciu etapach „Skyforge Ascent” uzyskało różne wyniki w kategoriach specyfikacji gry, jakości kodu, jakości treści, testów rozgrywki oraz jakości graficznej. Cztery z tych wymiarów wskazują, że Build potrafi przekształcić pojedyncze polecenie w kompletne, poprawne, grywalne i reprezentacyjne doświadczenie na platformie Roblox. Jeden wymiar wskazuje jednak, że nie jest to gra, w którą ktokolwiek zdecydowałby się zagrać po raz drugi. Pomiar tej luki, zamiast jej uśredniania, stanowi sedno oceny Build.

Jak wczesna ocena poprawiła Build 

Wyniki oceny to coś więcej niż tylko generowanie wyników – dostarczają one również praktycznych wskazówek dotyczących ulepszeń produktu. Dzięki połączeniu debugowania poszczególnych komponentów z całościowymi testami na poziomie systemu, offline’owe oceny partii oparte na standardowych zestawach poleceń bezpośrednio wpłynęły na rozwój Build. 

1. Szybkie rozwiązywanie problemów twórców w fazie alfa: Podczas naszej premiery wersji alfa w Nowej Zelandii użytkownicy przekazali nam informacje zwrotne, że Build czasami tworzył grę 2D, podczas gdy oni chcieli gry 3D. Struktura ewaluacyjna pomogła naszemu zespołowi szybko ulepszyć możliwości 3D Build. W ciągu dwóch tygodni poprawiliśmy zdolność Build do rozumienia intencji użytkownika dotyczących tworzenia gry 3D – nawet jeśli nie wyraził tego wprost. Udoskonaliliśmy również grywalność i dopracowanie grafiki 3D, naprawiając typowe problemy z pozycjonowaniem obiektów, oświetleniem itp. Od tego czasu odsetek skarg typu „nie tego chciałem” spadł z 18% do 3% wśród wszystkich zgłoszeń; ogólny poziom niezadowolenia po testach spadł o 10 punktów procentowych. Zgromadziliśmy również wiedzę podczas iteracji nad samym frameworkiem. 
2. Porównawcze testy porównawcze między modelami i architekturami: Wykorzystujemy nasz framework ewaluacyjny do rygorystycznego testowania porównawczego konfiguracji systemu Build w oparciu o standardowe zestawy poleceń. Przed wprowadzeniem zmian do środowiska produkcyjnego raporty z offline’owych testów A/B porównują potencjalne wersje z naszymi punktami odniesienia produkcyjnymi we wszystkich czterech wymiarach: 

Na przykład te porównania offline pozwalają nam wyodrębnić, w jaki sposób różne aktualizacje modelu i decyzje dotyczące routingu agentów wpływają na poszczególne sygnały jakości:

• Wydajność modelu bazowego: Ulepszenie naszego modelu bazowego przyniosło spójny wzrost we wszystkich wskaźnikach — co zaowocowało mniejszą liczbą nieudanych kompilacji przy pierwszej próbie, lepszym dopracowaniem wizualnym oraz bogatszą treścią rozgrywki.
• Architektura routingu agentów: Z drugiej strony, delegowanie konkretnych podzadań do lekkiego modelu w konfiguracji z dwoma agentami pozwoliło zachować głębię i różnorodność treści, ale spowodowało gwałtowne pogorszenie grywalności i jakości wizualnej.

1. Śledzenie poziomów odniesienia jakości w różnych paradygmatach tworzenia: Wykorzystujemy ten framework również do analizy aktualnej jakości kompilacji w różnych momentach przy użyciu najbardziej odpowiedniego zestawu ewaluacyjnego. Zestawy te dostarczają migawek coraz szerszych i bardziej złożonych zadań twórczych.
   Najwcześniejszy zestaw składa się wyłącznie z gier 2D o stosunkowo prostych mechanizmach. Logika gry była łatwa do zbudowania, dlatego wyniki testów rozgrywki były zazwyczaj wyższe; z drugiej strony, ocena treści pozostawała niska z dokładnie tego samego powodu.
   Gdy skupiamy się na grach 3D, rozkład wyników naturalnie się zmienia: gra bez błędów staje się trudniejsza, co obniża wyniki testów rozgrywki. Wyniki wizualne pozostają na stałym poziomie z powodu braku dopracowania zasobów, co nadaje grom charakter prototypu. Wyniki dotyczące treści są wyższe, ponieważ gry 3D mają potencjał, by być bardziej rozbudowane — jednak wyniki ogólne zazwyczaj pozostają niskie, ponieważ podpowiedzi w trybie pojedynczej tury oferują ograniczoną przestrzeń na rozszerzenie treści.

1. Odkrywanie specyficznych dla gatunków wąskich gardeł: Dane z oceny podkreślają również znaczne różnice w wydajności między poszczególnymi gatunkami. Gatunki, w których duży nacisk kładzie się na mechanikę rozgrywki (np. gry RPG, strzelanki, gry wyścigowe), zazwyczaj borykają się z większą liczbą problemów związanych z grywalnością. Gatunki o stosunkowo prostej logice (np. gry typu survival i symulatory biznesowe) często osiągają lepsze wyniki w testach rozgrywki, co sprawia, że kolejnym kamieniem milowym do rozwiązania staje się dopracowanie grafiki i projekt interfejsu użytkownika. Świadomość różnic między gatunkami motywuje nas do poszerzenia naszego zestawu ewaluacyjnego o bardziej zrównoważoną próbę gier z platformy Build.
2. Wnioski wyciągnięte podczas projektowania struktury testowej: Iteracyjne prace nad samą strukturą dostarczyły nam kluczowych wniosków dotyczących jej niezawodności:

• Metryki systemowe a metryki komponentów: Przejrzysta struktura kodu lub wykorzystanie API nie gwarantują, że gra będzie się dobrze grać. Rozróżniamy poprawność, projekt i prezentację, aby uniknąć ukrywania błędów wymagających naprawy.
• Słabe strony zestawu testowego i kalibracja przez ludzi: Kontrole statyczne mogą przeoczyć blokujące działanie gry błędy występujące w czasie wykonywania, podczas gdy automatyczne testy rozgrywki mają trudności z złożoną fizyką. Wirtualni sędziowie są stale kalibrowani w oparciu o profesjonalnych twórców gier i doświadczonych recenzentów ze społeczności.
• Rozszerzenie na edycje wieloetapowe i rzeczywisty ruch: Ponieważ prawdziwi twórcy nieustannie wprowadzają zmiany (dodając systemy, dostosowując poziom trudności, naprawiając błędy), rozszerzamy nasz system ewaluacyjny, aby oceniać edycje wieloetapowe i rzeczywiste rozkłady poleceń.

Co dalej

Obecnie skupiamy się na rozszerzaniu naszego systemu oceny tworzenia modeli „Build” w pięciu kierunkach:

1. Szerszy zakres obejmujący różne gatunki, doświadczenia 2D/2,5D/3D, scenariusze wieloosobowe oraz poziomy złożoności
2. Lepsza obsługa edycji wieloetapowych
3. Bardziej wiarygodne dowody w postaci testów rozgrywki, zrzutów ekranu, nagrań wideo i audio
4. Kalibracja na dużą skalę w oparciu o oceny użytkowników oraz przypadki referencyjne wskazane przez twórców
5. Lepsza integracja między oceną offline, sygnałami produktowymi online oraz testami regresji

Naszym długoterminowym celem jest przejrzysty, stale ulepszany system oceny, który mierzy Build na poziomie ważnym dla twórców: jakość doświadczeń, które mogą tworzyć, testować, udostępniać i dalej rozwijać. Obecnie sygnały te są wykorzystywane do oceny gier generowanych przez Build. Z czasem, w miarę ich dalszego udoskonalania i kalibracji w oparciu o ludzką ocenę, mogą one zostać uogólnione na inne procesy twórcze i pomóc w stworzeniu wspólnego języka służącego zrozumieniu jakości gier w całym ekosystemie Roblox.

Aby zapoznać się z powiązanym artykułem na temat oceny systemów agentycznych dla Roblox Assistant, zobacz artykuł „Wykorzystanie OpenGameEval do testów porównawczych agentycznych asystentów AI dla Roblox Studio”.