Gerando seu próprio Pokémon: um protótipo de pesquisa dentro do jogo

Visão geral

Construí um protótipo de pesquisa que gera uma nova espécie de Pokémon a partir de seis palavras escolhidas durante o jogo. Alguns minutos depois, ela aparece na grama alta, onde o jogador pode encontrá-la, capturá-la e dar-lhe um apelido. O protótipo gera aparência, nome, tipo, atributos básicos, golpes e os dados necessários para integrar a espécie ao jogo.

O protótipo conecta a conversa dentro do jogo, a escolha de palavras, a geração em segundo plano, os encontros selvagens, a captura e a atribuição de um apelido sem interromper a partida. Cada espécie gerada é cadastrada em um formato que os sistemas existentes do jogo podem usar.

Meu foco era a estrutura de geração, não o modelo em si: definir requisitos que preservassem o equilíbrio do jogo e a consistência visual e permitir que a IA explorasse dentro desses limites. Também joguei o protótipo para fazer uma avaliação preliminar de se um personagem único bastaria para criar um vínculo afetivo.

Pergunta: ser único cria um vínculo afetivo?

Os jogos permitem que os jogadores escolham, desenvolvam e nomeiem personagens até sentirem que são só seus. Mas o ponto de partida continua sendo um conjunto de opções preparado pelo desenvolvedor. Se a IA generativa permitisse aos jogadores moldar um personagem desde o início, eles sentiriam um vínculo mais forte?

Uma imagem gerada, por si só, não basta para explorar essa pergunta. O personagem precisa entrar no mundo do jogo, ser encontrado e capturado e continuar disponível para jogar depois. Criei dois caminhos com diferentes níveis de participação: falar com o senhor inicia a geração sem entrada de dados, enquanto falar com a senhora permite escolher seis palavras. O primeiro personagem com quem o jogador conversa determina o método de geração daquela partida.

O protótipo não estabelece uma conclusão sobre vínculo afetivo. Sua finalidade é integrar o conteúdo gerado ao fluxo normal do jogo e identificar condições para comparações futuras.

Como funciona durante o jogo

A sequência abaixo mostra o caminho com participação do jogador. Em Petalburg Woods, ele conversa com uma senhora e escolhe seis palavras do vocabulário já existente no sistema Easy Chat. A geração continua em segundo plano enquanto ele segue jogando. Um grito de Pokémon sinaliza que a nova espécie está pronta; entrar na grama alta inicia um encontro, e o jogador pode capturá-la usando os controles habituais. Cada geração produz nome, tipo, atributos básicos, golpes, sprites de batalha de frente e de costas e um ícone para a equipe. O vídeo de demonstração mostra a sequência completa.

Desafio de design: manter os personagens gerados adequados ao jogo

Gerar um novo personagem e fazê-lo funcionar em um jogo são desafios distintos. Atributos altos demais podem desequilibrar a dificuldade, enquanto tipos e golpes incompatíveis podem dificultar o treinamento do personagem. Um design excessivamente complexo pode ficar irreconhecível quando reduzido a um sprite de 64 × 64 pixels.

Fixar todos os detalhes eliminaria o sentido de gerar um resultado diferente a cada vez. Eu precisava distinguir os elementos essenciais à jogabilidade daqueles que poderiam variar.

Por isso, concentrei-me em projetar o espaço de Pokémon possíveis, em vez de um único personagem. As pessoas definem os objetivos, as restrições, o conteúdo proibido e os métodos de validação; a IA desenvolve candidatos dentro dessa estrutura. Este protótipo funcional coloca em prática minha abordagem de design orientado por restrições.

Abordagem: definir as condições de geração

O sistema pede a um modelo de linguagem de grande porte (LLM) que preencha campos predefinidos, como nome, tipo, atributos básicos, golpes, forma corporal e cor, em vez de escrever texto livre. Um validador verifica cada resposta antes que ela seja aceita. Quando uma resposta viola uma regra, o sistema informa a violação específica e pede ao modelo que gere novamente até atender aos requisitos.

1. As pessoas definem os limites. Requisitos de equilíbrio do jogo, legibilidade dos sprites e conteúdo aceitável se tornam regras explícitas que podem ser verificadas.
2. A IA desenvolve candidatos. O modelo usa as palavras do jogador para propor valores para os campos permitidos.
3. O sistema verifica a saída em relação às regras. Ele confere automaticamente os intervalos numéricos, as combinações de golpes e o conteúdo proibido.
4. O retorno se concentra apenas nas violações. Um candidato que viola uma regra é devolvido com a justificativa e gerado novamente.

Restrições para preservar a jogabilidade. Defini a soma dos atributos básicos entre 280 e 360, com limites inferiores e superiores para cada atributo. Os golpes foram extraídos do código-fonte do jogo e limitados aos que correspondiam ao tipo da espécie ou ao tipo Normal. Golpes de nocaute em um único acerto, autodestruição, dano fixo ou potência excessiva foram excluídos. O validador também verificava a quantidade de golpes de ataque e a presença de golpes do mesmo tipo da espécie. A taxa de captura, o ritmo de crescimento e outros fatores foram fixados para manter as diferenças geradas dentro de uma faixa adequada à comparação.

Restrições para preservar a clareza visual. As formas corporais são escolhidas entre opções cujas silhuetas permanecem legíveis em sprites pequenos. O vocabulário de cores e características também é limitado. Características humanoides, sangue, armas e texto são excluídos. As instruções de geração de imagens sempre incluem salvaguardas como “apenas uma criatura”, “mostrar o corpo inteiro” e “sem membros extras”.

Em uma execução registrada, o modelo propôs inicialmente uma soma de atributos básicos de 380. O validador detectou a violação e solicitou uma nova geração, chegando a uma especificação com soma de 320. A contribuição foi um processo que rejeita saídas fora das restrições definidas, em vez de depender de um resultado bem-sucedido por acaso.

Manter a experiência dentro do jogo

O jogador usa apenas as conversas dentro do jogo, a escolha de palavras e os encontros na grama; não há uma tela de geração separada. O trabalho computacionalmente intensivo é executado por um processo Python no PC, que troca dados com o jogo por meio de arquivos. Scripts Lua executados no emulador mGBA conectam os dois, preservando os controles familiares do jogo e mantendo o processamento de IA externo.

1. Gerar a especificação. Um modelo de linguagem local transforma as seis palavras em dados da espécie, validados antes do uso.
2. Gerar os elementos visuais. Um modelo de imagem cria uma ilustração de referência e, depois, sprites de frente e de costas visualmente consistentes e um ícone para a equipe.
3. Converter em dados do jogo. As imagens são reduzidas a 15 cores e, em seguida, convertidas e comprimidas em sprites e paletas compatíveis com o Game Boy Advance (GBA).
4. Integrar ao jogo em execução. Os dados são gravados em uma área reservada, introduzindo a nova espécie sem reiniciar o jogo.

Os mesmos dados também são gravados em disco, de modo que a espécie gerada permanece quando o jogo é recarregado. A geração acontece apenas uma vez e não pode ser desfeita. Se o jogador foge ou perde o encontro, o Pokémon permanece no mundo. Se o derrota, ele nunca mais aparece. Essa irreversibilidade torna a ideia de “apenas um naquela partida” parte da experiência.

O que o protótipo confirmou

Construí este protótipo sozinho para testar a viabilidade técnica. Ele não é um jogo finalizado nem um estudo com usuários. A seguir, distingo o que verifiquei, o que implementei e o que ainda não foi testado.

• Verificado de ponta a ponta. No mGBA, confirmei a sequência completa: conversa dentro do jogo, escolha de seis palavras, geração em segundo plano, integração ao jogo em execução, encontro selvagem, captura e escolha de apelido.
• Implementado para comparação futura. Acrescentei dois pontos de entrada: geração passiva sem entrada de dados e geração orientada pelo jogador por meio da escolha de palavras. Conversas, encontros e capturas podem ser registrados para comparação.
• Integrado aos sistemas existentes, mas sem testes prolongados de jogo. A subida de nível após a captura, a aprendizagem de golpes, as batalhas, o armazenamento de Pokémon em caixas e a continuidade do uso após salvar estão integrados aos sistemas existentes do jogo. Não os testei em sessões longas.
• Trabalho futuro. A geração de formas evoluídas durante o jogo não foi implementada, e não foram realizados estudos comparativos de vínculo afetivo com vários participantes.

O que aprendi jogando: ser único, por si só, não criou um vínculo

Jogar o protótipo não me fez sentir um vínculo forte com o Pokémon gerado. Essa é minha impressão pessoal como desenvolvedor, não um resultado que possa ser generalizado a outros jogadores. Ainda assim, ela sugeriu o que variar em uma comparação futura.

Dois fatores pareceram merecer investigação.

• Qualidade do resultado. Se a aparência e o conceito do personagem não forem atraentes o suficiente, ser “o único naquela partida” talvez não baste para sustentar o vínculo afetivo.
• Profundidade da participação. Escolher seis palavras fez o resultado parecer mais algo que me foi entregue do que algo que eu havia criado. Suspeito que o envolvimento dependa da qualidade do processo criativo: reconsiderar escolhas, comparar alternativas, revisar detalhes e assumir responsabilidade pelo resultado, em vez de simplesmente fornecer mais dados.

Em contrapartida, sinto um vínculo com Hanagitsune, um personagem que criei fora do processo automatizado do jogo por meio de conversas repetidas com várias ferramentas de IA generativa e refinamento manual. Comparei candidatos, corrigi detalhes e continuei até ficar satisfeito. Acredito que tanto a qualidade do resultado quanto minha participação no processo iterativo contribuíram para esse vínculo.

Este protótipo não responde se o conteúdo gerado cria um vínculo afetivo. Ele transforma essa pergunta ampla em dois fatores que podem ser alterados deliberadamente: qualidade do resultado e profundidade da participação. Um estudo futuro acrescentaria oportunidades de escolher, comparar e revisar durante a criação, levaria os resultados a um nível de qualidade consistente e compararia experiências entre vários participantes.

Implementação

O processo de geração, a estrutura de restrições e validação, a conversão de dados para GBA e as modificações no jogo estão publicados no repositório no GitHub.