Como Prototipar um Jogo Rápido para Validar a Ideia

Um protótipo de jogo existe pra responder uma única pergunta: essa mecânica é divertida ou não? Só isso. Não é demo, não é vertical slice, não é a "versão 0.1" do seu projeto dos sonhos. É um experimento descartável que custa dias e te salva de gastar meses (ou anos) construindo um jogo em cima de uma ideia que não para em pé.

A maioria dos projetos indie que morrem no meio do caminho não morre por falta de habilidade técnica. Morre porque a pessoa passou seis meses fazendo sistema de inventário, menu, save game e arte antes de descobrir que o loop central do jogo é chato. O protótipo inverte essa ordem: você testa a parte mais arriscada primeiro, com o mínimo de esforço possível.

Neste artigo eu mostro o método que uso na prática: protótipo cinza, escopo de uma pergunta, teste com gente de verdade e coragem de jogar fora.

A regra de ouro: uma pergunta por protótipo de jogo

Antes de abrir a engine, escreva uma frase. Uma só. Algo como:

• "Desviar de projéteis enquanto recarrego a arma cria tensão boa?"
• "Empilhar blocos com física imprecisa é engraçado ou frustrante?"
• "O jogador entende o teleporte sem tutorial?"

Se você não consegue formular a pergunta, você ainda não sabe o que está testando, e um protótipo sem pergunta vira só um projeto pequeno e bagunçado. A pergunta também define quando o protótipo acabou: no momento em que você tem a resposta, ele cumpriu o papel.

Isso significa que um jogo pode (e geralmente deve) ter vários protótipos. Um pra mecânica de movimento, outro pra economia, outro pro combate. Cada um isola uma incerteza. Misturar tudo num protótipo só é o jeito mais rápido de não validar nada.

Protótipo cinza: feio de propósito

Protótipo cinza (greybox) é aquele feito só com formas geométricas: cubos, cápsulas, retângulos coloridos. Zero arte, zero animação, zero som. E não é por preguiça, é por método.

Tem dois motivos práticos pra isso:

Primeiro: arte mente. Um jogo bonito com mecânica fraca parece bom nos primeiros dez minutos. Se o seu protótipo é um quadrado cinza pulando em plataformas cinzas e mesmo assim você quer jogar "só mais uma vez", a mecânica sustenta o jogo. Se nem com arte linda ficaria divertido, melhor saber agora.

Segundo: arte é cara de jogar fora. A função do protótipo é ser descartável. Se você passou duas semanas modelando o personagem, vai ter resistência emocional pra deletar o projeto quando a resposta for "não". Caixa cinza ninguém chora pra apagar.

No Godot, o setup de um protótipo 2D é literalmente isso: um CharacterBody2D com um ColorRect ou um Sprite2D usando o ícone padrão da engine, e StaticBody2D com retângulos pro cenário. No 3D, os nodes CSG (CSGBox3D, CSGCylinder3D) existem exatamente pra isso: blocagem rápida de nível sem abrir o Blender.

O controlador de protótipo que eu uso pra quase tudo top-down cabe em dez linhas:

extends CharacterBody2D

@export var speed := 400.0

func _physics_process(delta):
    velocity = Input.get_vector("ui_left", "ui_right", "ui_up", "ui_down") * speed
    move_and_slide()

Repare nos detalhes: ações ui_* padrão da engine (não perco tempo configurando Input Map) e @export na velocidade, pra ajustar pelo Inspector com o jogo rodando. Em protótipo, todo número que você vai querer mexer merece um @export. Tuning rápido é metade do valor do protótipo.

Montando o protótipo em poucos dias

O cronograma que funciona pra mim é apertado de propósito. Prazo folgado em protótipo vira projeto, e projeto é justamente o que a gente está tentando evitar nessa fase.

Dia 1: a mecânica central, e nada mais

Implemente só o verbo principal do jogo. Se o jogo é sobre dar dash entre inimigos, o dia 1 termina com um quadrado dando dash numa sala vazia. Sem vida, sem dano, sem menu, sem game over.

Um dash de protótipo, por exemplo:

extends CharacterBody2D

@export var speed := 400.0
@export var dash_speed := 1200.0
@export var dash_duration := 0.15

var dash_timer := 0.0
var dash_dir := Vector2.ZERO

func _physics_process(delta):
    var dir = Input.get_vector("ui_left", "ui_right", "ui_up", "ui_down")

    if Input.is_action_just_pressed("ui_accept") and dash_timer <= 0 and dir != Vector2.ZERO:
        dash_dir = dir
        dash_timer = dash_duration

    if dash_timer > 0:
        dash_timer -= delta
        velocity = dash_dir * dash_speed
    else:
        velocity = dir * speed

    move_and_slide()

Três variáveis exportadas, três coisas pra ajustar em tempo real até o movimento "sentir" certo. É código que vai pro lixo depois, então não tem state machine, não tem sinal, não tem arquitetura. Em protótipo, código limpo é desperdício.

Dia 2 e 3: o contexto mínimo da pergunta

Agora adicione só o que a pergunta exige. Se a pergunta é "desviar enquanto recarrega cria tensão?", você precisa de algo atirando em você e de uma recarga. Inimigo pode ser um retângulo parado que cospe círculos em linha reta. Serve.

A armadilha aqui é o "já que": "já que estou mexendo nisso, vou adicionar três tipos de inimigo". Não vai. Cada feature a mais atrasa a resposta e contamina o teste, porque você não vai saber se a diversão veio da mecânica central ou do acessório.

Dia 4 e 5: tuning e teste

Jogue você mesmo, ajuste os números, e depois coloque o protótipo na mão de outra pessoa. Essa parte não é opcional, e é onde a maioria pula.

Como validar a mecânica de verdade

Ver alguém jogar seu protótipo é desconfortável e insubstituível. Algumas regras pra extrair sinal de verdade do teste:

Fique calado. Não explique os controles, não justifique ("isso aí ainda vai mudar"), não dê dica. Se a pessoa não descobre o que fazer, isso é dado, não acidente. Anote e deixe ela se virar.

Observe o corpo, não só a fala. Gente é educada e mente pra não te magoar. "Ah, legal" não significa nada. Os sinais honestos são outros: a pessoa pediu pra jogar de novo sem você oferecer? Inclinou pra frente? Xingou quando morreu e tentou na hora? Esses comportamentos não dá pra fingir.

Pergunte o que ela faria, não o que ela achou. "O que você achou?" rende resposta vazia. "O que você estava tentando fazer ali?" e "como você esperava que o dash funcionasse?" rendem informação que você usa.

Teste com três a cinco pessoas. Com uma pessoa só, você não separa opinião individual de padrão. A partir de umas cinco, os mesmos problemas começam a se repetir e o retorno por teste cai. Não precisa de laboratório: amigo, colega de trabalho, alguém da família que joga.

E o critério final, que eu uso como régua: o protótipo é divertido mesmo sendo feio? Se a resposta exige um "vai ficar bom quando tiver arte, som e história", a mecânica não passou. Arte e som amplificam diversão que já existe, não criam diversão do zero.

Descartar cedo é o protótipo funcionando

Aqui está a parte que ninguém gosta de ouvir: a maioria dos protótipos deve morrer. E isso não é fracasso, é o sistema operando como projetado.

Pense no custo real. Um protótipo de uma semana que revela uma ideia ruim te custou uma semana. A mesma descoberta feita no mês oito de produção custou oito meses, e provavelmente custou também a sua motivação pra terminar qualquer coisa depois. Protótipo descartado cedo é o investimento mais barato que existe em game dev.

Pra facilitar a decisão, defina os critérios de morte antes de começar, enquanto você ainda está imparcial. Por exemplo: "se depois do tuning eu não tiver vontade de jogar mais uma rodada, encerro" ou "se ninguém dos testers pedir pra jogar de novo, encerro". Decidir o critério depois, com o protótipo na mão, não funciona: você vai mover a régua pra ideia passar, porque a essa altura já está apegado.

Duas saídas honestas quando a resposta é "não":

Pivotar a pergunta. Às vezes a mecânica não diverte do jeito planejado, mas algo inesperado apareceu no teste. O tester ignorou seu objetivo e passou dez minutos brincando com a física dos objetos? Isso pode ser o jogo de verdade. Faça outro protótipo em cima disso.

Arquivar e seguir. Guarde uma anotação do que aprendeu (uma página basta: pergunta, o que testou, por que falhou) e comece a próxima ideia. Quem prototipa rápido acumula essas respostas, e elas valem mais que qualquer curso de game design, porque são sobre os seus jogos.

Erros que matam a velocidade do protótipo

Pra fechar, os tropeços que eu mais vejo (e já cometi):

Escolher essa hora pra aprender engine nova. Protótipo pede a ferramenta que você já domina. Se você sabe Godot, prototipe em Godot, mesmo que o jogo final "talvez seja melhor em outra engine". Velocidade vence.

Escrever código bonito. Singleton, sinais bem arquitetados, pastas organizadas. Em produção isso é profissionalismo; em protótipo é procrastinação com cara de trabalho. Script único e variáveis chumbadas estão ótimos.

Polir antes de validar. Um particle effect aqui, um screen shake ali, "só pra ficar apresentável". Cada hora de polish numa mecânica não validada é aposta às cegas.

Mostrar pro público errado. Postar protótipo cinza em rede social rende feedback sobre a aparência, que é exatamente o que o protótipo não está testando. Teste ao vivo, com poucas pessoas, observando.

Nunca encerrar. Protótipo sem prazo e sem critério de morte vira projeto zumbi: nem morre, nem vira jogo. Caixa de tempo fechada, pergunta respondida, decisão tomada.

Fechando

Prototipar rápido é menos sobre técnica e mais sobre disciplina: uma pergunta por vez, caixas cinzas, prazo curto, teste com gente de verdade e coragem de apagar. O código é descartável; a resposta é o que você leva.

Se você tem uma ideia de jogo parada na cabeça, o exercício é direto: escreva a pergunta dela em uma frase, abra a engine e se dê cinco dias. Na sexta-feira você vai saber algo sobre essa ideia que hoje você só imagina. E saber é o que separa quem lança jogo de quem coleciona projeto inacabado.