Playtesting: Métodos🔗

Definição curta: Playtesting é o processo de observar jogadores jogando seu jogo para identificar problemas, validar design decisions e coletar feedback acionável — é a forma mais direta de descobrir se seu jogo é divertido.

O que é🔗

Playtesting é watch people play your game e coletar informações sobre:

• Onde eles ficam presos
• O que não entendem
• O que acham divertido
• Onde se frustram
• Que features não usam

flowchart TB
    subgraph Playtest["Playtest Session"]
        P["Preparar\n(test protocol, equipment)"]
        R["Recrutar\n(jogadores target)"]
        O["Observar\n(sem dirigir)"]
        C["Coletar\n(dados, feedback)"]
    end

    P --> R --> O --> C
    C -->|"insights"| I["Iterate\n(ajustar design)"]
    I --> P

Índice de sub-tópicos🔗

• Tipos de playtest
• Preparando o test
• Recrutando jogadores
• Observando efetivamente
• Tipos de dados a coletar
• Análise pós-test
• Frequência recomendada

Tipos de playtest🔗

1. Internal (Dogfood)🔗

• Quem: equipe do estúdio
• Quando: continuamente
• Valor: rápido, barato, primeiro indicador
• Limitação: viés de familiaridade

2. Friends & Family🔗

• Quem: amigos, família, network pessoal
• Quando: early prototype
• Valor: feedback honesto (geralmente)
• Limitação: podem ser muito nice, não representam target

3. External (Paid/Unpaid)🔗

• Quem: jogadores do target audience
• Quando: após prototype jogável
• Valor: feedback objetivo, representando público real
• Limitação: requer recruiting, possibly payment

4. QA vs Design playtest🔗

Preparando o test🔗

Definir objetivos🔗

Antes de qualquer test, responda:

1. O que queremos aprender? (pergunta específica)
2. Que decisão tomará baseada no resultado?
3. Quantos tests precisamos para confidence?

Criar test protocol🔗

## Playtest Protocol: "Dungeon Borks" v0.3

### Objetivo do test
- Validar se core loop de "explore → fight → collect" é engajante
- Identificar onde jogadores param de jogar

### Setup
- 45 minutos por sessão
- Sem help durante gameplay (only após)
- Gravação de tela (with permission)
- Observador anota timestamps de:
  - Frustration moments
  - Joy moments
  - Confusion moments

### Warm-up script
"Este é um prototype. Não é terminado. We want to see
what works and what doesn't. There are no wrong answers."

### Perguntas pós-session
1. Rate difficulty 1-10
2. O que foi mais divertido?
3. O que foi mais confuso?
4. Would you play again?

Equipment checklist🔗

• Build estável (não crash)
• Recording setup (tela + audio)
• Formulário de consentimento
• Questionário pós-test printed
• Observador com template de anotações
• Timer/cronômetro
• Room prepared (distrações mínimas)

Recrutando jogadores🔗

Critérios de recrutamento🔗

Defina seu target player:

## Critérios: "Dungeon Borks" target player

NECESSÁRIO:
- 18-35 anos
- Já jogou roguelike ou deckbuilder antes
- Disponível para 1h de test

NÃO PROCURAR:
- Designers de jogo (viés)
- Nunca jogou games antes
- Amigos próximos da equipe

Canais de recrutamento🔗

1. Discord communities de gamers
2. Reddit (r/playtesting, r/indiegaming)
3. Universities (game design clubs)
4. Local game stores (board game communities)
5. Social media do estúdio

Incentivos🔗

Observando efetivamente🔗

DO (faça)🔗

• Observe quietly — don’t help unless safety issue
• Take timestamps — mark when interesting things happen
• Note body language — frowns, smiles, confusion faces
• Let them struggle — if they figure it out, it’s valid design
• Ask clarifying questions — “O que você está pensando agora?”

DON’T (não faça)🔗

• Don’t teach — you’re testing, not tutoring
• Don’t suggest — “e se você tentasse…”
• Don’t defend — “mas essa mecânica funciona em outros jogos…”
• Don’t rush — silence often means they’re thinking

What to look for🔗

flowchart TB
    subgraph Observation["O que observar"]
        T["Timestamps\n(Quando eventos ocorrem)"]
        B["Bottlenecks\n(Onde players param)"]
        F["Frustrations\n(Expressões de tédio/frustração)"]
        J["Joy\n(Expressões de diversão)"]
        E["Exploration\n(O que they click/explore first)"]
    end

Tipos de dados a coletar🔗

Quantitativos (números)🔗

Qualitativos (descrições)🔗

• Notas de observação
• Gravações de tela
• Entrevistas pós-session
• Think-aloud protocol (player narrates thoughts)

Think-aloud protocol🔗

Peça ao jogador para narrar seus pensamentos em voz alta:

"Jogador: 'Ok, vejo três cards... esse parece bom...
mas não sei o que acontece se eu escolher o outro...
deixa eu ver o que acontece... ah, entendi!'"

Isso revela o model mental do jogador.

Análise pós-test🔗

pós-session interview🔗

Estrutura sugerida:

1. Abertura (2 min): “Obrigado por jogar. Como foi?”
2. Perguntas abertas (10 min): “Me conte sobre…”
3. Perguntas específicas (5 min): “Eu notei que você…”
4. Encerramento (3 min): “Alguma outra coisa?”

Síntese de insights🔗

Após cada batch de tests:

## Síntese: Playtest batch #3 (6 jogadores)

### INSIGHTS PRINCIPAIS

1. **Core loop funciona**: 5/6 jogadores completaram 3+ runs
2. **Tutorial é confuso**: 4/6 não entenderam crafting na primeira tentativa
   - Solução: adicionar tooltip no primeiro crafting attempt

3. **Classe B feels underpowered**: 0/6 escolheram B, all chose A ou C
   - Solução: buff B's special ability

### QUOTES

- "Eu não sabia que podia vender items... isso seria útil saber antes"
- "O boss do third floor me deu trabalho, mas foi justo"

Frequência recomendada🔗

Veja também🔗

• User Research para Jogos — métodos de pesquisa
• Paper Prototyping — testando sem código
• Balanceamento — aplicando insights de tests

Referências🔗

• Fullerton, Tracy (2004). Game Design Workshop. CRC Press. ISBN 978-0-240-80974-8.
• Koster, Raph (2013). A Theory of Fun for Game Design (2ª ed.). O’Reilly Media. ISBN 978-1-4493-6321-5.
• Brathwaite, Brenda & Schreiber, Ian (2009). Challenges for Game Designers. Charles River Media. ISBN 978-1-58450-580-8.
• Unger, Russ & Chandler, Carolyn (2009). A Project Guide to UX Design. New Riders. ISBN 978-0-321-60737-9.