Come Roblox valuta la creazione di giochi "Build"

Build, il nostro nuovo strumento di creazione mobile-first, consente agli utenti di Roblox di creare un gioco utilizzando prompt di testo e di pubblicarlo per i giocatori di tutto il mondo. La generazione di un gioco completo richiede un sistema agentico end-to-end per la generazione del gioco: un sistema che coordini codice, risorse visive, sistemi di gameplay, interfaccia utente e controlli in un unico artefatto composito. Questo sistema deve gestire in modo robusto i vari scenari che emergono con l’input dei giocatori e le interazioni multiplayer. Dal lancio della versione alpha in Nuova Zelanda, oltre 100.000 giocatori hanno utilizzato Build per provare a creare un gioco e sono stati pubblicati circa 9.000 giochi realizzati con Build.¹ Tra le migliaia di persone che hanno utilizzato Build per creare un gioco, il 71% non aveva mai utilizzato Roblox Studio in precedenza,¹ il che dimostra che stanno provando qualcosa di nuovo con Build.

Tuttavia, i creatori useranno questo nuovo strumento solo se è facile da usare e se la qualità dei giochi che genera è sufficientemente elevata da poter essere sviluppata ulteriormente. Per comprendere la qualità dei giochi creati con Build, valutiamo l’intero percorso di creazione e utilizziamo tali valutazioni, insieme al feedback dei creatori, per migliorare il prodotto. Il nostro framework di valutazione (eval) ci ha aiutato a dare priorità e a migliorare la comprensione delle intenzioni, la giocabilità 3D e la rifinitura. Dal lancio della versione alpha di Build in Nuova Zelanda, la soddisfazione dei creatori è aumentata del 10%, i risultati indesiderati sono scesi dal 18% al 3% e circa il 14% delle sessioni guidate e il 19% dei playtest vengono pubblicati.² Si tratta di indicatori descrittivi dei progressi, non di stime causali del solo impatto della valutazione.

Perché la valutazione della creazione di giochi è diversa

I giochi condividono alcune delle stesse sfide di valutazione riscontrate in altri sistemi che generano artefatti composti, come app, video e modelli del mondo. Ad esempio, la qualità dipende da come più componenti interagiscono tra loro, e nessun punteggio relativo a un singolo componente descrive appieno il risultato. 

Ciò che distingue i giochi è che l’artefatto è un sistema eseguibile in tempo reale guidato dai giocatori. Proprietà quali reattività, agenzia, progressione e sensazione di gioco emergono attraverso l’interazione e non possono essere valutate appieno solo ispezionando il codice o le risorse. Un gioco deve quindi superare una soglia particolarmente elevata di correttezza a basso livello (privo di difetti e giocabile), nonché di esperienza di gioco a livello elevato (un gioco che dia la sensazione di essere completo, non un prototipo). 

La domanda a cui cerchiamo di rispondere attraverso la valutazione non è se un singolo elemento sia corretto, ma se l’artefatto nel suo insieme corrisponda all’intento del creatore e se i giocatori possano vivere l’esperienza nella sua interezza. Per rispondere a questa domanda occorre più di un unico parametro.

Quattro segnali, un unico quadro di riferimento

Il nostro quadro di valutazione della creazione «Build» combina quattro segnali. Ciascuno risponde a una domanda diversa, individua una diversa classe di errori e produce un punteggio quantitativo concreto:

1. Qualità delle specifiche del gioco (punteggio da 0 a 100): Build è l’agente di creazione end-to-end: traduce le indicazioni del creatore in una specifica, quindi la utilizza per generare il gioco. Il valutatore verifica se la specifica definisce esplicitamente le decisioni importanti, preserva l’intento del creatore, tiene conto della fattibilità all’interno del runtime di Roblox ed evita di inventare requisiti che non sono mai stati espressi.

2. Qualità statica del gioco (punteggio da 0 a 100): il valutatore statico ispeziona il gioco generato nella modalità di modifica di Roblox Studio. Ciò include la struttura del gioco, gli script, le risorse, le proprietà, le connessioni e i confini client/server. In questa fase cerchiamo di rispondere a due domande. La prima è se il gioco sia stato realizzato correttamente: implementazione dei sistemi richiesti, scelte relative all’API del motore e alla rete, presenza dei controlli e dei componenti dell’interfaccia utente previsti, robustezza e coerenza dell’architettura del gioco. 

La seconda è se sia stato progettato per essere divertente: profondità del ciclo di gioco principale, varietà e intensificazione dei contenuti, progressione, rigiocabilità e innovazione che vada oltre gli standard del genere. Un gioco può avere un’architettura pulita ma non avere profondità nei contenuti, oppure essere pieno di idee ma mal strutturato. 

Separare questi due punti di vista e valutare il gioco rispetto alle migliori pratiche ci offre un’idea più dettagliata di dove il gioco fallisce.

3. Playtest (tasso di superamento 0 - 100%): il valutatore del playtest avvia il gioco ed esegue un piano di test con input simili a quelli di un giocatore reale, inclusi tocchi, clic, pressioni dei tasti e navigazione, anziché innescare eventi tramite codice. Un piano di test caso per caso verifica che il gioco si avvii, risponda, proceda, si riprenda da eventuali errori e non presenti errori di runtime. Ogni elemento è valutato con un risultato binario (superato/non superato), riportato come percentuale di superamento ponderata per livello insieme a un semplice verdetto “giocabile/non giocabile”. Ripetiamo le esecuzioni per misurare la coerenza.

4. Qualità visiva ed esperienziale (punteggio da 0 a 100): alcuni degli aspetti più importanti per l’aspetto e l’atmosfera di un gioco non possono essere ricavati dal codice, quindi il valutatore visivo assegna un punteggio alla presentazione in modo autonomo utilizzando filmati di gameplay acquisiti su finestre di visualizzazione che rappresentano diversi dispositivi. Questa rubrica esamina esclusivamente l’aspetto e il suono del gioco sulla base della realizzazione delle risorse, della rifinitura dell’interfaccia utente, del movimento, dell’illuminazione e dell’audio. La domanda fondamentale è: il gioco appare come un prodotto pronto per il lancio o come un prototipo? Separare gli aspetti visivi dalle meccaniche di gioco significa che «il codice funziona» e «il gioco sembra finito» non vengono mediati in un unico punteggio fuorviante.

Oltre ai segnali valutati, ogni esecuzione acquisisce metriche a solo scopo informativo, come l’utilizzo dei token, le chiamate agli strumenti, le abilità attivate e la latenza. Queste metriche non influenzano il punteggio della valutazione, ma possono spiegare come è stato prodotto un risultato e individuare regressioni che sfuggono alle rubriche, come una build che è diventata due volte più costosa per lo stesso gioco.

I segnali corrispondono agli errori che rilevano:

Percorso attraverso un percorso 3D Obby guidato

I segnali sono più facili da individuare in una descrizione reale. Ad esempio: “Un vero gioco Obby in 3D, con una piattaforma di partenza, ostacoli mobili, checkpoint e linea di arrivo”. Gli Obby sono un genere di gioco platform molto popolare su Roblox. L’intento del creatore è chiaro, anche se non prescrive ogni dettaglio di implementazione. Il build deve completare i dettagli con ipotesi ragionevoli.

Piano e specifiche

Il team di sviluppo ha redatto un documento di specifiche per un nuovo gioco, denominato Skyforge Ascent, che descrive in dettaglio un percorso articolato in cinque sezioni con punti di controllo e tre tipi di ostacoli. Il documento definisce il ciclo di gioco principale, la curva di difficoltà, la direzione artistica, le schermate, gli overlay e i comandi. La valutazione delle specifiche ha assegnato un punteggio di 91/100, con il massimo dei voti per completezza, rispetto tempestivo delle indicazioni, fattibilità e coerenza interna. La deduzione è derivata da due aspetti specifici: i dettagli di implementazione e la copertura dei criteri di accettazione. 

Le specifiche non hanno mai fissato le costanti numeriche, quali velocità di rotazione, distanze di scorrimento, tempi delle tessere, dimensioni delle piattaforme o altezza del piano di reset, pertanto un ingegnere deve ancora definirle. Inoltre, alcuni criteri di accettazione (come «circa 24 piattaforme» o «tavolozza dei colori della fucina celeste») non sono strettamente falsificabili. Un punteggio elevato delle specifiche dimostra solo che il documento è pronto per la realizzazione. Se tali impegni resistano alla prova dello sviluppo effettivo del gioco è ciò che misurano le tre fasi successive.

Controlli statici: qualità del codice e qualità dei contenuti

Il giudice virtuale ha esaminato il file di posizione di Skyforge Ascent senza giocarci, e le due prospettive di valutazione sono giunte a conclusioni diverse.

La lente ingegneristica, leggendo lo stesso file di livello, gli ha assegnato un punteggio di 98/100. Ha riscontrato una struttura esemplare con cinque sezioni e tre ostacoli mobili, che soddisfa pienamente l’intento del creatore grazie all’uso di checkpoint sequenziali gestiti dal server, sistemi di reset in caso di caduta e un’interfaccia utente basata sul framework StyleSheet. Tutto ciò che era delineato nelle specifiche è stato realizzato. L’unico problema erano due esportazioni di funzioni di supporto inutilizzate.

La prospettiva del design ha assegnato un punteggio di 31/100. Tutto funzionava, ma il gioco ha ottenuto zero in termini di progressione, rigiocabilità, autonomia del giocatore e elemento di richiamo originale. Il ciclo di gioco era semplice e lineare — raggiungere ogni checkpoint, tagliare il traguardo — con scarsa varietà tra una partita e l’altra e nessun motivo per tornare a giocarlo una seconda volta. Si tratta di un classico del genere obby, non di un gioco con un elemento di richiamo proprio.

Questa discrepanza è il risultato emerso. La qualità del codice e quella dei contenuti sono dimensioni fondamentalmente diverse, e una build può essere quasi perfetta in un ambito ma fallire nell’altro. Un unico punteggio di qualità combinato avrebbe fatto una media tra questi due aspetti, ottenendo un risultato privo di significato.

Test di gioco

L'agente di playtest ha giocato al gioco utilizzando input simili a quelli di un giocatore reale e ha superato tutti e nove i punti del piano di test: generazione di un personaggio sulla piattaforma di partenza, navigazione nella geometria 3D attraverso gli spazi vuoti, subendo impatti con gli ostacoli, attivazione dei checkpoint e del recupero automatico in caso di caduta, completamento della corsa e riavvio, il tutto senza alcun errore di runtime. In questa specifica sessione, Skyforge Ascent ha ottenuto un punteggio di 100/100 nel playtest.

Un punteggio perfetto nel playtest dimostra semplicemente che le meccaniche funzionano e che il gioco è tecnicamente giocabile dall’inizio alla fine. Non dice nulla sul fatto che il gioco sia effettivamente coinvolgente o divertente da giocare: è proprio questa distinzione il motivo per cui la valutazione dal punto di vista del design gli ha assegnato un punteggio di 31.

Qualità visiva

Infine, il sistema di valutazione ha valutato la sessione registrata su uno schermo delle dimensioni di uno smartphone per quanto riguarda la presentazione visiva. Skyforge Ascent ha ottenuto un punteggio di 86/100: grafica pulita, coerente e perfettamente in linea con quella di un tipico gioco di corsa a ostacoli; geometria delle piattaforme ben definita; pericoli chiaramente identificabili; e un HUD moderno e discreto. Alcuni piccoli limiti visivi ne impediscono la perfezione, ma non c’è nulla di difettoso, né nulla che possa indurre un giocatore a smettere di scorrere.

Metriche di tracciamento

La stessa esecuzione ha registrato anche le metriche di processo. La creazione del gioco ha richiesto circa otto minuti, non si sono verificati errori degli strumenti e la build ha utilizzato le competenze relative a 3D, interfaccia utente, modifica degli script, inserimento delle risorse e audio di gioco. Queste metriche non influenzano direttamente il punteggio di valutazione, ma ci indicano come è stato realizzato il gioco e segnalerebbero una build futura che risultasse più lenta o più costosa senza alcun vantaggio.

Nelle cinque fasi, Skyforge Ascent ha ottenuto punteggi diversi per quanto riguarda le specifiche di gioco, la qualità del codice, la qualità dei contenuti, il playtest e la qualità visiva. Quattro di queste dimensioni indicano che Build è in grado di trasformare un singolo prompt in un’esperienza Roblox completa, corretta, giocabile e presentabile. Una dimensione indica invece che non si tratta di un gioco che qualcuno sceglierebbe di giocare una seconda volta. Misurare questo divario, invece di annullarlo calcolandone la media, è lo scopo principale della valutazione di Build.

In che modo la valutazione precoce ha migliorato Build 

I risultati della valutazione non si limitano a generare punteggi, ma forniscono anche indicazioni concrete per il miglioramento del prodotto. Combinando il debug dei singoli componenti con test olistici a livello di sistema, le valutazioni offline in batch su suite di prompt standardizzate hanno plasmato direttamente lo sviluppo di Build. 

1. Risoluzione rapida dei punti critici per i creatori della versione alpha: durante il lancio della versione alpha in Nuova Zelanda, gli utenti ci hanno segnalato che Build a volte creava un gioco in 2D quando volevano un gioco in 3D. Il framework di valutazione ha aiutato il nostro team a migliorare rapidamente le capacità 3D di Build. Nel giro di due settimane, abbiamo migliorato la capacità di Build di comprendere l’intenzione dell’utente di creare un gioco in 3D, anche se non lo dichiarava esplicitamente. Abbiamo inoltre perfezionato la giocabilità e la rifinitura 3D risolvendo problemi comuni relativi al posizionamento degli oggetti, all’illuminazione, ecc. Da allora, i reclami del tipo «non è quello che voglio» sono scesi dal 18% al 3% sul totale dei reclami; la reazione complessiva di insoddisfazione dopo i playtest è diminuita di 10 punti percentuali. Abbiamo anche acquisito nuove conoscenze durante le iterazioni sul framework stesso. 
2. Benchmark comparativi tra modelli e architetture: utilizziamo il nostro framework di valutazione per confrontare rigorosamente le configurazioni del sistema Build con suite di prompt standardizzate. Prima di implementare le modifiche in produzione, i report di valutazione A/B offline confrontano le versioni candidate con le nostre linee di base di produzione in tutte e quattro le dimensioni: 

Ad esempio, queste differenze offline ci consentono di isolare l'impatto dei vari aggiornamenti del modello e delle decisioni di instradamento degli agenti sui singoli segnali di qualità:

• Prestazioni del modello di base: l'aggiornamento del nostro modello di base ha portato a miglioramenti costanti su ogni parametro, con conseguente riduzione degli errori di compilazione al primo tentativo, una rifinitura visiva superiore e contenuti di gioco più approfonditi.
• Architettura di instradamento degli agenti: al contrario, delegare specifici sotto-compiti a un modello leggero in una configurazione a doppio agente ha preservato la profondità e la diversità dei contenuti, ma ha causato forti regressioni nella giocabilità e nella rifinitura visiva.

1. Monitoraggio dei parametri di riferimento di qualità nei diversi paradigmi di creazione: utilizziamo inoltre il framework per comprendere l’attuale qualità della build in momenti diversi, utilizzando il set di valutazione più pertinente. Questi set forniscono istantanee di attività di creazione sempre più ampie e complesse.
   Il set più antico è costituito interamente da giochi 2D con meccaniche relativamente semplici. La logica di gioco era facile da realizzare, pertanto il punteggio del playtest tendeva ad essere più alto; d’altra parte, il punteggio relativo ai contenuti rimaneva basso proprio per lo stesso motivo.
   Man mano che spostiamo l’attenzione sui giochi 3D, la distribuzione dei punteggi si sposta naturalmente: giocare senza bug diventa più impegnativo, riducendo i punteggi dei playtest. I punteggi visivi rimangono stabili a causa della mancanza di rifinitura delle risorse, conferendo ai giochi l’aspetto di un prototipo. I punteggi relativi ai contenuti sono più alti poiché i giochi 3D hanno il potenziale per essere più profondi, ma i punteggi complessivi tendono a rimanere bassi poiché i prompt a turno singolo offrono uno spazio limitato per l’espansione dei contenuti.

1. Individuazione dei colli di bottiglia specifici per genere: i dati di valutazione evidenziano anche significative variazioni di prestazioni tra i generi. I generi che fanno ampio ricorso a meccanismi di gioco complessi (ad esempio, giochi di ruolo, sparatutto, giochi di corse) tendono a presentare maggiori problemi di giocabilità. I generi con una logica relativamente semplice (ad esempio, giochi di sopravvivenza e di gestione aziendale) spesso ottengono risultati migliori nei playtest, rendendo la rifinitura visiva e la progettazione dell’interfaccia utente la prossima sfida da affrontare. Conoscere la differenza tra i generi ci spinge ad ampliare il nostro set di valutazione con un campionamento più equilibrato tra i giochi di Build.
2. Lezioni apprese nella progettazione del framework di valutazione: l’iterazione sul framework stesso ci ha insegnato lezioni fondamentali sull’affidabilità del framework:

• Metriche di sistema vs. metriche dei componenti: una struttura del codice pulita o l’utilizzo delle API non garantiscono un gioco giocabile. Manteniamo distinti correttezza, progettazione e presentazione per evitare di nascondere bug risolvibili.
• Punti deboli del framework e calibrazione umana: i controlli statici possono non rilevare errori di runtime che causano il crash del gioco, mentre i playtest automatizzati faticano con la fisica complessa. I giudici virtuali vengono continuamente calibrati rispetto a sviluppatori di giochi professionisti e revisori esperti della community.
• Espansione ai turni multipli e al traffico reale: poiché i creatori reali iterano continuamente (aggiungendo sistemi, regolando la difficoltà, correggendo bug), stiamo espandendo il nostro framework di valutazione per valutare le modifiche a turni multipli e le distribuzioni dei prompt nel mondo reale.

Cosa ci aspetta

Attualmente ci stiamo concentrando sull’estensione del nostro sistema di valutazione della creazione «Build» in cinque direzioni:

1. Copertura più ampia tra generi, esperienze 2D/2.5D/3D, scenari multiplayer e livelli di complessità
2. Supporto più solido per le modifiche multi-turno
3. Prove di gioco, screenshot, video e prove audio più affidabili
4. Calibrazione su larga scala rispetto alle valutazioni umane e ai casi di riferimento definiti dai creatori
5. Migliore integrazione tra valutazione offline, segnali di prodotto online e test di regressione

Il nostro obiettivo a lungo termine è un sistema di valutazione trasparente e in continuo miglioramento che misuri Build al livello che interessa ai creatori: la qualità delle esperienze che possono realizzare, testare, condividere e continuare a sviluppare. Oggi, questi segnali vengono utilizzati per valutare i giochi generati da Build. Nel corso del tempo, man mano che li perfezioneremo e li calibreremo ulteriormente in base al giudizio umano, potrebbero essere estesi ad altri flussi di lavoro creativi e contribuire a fornire un linguaggio comune per comprendere la qualità dei giochi nell’ecosistema Roblox più ampio.

Per un approfondimento correlato sulla valutazione dei sistemi agentici per Roblox Assistant, consulta l’articolo “Utilizzo di OpenGameEval per il benchmarking degli assistenti IA agentici per Roblox Studio”.