Como Fazer um Bom Tutorial de Jogo (Onboarding que Não Espanta Jogador)

Os primeiros minutos decidem se o jogador fica ou fecha o jogo. E é exatamente nesses minutos que a maioria dos devs coloca a pior parte do jogo: o tutorial. Parede de texto, popup atrás de popup, dez mecânicas explicadas antes do jogador apertar um botão. O design de um bom tutorial de jogo segue uma regra simples que quase todo mundo ignora: ninguém aprende lendo, todo mundo aprende fazendo.

Esse artigo é sobre como construir um onboarding que ensina jogando. Vou passar pelos erros clássicos, pelos princípios que os melhores jogos usam há décadas, e fechar com um exemplo prático de dica contextual em Godot 4 que você pode adaptar pro seu projeto hoje.

Por que a maioria dos tutoriais falha

Os erros se repetem tanto que dá pra listar de cabeça:

Parede de texto. O jogo abre, aparece uma caixa com oito parágrafos explicando a história, os controles e o sistema de crafting. O jogador clica em "OK" sem ler, porque ele veio jogar, não estudar. Tudo que estava ali foi desperdiçado.

Despejar tudo de uma vez. Pulo, ataque, esquiva, inventário, mapa, habilidade especial, tudo nos primeiros dois minutos. Memória de curto prazo não segura isso. O jogador chega na primeira situação real sem lembrar de metade.

Tutorial separado do jogo. Aquela "sala de treino" desconectada de tudo, onde você executa comandos num ambiente estéril. O jogador aprende o botão, mas não aprende quando e por que usar, que é o que importa.

Interromper o fluxo. O jogador está se divertindo, descobrindo o mundo, e o jogo pausa pra abrir um popup. Cada interrupção quebra a imersão e treina o jogador a ignorar as mensagens.

Não deixar errar. Tutorial que trava tudo até o jogador executar a ação exata, na ordem exata. Vira um teste de obediência, não um aprendizado.

Repare no padrão: todos esses erros tratam o tutorial como um manual embutido. A solução é tratar o tutorial como level design.

Ensinar jogando: o princípio que resolve quase tudo

Os jogos que fazem onboarding bem raramente parecem ter tutorial. Eles têm fases desenhadas pra ensinar.

O exemplo mais estudado é a fase 1-1 de Super Mario Bros. Sem nenhum texto, ela ensina o jogo inteiro: o Mario começa do lado esquerdo da tela com espaço vazio à direita, então o único caminho é andar pra direita. O primeiro Goomba vem na sua direção, te forçando a descobrir o pulo. O primeiro cogumelo aparece num lugar onde é difícil desviar, porque o jogo quer que você encoste nele e descubra que power-up é coisa boa. Cada elemento foi posicionado pra provocar a descoberta.

Portal faz o mesmo com câmaras de teste: cada uma introduz um conceito novo usando os que vieram antes, em um ambiente onde a única forma de avançar é entender a mecânica. Megaman X usa a fase de abertura pra te ensinar a fugir, escalar parede e perder de propósito pro chefe, tudo dentro da narrativa. Celeste ensina dash, escalada e stamina só com a geometria das primeiras telas.

O que esses jogos têm em comum:

• O nível é o professor. A geometria, os inimigos e os obstáculos criam a situação onde a mecânica é a resposta natural.
• Descobrir é a recompensa. O jogador que percebe sozinho "ah, eu posso pular NISSO" sente que é esperto. Texto explicando a mesma coisa rouba esse momento.
• O contexto gruda na memória. Você não lembra "aperte X pra dash", você lembra da tela onde só o dash te salvava.

Isso não significa que texto é proibido. Um prompt curto na hora certa ("Espaço pra pular") é útil e barato. O problema é texto no lugar de design, não texto apoiando design.

Como estruturar o tutorial de jogo na prática

Princípio entendido, agora a estrutura. É assim que eu abordo o onboarding em projeto novo.

Uma mecânica por vez

Liste as mecânicas do seu jogo e ordene da mais essencial pra mais avançada. O onboarding apresenta uma de cada vez, e o jogador só encontra a próxima depois de usar a atual algumas vezes. Andar antes de pular, pular antes de atacar, atacar antes de combinar pulo com ataque.

A pergunta que guia a ordem: "sem qual mecânica o jogador trava na primeira tela?" Essa vem primeiro.

Apresente, repita, combine

Pra cada mecânica, o ciclo tem três etapas:

1. Apresente em uma situação onde ela é obviamente a solução e o fracasso custa pouco.
2. Repita duas ou três vezes em variações simples, pra fixar.
3. Combine com algo que o jogador já sabe, criando o primeiro desafio de verdade.

Esse ciclo é o esqueleto de quase toda fase introdutória bem feita. Se você analisar a primeira hora de um bom jogo de plataforma ou de puzzle, vai encontrar ele rodando em loop.

Espaço seguro pra errar

A primeira vez que o jogador testa uma mecânica não pode custar caro. Primeiro pulo sobre um buraco raso, não sobre um abismo. Primeiro combate contra um inimigo lento e fraco. Morrer no segundo 30 de jogo, antes de entender os controles, é frustração pura, e frustração nesse momento vira desinstalação.

Depois que a mecânica está aprendida, aí sim o custo do erro sobe. Dificuldade é mérito do jogo; punir ignorância que o próprio jogo causou é defeito.

Contexto em vez de interrupção

Quando precisar de texto, prefira dicas contextuais: uma mensagem curta que aparece no mundo, perto do lugar onde a ação é necessária, e some quando o jogador executa. Nada de pausar o jogo, nada de caixa de diálogo modal.

A dica contextual tem três vantagens: não interrompe, aparece exatamente quando é relevante, e desaparece pra quem já sabe. Jogador veterano atravessa seu tutorial sem nem perceber que ele existia. Esse é o padrão ouro: o onboarding invisível pra quem não precisa dele.

Deixe pular o que dá

Se o seu jogo tem uma sequência tutorial mais explícita (comum em jogos com sistemas complexos, tipo estratégia ou RPG), ofereça a opção de pular. Quem está jogando pela segunda vez, ou veio de outro jogo do gênero, agradece. Forçar um veterano a assistir explicação de movimento básico é desrespeito com o tempo dele.

Dica contextual no Godot 4: exemplo prático

Pra sair da teoria, aqui vai o componente de dica contextual que eu uso como base: uma Area2D que mostra um texto quando o jogador se aproxima e some pra sempre quando a ação é executada. É o suficiente pra montar um onboarding inteiro espalhando essas áreas pelo nível.

A estrutura de nodes:

DicaTutorial (Area2D)
├── CollisionShape2D
└── Label

E o script:

extends Area2D

# Nome da ação no Input Map que conclui a dica.
@export var acao: String = "jump"
@export var texto_dica: String = "Espaço pra pular"

@onready var label: Label = $Label

var concluida := false

func _ready() -> void:
    label.text = texto_dica
    label.visible = false
    body_entered.connect(_on_body_entered)
    body_exited.connect(_on_body_exited)

func _on_body_entered(body: Node2D) -> void:
    if body.is_in_group("player") and not concluida:
        label.visible = true

func _on_body_exited(body: Node2D) -> void:
    if body.is_in_group("player"):
        label.visible = false

func _unhandled_input(event: InputEvent) -> void:
    # Só conta como aprendido se o jogador usou a ação perto da dica.
    if label.visible and event.is_action_pressed(acao):
        concluida = true
        label.visible = false

Configure a Area2D pra detectar a layer do player, coloque o player no grupo player, e pronto. Cada instância dessa cena é uma dica independente: você posiciona uma antes do primeiro buraco com a ação de pulo, outra antes do primeiro inimigo com a ação de ataque, e por aí vai.

Dois upgrades naturais quando o projeto crescer: salvar concluida num autoload pra dica não voltar depois de trocar de cena, e trocar o Label por uma cena de UI com ícone do botão de acordo com o controle detectado (teclado ou gamepad).

Repare que o código é trivial. O trabalho difícil do onboarding não está no script, está no level design: decidir onde cada dica fica, qual situação força cada mecânica, e em que ordem tudo aparece.

Como saber se o seu onboarding funciona

Você não descobre isso jogando o próprio jogo. Você conhece cada mecânica de cor, então é a pior pessoa do mundo pra avaliar se elas são aprendíveis.

O teste que funciona: coloque alguém que nunca viu o jogo pra jogar e fique quieto. Não explique nada, não dê dica, só observe e anote. Onde a pessoa travou? Que mecânica ela não descobriu? Que dica ela ignorou? Cada travada é um buraco no seu onboarding, e o silêncio é obrigatório, porque no lançamento você não vai estar do lado de cada jogador explicando.

Três ou quatro sessões dessas já revelam os problemas graves. E prepare o ego: ver alguém travar por dois minutos numa parte que você achava óbvia dói, mas é a informação mais valiosa que um playtest entrega.

Fechando

Um bom tutorial de jogo não parece tutorial. Ele é a primeira fase, desenhada com intenção: uma mecânica por vez, situações onde a mecânica é a resposta natural, espaço pra errar barato, texto curto e contextual só onde o design sozinho não alcança.

Se você for guardar uma única coisa desse artigo, que seja essa: pare de escrever explicações e comece a desenhar situações. O jogador que descobre sozinho aprende mais rápido, lembra por mais tempo e ainda sai com a sensação de que é bom no seu jogo. E jogador que se sente bom no jogo continua jogando.