Um protótipo não é uma versão pequena do produto final. É um instrumento para reduzir incerteza. Essa distinção apareceu de formas diferentes nos projetos do portfólio: Radgear precisava provar um controle por swipe; Water Battle Arena, a leitura de quatro jogadores sobre água; e Stylized Action Prototype, a convivência entre exploração com câmeras de área e combate por cartas.
O caminho até um MVP jogável começa quando a equipe escolhe qual dessas incertezas merece ser resolvida primeiro — e aceita deixar o restante visivelmente incompleto.
Comece por uma pergunta que possa falhar
“Fazer um jogo de ação” não é uma pergunta testável. “O jogador consegue ler a mudança de câmera sem perder a direção?” é. “A ordem das cartas cria decisões ou apenas uma sequência correta?” também.
Uma boa pergunta de protótipo reúne três qualidades:
- existe um comportamento observável durante uma sessão curta;
- uma resposta negativa muda a direção do projeto;
- a interação pode ser testada sem construir o produto inteiro.
No Stylized Action Prototype, o recorte preservado concentra justamente os riscos centrais: movimentação no mundo, transições entre câmeras fixas e a base das combinações de cartas. Menus completos, volume de conteúdo e acabamento comercial não eram necessários para verificar se essas peças podiam formar uma experiência coerente.
Construa a menor fatia vertical honesta
“Pequena” não significa isolada. Um controlador impecável em uma sala vazia pode esconder problemas que só aparecem quando câmera, inimigo, objetivo e feedback competem pela atenção. A fatia precisa ser curta, mas deve conectar causa e efeito de ponta a ponta.
Em Water Battle Arena, três builds públicas registram esse crescimento. A primeira valida movimento e colisões; a segunda adiciona seleção e fluxo de partida; a terceira consolida água, CPU, marcadores e composição visual. Cada marco continua jogável e torna a próxima pergunta mais específica.
Uma ordem prática para esse tipo de evolução é:
- Ação: o jogador consegue executar a mecânica central?
- Leitura: entende o que aconteceu e por quê?
- Regra: percebe sucesso, falha e mudança de estado?
- Ritmo: a repetição sustenta uma sessão curta?
- Continuidade: o sistema aceita a próxima variação sem ser refeito?
Use acabamento para revelar, não para disfarçar
Feedback visual, câmera e áudio entram cedo quando ajudam a avaliar a mecânica. Eles entram tarde quando servem apenas para esconder que a regra ainda não está clara.
Radgear é um exemplo direto: a interface foi mantida leve para que os swipes e a resposta do personagem permanecessem no centro do teste. Em RacketGO, produzido em uma semana, uma ação principal simples recebeu leaderboard, quests sociais e registro de progresso somente porque o loop curto já conseguia sustentar repetição.
O critério não é “está bonito?”. É “agora consigo observar melhor a decisão do jogador?”. Um efeito que mostra direção, cooldown ou mudança de estado é parte do instrumento de teste. Uma sequência longa de apresentação pode esperar.
Registre decisões, não apenas versões
Um vídeo de build comprova que algo existiu. Para orientar produção, a equipe também precisa saber o que aquela build respondeu. Um registro mínimo pode conter:
- a hipótese testada;
- o comportamento observado;
- a decisão tomada;
- o risco que continua aberto;
- o próximo recorte jogável.
Essa disciplina evita que o protótipo vire um acúmulo de features. Se uma alteração não reduz um risco, melhora a leitura ou prepara a próxima validação, ela provavelmente não pertence à iteração atual.
Extraia sistemas somente depois de encontrar estabilidade
Abstrair cedo demais transforma suposições em arquitetura. Abstrair tarde demais faz cada variação quebrar a anterior. O ponto de transição costuma aparecer quando a mesma regra sobrevive a mais de uma iteração, mas seus valores, conteúdo ou apresentação continuam mudando.
Nesse momento, vale separar dados ajustáveis, estado da partida e apresentação; definir responsabilidades; e tornar transições importantes observáveis. O objetivo não é uma arquitetura universal. É permitir que o próximo experimento aconteça sem desmontar o aprendizado já validado.
O MVP é uma decisão de produto
O protótipo prova uma hipótese. O MVP reúne as hipóteses essenciais em uma experiência que outra pessoa consegue iniciar, compreender, concluir e avaliar. Isso inclui estados menos glamourosos: entrada, reinício, falha, recuperação e encerramento.
Antes de chamar um recorte de MVP, a equipe deve conseguir responder:
- qual promessa de experiência está sendo entregue;
- qual caminho o jogador percorre sem assistência;
- quais evidências mostram que o loop é compreensível;
- quais riscos foram aceitos para a próxima etapa;
- o que foi deliberadamente deixado fora.
O resultado não precisa parecer final. Precisa ser honesto, jogável e decisivo: pequeno o suficiente para mudar, completo o suficiente para ensinar.
