Sem LLM, fazer um jogo leva 3 meses; com LLM, 3 dias
(marianogappa.github.io)- Um engenheiro de software com 15 anos de experiência compartilha a experiência de desenvolver em Go um jogo de cartas da infância
- Ao desenvolver Truco sem LLM (modelo de linguagem de grande porte), ele resolveu manualmente todos os problemas, como design de UI e deploy serverless, e levou 3 meses
- Ao criar Escoba, usou LLM para converter código de backend e acelerar muito a implementação, com a maior parte funcionando já no primeiro prompt
- Na parte final, oferece um guia passo a passo para qualquer pessoa criar um jogo, usando um exemplo de Tic-Tac-Toe com backend em Go, conversão para WASM e integração com React
- Porém, o frontend em React e o gerenciamento de estado do jogo baseado em WASM ainda exigiram depuração e implementação manual
Introdução
- Um engenheiro de software com 15 anos de experiência percebeu que nunca havia realmente criado e publicado um jogo
- Decidiu desenvolver em Go um dos jogos de cartas que jogava com os amigos na infância, na Argentina
Truco: 3 meses sem LLM
- Em 18 de junho de 2024, começou a desenvolver o jogo de cartas Truco com backend em Go. O frontend foi escrito com apenas conhecimento mínimo de React
- A implementação da UI foi o maior desafio e, para evitar fornecer um servidor, ele usou TinyGo para transpilar para WASM (WebAssembly) e depois publicou os arquivos estáticos no GitHub Pages
- Como era um período sem LLM, precisou descobrir cada detalhe por conta própria e avançar por tentativa e erro, levando cerca de 3 meses para concluir
- O objetivo não era publicidade nem receita, mas apenas finalizar o jogo, e mesmo 1 ano após o lançamento ele continua sendo jogado regularmente
- Jogar Truco: https://marianogappa.github.io/truco-argentino
- Backend (Golang): https://github.com/marianogappa/truco
- Frontend (React): https://github.com/marianogappa/truco-argentino
Escoba: 3 dias com LLM
- Um ano depois, durante uma visita à Argentina para ver a família, ele ensinou ao sobrinho Escoba, o segundo jogo de cartas mais popular
- Desta vez, usou um LLM (Claude): clonou o backend de Truco, explicou as regras de Escoba no prompt e pediu uma refatoração do código
- Já no primeiro prompt, a implementação ficou quase perfeita, e ele só precisou corrigir manualmente alguns bugs pequenos e adicionar recursos extras
- O frontend ainda exigiu vários dias de implementação e depuração manuais. As limitações do LLM, o nível de habilidade com React e o ambiente incomum de gerenciar o estado do jogo em WASM foram fatores desafiadores
- Jogar Escoba: https://marianogappa.github.io/escoba-de-15
- Backend (Golang): https://github.com/marianogappa/escoba
- Frontend (React): https://github.com/marianogappa/escoba-de-15
Passo a passo: como criar seu próprio jogo
- Ele apresenta um guia prático mínimo e código de exemplo para que qualquer pessoa possa tentar desenvolver seu próprio jogo
- Disponibiliza um repositório de exemplo de Tic-Tac-Toe, que pode ser usado como ponto de partida via fork
Desenvolvimento do backend
- Em backends baseados em turnos, é possível definir as funcionalidades com clareza
- Manter uma estrutura serverless e evitar um modelo em que pessoas jogam entre si é uma escolha realista quando não há servidor comercial disponível
Desenvolvimento do frontend
- O frontend precisa realizar as seguintes tarefas
- Solicitar ao backend a criação de um novo
GameState - Exibir o estado na UI
- Oferecer uma interface para selecionar ações válidas
- Enviar comandos ao backend ao aplicar uma ação
- Fazer uma solicitação ao backend quando for a vez do bot
- Solicitar ao backend a criação de um novo
Conversão do backend para WASM
- Para compilar código Go para WASM, use
GOARCH=wasm GOOS=js go build - Como o tamanho do binário pode ser um problema, ele usa TinyGo para reduzir o tamanho
- Para exportar as funções que serão conectadas ao frontend, ele escreve um ponto de entrada separado em Go (ex.:
main_wasm.go) e faz o tratamento condicional no build - Na função principal, é necessário bloquear com
select {}para evitar que o programa seja encerrado imediatamente
Integração de dados entre backend e frontend
- Structs livres do Go, como
GameState, não podem ser serializadas/desserializadas diretamente no WASM - É necessário trocar todos os dados em formato JSON
- Seguindo a documentação fornecida pelo TinyGo, tanto a entrada quanto a saída são trocadas por serialização JSON
Interface frontend-backend
- No frontend, as funções do backend são chamadas diretamente
- O
GameStateé gerenciado apenas dentro do WASM e o frontend não pode mutá-lo; o backend é sempre a fonte da verdade - Depois de recompilar o WASM, é preciso substituir os arquivos, e ele mostra um exemplo de automação com Makefile
Ambiente de execução do WASM
- Para executar, é necessário incluir
wasm_exec.jsno head e usar esse script para criar a instância e executá-la
Conclusão
- Criar jogos foi uma experiência divertida, e a combinação de Go, WASM e React é uma abordagem que qualquer pessoa pode tentar
- A ajuda do LLM aumentou bastante a produtividade, mas a capacidade de frontend e a experiência de depuração continuam sendo importantes
- Qualquer pessoa pode tentar desenvolver seu próprio jogo com essa estrutura, então vale a pena experimentar
4 comentários
Se o código gerado no React usou
document.getElementById, que LLM será que usaram....Parece quase um título caça-cliques para gerar engajamento..
"Se fizer do zero, 3 meses; se fizer de novo algo parecido, 3 dias"
Acho que o autor original é do tipo que nem sabe muito bem o que faz no dia a dia.
Opiniões do Hacker News
O que gosto neste post é que ele aponta algo que muitos desenvolvedores ignoram. Em desenvolvimento de jogos, programar em si raramente foi o gargalo. Mesmo quem desenvolve sozinho consegue criar mecânicas rapidamente sem IA. As partes realmente difíceis são essas várias camadas invisíveis acima disso, como balancear o game loop, ajustar a dificuldade, produzir assets sem estranheza e dar o polimento necessário para manter o interesse do usuário por mais de 5 minutos. É por isso também que, mesmo depois dos LLMs, a Steam não ficou inundada de jogos excelentes. A tecnologia reduziu uma barreira, mas as barreiras maiores continuam lá. Foi a mesma coisa com a ascensão da Unity nos anos 2010. A engine democratizou o desenvolvimento de jogos, mas o que cresceu de forma explosiva não foi a quantidade de bons jogos, e sim o número de tentativas. Os LLMs no código e os modelos de imagem na arte estão causando o mesmo fenômeno, mas essas ferramentas não conseguem dizer qual jogo é realmente divertido. A pergunta que me interessa é: o que acontece se a IA passar a fazer não só implementação, mas também playtesting? Ou seja, se ela evoluir até o ponto de rodar milhares de loops e dizer quais mecânicas conseguem manter jogadores simulados engajados, seu papel vai além de hack de produtividade e passa a ser o de parceira de design. Ainda não estamos nesse ponto, mas este texto parece um ponto de dado inicial nessa direção
Sobre a opinião de que seria interessante ver um futuro em que a IA não só implementa, mas também faz playtesting, rodando milhares de loops para medir o quanto algo deixa o jogador mais imerso, isso levanta a dúvida de como a IA poderia simular jogadores e por que conseguiria julgar corretamente no que seres humanos reais vão se envolver
Quero contestar a ideia, no exemplo da ascensão da Unity nos anos 2010, de que não houve tantos jogos realmente bons. Na verdade, comparado à era do XBLA, o enorme volume de jogos que temos hoje seria impossível sem ferramentas como Unity, Godot, Gamemaker, Renpy e RPG Maker. Ou seja, houve claramente um salto enorme não só em qualidade, mas também em quantidade
Meu teste decisivo para IA generativa é ela conseguir produzir uma spritesheet completa para um jogo de ação 2D em pixel art. Por exemplo, eu queria pelo menos algo perfeito para o movimento de um tanque ou do protagonista, mas até hoje nunca vi um caso de sucesso
Acho que a observação de que "a IA não pode dizer se o seu jogo é realmente divertido" é o insight central. A IA não consegue vivenciar um jogo do mesmo jeito que um ser humano, nem experimentar qualquer outra coisa como um humano. No máximo, ela consegue fazer alguma previsão a partir de dados de avaliação humana de jogos parecidos. Ou seja, a IA não pode gostar do seu jogo. Essa essência vai definir o papel das pessoas na era da IA. A IA pode escrever documentos ou código de modo até certo ponto parecido com o humano com base em dados passados, mas isso prova que existem integração e experiência significativas que só seres humanos conseguem realizar. Existe um ponto do valor humano que não pode ser substituído; só precisamos olhar para esse valor de outra forma
Esse padrão também vale para áreas além do desenvolvimento de jogos. Como todo mundo espera, há um potencial enorme em coding com agentes, mas por enquanto só algumas tarefas são resolvidas de forma absurdamente rápida, como demos rápidas de webapps ou integração de pequenas bibliotecas, enquanto isso ainda não se aplica bem a software realmente grande. Tanto a forma como os modelos foram treinados quanto nosso know-how de uso ainda são insuficientes. Isso não é surpreendente. Até o git levou 5 anos para ser adotado direito por empresas de elite e mais 5 para se popularizar. No fim, hoje já estamos muito acostumados, mas eu diria que usar LLMs corretamente é ainda mais difícil do que usar git. Se pelo menos houvesse menos exagero do tipo "acabou, tudo foi revolucionado" em cada produto, OSS ou post de blog, talvez isso avançasse mais rápido. Ainda estamos em fase de tentativa e erro e experimentação, e isso leva tempo. Não devemos tirar conclusões cedo demais. Se já estivéssemos na fase em que tudo foi resolvido, no mínimo estaríamos soterrados por software muito melhor; mas por enquanto mal estamos encontrando equilíbrio. Ainda assim, para apenas 1 ou 2 anos desde o surgimento dessa nova tecnologia, já é um resultado bastante impressionante
O LLM teve uma vantagem de 3 meses por se apoiar no código, em usar o jogo anterior como template e, acima de tudo, em toda a experiência e nos erros acumulados durante a implementação manual
No começo achei que seria um título sensacionalista, mas de fato houve algo impressionante na parte em que a pessoa "copiou o backend do Truco, explicou longamente as regras de Escoba ao Claude e fez ele refatorar o código". Fiquei curioso para saber quanto tempo levaria para uma pessoa fazer esse refactor manualmente. Talvez mais de 3 dias, embora talvez não
Outra coisa importante é que esse jogo foi o primeiro jogo do participante. Ou seja, na primeira tentativa você precisa lidar com inúmeras variáveis desconhecidas, mas se começar de novo já com os insights e o know-how obtidos na primeira experiência, provavelmente conseguiria fazer em muito menos de 3 meses mesmo sem LLM
Na prática, eu mesmo já vi que, quando você repete o mesmo projeto duas ou três vezes, algo que levou alguns meses na primeira vez cai para cerca de um terço do tempo nas seguintes
<i>cof cof</i> Já desenvolvi em menos de 24 horas, há exemplos em nordicgamejam.com. Quero dizer que, na época em que não havia LLM, GenAI nem Unity, o melhor que existia era Microsoft XNA e C#. A arte também era, na maior parte, desenho manual feito no Paint. Mesmo assim, todo ano surgiam jogos divertidos em quantidade suficiente, e alguns até ficaram conhecidos do grande público, como Baba is You e Braid. O gargalo não era o código e, pessoalmente, tenho certeza de que o verdadeiro bottleneck era a comunicação entre os membros
Olhando esta sequência de comentários, parece haver muitos textos de gente sem experiência em desenvolvimento de jogos. Na prática, os projetos em que LLM é usado já são de tipos muito presentes nos dados de treino. Por exemplo, são projetos comuns em disciplinas introdutórias de programação, e em países do sul da Europa existem muitos jogos parecidos com o jogo de cartas citado neste blog. No meu primeiro ano de faculdade, sem experiência nenhuma, implementei Moon Patrol em Python do zero; levei 2 ou 3 meses, virando a noite 3 dias por semana. Fazer um jogo de cartas é até mais fácil do que isso. Os LLMs são certamente úteis em alguns pontos, mas exemplos simples assim não são adequados para medir produtividade ou utilidade de LLM para programação
Fiz algo parecido com LLM, olhando de vez em quando ao longo de alguns dias: stacky. No total, devo ter trabalhado de fato uns dois dias. Comecei desenvolvendo do zero e depois fui mexendo em estilo brownfield, sem intenção de levar tão a sério até o fim. Mas, à medida que fui adicionando mais detalhes e funcionalidades, continuavam surgindo ideias novas (super rotation, DAS etc.). Ainda está incompleto, talvez em 10% a 20% do jogo todo. Também roda uma versão WebGL. Mas achei que, se eu tentasse fazer a versão definitiva de Tetris, provavelmente tomaria processo, e eu não tenho dinheiro para a licença, então parei. No fim, o que ganhei foi confiança e experiência. Recentemente vi no HN um link sobre funções paramétricas e também fiz em 1 ou 2 horas o playground graphy. De novo, o tempo vai embora nos detalhes. Se você souber com clareza o que quer, esse tipo de trabalho com LLM pode ser bem prazeroso
Já faço desenvolvimento de jogos como hobby de forma consistente há um bom tempo e concluí vários jogos. Ainda assim, nesta sequência de comentários toda, parece haver pouca experiência real com desenvolvimento de jogos. Não consigo concordar com a afirmação de que programar em jogos é fácil. Pensar em ideias novas ou em mecânicas que variem um gênero é, na verdade, mais fácil, e a parte de implementar isso em código parece muito mais difícil. Por exemplo, é fácil imaginar um Vampire Survivors multiplayer com personalização de BattleMech, mas implementar isso só com LLM é praticamente impossível. Neste caso, estamos falando de regras de um jogo de cartas já totalmente conhecido, então é tão simples quanto um jogo da cobrinha. Não é um ataque ao autor, só quero apontar que muita gente está julgando desenvolvimento sem experiência prática real
Não concordo com a ideia de que programar seja a parte difícil no desenvolvimento de jogos. Claro, pode ser difícil, mas o realmente difícil é ter ideias novas e divertidas. Se você tiver uma boa ideia, dá para quebrá-la em partes pequenas e iterar até conseguir implementar. O verdadeiro obstáculo é decidir o que fazer a partir de uma folha em branco. Fazer uma caminhada, tentar de tudo, esse é um problema repetido há milhares de anos na arte. Já programar acaba sendo uma tarefa de engenharia. Eu mesmo, estudando desenvolvimento de jogos recentemente e junto com isso matemática, achei aprender matemática vetorial ou quaternions muito mais fácil do que decidir "que jogo eu quero fazer?"
Concordo em termos gerais, mas para mim sempre foi bem mais difícil pensar em ideias novas ou fazer tentativas criativas. Consigo programar praticamente qualquer mecânica de jogo, mas a parte de escrita/criatividade é realmente difícil. Se isso é fácil para você, então você é de fato abençoado. Não é algo natural para todo mundo
Se a ideia é fazer um jogo totalmente client-side, fico me perguntando por que se fala em precisar de um "backend" e por que só o backend teria uma tecnologia diferente em vez do app inteiro
Tenho a impressão de que, na indústria de software, quase desapareceram os espaços em que ideias podem ser realizadas de forma fácil e rápida. A concorrência já é tão intensa que, mesmo tentando capturar um mercado minúsculo, você está competindo diretamente com VC global e IA global. Antes, pelo menos, ainda dava para achar nichos que grandes empresas ignoravam. Hoje, seja um grande VC ou um nicho, você de qualquer forma compete com o mundo inteiro, então só sobram mercados pequenos que exigem tecnologia extremamente complexa, ou áreas com baixa rentabilidade, alta chance de fracasso e ciclo de vida curto — e a maioria dos jogos cai justamente aí. No primeiro caso, é preciso um marketing quase de sair batendo de porta em porta para explicar o produto. Pela minha experiência na indústria de jogos, antes mesmo de entrar na fase de desenvolvimento, um caso de grande sucesso já equivale a "conseguir um milhão de views e estar completamente morto seis meses depois". Como quase não há receita recorrente, só começar já é profundamente desmotivador. Fazer um jogo como Minecraft é praticamente ganhar na loteria. Ainda assim, a indústria de jogos é relativamente meritocrática em comparação com outros setores de software. Qualidade e diversão têm alguma relação com adoção. Outros setores são um labirinto de regulação, monopólios por efeito de rede ou controle governamental. Às vezes eu até gostaria que, logo no começo, o governo dissesse "essa área já está dominada por tal empresa, então não abra startup aqui, vá fazer outra coisa", para eu não desperdiçar um ano
Fico me perguntando quando vão perceber que projetos greenfield (totalmente novos) são o pior caso possível para benchmark de habilidade de coding com agentes
Gosto de LLMs porque eles me ajudam a lidar com código de uma forma mais próxima de como abstraio programas na minha cabeça. Quando leio código, entendo quase como se fosse uma AST, convertendo funções e chamadas em nós abstratos de entrada e resultado. Com LLM, ficou absurdamente simples fazer esse caminho inverso e transformar isso em código. Não preciso mais sair caçando exemplos de código compatíveis com a ideia ou puxando da memória; basta mandar o LLM escrever um boilerplate repetitivo, como inicialização de WiFi. No fim, isso me permite montar programas como se estivesse empilhando blocos de Lego. Já era possível trabalhar assim antes dos LLMs, mas exigia muito mais esforço. Graças a isso, hoje estou desenvolvendo com facilidade entre várias linguagens diferentes. Não aprendo muito sobre a estrutura interna ou a sintaxe das linguagens, mas esse é justamente o ponto. Linguagem e sintaxe são detalhes secundários que não têm relação com o fluxo lógico do programa. Assim como evoluímos de código de máquina para assembly, C e linguagens cada vez mais de alto nível, agora estamos nos aproximando cada vez mais não de "codificar", mas de "programar" em si. Ninguém sabe qual será a forma final disso, mas certamente vamos gastar cada vez menos tempo com a "escrita" e mais tempo focando em "programar"