Este post foi originalmente escrito em italiano por Paolo Gambardella. Foi traduzido por um agente de inteligência artificial e pode conter imprecisões.
Da quanto consigo entender, Miyamoto nunca escreveu uma linha de código nos seus jogos. Numa antiga Iwata Asks, Toshihiko Nakago, o programador principal, conta como funcionava. Miyamoto e Takashi Tezuka desenhavam as fases a lápis em enormes folhas de papel milimetrado. A equipe de Nakago inseria os dados à mão, bloco por bloco. À noite gravavam tudo numa ROM e os dois designers jogavam a fase. As correções voltavam como anotações a lápis na folha. “Mal conseguíamos fechar um ciclo de alterações por dia”, diz Nakago.
Um ciclo por dia. Hoje, com um modelo de linguagem aberto ao lado do editor, consigo fazer um a cada dois minutos.
Já escrevi que o gênio solitário é um mito e continuo pensando assim: sem Nakago não teria existido Super Mario. Hoje, parte desse diálogo entre designer e programador é feito por um modelo. O diálogo, porém, continua existindo, e a forma como Miyamoto se movia dentro dele diz muito sobre o que o nosso ofício está se tornando.
O designer como diretor
Gosto de imaginar Miyamoto como alguém que sabia o que queria e sabia comunicar isso. O trabalho dele era descrever: onde fica o bloco, até que altura vai o pulo, o que o Goomba faz quando bate num cano. A tradução para assembly ficava com os outros.
Com a IA acontece algo parecido. Posso descrever uma mecânica, os estados de um personagem, os casos extremos, e obter um script para Godot ou Unity que os executa. A qualidade do resultado depende de quão claras estão as minhas ideias — vou gastar mais ou menos tokens conforme a minha precisão.
O designer decide o que deve acontecer, por quê, e que sensação deve provocar. Escrever o código vira uma parte do processo que pode ser delegada. Comentei isso outro dia a respeito dos juniores: a tarefa sempre foi instruir uma máquina para que ela se torne um jogo.
Os limites de hoje
O NES tinha 2 KB de RAM de trabalho. Nakago conta que ficavam caçando memória livre: com vinte bytes disponíveis dava para adicionar dez blocos a uma fase. Dessas restrições nasceram soluções que ficaram para a história, como as nuvens e os arbustos de Super Mario Bros., que são o mesmo desenho com uma cor diferente.
Miyamoto não programava, mas conhecia esses limites de cor e salteado. Por isso pedia coisas que eram possíveis de fazer.
A IA também tem os seus limites, e quem a usa precisa conhecê-los da mesma forma. O modelo esquece o que sai da sua janela de contexto. Dá respostas diferentes para a mesma pergunta. Se rodar em tempo real dentro de um jogo, cada chamada tem um tempo de resposta e um custo. Quem conhece esses limites consegue projetar em torno deles, e às vezes transformá-los em mecânicas: um personagem que lembra as coisas errado, um oráculo imprevisível, um mundo que muda toda vez que você o visita.
Dez ciclos por dia, depois cem
Na mesma entrevista, Nakago conta que, com as ferramentas que vieram depois, conseguiam modificar uma fase dez ou vinte vezes por dia. Hoje o ciclo entre ideia, implementação e teste encolhe quase a zero. Mudo a gravidade, jogo de novo, mudo outra vez.
Isso desloca o gargalo. Antes o limite era a velocidade com que alguém conseguia implementar uma mudança. Agora o limite é a velocidade com que eu consigo entender se a mudança funcionou. E para entender isso preciso jogar, sentir, comparar. O feel de um pulo só se acha com o controle na mão.
O que a IA não sabe
A IA escreve código, esboça diálogos, gera assets em poucos segundos. Mas ela não sabe quando uma fase está longa demais, quando um inimigo aparece na hora errada, quando um pulo vira frustração. Ela não sente alegria, tédio ou tensão. Imita bem as soluções que outros já encontraram; escolher qual delas fica é tarefa de quem joga.
Por isso acredito que o valor do game designer está se deslocando ainda mais em direção ao gosto, ao ritmo e à psicologia do jogador. São as qualidades que tornaram o trabalho de Miyamoto atemporal, e ele as exercitava com um lápis e uma folha quadriculada.
Três coisas para treinar a partir de amanhã
- Escreva especificações que outra pessoa consiga executar. Pegue uma mecânica que você conhece bem, por exemplo o pulo do Mario, e descreva-a em dez linhas. Depois passe para um modelo e veja o que sai. Cada diferença entre o que você tinha na cabeça e o que você vê é um ponto em que a sua descrição estava vaga.
- Estude os limites da sua ferramenta. Miyamoto conhecia a memória do NES; você aprenda o que o modelo faz mal: onde ele se confunde, o que ele esquece, quando ele inventa. São informações de design.
- Jogue mais do que gera. Se uma iteração custa dois minutos, é fácil produzir cinquenta sem jogar de verdade nenhuma delas. Reserve momentos para pegar o controle e julgar, e escreva o que sentiu antes de pedir a próxima alteração.