1 pontos por hrjy6278 7 시간 전 | Ainda não há comentários. | Compartilhar no WhatsApp

Olá. Recentemente fiz sozinho um jogo mobile chamado ‘Sumbi’. É um roguelike vertical inspirado no trabalho de mergulho das haenyeo de Jeju. Você entra no mar com uma única respiração, coleta frutos do mar e decide se arrisca pegar mais ou se volta agora.

Comecei o planejamento em 2 de julho, subi a primeira build no Google Play em 9 de julho e, corrigindo continuamente os pontos que me incomodavam ao jogar, em 19 de julho já havia enviado a build v1.1 para produção.

O que me intrigava desde o início não era simplesmente “quão rápido a IA escreve código”. Eu queria testar até onde daria para criar um jogo realmente publicável se eu atribuísse papéis diferentes a vários modelos de IA e os colocasse para funcionar como uma equipe de desenvolvimento.

Que tipo de jogo é esse

‘Sumbi’ vem de ‘sumbisori’, o som parecido com um assobio da respiração que as haenyeo soltam ao subir à superfície depois do mergulho.

Cada partida dura cerca de 10 a 30 segundos. Com uma mão, você move a haenyeo para descer mais fundo ou coletar os frutos do mar ao redor. Para levar tudo o que coletou, é preciso chegar em segurança à superfície, então o jogo faz você ponderar o tempo todo entre se arriscar mais um pouco ou voltar agora. Ao subir, você acerta o valor do que coletou, melhora capacidade pulmonar, nadadeiras, rede de coleta e percepção, e então mergulha de novo.

Incluí um draft roguelike em que você escolhe uma entre três habilidades por rodada, um catálogo com 60 tipos de frutos do mar, equipamentos e árvore de progressão, promoção de rank de haenyeo e o corredor de mergulho que vai até 100 m. Mantive os controles simples, mas fiz com que, quanto mais você repete os mergulhos, mais mudem os recordes e builds que vale a pena buscar.

Não usei a IA como um desenvolvedor faz-tudo

Se um único modelo cuida de tudo, do design à implementação e à própria revisão, fica fácil ele tratar as próprias premissas como se fossem a resposta certa. Por isso dividi os papéis assim.

  • Fable 5: estrutura do jogo e especificação de funcionalidades, metas de balanceamento econômico, definição de critérios de conclusão
  • Opus 4.8: implementação em Flutter·Flame, escrita de testes, depuração
  • Fable 5: nova comparação entre a especificação original e o resultado implementado para verificar omissões e regressões
  • Codex GPT-5.5: revisão independente do código e das alterações, apontando edge cases

A ordem de trabalho era, em geral, planejamento → implementação → revalidação pelo autor do plano original → revisão independente de código → testes automatizados e gameplay real.

Ao fazer isso, percebi que era mais importante definir primeiro critérios de conclusão verificáveis do que escrever prompts bonitos. Em vez de “deixe a sensação de progressão melhor”, defini números: quantas compras acontecem nos primeiros 10 minutos, quanto tempo leva até a primeira promoção, se existe algum trecho da progressão em que o jogador fica muito tempo sem poder comprar nada, e assim por diante. Depois conferi isso com um simulador econômico e testes.

Atualmente há 627 testes automatizados, e todos passam. A análise estática do Flutter também passa sem erros no escopo do código do app, testes e ferramentas.

Casos em que a IA errou de forma convincente

O primeiro design não virou imediatamente um jogo divertido.

Na versão inicial, havia só de 5 a 9 alvos para coletar por partida. Era um jogo de coleta, mas o mar parecia vazio. Joguei eu mesmo e abandonei essa estrutura. Mudei para que o cenário ficasse mais rico conforme o jogador progride, e para que frutos do mar voltassem a crescer nos locais já coletados. Em certas builds de progressão, dá para coletar cerca de 40 itens em uma única partida.

A árvore de progressão foi parecida. Havia 290 nós, mas na prática a jogabilidade era quase linear. A IA cumpriu a exigência de “290 nós”, mas não criou a diversão de escolher entre eles. No fim, separei de novo a estrutura entre três rotas especializadas e nós permanentes.

A IA produziu muito código e muito rápido, mas não conseguiu garantir diversão nem prioridades. Jogar pessoalmente e dizer sem rodeios “isso não está divertido” ou “há muitas funções, mas o próximo objetivo não está claro” ainda continuou sendo papel humano.

Também criei pipelines próprios para imagem e som

Os principais assets visuais, como a personagem haenyeo, frutos do mar, equipamentos e ícones de cartas, foram criados com a API de geração de imagens do GPT. Em vez de usar as spritesheets geradas como estavam, eu as passava por um pipeline de correção com remoção de chroma key, alinhamento de frames, padronização de tamanho e quantização de pixels, e só então validava o resultado. O fundo, as bolhas, os feixes de luz e afins foram desenhados principalmente por código.

No som, em vez de reunir assets externos, sintetizei WAV com código Dart. O sumbisori ouvido no fim de cada mergulho foi tratado como o som central em que o nome do jogo e o fim de uma rodada se encontram.

O que mudou na minha visão depois de fazer isso

Costuma-se dizer que “a IA funciona bem quando você sabe mandar bem”. Desta vez, aprendi ainda mais que “é preciso existir uma estrutura capaz de detectar quando ela erra”.

Separei designer, implementador e revisor, e fiz modelos diferentes examinarem plano e código de forma agressiva. O veredito final ficou a cargo de números, testes e gameplay real. Esse método foi muito mais estável do que manter uma conversa longa com um único modelo e deixá-lo responsável por tudo.

Mesmo com a IA mais rápida, o gargalo do desenvolvimento solo não desapareceu. Em vez disso, o gargalo saiu da codificação e foi para o julgamento. Decidir o que manter e o que descartar, e por que algo ainda não está divertido, foi o que mais tomou tempo.

Google Play
https://play.google.com/store/apps/details?id=com.kinderia.sumbi

Como ainda é um jogo feito sozinho, há muitas partes que podem melhorar. Quero ouvir opiniões sobre se ele está divertido e se o menu de progressão não ficou complexo demais. Se tiver perguntas sobre a forma de desenvolvimento ou a divisão de papéis entre os modelos, fique à vontade para deixar um comentário.

Ainda não há comentários.

Ainda não há comentários.