Do conceito ao jogo completo: documentação, design e produção
Esta página fica fora da sequência das aulas e pode ser lida a qualquer momento do Módulo 2. Ela não ensina uma API nova: trata do que acontece em volta do código quando se quer terminar um jogo — decidir o que o jogo é, registrar essas decisões, planejar, testar com pessoas e ajustar. Os exemplos usam Drone Gate, o jogo construído na Aula 11; ler a Aula 11 antes ajuda, mas não é obrigatório.
Objetivos
Ao final desta leitura você deve ser capaz de:
- Descrever as fases do ciclo de vida de um jogo e o que cada marco (protótipo, vertical slice, alfa, beta) precisa demonstrar.
- Formular a fantasia do jogador, os pilares de design e o core loop de um jogo e usá-los para aceitar ou recusar uma funcionalidade.
- Analisar um jogo com o modelo MDA, separando mecânicas, dinâmicas e estéticas.
- Distinguir one-pager, GDD e TDD quanto a público, conteúdo e momento de uso, e redigir um one-pager.
- Especificar uma mecânica com números verificáveis, em vez de adjetivos.
- Delimitar o escopo de um projeto com MoSCoW e planejar protótipos que respondam a uma pergunta por vez.
- Organizar o trabalho em backlog, marcos e definição de pronto, e configurar um repositório Git adequado a um projeto Unity.
- Conduzir um playtest sem interferir no jogador e transformar observações em mudanças de projeto.
- Calibrar a dificuldade com uma planilha de balanceamento e relacioná-la ao canal de fluxo.
- Aplicar princípios de game feel, onboarding e acessibilidade e redigir um postmortem.
Conteúdo
Por que planejar um jogo que ainda nem existe
Um jogo pequeno cabe na cabeça de uma pessoa. Um jogo que precisa ser terminado por duas pessoas, em poucas semanas, com arte, som, interface e regras que se afetam mutuamente, já não cabe. Três problemas aparecem cedo:
- Cada pessoa imagina um jogo diferente. “Um jogo de nave com bateria” pode ser um arcade de reflexo ou um quebra-cabeça de economia de recursos. Enquanto a ideia não é escrita, a divergência não aparece.
- Funcionalidades crescem sem parar. Cada ideia nova parece pequena; a soma delas é o motivo mais comum para um projeto não terminar — o chamado feature creep.
- Ninguém sabe se o jogo é bom até alguém jogá-lo. O autor sabe onde estão os perigos e o que cada barra significa. O jogador não sabe.
As práticas desta página atacam esses três problemas. Nenhuma delas é burocracia obrigatória: a indústria usa desde documentos de centenas de páginas até uma única folha, e cada equipe adapta o formato ao próprio tamanho. A regra que atravessa todas é a mesma: escrever o mínimo que mantém a equipe alinhada e testar o quanto antes.
O ciclo de vida de um jogo
A produção de um jogo costuma ser dividida em fases, separadas por marcos (milestones). Cada marco é uma pergunta que precisa ter resposta antes de seguir. A Figura 1 mostra a sequência usual; nomes e fronteiras variam entre empresas.
| Fase / marco | Pergunta que precisa responder | Critério de saída típico |
|---|---|---|
| Conceito | Vale a pena fazer este jogo? | One-pager aprovado pela equipe |
| Protótipo | A mecânica central é divertida? | Alguém de fora joga por alguns minutos sem explicação e quer repetir |
| Vertical slice | Sabemos produzir o jogo com a qualidade final? | Um trecho curto com arte, som, interface e regras no nível do produto final |
| Alfa | O jogo está completo? | Todas as funcionalidades existem e podem ser jogadas do início ao fim, ainda com defeitos |
| Beta | O jogo está estável? | Nenhuma funcionalidade nova entra; só correções, balanceamento e polimento |
| Lançamento (gold) | Podemos entregar? | Build final gerada, testada na plataforma-alvo e registrada |
Duas regras práticas saem dessa tabela. Primeiro, o protótipo vem antes do documento longo: não adianta detalhar 30 inimigos de um jogo cuja mecânica central ainda não foi testada. Segundo, depois do alfa não entram funcionalidades novas — o tempo restante é de quem corrige e ajusta, e é nele que o jogo fica bom.
Antes do documento: o que é o seu jogo?
Documentar exige ter decidido algumas coisas. Quatro ferramentas conceituais ajudam a decidir — e todas cabem em poucas linhas.
Fantasia do jogador e pilares de design
A fantasia do jogador é a experiência prometida, em uma frase, do ponto de vista de quem joga: não “um jogo de drone com portais”, mas “pilotar no limite da bateria, onde cada toque é uma decisão”.
Os pilares de design são de três a cinco princípios que derivam dessa fantasia e servem de filtro: toda funcionalidade proposta precisa reforçar ao menos um pilar e não contradizer nenhum. Um pilar útil é específico o bastante para recusar ideias; “ser divertido” não recusa nada.
Os pilares de Drone Gate, reconstruídos a partir das decisões da Aula 11:
| Pilar | O que significa | O que ele recusa |
|---|---|---|
| Um botão, uma decisão | todo o jogo se controla com um único comando; a profundidade está em quando apertar | controles extras, como tiro ou movimento horizontal |
| Cada toque tem custo | a bateria transforma ritmo em economia: rajadas gastam o dobro de um toque por arco | recarga automática com o tempo |
| Falhar custa pouco | a partida dura segundos e recomeça com um comando, sem menus | vidas, checkpoints e telas de carregamento |
O último pilar tem história: checkpoints chegaram a ser testados no projeto e foram descartados porque, num corredor infinito de obstáculos sorteados, o progresso é o placar. É exatamente o tipo de decisão que um pilar escrito torna rápida e explicável.
Core loop: o que o jogador faz repetidamente
O core loop (laço central) é a sequência curta de ações que o jogador repete durante quase todo o tempo de jogo. Se ele não for bom sozinho, nada em volta o salva. Em volta dele há laços mais longos — o meta loop —, que dão motivo para voltar: recorde, desbloqueios, progressão.
Não confunda com o laço de jogo da Aula 10 (entrada → atualização → desenho): aquele é um laço do programa, que roda dezenas de vezes por segundo; o core loop é um laço do jogador, que dura alguns segundos. A Figura 2 mostra os dois laços de jogador de Drone Gate.
Escrever o core loop revela lacunas. Em Drone Gate, a seta “Recompensa” tem duas partes, ponto e carga. Se a interface mostrasse só o placar, a segunda recompensa ficaria invisível e o jogador não entenderia por que o drone deixou de responder. Por isso a barra de bateria faz parte do laço, e não é enfeite: toda recompensa do core loop precisa ser percebida.
Mecânicas, dinâmicas e estéticas (MDA)
O modelo MDA (Hunicke, LeBlanc e Zubek, 2004) separa um jogo em três camadas:
- Mecânicas — as regras e os dados, como estão no código: gravidade, impulso, custo por toque, colliders.
- Dinâmicas — o comportamento que emerge quando as mecânicas encontram um jogador: ritmo de toques, estratégias, erros típicos.
- Estéticas — as respostas emocionais desejadas: desafio, tensão, domínio.
O ponto central do modelo é a assimetria de perspectiva: o designer só controla as mecânicas diretamente e chega às estéticas por meio das dinâmicas; o jogador percorre o caminho inverso, sente a estética primeiro e raramente enxerga a regra. Por isso uma mudança de regra precisa ser testada com gente jogando — só assim se vê a dinâmica que ela produz.
| Camada | Em Drone Gate |
|---|---|
| Mecânica | impulso zera a velocidade vertical e a deixa em 5,5 u/s; gravidade de 9,81 × 1,5; cada impulso gasta 1 de 10 cargas; cada portal devolve 4 |
| Dinâmica | tocar uma vez por arco, no fim da queda, gasta cerca de 3,2 cargas por portal; rajadas gastam de 5,4 a 6,4 e esvaziam a bateria em poucos portais |
| Estética | desafio (dominar o ritmo) e tensão (a barra baixando quando o jogador se afoba) |
Os autores listam oito tipos de estética — sensação, fantasia, narrativa, desafio, companheirismo, descoberta, expressão e passatempo (submission). Um jogo não precisa de todas; precisa saber quais busca. Drone Gate aposta em desafio, com um pouco de sensação no setor escuro com farol.
Nenhuma linha do código diz “não aperte em rajadas”. A mecânica (o impulso zera a velocidade antes de aplicar a nova) produziu essa dinâmica sozinha. Na análise MDA, perguntar “que comportamento esta regra vai incentivar?” vale mais que perguntar “esta regra está implementada?”.
Os documentos de design
Uma busca por game design document devolve dezenas de modelos, regras de formatação e listas de seções obrigatórias — o bastante para desanimar quem só quer começar. Na prática, documentos de design são feitos sob medida pela equipe que os usa. Três tipos cobrem quase todos os casos (Ferrone, 2025):
| Documento | Para quem | O que contém | Tamanho |
|---|---|---|---|
| One-pager (documento de uma página) | quem ainda não conhece o jogo: equipe nova, professor, divulgação | um retrato do jogo: conceito, fantasia, mecânicas centrais, controles, condições de vitória e derrota | uma página, por definição |
| GDD (Game Design Document) | toda a equipe, principalmente design, arte e som | como se joga, regras com números, fluxo de telas, estética, narrativa, conteúdo | de poucas a centenas de páginas, conforme o jogo |
| TDD (Technical Design Document) | quem programa | plataforma, arquitetura, componentes, dados, convenções, riscos técnicos | proporcional à complexidade técnica |
Em um projeto pequeno, o one-pager e um GDD curto — que pode morar em arquivos Markdown dentro do próprio repositório — bastam; o TDD vira uma ou duas seções técnicas do mesmo documento.
One-pager
O one-pager responde, numa leitura de dois minutos, “que jogo é este?”. O livro de Ferrone (2025) usa um para o protótipo Hero Born, um jogo em 3D feito só com primitivas da engine, organizado em seis linhas: conceito (furtividade e coleta de itens, com um pouco de tiro), história (um herói preso numa arena desconhecida), estilo de arte (GameObjects primitivos, trocáveis por modelos mais tarde), mecânicas centrais (linha de visão dos inimigos e coleta), controles (teclado, com teclas nomeadas) e condições de vitória e derrota (coletar tudo / vida chegar a zero). Repare que a arte é descrita como provisória de propósito: o one-pager registra também o que não será feito agora.
O mesmo formato, preenchido para Drone Gate:
| Campo | Drone Gate |
|---|---|
| Conceito | Arcade 2D de visão lateral e um único comando: atravessar portais com um drone que perde altitude e cuja bateria limita os impulsos. |
| Fantasia do jogador | Pilotar no limite da bateria — cada toque é uma decisão. |
| Ponto de partida | Flappy Bird (2013), acrescido de um recurso limitado. |
| Estilo de arte | Pixel art própria, três sprites (fundo 320 × 180, drone 18 × 14, módulo de portal 18 × 18 fatiado em 9-slice); luzes 2D e parallax como extensões. |
| Mecânicas centrais | Gravidade constante; impulso vertical fixo; bateria de 10 cargas (1 por impulso, +4 por portal); portais com passagem em alturas sorteadas. |
| Controles | Um comando, Impulsionar: espaço, clique ou botão sul do controle. Após a derrota, espaço ou botão sul reiniciam (depois de 0,6 s); com o mouse, pelo botão Reiniciar. |
| Vitória e derrota | Sem vitória: o objetivo é o maior placar. Tocar uma estrutura ou um limite da pista encerra a partida. |
| Público e sessão | Qualquer pessoa; partidas de segundos a poucos minutos, em computador ou navegador. |
| Fora do escopo agora | Áudio, animação, menus e recorde persistente (ficam para versões posteriores). |
Entregue o one-pager a alguém que não conhece o projeto e peça que descreva o jogo com as próprias palavras. Se a descrição divergir da sua, o documento — ou a ideia — ainda não está pronto.
GDD: o documento de design do jogo
O GDD é a referência de como o jogo funciona. Não existe formato certo ou errado; existem GDDs que a equipe consulta e GDDs que ninguém abre. Os que são consultados costumam seguir alguns princípios:
- É um documento vivo. Muda a cada playtest. Um GDD escrito no primeiro dia e nunca mais atualizado descreve um jogo que não existe. Versione-o junto com o projeto e registre as decisões que mudaram.
- Números, não adjetivos. “O drone sobe rápido” não pode ser testado; “o impulso deixa a velocidade vertical em 5,5 u/s” pode.
- Escrito para consulta, não para leitura corrida. Títulos, tabelas, listas, figuras de referência. Quem procura “quanto recarrega um portal?” precisa achar a resposta em segundos.
- Um responsável por seção. Seção sem dono desatualiza primeiro.
- Liberdade de forma. Esboços, capturas de jogos de referência e diagramas comunicam melhor que parágrafos. Stone Librande (2010) propõe one-page designs: cada sistema do jogo resumido num único pôster ilustrado, afixado na parede da equipe. No outro extremo, o documento de design original de Grand Theft Auto — então chamado Race'n'Chase, da DMA Design — foi publicado e é uma leitura instrutiva sobre como a ideia inicial de um jogo difere do produto final (ver Referências).
Uma estrutura de partida, para ser cortada ou ampliada conforme o jogo:
| Seção | Conteúdo |
|---|---|
| 1. Visão geral | o one-pager, a fantasia do jogador e os pilares |
| 2. Jogabilidade | core loop e meta loop; regras; condições de vitória e derrota |
| 3. Mecânicas | uma subseção por mecânica, com números (ver o exemplo abaixo) |
| 4. Controles | ações do jogador e seus bindings por dispositivo |
| 5. Fluxo de telas e estados | início, jogo, pausa, fim, reinício |
| 6. Interface (HUD) | o que é mostrado, onde e por quê |
| 7. Conteúdo | fases, inimigos, itens, ondas — com tabelas |
| 8. Estética | referências visuais, paleta, tom do som |
| 9. Progressão e dificuldade | como o jogo muda ao longo da partida (ver Playtest e balanceamento) |
| 10. Histórico de decisões | o que mudou, quando e por quê |
Especificar uma mecânica
A seção de mecânicas é a mais consultada e a que mais sofre com texto vago. Compare duas versões da mesma mecânica:
Versão vaga. O drone tem uma bateria que acaba se o jogador apertar demais. Passar pelos portais recarrega um pouco.
Versão especificada. Bateria — recurso do drone. Capacidade: 10 cargas. Custo: 1 carga por impulso. Recarga: +4 ao atravessar um portal, sem passar da capacidade. Bateria vazia: o comando é ignorado e o drone cai. Ativação: a bateria começa desligada e liga quando o drone cruza uma linha invisível pouco antes do primeiro portal; antes disso, impulsos são gratuitos. Interface: barra horizontal que encolhe para a esquerda; cinza enquanto desligada, vermelha abaixo de 25 %. Intenção de design: premiar o ritmo de um toque por arco (≈ 3,2 cargas por portal) e punir rajadas (≈ 5,4 a 6,4 cargas por portal). Parâmetros ajustáveis: capacidade, recarga por portal, posição da linha de ativação.
A versão especificada pode virar código sem perguntas, pode virar caso de teste e, principalmente, traz a intenção de design: quem for ajustar os números sabe o que eles deveriam produzir.
TDD: o documento técnico
O TDD responde “como vamos construir isto?”. Em equipes pequenas, ele é curto e muito prático: serve para que duas pessoas programem partes diferentes sem se atrapalhar. Seções úteis:
- Ambiente e plataforma-alvo — versão exata da engine, pipeline de renderização, pacotes e plataformas de build.
- Arquitetura — componentes, quem é dono de cada estado, como se comunicam.
- Estados do jogo — a máquina de estados que governa a partida.
- Dados — o que é configurável e onde mora (Inspector, arquivos de dados).
- Convenções — nomes, pastas, estilo de código, fluxo de Git.
- Riscos técnicos — o que pode não funcionar e como será testado cedo.
Um trecho de TDD de Drone Gate, extraído das decisões da Aula 11:
| Item | Decisão |
|---|---|
| Engine e pipeline | Unity 6.3 LTS (6000.3.24f1), template Universal 2D (URP + 2D Renderer) |
| Entrada | Input System; uma ação, Impulsionar, com três bindings |
| Física | Rigidbody2D dinâmico no drone; cinemático nos portais, movidos com MovePosition em FixedUpdate |
| Estado central | ControladorJogo é o único que escreve PartidaAtiva, PartidaIniciada e a pontuação; os demais componentes só leem |
| Criação de objetos | Instantiate pelo GeradorPortais; cada portal se destrói ao passar de X = −10 |
| Reinício | recarregar a cena ativa com SceneManager.LoadScene (a cena precisa estar na Scene List) |
| Convenções | um MonoBehaviour por arquivo; [SerializeField] private em vez de campos públicos; nomes de domínio em português sem acento |
| Risco verificado | BoxCollider2D com Auto Tiling em sprite fatiado cresceu além do sprite na versão de referência — manter Auto Tiling desligado e conferir o tamanho do collider com os Gizmos |
A máquina de estados da partida, na Figura 3, é a parte do TDD que mais evita defeitos: ela diz quais eventos valem em cada estado.
Dados de ajuste fora do código
Parâmetros de jogo mudam o tempo todo durante o balanceamento. Na Aula 11 eles
ficam espalhados em campos serializados de vários componentes — intervalo no
gerador, velocidade em cada portal, capacidade na bateria. Quando a lista
cresce, vale reuni-los num ScriptableObject: um asset de dados, editável
no Inspector, que vários componentes podem ler. Trocar o asset troca a
dificuldade inteira sem tocar no código nem na cena.
O trecho abaixo é um esboço (somente leitura) de como os dados da dificuldade progressiva da Atividade 2 da Aula 11 caberiam num asset. Quem lê esses valores e os aplica aos portais continua sendo o trabalho da atividade.
using UnityEngine;
namespace Aula11
{
[CreateAssetMenu(fileName = "ConfiguracaoDificuldade",
menuName = "Drone Gate/Configuração de dificuldade")]
public class ConfiguracaoDificuldade : ScriptableObject
{
[Header("Portais")]
[Min(0.1f)] [SerializeField] private float velocidadeInicial = 3f;
[Min(0.1f)] [SerializeField] private float velocidadeMaxima = 5f;
[Min(0f)] [SerializeField] private float incrementoPorNivel = 0.5f;
[Min(1)] [SerializeField] private int pontosPorNivel = 5;
[Min(0.1f)] [SerializeField] private float distanciaEntrePortais = 7.2f;
public float VelocidadePara(int pontuacao)
{
int nivel = pontuacao / pontosPorNivel;
return Mathf.Min(velocidadeMaxima, velocidadeInicial + incrementoPorNivel * nivel);
}
public float IntervaloPara(float velocidade) => distanciaEntrePortais / velocidade;
}
}
Com o script no projeto, Assets → Create → Drone Gate → Configuração de
dificuldade cria o asset. Depois que o gerador passa a ler um campo desse
tipo, dois assets — Dificuldade_Facil e Dificuldade_Normal, por exemplo —
viram dois modos de jogo sem nenhuma linha de código nova.
Outros documentos que ajudam
| Documento | Serve para | Em Drone Gate |
|---|---|---|
| Guia de estilo (art bible) | manter arte coerente entre pessoas | PPU 18, filtro Point, sem compressão; bordas de 4 px para o 9-slice; paleta do fundo |
| Lista de assets | saber o que falta e de onde veio cada arquivo, com a licença | três PNGs próprios (CC BY-SA 4.0); alternativas CC0 anotadas com a origem |
| Planilha de balanceamento | ver o efeito de cada número antes de jogar | ver Playtest e balanceamento |
| Documento de fase (level design) | planejar o percurso, o ritmo e o ensino de cada trecho | não se aplica: os portais são sorteados; o equivalente são os limites de altura e o intervalo |
| Backlog | saber o que fazer a seguir | ver Produção e processo |
Prototipagem e escopo
Protótipos respondem perguntas
Um protótipo é uma versão descartável feita para responder uma pergunta, o mais barato possível. A pergunta vem antes do protótipo: “o impulso com custo é divertido?” gera um protótipo; “vamos começar o jogo” não. Os tipos mais comuns, do mais barato ao mais caro:
| Tipo | Como | Responde | Em Drone Gate |
|---|---|---|---|
| Protótipo de papel | cartas, dados, fichas, papel quadriculado | regras, economia de recursos, turnos | fichas como cargas: o colega move o “drone” numa folha e paga uma ficha por impulso — o custo por portal aparece antes de uma linha de código |
| Protótipo digital cinza (greybox, blockout) | primitivas da engine (quadrados, cubos, cápsulas), sem arte | controle, ritmo, espaço, câmera | quadrado branco como drone, retângulos como portais: valida gravidade, impulso e passagem |
| Protótipo de sistema | um sistema isolado numa cena de teste | se a técnica funciona e cabe no desempenho | cena só com a luz 2D do farol, antes de ligá-la ao placar |
| Vertical slice | um trecho curto com qualidade final | se a equipe sabe produzir o jogo inteiro nesse nível | as primeiras partidas com arte, interface e luzes finais |
O Hero Born de Ferrone (2025) é deliberadamente um greybox: o one-pager declara que personagens e cenário serão GameObjects primitivos até que a jogabilidade esteja resolvida. É a mesma lógica: arte é cara de mudar; primitiva não. Enquanto a regra ainda pode mudar, gaste o mínimo na aparência.
Duas advertências. Primeiro, protótipo é descartável: o código escrito às pressas para responder a uma pergunta não deve virar, sem revisão, a base do jogo. Segundo, o vertical slice não é o MVP (produto mínimo viável): o slice é fino e de qualidade final, para provar a produção; o MVP é o jogo inteiro no mínimo de funcionalidades, para ser entregue e jogado.
Escopo: o que entra, o que fica de fora
O erro de planejamento mais comum em projetos de jogos é o escopo maior que o tempo. A técnica MoSCoW força a decisão classificando cada funcionalidade em quatro grupos:
- Must have — sem isto não há jogo. Define o MVP.
- Should have — importante, mas o jogo funciona sem; entra logo depois.
- Could have — desejável; entra se sobrar tempo.
- Won't have (this time) — decidido que não entra nesta versão. Esta categoria é a mais importante: escrever o que não será feito encerra a discussão.
Drone Gate, classificado a partir da própria Aula 11:
| Categoria | Funcionalidades |
|---|---|
| Must | impulso com Input Action; gravidade; portais gerados em alturas sorteadas; colisão fatal; pontuação por travessia; reinício |
| Should | bateria com barra na interface; bateria desligada até o primeiro portal; espera de 0,6 s antes de reiniciar pelo teclado |
| Could | setor escuro com farol; dificuldade progressiva; parallax; portais que oscilam; correntes de vento; cristais; inclinação visual |
| Won't (agora) | áudio, animação quadro a quadro, menus, recorde persistente, build publicada |
A ordem da Aula 11 segue essa tabela: todos os checkpoints constroem o Must; a bateria (Should) vem em seguida; as atividades de laboratório e as extensões opcionais são os Could, e só começam depois que o jogo básico está completo. Esse é o padrão a copiar: o jogo precisa estar jogável do início ao fim o mais cedo possível, e cada adição a partir daí deixa o jogo jogável de novo.
- A lista de Must tem mais de oito ou dez itens para um projeto de poucas semanas.
- Nenhum item está em Won't.
- Nenhum protótipo foi jogado, mas já há arte final sendo produzida.
- A estimativa de cada tarefa é “umas horinhas”.
- O jogo depende de um sistema que ninguém da equipe fez antes (rede, IA complexa, geração procedural) e ele não foi prototipado primeiro.
Produção e processo
Backlog e histórias de usuário
O backlog é a lista ordenada de tudo o que falta fazer. Cada item deve ser pequeno (de uma a poucas horas de trabalho) e verificável. Um formato útil para itens de jogabilidade é a história de usuário, que obriga a dizer para quem e para quê:
Como jogador, quero ver a carga da bateria diminuir a cada impulso, para entender por que o drone parou de responder.
Cada história ganha critérios de aceitação — condições objetivas que dizem quando ela está pronta:
- a barra encolhe uma fração a cada impulso e cresce ao atravessar um portal;
- a barra fica cinza enquanto a bateria está desligada;
- abaixo de 25 % a barra muda de cor;
- a barra encolhe em direção à borda esquerda, sem se deslocar para o centro.
Os checkpoints da Aula 11 são exatamente isso: o Checkpoint 6 — Jogo completo é a lista de critérios de aceitação do jogo inteiro.
Quadro Kanban
Um quadro Kanban torna o backlog visível em colunas. O mínimo útil tem quatro:
| A fazer | Fazendo | Em teste | Pronto |
|---|---|---|---|
| Portais que oscilam | Barra da bateria (Ana) | Geração de portais (Bruno) | Impulso com Input Action |
| Setor escuro com farol | Colisão fatal e reinício | ||
| Dificuldade progressiva | Pontuação por travessia |
Duas regras fazem o quadro funcionar: limitar o trabalho em andamento (no máximo um ou dois cartões em “Fazendo” por pessoa) e só mover para “Pronto” o que cumpre a definição de pronto combinada pela equipe, por exemplo:
- os critérios de aceitação da história foram verificados em Play Mode;
- o Console não mostra erros nem avisos novos;
- o trabalho foi integrado ao ramo principal e o projeto abre sem erros num clone limpo;
- os valores ajustáveis estão em campos serializados, não fixos no código;
- o GDD foi atualizado se alguma regra mudou.
Marcos com critério de saída
Em projetos curtos, os marcos da Figura 1 se reduzem a alguns pontos de verificação. O que importa é que cada um tenha um critério de saída verificável:
| Marco | Critério de saída |
|---|---|
| M0 — Conceito | one-pager, pilares e MoSCoW escritos e aceitos pela equipe |
| M1 — Protótipo jogável | o core loop funciona em greybox; alguém de fora jogou |
| M2 — MVP | todos os Must prontos: dá para jogar do início ao fim e reiniciar |
| M3 — Alfa | os Should prontos; arte e interface finais no lugar |
| M4 — Beta | nada novo entra; playtests feitos e ajustes aplicados |
| M5 — Entrega | build gerada e testada fora do Editor; postmortem escrito |
Se um marco atrasa, o ajuste é feito no escopo — um Could vira Won't —, nunca na qualidade do que já é Must.
Git em um projeto Unity
Controle de versão é o que permite a duas pessoas trabalharem no mesmo jogo e voltar atrás quando algo quebra. Um projeto Unity exige três cuidados específicos.
1. Versione só o que é fonte. As pastas Assets/, Packages/ e
ProjectSettings/ são o projeto; Library/, Temp/, Logs/, UserSettings/
e as pastas de build são geradas pelo Editor e nunca entram no
repositório. Um .gitignore mínimo, derivado do modelo mantido pela
comunidade (github/gitignore), fica na raiz do projeto:
/[Ll]ibrary/
/[Tt]emp/
/[Oo]bj/
/[Bb]uild/
/[Bb]uilds/
/[Ll]ogs/
/[Uu]ser[Ss]ettings/
/[Mm]emoryCaptures/
/[Rr]ecordings/
# Arquivos de IDE regenerados pela Unity
*.csproj
*.sln
*.slnx
*.suo
*.user
*.userprefs
.vs/
.idea/
# Builds
*.apk
*.aab
2. Versione os arquivos .meta. Cada asset tem um .meta com seu
identificador (GUID); é por ele que cenas e prefabs se referem ao asset. Um
asset sem .meta versionado chega ao colega com outro GUID, e todas as
referências a ele se quebram — o sintoma típico é um Missing no Inspector.
Mova e renomeie assets pela janela Project, nunca pelo sistema de
arquivos, para que o .meta acompanhe.
3. Serialize como texto. Em Edit → Project Settings, confira na
categoria Editor o campo Asset Serialization → Mode = Force Text e, na
categoria Version Control, Mode = Visible Meta Files. São os padrões
em projetos novos. Com isso, cenas e prefabs são
arquivos YAML que o Git consegue comparar. Um .gitattributes normaliza o fim
de linha desses arquivos e marca imagens e sons como binários:
* text=auto
*.cs text diff=csharp
*.unity text eol=lf
*.prefab text eol=lf
*.asset text eol=lf
*.mat text eol=lf
*.meta text eol=lf
*.png binary
*.jpg binary
*.wav binary
*.ogg binary
*.fbx binary
Mesmo em texto, cenas são o arquivo com mais conflitos: duas pessoas
editando a mesma cena ao mesmo tempo produzem um YAML difícil de mesclar à
mão. A Unity distribui junto com o Editor uma ferramenta de mesclagem
semântica, o UnityYAMLMerge (Smart Merge), que pode ser configurada como
mergetool do Git conforme o manual; para localizá-la numa instalação feita
pelo Hub, procure o arquivo UnityYAMLMerge dentro da pasta da versão do
Editor. A prevenção, porém, funciona melhor que a ferramenta:
- divida o trabalho por prefab, não por cena: cada pessoa é dona de prefabs diferentes, e a cena só junta instâncias;
- quem precisa alterar a cena avisa antes e faz commit logo depois;
- faça commits pequenos e frequentes, com mensagens que digam o que mudou (“Bateria: recarga por portal 4 → 3”);
- use um ramo por funcionalidade e integre ao principal só o que cumpre a definição de pronto.
Para arquivos grandes — áudio sem compressão, texturas em alta resolução, arquivos de ferramentas de arte —, o Git LFS guarda o conteúdo fora do histórico principal; serviços de hospedagem costumam recusar arquivos individuais acima de algumas dezenas de megabytes. Em um jogo com arte de poucos kilobytes, como Drone Gate, ele é desnecessário.
Playtest e balanceamento
O playtest
Playtest é observar outra pessoa jogando para descobrir o que o jogo de fato comunica. O autor é o pior testador do próprio jogo: ele sabe o que a barra significa, onde a passagem vai aparecer e que o primeiro portal não gasta bateria. Fullerton (2018) trata o playtest como o centro do processo de design — joga-se, observa-se, ajusta-se e joga-se de novo, desde o protótipo de papel.
Tipos de teste, conforme a pergunta:
| Tipo | Quem joga | Responde |
|---|---|---|
| Autoteste | a própria equipe | “funciona?” — defeitos, travamentos, regras quebradas |
| Teste com colegas | quem conhece jogos mas não o projeto | “é jogável? é divertido?” |
| Teste com o público-alvo | pessoas como as que vão jogar | “entendem sem ajuda? voltam a jogar?” |
| Teste “descartável” | alguém que nunca viu o jogo, usado uma única vez | “o que acontece no primeiro minuto?” — depois do primeiro teste, a pessoa já aprendeu e não serve mais para isso |
Regras para conduzir uma sessão:
- Não explique o jogo. Entregue-o como ele será entregue. Se for preciso explicar, anote: é um defeito de onboarding.
- Peça que a pessoa pense em voz alta (think-aloud): “o que você está tentando fazer agora?”.
- Não ajude e não defenda. Frases como “na verdade a ideia é…” anulam o teste. Observe e anote.
- Anote comportamento, não opinião. “Apertou em rajadas nos três primeiros portais” vale mais que “achou difícil”.
- Pergunte no fim, com perguntas abertas. “O que a barra no alto da tela fazia?” revela se a bateria foi entendida; “gostou da bateria?” não revela nada.
- Procure padrões. Um testador que se perde pode ser acaso; três que se perdem no mesmo lugar são um problema de projeto.
Um roteiro pronto está no Kit de modelos.
Medir, além de observar
Observar mostra por que; medir mostra quanto. Um registro simples de
cada partida — placar, duração, onde terminou — revela padrões que a
observação de poucas sessões não mostra. O esboço abaixo (somente leitura)
grava uma linha por partida num arquivo CSV na pasta de dados persistentes da
aplicação (Application.persistentDataPath; no macOS,
~/Library/Application Support/<empresa>/<produto>; no Windows,
%userprofile%\AppData\LocalLow\<empresa>\<produto>):
using System;
using System.Globalization;
using System.IO;
using UnityEngine;
namespace Aula11
{
public static class RegistroPartidas
{
private const string NomeArquivo = "partidas.csv";
public static void Registrar(int pontuacao, float duracao)
{
string caminho = Path.Combine(Application.persistentDataPath, NomeArquivo);
if (!File.Exists(caminho))
{
File.WriteAllText(caminho, "data_hora;pontuacao;duracao_s\n");
Debug.Log($"Registro de partidas em {caminho}");
}
string linha = string.Format(CultureInfo.InvariantCulture,
"{0:yyyy-MM-dd HH:mm:ss};{1};{2:F2}\n", DateTime.Now, pontuacao, duracao);
File.AppendAllText(caminho, linha);
}
}
}
No ControladorJogo da Aula 11, bastam três linhas: um campo
private float instanteInicio;, a atribuição instanteInicio = Time.time;
em IniciarPartida e, em RegistrarDerrota, depois de
PartidaAtiva = false;, a chamada
if (PartidaIniciada) RegistroPartidas.Registrar(pontuacao, Time.time - instanteInicio);.
Depois de uma sessão de playtest, a planilha mostra a distribuição dos
placares: se a maioria das partidas acaba com 0 ou 1 ponto, o começo está
difícil demais; se quase ninguém morre antes de 20, a dificuldade não cresce.
Em builds para navegador, o acesso a arquivos é diferente — use o registro no
Editor ou em builds de computador.
Dificuldade e o canal de fluxo
Fluxo (flow) é o estado de concentração total descrito por Csikszentmihalyi (1990): acontece quando o desafio está à altura da habilidade. Desafio acima da habilidade gera ansiedade; abaixo, tédio. Como a habilidade do jogador cresce com o tempo de jogo, a dificuldade precisa crescer junto — é o canal de fluxo da Figura 4, aplicado a jogos por Chen (2007).
Três lições práticas saem da figura:
- Dificuldade constante envelhece. O Drone Gate básico é igual no portal 1 e no portal 50; quem aprendeu o ritmo cai no tédio. A Atividade 2 da Aula 11 existe por isso.
- Degraus com respiros. Uma curva que só sobe cansa. Alternar tensão e alívio — um trecho mais fácil logo depois de um aumento — dá ao jogador tempo de consolidar o que aprendeu. O setor escuro da Atividade 1, que alterna com o claro a cada 5 pontos, é uma variação desse tipo.
- O começo é o trecho mais crítico. É onde a habilidade é menor e onde a maioria desiste. A bateria desligada até o primeiro portal é, entre outras coisas, uma decisão de dificuldade inicial.
Planilha de balanceamento
Balancear é escolher números. Uma planilha permite prever o efeito de cada número antes de jogar e registrar por que ele foi escolhido. A tabela abaixo aplica as regras da Atividade 2 da Aula 11 — a cada 5 pontos, os portais ganham 0,5 u/s até 5 u/s, sempre a 7,2 unidades um do outro — e estima o custo da bateria com a mesma conta da Aula 11: a gravidade ( u/s²) retira de velocidade entre dois portais, e um toque por arco devolve cerca de 11 u/s.
| Placar | Velocidade (u/s) | Intervalo (s) | Tempo de reação (s) | Cargas por portal | Saldo com recarga 4 |
|---|---|---|---|---|---|
| 0–4 | 3,0 | 2,40 | 4,33 | 3,2 | +0,8 |
| 5–9 | 3,5 | 2,06 | 3,71 | 2,8 | +1,2 |
| 10–14 | 4,0 | 1,80 | 3,25 | 2,4 | +1,6 |
| 15–19 | 4,5 | 1,60 | 2,89 | 2,1 | +1,9 |
| 20 ou mais | 5,0 | 1,44 | 2,60 | 1,9 | +2,1 |
O “tempo de reação” é o tempo que um portal leva do ponto de geração (X = 10) até o drone (X = −3). A última coluna esconde uma surpresa: à medida que o jogo acelera, a bateria fica mais fácil. Com portais mais próximos no tempo, a gravidade retira menos velocidade entre dois portais e o jogador precisa de menos toques, mas continua recebendo 4 cargas por portal. A dificuldade de reflexo sobe; a de economia cai. Nenhuma regra foi escrita para isso — é uma dinâmica que surgiu da combinação de duas mecânicas, exatamente o que o modelo MDA prevê.
Se a intenção de design é que a bateria continue pesando, uma correção possível é reduzir a recarga com o nível:
| Placar | Cargas por portal | Recarga proposta | Saldo |
|---|---|---|---|
| 0–4 | 3,2 | 4 | +0,8 |
| 5–9 | 2,8 | 4 | +1,2 |
| 10–14 | 2,4 | 3 | +0,6 |
| 15–19 | 2,1 | 3 | +0,9 |
| 20 ou mais | 1,9 | 3 | +1,1 |
A planilha não decide: ela aponta o que testar. As contas supõem um jogador que toca uma vez por arco; jogadores reais erram mais sob pressão, e só o playtest diz se a proposta ficou justa ou punitiva. Registre no GDD a versão escolhida e o motivo.
Os “Experimentos de calibração” da Aula 11 seguem a regra de ouro do balanceamento: altere uma propriedade, jogue, registre o efeito e só então altere a próxima. Mudar três números ao mesmo tempo impede saber qual deles produziu o resultado.
Game feel: a resposta que o jogador sente
Game feel (Swink, 2008) é a sensação de controlar algo no jogo: o quanto a resposta ao comando parece imediata, precisa e prazerosa. Ela depende de três coisas: resposta (a ação acontece no quadro seguinte ao comando), simulação (o movimento obedece a regras consistentes, como a gravidade do drone) e polimento — os efeitos que confirmam cada evento, que a comunidade chama de juice.
| Evento | Sem polimento | Com polimento (ideias para a Aula 14) |
|---|---|---|
| Impulso | o drone sobe | pequena rajada de partículas sob o drone; som curto |
| Travessia | o placar muda | o número cresce e volta ao tamanho; a barra pisca ao recarregar |
| Bateria no fim | a barra fica vermelha | a barra pulsa; som de alerta discreto |
| Colisão | o painel aparece | pausa de poucos centésimos (hit-stop); tremor curto da câmera; só então o painel |
Dois cuidados. Juice não conserta um core loop ruim — ele amplifica o que já existe. E efeito que atrapalha a leitura do jogo (tremor longo, partículas sobre a passagem) é defeito, não polimento.
Onboarding e acessibilidade
Onboarding é como o jogo ensina a si mesmo. Os melhores ensinam fazendo, um conceito por vez, num espaço seguro. Drone Gate já faz isso de três modos: o drone espera o primeiro comando sem cair; o aviso inicial diz qual é o comando e some ao começar; e a bateria só liga perto do primeiro portal, de modo que o jogador aprende a voar antes de aprender a economizar.
Acessibilidade é permitir que mais pessoas joguem. As Game Accessibility Guidelines organizam recomendações em níveis; várias das básicas custam pouco num projeto Unity:
| Recomendação | Em Drone Gate |
|---|---|
| Permitir remapear os controles | a ação Impulsionar do Input System já separa intenção e dispositivo; o pacote oferece reatribuição de bindings durante a execução |
| Não usar cor como único portador de informação | a barra usa comprimento além da cor — um jogador daltônico ainda lê a carga |
| Texto legível, com bom contraste | placar em texto grande e claro, destacado do fundo escuro |
| Evitar efeitos que piscam ou tremem em excesso | limitar o tremor de câmera e oferecer opção para desligá-lo |
| Oferecer opções de dificuldade | um asset ConfiguracaoDificuldade “Fácil” com portais mais lentos e recarga maior |
| Permitir pausar | ainda não existe — bom candidato a Should |
Um jogo de um único botão já é, por construção, mais acessível a quem tem mobilidade reduzida do que um jogo de muitos comandos simultâneos. Acessibilidade não é uma camada no fim: é mais barata quando entra no GDD desde o início.
Postmortem: fechar o ciclo
Ao terminar um projeto — ou um marco importante —, a equipe escreve um postmortem: o que deu certo, o que deu errado e o que fará diferente na próxima vez. A indústria publica postmortems há décadas e eles são uma das melhores fontes de aprendizagem sobre desenvolvimento de jogos. Três regras:
- Evidência, não impressão. “A bateria ficou pronta dois dias depois do previsto porque o pivô da barra encolhia para o centro” ensina algo; “a interface deu trabalho” não.
- Sem culpados. O foco é o processo: que prática teria evitado o problema?
- Termina em ações. Cada problema gera uma mudança concreta para o próximo projeto.
Kit de modelos
Os modelos abaixo estão em Markdown, prontos para copiar para um arquivo
docs/ dentro do repositório do seu projeto. Corte o que não se aplica.
# <Nome do jogo> — One-pager
| Campo | Descrição |
|---|---|
| Conceito | <gênero, visão de câmera e a ação principal, em uma frase> |
| Fantasia do jogador | <a experiência prometida, do ponto de vista de quem joga> |
| Referências | <1 a 3 jogos e o que se aproveita de cada um> |
| Estilo de arte | <estilo; o que é provisório (primitivas) e o que é final> |
| Mecânicas centrais | <2 a 4 regras, com números quando já existirem> |
| Controles | <ações e bindings por dispositivo> |
| Vitória e derrota | <condições objetivas> |
| Público e sessão | <quem joga, onde e por quanto tempo> |
| Fora do escopo agora | <o que foi decidido não fazer nesta versão> |
**Pilares:** 1. <...> 2. <...> 3. <...>
# <Nome do jogo> — GDD (versão <x.y>, <data>)
## 1. Visão geral — one-pager, fantasia, pilares
## 2. Jogabilidade — core loop, meta loop, regras, vitória e derrota
## 3. Mecânicas — uma subseção por mecânica:
### <Mecânica> — definição · números · exceções · interface ·
### intenção de design · parâmetros ajustáveis
## 4. Controles — ação → binding (teclado, mouse, controle, toque)
## 5. Estados e telas — diagrama de estados; o que vale em cada estado
## 6. Interface (HUD) — elemento · informação · posição · quando aparece
## 7. Conteúdo — fases, inimigos, itens, ondas (tabelas)
## 8. Estética — referências visuais, paleta, som
## 9. Dificuldade — curva, planilha de balanceamento, justificativas
## 10. Acessibilidade — recomendações adotadas
## 11. Escopo (MoSCoW) — Must · Should · Could · Won't
## 12. Histórico — data · decisão · motivo
# <Nome do jogo> — TDD
## Ambiente — engine e versão exata, pipeline, pacotes, plataformas de build
## Arquitetura — componente · responsabilidade · estado que possui · quem lê
## Estados do jogo — diagrama e eventos aceitos em cada estado
## Dados — parâmetros ajustáveis e onde moram (Inspector, ScriptableObjects)
## Convenções — nomes, pastas, estilo de código, ramos e mensagens de commit
## Divisão do trabalho — dono de cada prefab/sistema; regra para editar cenas
## Riscos técnicos — risco · como será testado · até quando
# Playtest — <versão/build>, <data>
Testador: <perfil, sem nome> Já jogou antes? <sim/não> Observador: <nome>
## Antes
- Não explicar o jogo. Pedir para pensar em voz alta.
- Pergunta de teste desta sessão: <o que queremos descobrir?>
## Durante (anotar comportamento, com tempo aproximado)
| Tempo | O que fez | O que disse | Observação |
|---|---|---|---|
- Tempo até entender o objetivo: ____ Tempo até o primeiro ponto: ____
- Onde errou (e quantas vezes): ____
- Pediu ajuda? Em quê? ____
## Depois (perguntas abertas)
1. Descreva o jogo com suas palavras.
2. O que cada elemento da tela fazia? (placar, barra, ...)
3. Em que momento foi mais tenso? E mais chato?
4. Se pudesse mudar uma coisa, qual seria?
## Conclusão do observador
- Padrões que se repetem com outros testadores: ____
- Mudanças propostas (uma por linha, com a evidência): ____
# Postmortem — <Nome do jogo>
## Resumo — o que era para ser, o que foi entregue (links, build)
## Números — duração, tarefas previstas × concluídas, itens cortados
## O que deu certo — 3 a 5 itens, cada um com evidência
## O que deu errado — 3 a 5 itens, cada um com evidência e causa
## O que faremos diferente — uma ação concreta por problema
Atividade aplicada — Do Drone Gate ao seu jogo
Objetivo. Praticar, sobre um jogo que já existe, as técnicas desta página e depois aplicá-las ao planejamento de um jogo novo.
Ponto de partida. O Drone Gate da Aula 11, com o jogo básico completo (Checkpoint 6). As atividades de laboratório da aula são bem-vindas, mas não necessárias.
Roteiro
Passo 1 — Playtest cruzado. Troque de computador com outra equipe e conduza um playtest do Drone Gate dela com o roteiro do Kit de modelos, com pelo menos dois testadores que não tenham visto aquela versão. Anote comportamento, não opinião.
Passo 2 — Uma mudança, uma previsão. Escolha uma mecânica (recarga por portal, capacidade, intensidade do impulso, intervalo) e, antes de mudá-la, escreva no formato MDA: mecânica alterada → dinâmica esperada → estética esperada. Mude só esse valor, jogue cinco partidas e compare o resultado com a previsão.
Passo 3 — Planilha. Monte numa planilha a tabela de balanceamento desta página, com fórmulas em vez de valores digitados (velocidade, intervalo, tempo de reação, cargas por portal, saldo). Acrescente uma coluna com a sua proposta de recarga e justifique-a em uma frase.
Passo 4 — O seu jogo. Para o jogo que sua equipe pretende desenvolver,
escreva o one-pager, três pilares, o core loop (um diagrama simples basta)
e a tabela MoSCoW. Coloque os arquivos numa pasta docs/ do repositório do
projeto.
Checklist de conclusão
- O registro do playtest tem ao menos um padrão observado em mais de um testador.
- A previsão MDA foi escrita antes do teste e comparada com o resultado.
- A planilha recalcula todas as colunas quando a velocidade inicial ou a distância entre portais muda.
- O one-pager cabe em uma página e alguém de fora da equipe o descreveu corretamente.
- Cada pilar recusa ao menos uma funcionalidade concreta.
- A tabela MoSCoW tem ao menos um item em Won't.
Para responder
- Qual observação do playtest mais surpreendeu a equipe que fez o jogo? Por que ela não tinha percebido isso sozinha?
- Sua previsão MDA acertou a dinâmica? Se não, que parte da mecânica você não tinha levado em conta?
- Qual funcionalidade do seu projeto foi mais difícil de colocar em Won't, e que pilar justificou a decisão?
Exercícios (checkpoints)
Questões dissertativas
Explique a diferença entre o laço de jogo (entrada → atualização → desenho) da Aula 10 e o core loop de um jogo. Dê a duração aproximada de cada um em Drone Gate.
Por que um pilar como “ser divertido” não serve como pilar de design? Reescreva-o como um pilar útil para Drone Gate e cite uma funcionalidade que ele recusaria.
Na planilha de balanceamento, o saldo da bateria cresce de +0,8 para +2,1 cargas por portal conforme os portais aceleram. Explique a causa em termos de mecânicas e dinâmicas e proponha uma forma de manter a bateria relevante.
Durante um playtest, o testador aperta em rajadas, esvazia a bateria no terceiro portal e pergunta: “por que o drone parou de subir?”. O que você deve fazer naquele momento e o que essa observação indica sobre o projeto?
Duas pessoas vão trabalhar no mesmo projeto Unity com Git. Liste três configurações ou práticas que evitam perda de referências e conflitos, explicando o problema que cada uma resolve.
Compare protótipo, vertical slice e MVP quanto à pergunta que cada um responde e à qualidade de arte esperada.
Questões objetivas
1. Qual documento é o mais adequado para apresentar o jogo, em dois minutos, a alguém que nunca ouviu falar dele?
- a)TDD
- b)GDD completo
- c)One-pager
- d)Backlog
- e)Planilha de balanceamento
2. No modelo MDA, “jogadores que apertam em rajadas esvaziam a bateria em poucos portais” é um exemplo de quê?
- a)Mecânica
- b)Dinâmica
- c)Estética
- d)Pilar de design
- e)Critério de aceitação
3. Segundo o modelo MDA, qual camada o designer controla diretamente?
- a)As estéticas
- b)As dinâmicas
- c)As mecânicas
- d)As três igualmente
- e)Nenhuma: só o jogador as controla
4. Por que a categoria Won't have é considerada a mais importante do MoSCoW?
- a)Porque reúne as funcionalidades mais difíceis
- b)Porque registra explicitamente o que não entra nesta versão, encerrando discussões e protegendo o prazo
- c)Porque é a única que vai para o GDD
- d)Porque define o MVP
- e)Porque é preenchida pelo público
5. Qual destas frases é uma especificação verificável de mecânica?
- a)O drone deve ser ágil e responsivo
- b)Os portais ficam mais difíceis com o tempo
- c)A cada 5 pontos, os portais ganham 0,5 u/s, até 5 u/s, mantendo 7,2 unidades entre si
- d)A bateria acaba se o jogador exagerar
- e)O jogo deve ter uma curva de dificuldade agradável
6. Durante um playtest, qual atitude do observador é adequada?
- a)Explicar o objetivo antes de começar, para economizar tempo
- b)Corrigir o jogador quando ele usa uma estratégia errada
- c)Anotar o que o jogador faz e diz, sem ajudar, e fazer perguntas abertas no fim
- d)Perguntar “gostou?” a cada portal
- e)Jogar uma partida de demonstração
7. No canal de fluxo, o que acontece com um jogador experiente num jogo de dificuldade constante?
- a)Permanece no canal indefinidamente
- b)Tende à ansiedade
- c)Tende ao tédio, porque sua habilidade cresce e o desafio não
- d)Passa a errar mais
- e)Nada: dificuldade não afeta o fluxo
8. Um colega clona o repositório e vê referências Missing em vários componentes, embora os arquivos dos assets estejam lá. Qual é a causa mais provável?
- a)A pasta Library/ não foi versionada
- b)Os arquivos .meta não foram versionados, e os assets ganharam novos GUIDs
- c)A cena foi salva em Force Text
- d)O .gitignore ignora *.csproj
- e)O Git LFS não foi instalado
Referências
Principais (essenciais)
- FERRONE, H. Learning C# by Developing Games with Unity 6. 8. ed. Birmingham: Packt, 2025. Capítulo 6, Getting Your Hands Dirty with Unity — seção Game design documents e o one-pager de Hero Born.
- HUNICKE, R.; LEBLANC, M.; ZUBEK, R. MDA: A Formal Approach to Game Design and Game Research. In: AAAI Workshop on Challenges in Game AI, 2004. Disponível em: aaai.org/papers/ws04-04-001-mda-a-formal-approach-to-game-design-and-game-research
- SCHELL, J. The Art of Game Design: A Book of Lenses. 3. ed. Boca Raton: CRC Press, 2019.
- FULLERTON, T. Game Design Workshop: A Playcentric Approach to Creating Innovative Games. 4. ed. Boca Raton: CRC Press, 2018.
- Unity Technologies. Unity User Manual 6.3 — ScriptableObject. Disponível em: docs.unity3d.com/6000.3/Documentation/Manual/class-ScriptableObject.html
- Unity Technologies. Unity User Manual 6.3 — Smart merge. Disponível em: docs.unity3d.com/6000.3/Documentation/Manual/SmartMerge.html
Aprofundamento (opcionais)
- RYAN, T. The Anatomy of a Design Document, Part 1: Documentation Guidelines for the Game Concept and Proposal. Game Developer (antiga Gamasutra), 1999. Disponível em: gamedeveloper.com/design/the-anatomy-of-a-design-document-part-1-documentation-guidelines-for-the-game-concept-and-proposal
- LIBRANDE, S. One-Page Designs. Game Developers Conference, 2010. Slides disponíveis em: stonetronix.com/gdc-2010/OnePageDesigns.ppt
- DMA DESIGN. Race'n'Chase — documento de design original de Grand Theft Auto. Disponível em: gamedevs.org/uploads/grand-theft-auto.pdf
- ROGERS, S. Level Up! The Guide to Great Video Game Design. 2. ed. Chichester: Wiley, 2014.
- SWINK, S. Game Feel: A Game Designer's Guide to Virtual Sensation. Burlington: Morgan Kaufmann, 2008.
- CSIKSZENTMIHALYI, M. Flow: The Psychology of Optimal Experience. New York: Harper & Row, 1990.
- CHEN, J. Flow in Games (and Everything Else). Communications of the ACM, v. 50, n. 4, p. 31–34, 2007.
- NYSTROM, R. Game Programming Patterns. Genever Benning, 2014 — capítulo “State”. Disponível em: gameprogrammingpatterns.com
- Game Accessibility Guidelines. Disponível em: gameaccessibilityguidelines.com
- github/gitignore — modelo
Unity.gitignore. Disponível em: github.com/github/gitignore/blob/main/Unity.gitignore - BOWMAN, D. A.; KRUIJFF, E.; LAVIOLA, J. J.; POUPYREV, I. 3D User Interfaces: Theory and Practice. Boston: Addison-Wesley, 2004. (004.738.52 T531) — capítulo sobre avaliação de interfaces 3D com usuários, base metodológica do playtest.