Transforme a ideia em um teste, não em uma lista de desejos
É possível criar um jogo com IA definindo um ciclo jogável, pedindo uma implementação pequena e verificando o resultado antes de acrescentar mais elementos. Um prompt é uma instrução, não uma prova de que as funcionalidades solicitadas funcionam. Depois da geração, a pergunta útil não é “Isso parece um jogo?”, mas “O jogador consegue executar a ação, alcançar o objetivo, entender como perdeu e reiniciar?”
Este guia reúne um exemplo documentado da SEELE, preservado do artigo original, e uma proposta didática separada. O exemplo tem um link jogável e gravações existentes; a proposta didática não foi gerada nem testada para este texto. Manter essa distinção evita que um processo plausível seja confundido com um caso de sucesso comprovado.
O que o exemplo documentado de sobrevivência a zumbis comprova
O artigo de origem descreve um registro de geração na SEELE de outubro de 2026 que solicitava um jogo de sobrevivência a zumbis em primeira pessoa com Three.js. As funções pedidas incluíam movimentação com bloqueio do ponteiro, armas de fogo, recarga, mira pela alça da arma, agachar, correr, itens coletáveis e um minimapa.
O relato do artigo sobre a gravação do resultado identifica uma arma em primeira pessoa, HUD de vida e munição, minimapa, contador de ondas, inimigos e uma indicação para coletar itens. A gravação de jogo de 21,5 segundos cobre apenas parte da primeira onda. Esses elementos visíveis não comprovam, por si só, recarga ou agachamento funcionais, todas as interações com itens, uma partida completa de cinco ondas ou compatibilidade com outros navegadores. Esses são os limites do exemplo publicado, não o relato de uma nova verificação prática completa.
A imagem documenta o processo orientado por prompt desse projeto específico.
Abrir o projeto jogável existente.
Copie uma proposta menor para o primeiro build
Use o exemplo didático a seguir quando um jogo de tiro tiver sistemas interligados demais para uma primeira tentativa:
Exemplo didático, não um build testado: crie um jogo de navegador de tela única, com visão de cima, chamado Signal Run. O jogador se move com WASD ou as setas, coleta três baterias e chega a uma saída visível. Mostre a contagem de baterias e os controles. Um obstáculo se move horizontalmente entre dois pontos fixos. O contato provoca uma tela de derrota; chegar à saída sem todas as baterias mostra uma mensagem sobre o requisito. Coletar as três e chegar à saída mostra uma tela de vitória. A tecla R reinicia após qualquer um dos resultados e restaura o jogador, as baterias, o contador e o obstáculo. Use formas provisórias fáceis de identificar. Não adicione inimigos, armas, salvamentos, rede, fases extras ou pagamentos. Explique os componentes alterados do projeto e indique verificações para movimento, coleta, vitória, derrota e reinício.
A criação de jogos orientada por prompt da SEELE é pertinente na etapa que transforma a proposta em protótipo. Os controles e o comportamento de reinício solicitados ainda precisam ser validados no resultado real; o texto do prompt não os garante.
Etapa 1: examine o primeiro ciclo jogável
Antes de aprimorar a aparência, execute o build no ambiente pretendido e siga os controles mostrados nele. Verifique o movimento em todas as direções e confirme que não é possível sair da área de jogo. Colete uma bateria e passe novamente pelo local onde ela estava: o contador não deve aumentar duas vezes.
Tente chegar à saída antes da hora e registre a mensagem. Complete o percurso de coleta e confira a vitória. Toque no obstáculo de propósito e confira a derrota. Reinicie após os dois resultados. Se o obstáculo voltar ao estado inicial, mas as baterias não, relate essa diferença exata em vez de pedir à IA apenas para “consertar o jogo”.
Etapa 2: use o caso para criar um registro de verificação
Para cada função, mantenha quatro campos: comportamento solicitado, evidência disponível, comportamento observado e status. No exemplo dos zumbis, um minimapa visível entra no campo de evidências; o rastreamento preciso da posição continua sem comprovação até ser testado. Um pedido de recarga pertence ao campo de especificação até que seja possível registrar a ação de recarregar e a mudança na munição.
Aplique o mesmo rigor ao Signal Run. “Três baterias solicitadas” não equivale a “três itens distintos contados corretamente”. Marque o que for incerto como não verificado, em vez de preencher a lacuna com uma legenda confiante. Esse registro torna o próximo prompt mais específico e oferece aos colaboradores uma descrição confiável do build.
Etapa 3: altere uma regra e execute o ciclo novamente
Depois de salvar uma versão funcional, solicite uma única mudança: reduza em 20% a velocidade de movimento do obstáculo, preservando seu trajeto e todas as regras de coleta. Repita a mesma travessia a partir do mesmo ponto, compare os tempos e teste os dois estados finais outra vez.
Se a movimentação parar de funcionar após uma alteração visual sem relação com ela, volte à versão que funcionava e restrinja o pedido. Forneça o erro exato, o ambiente de destino, o comportamento esperado e a sequência mais curta para reproduzir o problema. Evite acumular reescritas amplas sobre uma falha ainda sem explicação.
Etapa 4: verifique a entrega técnica separadamente
Um link jogável não é a entrega do projeto-fonte. Antes de depender de uma ferramenta para continuar o desenvolvimento, confira as opções de acesso ao projeto e exportação do plano atual. Se o formato desejado estiver disponível, salve uma cópia versionada e faça um inventário do ponto de entrada, dos arquivos-fonte, assets, manifesto de dependências, lockfile e instruções de execução. Pergunte o que foi gerado, o que é uma dependência e o que exige um serviço separado. Não publique credenciais, endpoints privados ou tokens de conta junto com o projeto.
Em uma pasta separada e limpa, siga os comandos documentados de instalação e execução para aquela engine ou framework específico. Registre a versão do ambiente de execução e quaisquer dependências ausentes. Repita os testes de movimento, coleta, vitória, derrota e reinício sem depender do espaço de trabalho hospedado. Se o build local falhar ou a exportação não estiver disponível, registre essa limitação; uma prévia hospedada não supre a falta de evidência. Não foi comprovada a exportação do código-fonte nem a execução local do exemplo de zumbis preservado.
Etapa 5: prepare um compartilhamento limitado e honesto
Antes de compartilhar, verifique o carregamento em um ambiente limpo, a legibilidade dos controles, o áudio se houver, o foco do teclado e o reinício. Consulte os termos atuais da ferramenta e dos assets para o uso pretendido. Teste outro navegador ou dispositivo antes de afirmar que há suporte. Vincule afirmações de desempenho a hardware identificado e a um método registrado, não à aparente fluidez de um vídeo incorporado.
Comece seu próprio protótipo pequeno com a SEELE, usando a proposta acima. Preserve o build funcional, o prompt exato e as anotações de teste antes de pedir novas mudanças. O marco é um ciclo verificado, não uma longa lista de recursos: uma pessoa nova consegue se mover, entender o objetivo, chegar aos dois resultados e reiniciar. Adicione fases e assets mais elaborados somente depois que esse ciclo puder ser demonstrado sem explicações de quem o criou. Se continuar fora do espaço de trabalho for importante para o projeto, trate a entrega do código-fonte e a execução local limpa como critérios de aceitação separados, não como pressupostos sobre a prévia.
Matriz de evidências e aceitação
Esta matriz organiza as verificações propostas no artigo. Ela não é um relato de teste concluído.
| Afirmação ou tarefa | O que a fonte ou proposta estabelece | O que ainda precisa ser verificado |
|---|---|---|
| Exemplo de sobrevivência gravado | O artigo descreve uma gravação curta e identifica elementos visíveis do HUD e inimigos. | Não deduzir o comportamento de uma partida completa nem a compatibilidade com navegadores a partir de um trecho curto. |
| Ciclo jogável | A proposta didática sugere uma ação, um objetivo, uma condição de derrota e reinício. | Executar cada comportamento no build real e registrar o resultado. |
| Revisão | O processo solicita uma mudança delimitada. | Repetir as verificações iniciais após aplicar a mudança. |
| Entrega técnica | A entrega é uma etapa separada do processo. | Examinar os arquivos reais, as instruções de configuração e os usos permitidos. |
Perguntas frequentes
Um vídeo curto de jogo pode provar que o jogo inteiro funciona?
Não. Ele só dá suporte ao que aparece no intervalo gravado. Um HUD pode estar visível sem que todas as regras por trás dele estejam corretas. Use uma lista de funções, entradas reproduzíveis e gravações direcionadas mais longas para comprovar os comportamentos. Mantenha a distinção entre vídeo do processo, prévia da aparência e teste de jogo concluído.
Preciso entender todos os arquivos gerados?
Você precisa entender o suficiente para testar o jogo, proteger versões funcionais e localizar alterações relevantes. Peça ao assistente que explique componentes e pressupostos em linguagem simples. Para comportamentos desconhecidos específicos da engine, consulte a documentação atual dela. Evite aceitar uma reescrita ampla do código apenas porque a explicação parece tecnicamente convincente.
Quando devo substituir a arte provisória?
Depois que o ciclo estiver claro e puder ser repetido. Substitua assets em pequenos grupos e verifique novamente colisão, escala, contraste, carregamento e direitos de uso. Recursos visuais atraentes podem melhorar a comunicação, mas não comprovam uma mecânica não testada. Identifique imagens conceituais com honestidade, em vez de apresentá-las como capturas de um resultado gerado e funcional.
Escolha um fluxo de trabalho para o próximo marco jogável
Use um criador de jogos quando a próxima decisão puder ser testada em um loop jogável no navegador. Se um projeto já tiver um mecanismo, ativos ou uma base de código, teste um assistente em uma alteração limitada nesse ambiente. Mantenha uma lista de verificação de exportação e ativos junto com as notas do teste de jogo para que um resultado jogável e um projeto portátil possam ser avaliados separadamente.
