Generare un Pokémon tutto tuo: un prototipo di ricerca integrato nel gioco

Panoramica

Ho realizzato un prototipo di ricerca che genera una nuova specie di Pokémon a partire da sei parole scelte durante la partita. Dopo alcuni minuti compare nell’erba alta, dove il giocatore può incontrarla, catturarla e darle un soprannome. Il prototipo genera aspetto, nome, tipo, statistiche di base, mosse e dati necessari a integrarla nel gioco.

Il prototipo collega conversazioni, scelta delle parole, generazione in background, incontri selvatici, cattura e assegnazione del soprannome senza interrompere il gioco. Ogni specie generata viene registrata in un formato utilizzabile dai sistemi di gioco esistenti.

Mi sono concentrato sulla struttura del processo di generazione più che sul modello stesso: definire requisiti che preservino equilibrio di gioco e coerenza visiva, lasciando poi che l’IA esplori entro quei confini. Ho anche giocato personalmente con il prototipo per valutare in via preliminare se un personaggio unico fosse sufficiente a suscitare attaccamento.

La domanda: essere unico basta a suscitare attaccamento?

I giochi permettono di scegliere, far crescere e dare un nome ai personaggi fino a sentirli propri. Il punto di partenza resta però un insieme di opzioni preparato dagli sviluppatori. Se l’IA generativa permettesse ai giocatori di dare forma a un personaggio fin dall’inizio, il legame sarebbe più forte?

Una sola immagine generata non basta per esplorare questa domanda. Il personaggio deve entrare nel mondo di gioco, poter essere incontrato e catturato e restare disponibile per continuare a giocare. Ho creato due percorsi con diversi livelli di coinvolgimento: parlare con l’anziano avvia la generazione senza input, mentre parlare con l’anziana permette di scegliere sei parole. Il primo personaggio con cui si parla determina il metodo di generazione per quella partita.

Il prototipo non trae conclusioni sull’attaccamento. Il suo scopo è integrare contenuti generati nel normale svolgimento del gioco e individuare condizioni per confronti futuri.

L’esperienza di gioco

La sequenza seguente mostra il percorso guidato dal giocatore. Nel Bosco Petalo, il giocatore parla con un’anziana e sceglie sei parole dal vocabolario Easy Chat già presente nel gioco. La generazione prosegue in background mentre la partita continua. Un verso segnala che la nuova specie è pronta; entrare nell’erba alta avvia l’incontro e il giocatore può catturarla con i comandi abituali. Ogni generazione produce nome, tipo, statistiche di base, mosse, sprite di battaglia frontale e posteriore e un’icona per la squadra. Il video dimostrativo mostra l’intera sequenza.

La sfida progettuale: mantenere giocabili i personaggi generati

Generare un nuovo personaggio e farlo funzionare all’interno di un gioco sono due sfide distinte. Statistiche troppo alte possono alterare il bilanciamento della difficoltà, mentre tipi e mosse poco compatibili possono renderlo difficile da allenare. Un aspetto troppo complesso può diventare irriconoscibile quando viene ridotto a uno sprite di 64 × 64 pixel.

Fissare ogni dettaglio toglierebbe senso alla generazione di un risultato diverso ogni volta. Dovevo distinguere gli elementi essenziali per il gioco da quelli che potevano variare.

Mi sono quindi concentrato sulla progettazione dello spazio dei Pokémon possibili, anziché di un singolo personaggio. Le persone definiscono obiettivi, vincoli, contenuti vietati e metodi di validazione; l’IA sviluppa proposte entro questa struttura. Il prototipo funzionante mette in pratica il mio approccio alla progettazione per vincoli.

L’approccio: definire le condizioni di generazione

Il sistema chiede a un modello linguistico di grandi dimensioni (LLM) di compilare campi predefiniti, come nome, tipo, statistiche di base, mosse, forma del corpo e colore, anziché scrivere un testo libero. Un validatore controlla ogni risposta prima di accettarla. Se una risposta viola una regola, il sistema restituisce la violazione specifica e chiede al modello di rigenerare finché i requisiti sono soddisfatti.

1. Le persone definiscono i confini. I requisiti di equilibrio del gioco, leggibilità degli sprite e ammissibilità dei contenuti diventano regole esplicite e verificabili.
2. L’IA sviluppa proposte. Il modello usa le parole del giocatore per proporre valori nei campi consentiti.
3. Il sistema verifica che l’output rispetti le regole. Controlla automaticamente intervalli numerici, combinazioni di mosse e contenuti vietati.
4. Il feedback riguarda solo le violazioni. Una proposta che viola una regola viene restituita con la motivazione e rigenerata.

Vincoli che proteggono il gioco. Ho fissato il totale delle statistiche di base tra 280 e 360, con limiti superiori e inferiori per ciascuna statistica. Le mosse sono state estratte dal codice sorgente del gioco e limitate a quelle dello stesso tipo della specie o di tipo Normale. Sono state escluse mosse da KO in un colpo, autodistruttive, a danno fisso ed eccessivamente potenti. Il validatore controllava anche il numero di mosse offensive e la presenza di mosse dello stesso tipo della specie. Tasso di cattura, tasso di crescita e altri fattori sono stati mantenuti fissi per contenere le differenze generate entro un intervallo adatto al confronto.

Vincoli che preservano la chiarezza visiva. Le forme del corpo sono selezionate tra opzioni con sagome leggibili anche in sprite piccoli. Sono limitati anche i termini utilizzabili per colori e caratteristiche. Sono esclusi tratti umani, sangue, armi e testo. Le istruzioni di generazione delle immagini includono sempre condizioni come «una sola creatura», «mostrare il corpo intero» e «nessun arto aggiuntivo».

In un’esecuzione registrata, il modello aveva inizialmente proposto un totale di statistiche di base pari a 380. Il validatore ha rilevato la violazione e chiesto una nuova generazione, arrivando a una specifica con un totale di 320. Il contributo consiste nel processo che rifiuta risultati fuori dai vincoli definiti, senza affidarsi alla casualità di un risultato riuscito.

Mantenere l’esperienza all’interno del gioco

Il giocatore usa soltanto conversazioni, scelta delle parole e incontri nell’erba presenti nel gioco: non c’è una schermata di generazione separata. Le elaborazioni più impegnative vengono eseguite da un processo Python sul PC, che scambia dati con il gioco attraverso file. Script Lua nell’emulatore mGBA collegano i due ambienti, preservando i comandi familiari del gioco e mantenendo esterna l’elaborazione dell’IA.

1. Generare la specifica. Un modello linguistico locale trasforma le sei parole in dati della specie, validati prima dell’uso.
2. Generare le immagini. Un modello di immagini crea un’illustrazione di riferimento, poi sprite frontale e posteriore e un’icona di squadra visivamente coerenti.
3. Convertire in dati di gioco. Le immagini vengono ridotte a 15 colori, poi convertite e compresse in sprite e palette compatibili con Game Boy Advance (GBA).
4. Integrare nel gioco in esecuzione. I dati vengono scritti in un’area riservata, introducendo la nuova specie senza riavviare il gioco.

Gli stessi dati vengono salvati anche su disco, così la specie generata permane quando si ricarica il gioco. La generazione avviene una sola volta e non può essere annullata. Se il giocatore fugge o perde l’incontro, il Pokémon rimane nel mondo. Se lo sconfigge, non ricompare più. Questa irreversibilità rende l’essere «l’unico in quella partita» parte dell’esperienza.

Che cosa ha confermato il prototipo

Ho realizzato da solo questo prototipo per verificarne la fattibilità tecnica. Non è né un gioco finito né uno studio con utenti. Di seguito distinguo ciò che ho verificato, ciò che ho implementato e ciò che resta da provare.

• Verificato dall’inizio alla fine. In mGBA ho confermato l’intera sequenza: conversazione e scelta delle sei parole, generazione in background, integrazione nel gioco in esecuzione, incontro selvatico, cattura e inserimento del soprannome.
• Implementato per confronti futuri. Ho aggiunto due punti di partenza: generazione passiva senza input e generazione guidata dal giocatore attraverso la scelta delle parole. Conversazioni, incontri e catture possono essere registrati per confrontarli.
• Collegato ai sistemi esistenti, ma non verificato con sessioni prolungate. Aumento di livello dopo la cattura, apprendimento delle mosse, battaglie, deposito nei box e uso dopo il salvataggio sono integrati con i sistemi di gioco esistenti. Non li ho verificati attraverso lunghe sessioni di gioco.
• Lavoro futuro. La generazione di forme evolute durante la partita non è stata implementata e non sono stati condotti studi comparativi sull’attaccamento con più partecipanti.

Che cosa ho imparato giocando: l’unicità da sola non mi ha fatto affezionare

Giocare personalmente con il prototipo non mi ha fatto sviluppare un forte attaccamento al Pokémon generato. È la mia impressione di sviluppatore, non un risultato generalizzabile ad altri giocatori. Mi ha però suggerito che cosa variare in un futuro confronto.

Due fattori mi sono sembrati degni di approfondimento.

• Qualità del risultato. Se l’aspetto e l’idea del personaggio non sono abbastanza attraenti, essere «l’unico in quella partita» potrebbe non bastare a sostenere l’attaccamento.
• Profondità del coinvolgimento. Scegliere sei parole mi faceva percepire il risultato più come qualcosa di ricevuto che di creato. Sospetto che il coinvolgimento dipenda dalla qualità del processo creativo: riconsiderare scelte, confrontare alternative, rivedere dettagli e assumersi la responsabilità del risultato, più che fornire semplicemente più input.

Al contrario, provo attaccamento per Hanagitsune, un personaggio che ho creato al di fuori del processo automatizzato del gioco, attraverso conversazioni ripetute con diversi strumenti di IA generativa e rifiniture manuali. Ho confrontato proposte, corretto dettagli e continuato fino a essere soddisfatto. Penso che abbiano contribuito a questo legame sia la qualità del risultato sia il mio coinvolgimento nel processo iterativo.

Questo prototipo non risponde alla domanda se i contenuti generati suscitino attaccamento. Traduce la domanda generale in due fattori che si possono variare deliberatamente: qualità del risultato e profondità del coinvolgimento. Uno studio futuro introdurrebbe occasioni per scegliere, confrontare e correggere durante la creazione, porterebbe i risultati a un livello qualitativo omogeneo e confronterebbe le esperienze di più partecipanti.

Implementazione

Il processo di generazione, la struttura dei vincoli e della validazione, la conversione dei dati GBA e le modifiche lato gioco sono pubblicati nel repository GitHub.