LLM controla o herói de um RPG online: Gemini dá conta de apenas 1 em cada 10 passos do jogo

A maioria dos projetos de jogos com LLM acaba em conversas: a rede neural faz o papel de um NPC e responde a falas. O autor deste experimento foi além e entregou ao modelo o controle de um personagem em um RPG em rede. A diferença é fundamental: pode-se dizer qualquer coisa, mas só se pode fazer o que as regras do mundo permitem.

Como funciona

O jogo é assíncrono: o servidor não espera o jogador, e outros personagens e goblins correm por perto. Por isso o cliente é construído sobre três threads. A primeira recebe linhas do servidor e as converte em uma estrutura. A segunda envia uma requisição ao LLM e aguarda a resposta. A terceira retransmite a imagem para um navegador, para que uma pessoa possa acompanhar o que acontece.

O prompt é montado em tempo real a partir de observações: o que o personagem vê e ouve, o que tem no inventário, quais recursos são necessários para o objetivo e quais ações estão disponíveis no momento. No início, é enviado um MASTER-PROMPT estático com as regras do jogo e as receitas de fabricação. Depois, cada resposta é ligada à requisição seguinte por meio de um identificador, como a continuação de um diálogo.

O formato da resposta é definido por um esquema response_format. O autor comparou duas abordagens: campos numéricos com uma probabilidade para cada ação e um único campo action com um enum. Não encontrou diferença perceptível na qualidade e escolheu o enum, porque é mais fácil de analisar. Além disso, o modelo devolve um objetivo, planos, pensamentos e uma fala opcional.

Onde tudo esbarra nos limites

No plano gratuito, os modelos lite podem fazer uma requisição a cada 4 segundos. O passo do servidor é de 0,45 s, então, na melhor das hipóteses, o LLM vê um em cada dez passos. O limite diário é de 500 requisições, depois das quais é preciso trocar de modelo. Há também um limite pouco óbvio: a cadeia de respostas se rompe com um erro de profundidade máxima após cerca de 100 iterações. Possivelmente, isso depende do preenchimento do contexto.

A memória do agente teve de ser construída à mão: uma memória por células de objetos importantes, uma memória de eventos e uma memória de ações passadas. À parte, surgiu uma memória de escassez. O modelo "coloca na fundição", com toda a confiança, itens que não possui. Quando o parser percebe a inconsistência, o item que falta é registrado e as ações que o contradizem são filtradas.

O que resultou

O agente anda, coleta itens, constrói edifícios e, às vezes, funde metal. Certa vez, fundiu uma ponta de picareta, uma das receitas mais complexas, embora tenha encontrado parte dos ingredientes no cadáver de um anão. Suas falas são bastante coerentes: ele comenta as próprias ações e tenta conversar com NPCs.

Mas o comportamento não pode ser chamado de inteligente. O agente cai em loops mortos: fabrica coisas desnecessárias, gira no mesmo lugar e fica preso em trocas. Ele pode ignorar a dica "à direita há uma parede com os minerais necessários" e passar direto. O único negócio bem-sucedido com um anão acabou sendo prejudicial: ele trocou todo o seu estanho por minério de cobre, carvão e argila, ou seja, o raro pelo comum.

Conclusão prática

Primeiro, a velocidade é decisiva. Se a resposta chegasse em meio segundo, o jogo poderia rodar de forma síncrona sem perder passos. O autor pensa em um pequeno modelo local. Segundo, uma lista de coordenadas em texto funciona mal como descrição espacial. Terceiro, a conclusão mais sensata é esta: vale confiar ao LLM as decisões de alto nível e a fala, por exemplo "vá até a forja", e deixar o trajeto e a execução para algoritmos clássicos.

É o mesmo padrão dos agentes de produto: o modelo planeja, o código determinístico executa e verifica. A limitação do experimento é que se trata de um único protótipo ingênuo, sem métricas, mas o conjunto de armadilhas com limites, loops e memória será familiar a qualquer pessoa que construa agentes.