Escreva o documento de que o próximo build precisa
Um documento de design de jogo deve explicar o que construir, o que deixar de fora e como saber se o protótipo funciona. Para desenvolvimento com ajuda de IA, as seções mais úteis são regras concretas, controles, limites de escopo e verificações de aceitação. Um longo resumo da história não resolve se um item pode ser contado duas vezes ou o que Reiniciar deve restaurar.
Este guia usa um único exemplo didático: Rain Route, um pequeno jogo de entregas com um robô. Seu GDD, prompts, revisão e testes se referem ao mesmo jogo proposto. Não se trata de um projeto realmente gerado nem de uma experiência de usuário relatada. O fluxo mostra como conectar decisões à implementação sem afirmar que o build proposto já existe.
Copie este mini-GDD preenchido
Rain Route, versão de design 0.1.
Conceito: um robô, visto de cima, carrega pacotes de memórias por um quarteirão chuvoso.
Jogador e plataforma: uma pessoa jogando sozinha em navegador de computador com teclado. A meta de uma primeira sessão de cerca de cinco minutos é um objetivo de design, não um resultado medido.
Promessa e pilares: navegação tranquila, destinos legíveis e pequenas escolhas de rota. Priorizar respostas claras em vez de sistemas adicionais.
Ciclo central: pegar um pacote no depósito, caminhar até a porta numerada correspondente, entregá-lo e voltar para buscar o próximo. Concluir três entregas para vencer.
Controles e câmera: câmera fixa vista de cima. WASD ou setas movem o robô. E pega ou entrega dentro da área de interação marcada. R reinicia após a vitória. Mostrar instruções na tela.
Regras: apenas um pacote pode ser carregado. As entregas ocorrem em ordem: portas 1, 2 e depois 3. E na porta errada mostra uma mensagem, mas não remove o pacote. Cada entrega correta aumenta o contador uma vez. Pressionar E repetidamente não pode contar uma entrega já concluída.
Mapa e desafio: um quarteirão, um depósito, três portas, uma travessia por poça e um desvio seco. Dentro da poça, a velocidade de movimento é metade da normal. Sem perda de vida, inimigos ou derrota por tempo.
Feedback: mostrar destino atual, pacote carregado e entregas concluídas. Usar números de porta distintos e uma confirmação visível da entrega. A ambiência de chuva deve ser discreta; oferecer opção de silenciar.
Escopo técnico: um protótipo de navegador, sem contas, salvamentos na nuvem, rede, compras, mapas extras ou sistema de desbloqueio. Recarregar inicia uma nova partida. Usar formas originais simples até o ciclo passar nos testes.
Vitória e reinício: após a terceira entrega, mostrar um painel de vitória. R restaura robô, pacote, destino, contador de entregas e painel de vitória ao estado inicial.
Pergunta de revisão: uma pessoa nova consegue concluir a primeira entrega usando apenas as instruções visíveis?
Etapa 1: transforme o GDD em uma solicitação de construção
Use o documento como entrada, não como prova de implementação. Antes de enviá-lo, verifique contradições entre escopo, controles e condição de vitória. “Recarregar inicia uma nova partida” impede prometer entregas persistentes; “um pacote” impede uma fila oculta de inventário. Resolva essas decisões no GDD em vez de deixar a implementação adivinhar. Um primeiro prompt adequado é:
Construa Rain Route a partir da versão de design 0.1. Primeiro implemente apenas o mapa, o movimento, a retirada no depósito e a entrega na porta 1. Mantenha as portas posteriores visíveis, porém inativas. Mostre o destino atual e se um pacote está sendo carregado. Use formas originais simples. Não adicione efeitos climáticos, desbloqueios, cronômetros de derrota ou mecânicas extras. Explique os componentes alterados e como testar retirada, interação na porta errada, entrega correta e pressionamentos repetidos de E.
Mantenha essa primeira solicitação limitada ao trecho de entrega. O resultado deve permitir inspecionar uma interação completa antes de multiplicar os destinos. Se a rota não puder ser concluída com os controles documentados, corrija o trecho em vez de expandir o mapa.
Etapa 2: ligue requisitos a testes no mesmo jogo
Dê identificadores curtos às regras importantes e mantenha-os no prompt, nas anotações e no registro de teste:
| Requisito | Ação em Rain Route | Resultado esperado |
|---|---|---|
| R1: no máximo um pacote | Pressionar E duas vezes no depósito | Continuar carregando um pacote |
| R2: apenas o destino correto | Visitar a porta 2 com o pacote 1 | Uma mensagem aparece; o pacote permanece |
| R3: entrega contada uma vez | Entregar na porta 1 e pressionar E repetidamente | O contador permanece em um |
| R4: progresso ordenado | Concluir as três entregas | O destino avança 1 → 2 → 3; a vitória aparece uma vez |
| R5: redução de velocidade na poça | Cronometrar a mesma rota marcada dentro e fora da água | A velocidade na poça corresponde à metade especificada |
| R6: reinício completo | Pressionar R após vencer | Posição inicial, mãos vazias, zero entregas, nenhum painel de vitória |
Registre as observações reais em um diário de execução separado, com a versão do build e o ambiente. Só adicione um status como aprovado, reprovado ou bloqueado depois de executar a ação. Se o primeiro trecho falhar em R2, corrija essa interação antes de solicitar três entregas. Descreva a sequência de entradas com precisão suficiente para outra pessoa reproduzir a falha.
Etapa 3: amplie o ciclo e depois adicione atmosfera
Depois que a primeira entrega passar no teste, solicite as portas 2 e 3 e os estados de vitória e reinício. Execute R1 a R4 e R6 novamente. Depois solicite a redução de velocidade na poça e verifique R5 sem alterar a lógica de retirada.
Só depois que essas regras passarem você deve adicionar visuais de chuva e uma ambiência discreta. Verifique se a chuva não encobre números ou marcadores de interação e se a opção de silenciar funciona. Se o efeito climático tornar o mapa ilegível, reduza-o em vez de aceitar atmosfera às custas da promessa documentada ao jogador.
Etapa 4: atualize o GDD quando evidências mudarem uma decisão
Suponha que um teste futuro mostre que jogadores não percebem o destino atual. Aqui isso é uma observação hipotética, não um resultado. Uma revisão pontual pediria um rótulo de destino mais visível, preservando a ordem das portas e as regras de entrega. Teste novamente a mesma pergunta sobre a primeira entrega com uma pessoa nova.
Registre a decisão como versão 0.2, explique por que mudou e vincule-a ao requisito e ao build afetados. Mantenha as decisões anteriores disponíveis para que um resultado antigo não seja confundido com evidência sobre uma regra nova. Um requisito revisado deve identificar quais verificações anteriores precisam ser executadas novamente.
Quando uma alteração gerada quebrar um requisito anterior, reverta-a ou isole-a. Relate o requisito que falhou, a entrada exata, o resultado esperado e o real. “R3 conta duas vezes após pressionar E repetidamente” é mais acionável do que “o protótipo parece ter bugs”.
Use o SEELE entre a especificação e o diário de teste
O SEELE oferece criação de jogos em linguagem natural e alterações iterativas em jogabilidade, cenas e recursos. Forneça o mini-GDD como entrada de design e solicite um trecho limitado de implementação. O resultado útil é um build candidato que pode ser comparado ao mesmo documento, não um substituto para decisões de design nem um registro de teste concluído.
Em cada solicitação posterior, nomeie o requisito que mudou e os que devem permanecer estáveis. Pedir um rótulo de destino mais claro não deve introduzir silenciosamente um cronômetro ou mudar a ordem das portas. Mantenha documento, prompt e resultado observado vinculados por versão para que uma descrição bem escrita nunca substitua o comportamento real.
Use o GDD para iniciar, não adiar, a construção
Um GDD útil encurta a distância entre uma decisão e uma verificação. Rain Route precisa de uma regra clara de retirada, ordem de destinos e definição de reinício antes de precisar de um resumo mais longo da história. Mantenha o documento pequeno, mas torne as regras precisas o suficiente para que outra pessoa possa avaliar o mesmo build.
Copie a especificação para o SEELE e solicite o primeiro trecho de entrega. Mantenha documento, build funcional e diário de teste alinhados por versão. Amplie o escopo apenas quando as regras existentes do mesmo jogo resistirem à implementação e à revisão, e atualize o GDD quando evidências mudarem uma decisão.
Rastreie o design até uma verificação jogável
Esta tabela organiza as verificações propostas no artigo. Ela não é um relatório de teste concluído.
| Elemento do GDD | Pergunta que responde | Exemplo de verificação de aceitação |
|---|---|---|
| Jogador e entrada | Quem joga e como age? | Uma pessoa no computador consegue mover o robô com os controles de teclado especificados. |
| Objetivo e escopo | O que deve acontecer nesta versão? | O jogador consegue entregar o pacote especificado na cena definida. |
| Regras e limites | O que acontece quando uma regra é acionada? | Uma entrega ou retirada é contada somente como o design especifica. |
| Falha e recuperação | O que acontece quando o jogador não consegue concluir a tarefa? | O comportamento informado de falha ou reinício retorna o jogo ao estado documentado. |
| Registro de revisões | Qual decisão mudou e por quê? | Registre a observação, a regra alterada e o resultado da nova verificação. |
Perguntas frequentes
Qual deve ser o tamanho de um GDD de protótipo?
O menor possível, desde que resolva as próximas decisões de implementação. O exemplo preenchido especifica escopo, controles, regras e testes sem uma bíblia de produção. Acrescente seções quando elas mudarem o que alguém constrói ou verifica. Uma regra de interação ausente custa mais do que uma página de história de fundo que falta.
A IA pode escrever o documento por mim?
A IA pode redigir seções e revelar ambiguidades, mas você precisa decidir as regras e verificar a viabilidade. Peça que ela identifique requisitos conflitantes e critérios de aceitação ausentes. Não trate um documento bem escrito como validação da diversão, da qualidade da implementação, dos direitos sobre recursos ou de capacidades do produto que não foram verificadas.
Qual é a diferença entre o GDD e o diário de teste?
O GDD declara o comportamento pretendido e as decisões. O diário de teste registra o que aconteceu em um build e ambiente específicos. Mantenha-os conectados, mas separados: uma expectativa de aprovação não é um teste aprovado. Quando observações justificarem alterar uma regra, atualize o design explicitamente e execute novamente as verificações afetadas.
Uma lista de verificação de capítulo para um GDD maior
Adicione seções somente quando elas orientarem uma decisão para a próxima construção. Comece com o público, a plataforma e o argumento de venda de uma frase. Siga com o loop principal, controles, progressão, mundo ou narrativa, restrições de arte e som e requisitos técnicos. Para cada recurso no escopo, indique seu proprietário, a menor prova jogável e um teste que a equipe pode executar novamente. Mova ideias opcionais para uma lista de pendências separada.
