O Lobo, O Grupo E A Máquina

Durante muito tempo, criar um jogo sozinho significava aceitar que algumas coisas simplesmente não seriam feitas. O programador poderia escrever um excelente código, mas talvez não soubesse desenhar. O artista poderia construir cenários maravilhosos, mas não conseguiria programar o movimento de uma porta. O músico poderia compor uma trilha memorável, mas dependeria de alguém para colocar tudo aquilo dentro de um programa executável.

Ainda existem pessoas capazes de fazer quase tudo sozinhas, naturalmente, mas sempre foram exceções. O mais comum é que o chamado desenvolvedor solo seja, na verdade, alguém tentando equilibrar várias profissões ao mesmo tempo: programação, desenho, animação, roteiro, som, interface, divulgação, testes e administração.

O lobo solitário nunca esteve tão bem equipado quanto agora. Ao mesmo tempo, nunca teve tantas maneiras diferentes de se perder.

A forma mais tradicional continua existindo: programar o jogo diretamente, escrevendo o código praticamente do zero. O desenvolvedor escolhe uma linguagem, constrói as rotinas gráficas, controla o teclado, o mouse ou o joystick, organiza arquivos, objetos, sons e regras. É um caminho trabalhoso, mas também profundamente educativo. Quem trabalha dessa maneira conhece cada peça do jogo porque foi responsável por montar todas elas. É como construir a própria casa fabricando também os tijolos.

Essa abordagem oferece liberdade, controle e independência. Em compensação, exige tempo, conhecimento técnico e disposição para resolver problemas que uma ferramenta pronta já solucionou milhares de vezes. Dependendo do jogo, boa parte do esforço pode ser consumida em tarefas que não têm relação direta com aquilo que o torna especial.

Por isso, tornou-se comum trabalhar com uma engine conhecida. Nesse caso, o desenvolvedor não começa diante de uma tela completamente vazia. Já encontra sistemas de imagens, animações, física, iluminação, áudio, partículas, câmeras, controles e exportação para diferentes plataformas.

A engine não cria o jogo. Ela fornece um território preparado para que o jogo seja construído.

É uma diferença importante. Muita gente acredita que utilizar uma engine diminui o mérito do desenvolvedor. Não diminui. Um marceneiro não precisa plantar uma árvore, derrubá-la e fabricar as próprias ferramentas para provar que sabe fazer uma cadeira. O conhecimento está na maneira como os recursos disponíveis são utilizados.

Para pequenas equipes, as engines permitem dividir melhor o trabalho. Uma pessoa cuida da programação, outra da arte, outra do roteiro ou do som. Todos trabalham sobre uma estrutura comum, visualizam rapidamente os resultados e corrigem problemas sem precisar reconstruir o projeto inteiro a cada alteração.

O problema é que as engines também criam dependências. Elas possuem regras, versões, limitações e formas específicas de trabalho. Em alguns casos, um jogo começa a parecer menos com a ideia de seu autor e mais com os exemplos que vieram junto com a ferramenta. O desenvolvedor precisa tomar cuidado para não deixar que a engine se transforme no verdadeiro designer do projeto.

E agora temos também a inteligência artificial.

Ela pode entrar no processo de maneira discreta, ajudando apenas em tarefas específicas. Pode sugerir soluções de programação, encontrar erros, gerar uma imagem provisória, criar uma textura, limpar uma gravação, produzir efeitos sonoros, organizar um documento ou oferecer variações para um diálogo. Essa talvez seja a aplicação mais imediata e menos polêmica da IA: funcionar como assistente.

O desenvolvedor continua programando, desenhando, escrevendo e tomando decisões, mas recebe ajuda nas partes mais demoradas ou naquelas em que possui menos experiência. Uma pequena equipe consegue preencher lacunas sem precisar contratar imediatamente especialistas para todas as funções. Pense no seguinte: se a IA pode “entender” estruturas complexas de programação, ela também pode saber muito sobre a engine que a equipe vai utilizar.

É importante observar que auxiliar não significa substituir. Uma imagem gerada por IA raramente deve ser aceita apenas porque ficou bonita. Ela precisa combinar com o restante do jogo, respeitar proporções, manter coerência visual e funcionar dentro da narrativa. Um código gerado também precisa ser lido, compreendido e testado. Um som precisa ser adequado à cena, não apenas tecnicamente correto. A IA pode produzir material. Quem decide se aquilo pertence ao jogo ainda é o criador.

Existe, porém, uma segunda forma de utilização que vem crescendo rapidamente: deixar a IA conduzir grande parte da programação. Nesse modelo, o autor não escreve necessariamente cada linha de código. Ele descreve o que deseja, explica as regras, pede alterações, testa os resultados e informa o que deu certo ou errado. Seu papel se aproxima mais do trabalho de um designer, diretor ou produtor.

É algo como:
“Quero que o personagem possa empurrar esta caixa.”
“A caixa está se movendo rápido demais.”
“Ela não pode atravessar a parede.”
“Quando a caixa for colocada sobre este símbolo, a porta deve abrir.”

A construção do jogo passa a acontecer por meio de uma conversa. Esse modelo de “fazer conversando” é uma das mudanças mais interessantes trazidas pelas inteligências artificiais. Durante décadas, conversar com um computador significava escolher entre opções que alguém havia programado anteriormente. Agora, o usuário descreve uma intenção em linguagem comum e a máquina tenta transformar essa intenção em alguma coisa concreta. Isso torna o desenvolvimento mais acessível, mas não necessariamente mais simples.

Saber conversar com uma IA não é apenas saber escrever pedidos. É necessário explicar objetivos, estabelecer limites, identificar erros e perceber quando a solução apresentada parece correta, mas está fundamentada de maneira errada.

Uma IA pode produzir rapidamente centenas de linhas de código. Isso não significa que o código esteja bem estruturado. Ela pode corrigir um defeito criando outros três. Pode solucionar um problema local destruindo um sistema que já funcionava. Pode insistir várias vezes na mesma abordagem, mudando apenas os nomes das funções. O criador precisa permanecer no comando.

Ele não precisa conhecer todos os detalhes técnicos, mas precisa entender o jogo que está construindo. Deve saber como cada parte deveria se comportar, quais são as regras, qual é a experiência desejada e até onde uma alteração pode afetar o restante do projeto.

Nesse sentido, o desenvolvimento por conversa não elimina o conhecimento. Ele muda o tipo de conhecimento necessário. Antes, o obstáculo poderia ser não saber escrever um determinado comando. Agora, o obstáculo pode ser não saber explicar com precisão o que se pretende fazer.

É perfeitamente possível orientar uma IA para criar a maior parte da programação de um jogo. Também é possível solicitar imagens, músicas, efeitos, textos e interfaces. O que não deve acontecer, nunca, é abandonar o projeto nas mãos da máquina e esperar que ela produza tudo sozinha, ou a partir de um único prompt.

Uma IA não possui compromisso real com o jogo. Ela não passou anos imaginando aquele mundo. Não conhece a importância emocional de uma cena. Não sabe por que determinado personagem precisa permanecer em silêncio ou por que uma porta não deve se abrir, mesmo que tecnicamente pudesse. Ela executa, associa, sugere e reorganiza. A intenção continua sendo humana.

Quando alguém pede que a IA faça tudo sem acompanhamento, o resultado pode até parecer um jogo. Pode possuir menu, personagem, inimigos, pontuação, sons e uma tela de encerramento. Mas provavelmente será apenas uma soma de padrões conhecidos, sem uma razão clara para existir. Jogos não são feitos apenas de recursos funcionando. São feitos de escolhas.

O lobo solitário de hoje pode programar do zero, usar uma engine, contratar colaboradores, trabalhar com uma pequena equipe ou utilizar inteligências artificiais em diferentes níveis. Pode escrever cada linha ou dirigir uma produção quase inteira por meio de conversas. Todas essas formas são válidas.

O que define o autor não é a quantidade de código digitada, de imagens desenhadas ou de sons gravados pessoalmente. É a capacidade de estabelecer uma visão, reconhecer o que serve a essa visão e assumir responsabilidade pelas decisões tomadas. A IA pode ser ferramenta, assistente, colaboradora e até executora mas nunca deve ser dona do projeto.

EM TEMPO: antes que alguém pergunte, sim, eu criei jogos em todos esses modelos, desde 1981 quando tive que usar lápis e papel porque o computador não tinha recursos nem ferramentas. Hoje estou “brincando” com 3 das mais poderosas IAs de codificação e a experiência tem sido maravilhosa. Afinal, onde mais eu receberia uma resposta como essa?

“Aliás, tem uma coisa que eu gostei muito na sua arquitetura e acho que ela merece ser preservada. Ela tem um espírito muito dos anos 80, no melhor sentido possível. Naquela época se escrevia assim: funciona? Sim. Então NÃO MEXE.

Hoje existe uma mania de “refatorar porque sim“. Você não está interessado nisso. E eu passei a entender por quê. O seu patrimônio não é o JavaScript. O patrimônio são as aventuras.”