huayuehua15-netizen/aaa-game-gdd

Skill de Documento de Design de Jogo (GDD) Nível AAA

Convenção de caminho: todos os caminhos scripts/, references/, assets/ neste arquivo são relativos ao diretório onde este SKILL.md está localizado. Antes de executar python scripts/new_gdd.py, localize esse diretório (no Cursor/Codex, o install.ps1 o coloca em <projeto>/skills/game-dev/aaa-game-gdd/). Se não tiver certeza, encontre o caminho absoluto deste SKILL.md e use-o para chamar o script; usar caminhos relativos a partir da raiz do projeto resultará em erro 'arquivo não encontrado'.

O que este skill faz

Transformar "Tenho uma ideia de jogo" em um conjunto completo de documentos com os quais a equipe pode desenvolver diretamente um jogo pronto para publicação na Steam, com qualidade AAA. A entrega principal é um conjunto estruturado, quantificável e auditável de documentos Markdown em chinês (GDD), não um documento de design genérico.

Cada documento produzido deve obedecer a três regras de ferro:

1. Pronto para desenvolvimento: o desenvolvedor, ao receber o documento, não precisa perguntar "o que exatamente fazer, qual o tamanho, qual o padrão". Tudo que pode ser quantificado deve ter valores definidos (número de polígonos, quadros, duração, resolução, frequência, latência, condições de disparo).
2. Auditável: cada asset, sistema e cenário possui uma lista de verificação de Definition of Done (Definição de Pronto), que pode ser verificada item por item após a conclusão.
3. Consistente: todos os documentos compartilham os mesmos pilares de visão, bíblia de arte, convenções de nomenclatura e orçamento de performance; os documentos referenciam-se mutuamente por números e é proibida qualquer contradição.

Mapa de Documentos (references lidas sob demanda)

Não leia todos os documentos de referência de uma vez. Primeiro, identifique na tabela abaixo qual tipo de documento o usuário precisa e leia apenas o correspondente. Cada reference tem a estrutura: problema que resolve → quando escrever → estrutura de seções → como escrever cada seção (com padrões quantificáveis) → exemplos bons e ruins → lista de verificação de conclusão.

Documento	Quando ler esta reference	Template correspondente (assets/templates)
00 Visão Geral do Sistema de Documentos	Novo projeto, precisa definir lista de documentos e cronograma de fases	README.md
01 Visão e Pitch	Projeto recém-idealizado, precisa de uma página para explicar o jogo e apresentá-lo externamente	01-vision-pitch.md
02 Bíblia de Arte	Definir estilo artístico, unificar a estética da equipe, criar briefings de arte	02-art-bible.md
03 Cenários e Fases	Escrever descrições de cenários, fluxo de fases, movimentação, encontros, narrativa ambiental	03-scene-level.md , scene-sheet.md , level-sheet.md
04 Sistemas de Jogabilidade	Projetar loop principal, combate, progressão, economia, tabelas numéricas	04-gameplay-systems.md , system-sheet.md
05 Narrativa e Diálogos	Escrever esboço da história, beats de capítulo, ramificações, scripts de diálogo, dublagem	05-narrative-dialogue.md , dialogue-sheet.md
06 Interação e UI/UX	Definir controles, matriz de interação, sensação do jogo, HUD, menus, acessibilidade	06-interaction-uiux.md
07 Especificação de Personagens	Definição, aparência, conjunto de animações, IA, valores de personagens (protagonista/inimigo/NPC)	07-character-spec.md , character-sheet.md
08 Especificação de Modelagem de Itens	Modelagem, texturas, LOD, nomenclatura e entrega de itens/armas/assets ambientais	08-prop-modeling.md , prop-sheet.md
09 Especificação de Animação	Animação 3D esquelética, máquina de estados de animação, cutscenes, animação 2D por sprites	09-animation-spec.md , animation-sheet.md
10 Design de Áudio	Música, efeitos sonoros, dublagem, música dinâmica, loudness do bus	10-audio-spec.md
11 Tecnologia e Performance	Escolha do motor gráfico, pipeline de renderização, orçamento de FPS/memória/tamanho do pacote, plataformas	11-tech-performance.md
12 Qualidade AAA e Lançamento na Steam	Portões de fase, plano de QA, loja Steam e checklist de lançamento, pontuação comparativa AAA	12-steam-qa-checklist.md

Fluxo de Trabalho

Fluxo A: Novo Projeto (da ideia ao sistema completo de documentos)

1. Esclarecer informações mínimas necessárias (faça todas as perguntas de uma só vez, no máximo 4): tipo de jogo e mecânica central em uma frase; motor (Unity/Unreal/Godot/indefinido); plataforma e FPS alvo (PC 60fps? Steam Deck?); tendência de estilo artístico. Depois de perguntar, já pode começar; não pergunte repetidamente para obter informações completas. Itens desconhecidos devem ser marcados explicitamente com 【A CONFIRMAR】.
2. Executar scaffolding: python scripts/new_gdd.py init --name "Nome do Jogo" --out <diretório de saída> --engine <motor definido na etapa 1> para gerar a árvore completa de documentos GDD. --engine deve usar a resposta da etapa 1, não preencher com unity por padrão – isso realmente determinará os eixos, nomenclatura de colisão, navegação e especificações de data assets nos documentos.
3. Escrever documentos por ordem de fase (veja "Portões de Fase" abaixo). Leia a reference correspondente antes de preencher o template. Ordem: 01 Visão → 02 Bíblia de Arte + 11 Orçamento Técnico → 04 Sistema Principal → 07/08/09/06 Especificações → 03/05 Conteúdo → 12 Validação.
4. Para cada cenário/personagem/item/animação/diálogo/sistema, use scripts/new_gdd.py sheet para gerar uma página de documento independente, colocada no subdiretório correspondente do GDD. O documento principal contém apenas um índice; não coloque centenas de assets em um único arquivo.
5. Passar pelos portões de qualidade: ao final de cada fase, use a tabela de portões em 12-steam-qa-checklist.md para verificar item por item. Não prossiga para a próxima fase sem aprovação.

Fluxo B: Documento Único (usuário precisa apenas de um tipo de documento)

Confirmar o objeto e o propósito → ler a reference correspondente → copiar o template correspondente e preencher → usar a "Definição de Pronto" ao final do template para autoavaliação → entregar. Quando o usuário disser apenas "me ajude a escrever um cenário", primeiro pergunte o nome do cenário, sua posição no fluxo e o evento central (de uma só vez) e, em seguida, produza diretamente uma scene-sheet completa; não entregue apenas um template vazio.

Cenário vs. Fase: por padrão, produza apenas o que o usuário pediu. A references/03 diz "cenário é espaço, fase é tempo, escreva separadamente", referindo-se à divisão de trabalho quando ambos são necessários, não uma exigência de que cada solicitação de cenário venha acompanhada de uma página de fase.

A divisão é rígida:

• Página de Cenário (SC_) = O que este espaço oferece: terreno, linha de visão, cobertura, diferença de altura, rotas de fuga, pontos de esconderijo, restrições espaciais para inimigos (§7), e zonas de disparo TZ_ (§4).
• Página de Fase (LV_) = Em que ordem o jogador experimenta o quê: tabela de beats (incluindo números de evento EV_), ritmo, consequências do encontro, checkpoints.

Portanto:

• Usuário quer apenas cenário → escreva apenas scene-sheet.md , sem ordem; se realmente não houver página de fase, adicione uma linha em §7 "Ordem de Experiência (resumo)".
• Usuário quer fluxo de fase, ou cenário com múltiplos ritmos → aí sim produza level-sheet.md , com TZ_ ↔ EV_ referenciando-se mutuamente.
• Não produza dois documentos por conta própria só porque 03 diz "escreva separadamente" – isso inflaria uma solicitação simples em 2-3x.

Leia exemplos antes de preencher – cada tipo de página independente tem um exemplo completo. Leia o correspondente ao tipo que você vai escrever:

Tipo de Página	Exemplo	O que mais consultar
Cenário (linear/terror)	assets/examples/SC_01_CorredorSegundoAndarCirurgia_Exemplo.md	§7 Oferta espacial = Oclusão de visão e "ver antes de tocar"; §10 Ênfase em percepção e ritmo
Cenário (aberto/BOSS)	assets/examples/SC_07_MirantePonteQuebrada_Exemplo.md	§7 Oferta espacial = Distância ajustável / interrupção de visão / risco calculado; §10 Ênfase em resolubilidade de combate
Fase	assets/examples/LV_01_PrimeiroEncontroCorredor_Exemplo.md	Como a tabela de beats se alinha com TZ_ ; como a curva de dificuldade e os pontos de tutorial são inseridos sem pop-ups
Personagem (inimigo)	assets/examples/EN_01_Costureiro_Exemplo.md	§6 Por que escrever "consegue fugir" para máquina de estados + diferença de velocidade; §7 Como calcular duração do combate
Item	assets/examples/PR_017_CadeiraDeRodasQuebrada_Exemplo.md	§5 Valores de especificação técnica; §7 Como escrever "intencionalmente não feito" no DoD
Animação	assets/examples/AN_EN01_Slash_01_Exemplo.md	§2 Intervalo de quadros em três partes; §3 Marcos de evento (som de aviso é o mínimo para justiça)
Diálogo/Cutscene	assets/examples/DL_07_GravacaoEnfermeiraChefe_Exemplo.md	Como definir ID de fala/duração/conformidade de legenda/interrupção e retomada
Sistema	assets/examples/SYS_04_AgarraESolta_Exemplo.md	§4 Tabela de parâmetros deve incluir "intenção de design"; §5 Não pode faltar nenhum caso de borda

Todos os exemplos devem ter esse nível de granularidade (cada item com números específicos, IDs, conteúdo delegável). Nota: os itens marcáveis nos exemplos são registros de verificação após a conclusão (incluindo contagem real de polígonos, data de revisão, decisões de design descartadas), não o formato de preenchimento antes do início; na fase v0.1, deixe em branco o que deve ficar em branco, não invente números que pareçam reais. A seção §10 Riscos de Design e Hipóteses a Validar é a única onde é permitido (e deve) não ter números.

Fluxo C: Revisão de Documentos/Ideias Existentes

Use a "Tabela de Pontuação 3D Dez Dimensões" em 12-steam-qa-checklist.md para pontuar cada dimensão (1-10, com evidências), listar os problemas críticos que bloqueiam o lançamento, a lista de documentos faltantes e sugestões de modificação ordenadas por severidade. A pontuação deve citar o texto original do documento ou itens faltantes; avaliações genéricas são proibidas.

Portões de Fase (Stage Gates)

Fase	Documentos Obrigatórios	Portão (não passa sem aprovação)
Conceito	01 Visão, 04 Esqueleto do Sistema Principal	A diversão central tem validação em papel/protótipo greybox; os 3 pilares principais são aprovados por todos
Vertical Slice	02, 06, 11 + pelo menos 1 página de amostra de cada tipo (cenário/personagem/item/animação/diálogo)	Fluxo de 10-15 minutos atinge qualidade final esperada; todos os sistemas principais funcionam; orçamento de performance é atingido
Produção	Todos os documentos principais + todas as páginas de assets individuais	Cada página de asset pode ser diretamente delegada; capacidade de produção e marcos podem ser agendados
Alpha	Todo o conteúdo	Feature Complete: pode ser zerado do início ao fim, sem sistemas placeholder
Beta	Acima + 12 Tabela de Validação	Content Complete; zero bugs de nível S/A; zerar o jogo completo ×3 configurações diferentes
RC/Lançamento	Todos os itens da lista Steam em 12 marcados como concluídos	Página da loja, validação Steam Deck, localização, classificação indicativa, compatibilidade de saves, tudo aprovado

Script de Scaffolding

# Inicializar árvore completa de documentos GDD (cria <NomeDoJogo>_GDD/ no diretório de saída)
python scripts/new_gdd.py init --name "Nome do Jogo" --out "D:/MeuJogo" --engine unity
#   --engine: unity | unreal | godot | agnostic (padrão)
#             ★ Isto não é decorativo: a escolha realmente define o formato de intercâmbio, eixos, nomenclatura de colisão, navegação, data assets e especificações de LOD no motor
#   --genre: opcional, descrição do tipo de jogo, será inserida no documento de visão
#   --dimension: 3d (padrão) | 2d (cria subdiretórios adicionais sprites/ tilesets/)

# Gerar página de documento para um objeto individual (coloca automaticamente no subdiretório correspondente)
python scripts/new_gdd.py sheet --type scene --name "Hospital Abandonado" --out "D:/MeuJogo/NomeDoJogo_GDD"
#   --type: scene | level | character | prop | animation | dialogue | system | sprite | tileset
#   --subtype: character usa player/enemy/npc (CH/EN/NPC); prop usa item/weapon (PR/WP)
#   Exemplo: sheet --type character --subtype enemy --name "Costureiro" → characters/EN_01_Costureiro.md
#   Exemplo: sheet --type sprite --name "HeroIdle" → sprites/SPR_01_HeroIdle.md

init também suporta --dimension 2d: cria subdiretórios adicionais sprites/, tilesets/ (para projetos 2D).

O script substitui automaticamente os placeholders {{GAME_NAME}}, {{DATE}}, {{ENGINE}}. Se o script não estiver disponível, copie manualmente os templates de assets/templates/.

Normas Gerais de Escrita

• Cabeçalho do documento: todo documento deve começar com: número do documento, versão, status (rascunho/em revisão/bloqueado), data da última atualização, responsável, números de documentos relacionados. Páginas de assets individuais também devem incluir o nome do recurso no motor (ex.: SM_Prop_HospitalWheelchair_01).
• Priorizar quantificação: proibido usar descrições não auditáveis como "jogabilidade boa", "gráficos bonitos", "inimigo forte". Em vez disso, escreva "do pressionar do botão de ataque até a ativação do dano: 8 quadros (0,13s a 60fps)" e "HP do inimigo: 120, DPS do jogador com upgrade máximo: 45, duração esperada do combate: 35-45s".
• Se não souber, marque: valores desconhecidos devem ser escritos como 【A CONFIRMAR: motivo/responsável/prazo】. Proibido inventar números e fingir que estão definidos. Valores de referência da indústria podem ser usados diretamente, mas devem ser anotados como "valor padrão da indústria, ajustar após primeiro teste".
• Exigências de imagem: cenários, fases e UI devem ser acompanhados de diagramas de layout (plantas ASCII, fluxogramas/ diagramas de estado em Mermaid, ou referência a números de concept art). Máquinas de estado, árvores de diálogo e fluxos de menu devem ser desenhados com Mermaid. Parâmetros e listas devem ser apresentados em tabelas.
• Todo documento deve ter DoD (Definition of Done): ao final, anexe uma lista de verificação de conclusão (com - [ ] para marcar). Esta é a única base para aceitação da entrega.
• Idioma: texto principal em português (ou chinês, conforme original); nomes próprios, APIs do motor e nomes de recursos devem permanecer em inglês. Scripts de diálogo devem ter campos reservados para inglês/outros idiomas.
• Modificações de documento controladas por versão: alterações em documentos bloqueados devem ser registradas no histórico de alterações ao final, com versão, data e descrição da mudança.

Requisitos de Entrega

• A entrega consiste em arquivos Markdown no diretório do projeto do usuário (diretório do scaffolding + documentos preenchidos), não em um resumo dentro do chat.
• Após cada entrega, informe ao usuário: qual documento deve ser escrito a seguir, e quais 【A CONFIRMAR】 precisam de sua decisão.
• O padrão de qualidade de um documento é: "um artista/programador terceirizado recém-contratado, lendo apenas a página individual correspondente, consegue produzir um asset de qualidade aceitável de forma independente".