Da quel che mi pare di capire, Miyamoto non ha mai scritto una riga di codice nei suoi giochi. In un vecchio Iwata Asks, Toshihiko Nakago, il programmatore principale, racconta come funzionava. Miyamoto e Takashi Tezuka disegnavano i livelli a matita su enormi fogli di carta millimetrata. Il team di Nakago inseriva i dati a mano, blocco per blocco. La sera masterizzavano tutto su una ROM e i due designer giocavano il livello. Le correzioni tornavano come appunti a matita sul foglio. “Riuscivamo a malapena a stare in un ciclo di modifiche al giorno”, dice Nakago.
Un giro al giorno. Oggi, con un modello linguistico aperto accanto all’editor, ne posso fare uno ogni due minuti.
Ho già scritto che il genio solitario è un mito e lo penso ancora: senza Nakago non ci sarebbe stato Super Mario. Oggi una parte di quel dialogo tra designer e programmatore la fa un modello. Il dialogo però resta, e il modo in cui Miyamoto ci stava dentro dice molto su cosa diventa il nostro mestiere.
Il designer come regista
Mi piace immaginare Miyamoto come una persona che sapeva cosa voleva e sapeva comunicarlo. Il suo lavoro era descrivere: dove sta il blocco, quanto in alto arriva il salto, cosa fa il Goomba quando sbatte contro un tubo. La traduzione in assembly toccava ad altri.
Con l’AI succede qualcosa di simile. Posso descrivere una meccanica, gli stati di un personaggio, i casi limite, e ottenere uno script per Godot o Unity che li esegue. La qualità del risultato dipende da quanto ho le idee chiare, consumerò più o meno token in base a quanto sarò accurato.
Il designer decide cosa deve succedere, perché, e che sensazione deve dare. Scrivere il codice diventa una parte del processo che si può delegare. Ne parlavo ieri a proposito dei junior: il compito è sempre stato istruire una macchina perché diventi un gioco.
I limiti di oggi
Il NES aveva 2 KB di RAM di lavoro. Nakago racconta che andavano a caccia di memoria libera: con venti byte a disposizione potevi aggiungere dieci blocchi a un livello. Da quei limiti sono nate soluzioni rimaste nella storia, come le nuvole e i cespugli di Super Mario Bros., che sono lo stesso disegno con un colore diverso.
Miyamoto non programmava, però quei limiti li conosceva benissimo. Per questo chiedeva cose che si potevano fare.
Anche l’AI ha i suoi limiti, e chi la usa deve conoscerli allo stesso modo. Il modello dimentica quello che esce dalla sua finestra di contesto. Dà risposte diverse alla stessa domanda. Se gira in tempo reale dentro un gioco, ogni chiamata ha un tempo di risposta e un costo. Chi li conosce può progettarci attorno, e a volte trasformarli in meccaniche: un personaggio che ricorda male, un oracolo imprevedibile, un mondo che cambia ogni volta che lo visiti.
Dieci giri al giorno, poi cento
Nella stessa intervista Nakago dice che, con gli strumenti arrivati dopo, potevano modificare un livello dieci o venti volte al giorno. Oggi il ciclo tra idea, implementazione e prova si accorcia quasi a zero. Cambio la gravità, rigioco, la cambio ancora.
Questo sposta il collo di bottiglia. Prima il limite era quanto velocemente qualcuno riusciva a implementare una modifica. Adesso il limite è quanto velocemente io riesco a capire se la modifica funziona. E per capirlo devo giocare, sentire, confrontare. Il feel di un salto si trova solo con il controller in mano.
Quello che l’AI non sa
L’AI scrive codice, abbozza dialoghi, genera asset in pochi secondi. Però non sa quando un livello è troppo lungo, quando un nemico arriva nel momento sbagliato, quando un salto diventa frustrante. Non prova gioia, noia o tensione. Imita bene le soluzioni che altri hanno già trovato; scegliere quale tenere spetta a chi gioca.
Per questo credo che il valore del game designer si stia spostando ancora di più verso il gusto, il ritmo e la psicologia del giocatore. Sono le qualità che hanno reso il lavoro di Miyamoto senza tempo, e lui le esercitava con una matita e un foglio a quadretti.
Tre cose da allenare da domani
- Scrivi specifiche che qualcun altro possa eseguire. Prendi una meccanica che conosci bene, per esempio il salto di Mario, e descrivila in dieci righe. Poi dalla a un modello e guarda cosa ne esce. Ogni differenza tra quello che avevi in testa e quello che vedi è un punto in cui la tua descrizione era vaga.
- Studia i limiti del tuo strumento. Miyamoto conosceva la memoria del NES; tu impara cosa il modello fa male: dove si confonde, cosa dimentica, quando inventa. Sono informazioni di design.
- Gioca più di quanto generi. Se un’iterazione costa due minuti, è facile produrne cinquanta senza giocarne davvero nessuna. Fissa dei momenti in cui prendi il controller e giudichi, e scrivi cosa hai sentito prima di chiedere la modifica successiva.