Rapid Prototyping🔗

Definição curta: Rapid prototyping é a filosofia de criar, testar e descartar prototypes muito rapidamente (horas a dias) para aprender sobre seu jogo antes de investir tempo significativo em desenvolvimento.

O que é🔗

Rapid prototyping aplica o princípio fail fast a game design:

1. Tenha uma ideia
2. Crie prototype no menor tempo possível
3. Teste
4. Aprenda
5. Repita ou descarte

flowchart LR
    I["Idea\nIdeia"] --> P["Prototype\n(horas-dias)"]
    P --> T["Test\nPlaytest"]
    T -->|"Works"| K["Keep & Evolve\nManter"]
    T -->|"Fails"| D["Discard\nDescartar"]
    D --> I
    K --> I

Key insight: o objetivo do prototype é aprender, não terminar.

Índice de sub-tópicos🔗

• Filosofia fail-fast
• Timeboxing
• Defining success
• Rapid prototype workflow
• Common mistakes
• Exemplo de sessão

Filosofia fail-fast🔗

Por que fail-fast funciona🔗

• Custo de mudança é menor cedo
• Aprendizado é mais valioso que progresso
• Energia da equipe é preservada (working on fun stuff)

Fail-fast ≠ giving up🔗

Fail-fast não significa:

• “Isso não funcionou, projeto cancelado”
• “Meu ideia é ruim, sou um mal designer”

Fail-fast significa:

• “Isso não funcionou, aprendi algo, vamos tentar outra coisa”
• “Ideia validada, agora posso continuar com confiança”

Mindset shift🔗

ANTES: "Preciso fazer isso funcionar"
DEPOIS: "Preciso descobrir se isso funciona"

Timeboxing🔗

O que é timeboxing🔗

Definir um tempo máximo para cada prototype, não um escopo máximo.

## Prototype #3: Combo System

**Timebox**: 2 dias (16 horas)

**Goal**: Descobrir se sistema de combos em tempo real é divertido

**Mínimo viável**:
- [x] Player pode attack
- [x] Ataques em sequência criam combos
- [x] Feedback visual de combo

**Não incluído**:
- [ ] Vários tipos de ataque
- [ ] Enemy completo
- [ ] Áudio

**Sucesso**: 5+ jogadores dizem "isso é legal" após 5 minutos

Timebox levels🔗

Como fazer timebox funcionar🔗

1. Escopo proporcional ao tempo — 2 dias = apenas essentials
2. Prioritize ruthlessly — O que é realmente necessário?
3. Cut features, not quality within scope — menos features, não feature mal-feita
4. Ship when timebox ends — não quanto

Defining success🔗

Antes de começar, defina sucesso🔗

## Prototype #4: Inventory System

**Pergunta**: "É melhor ter inventory grid-based (Tetris) ou list-based (scroll)?"

**Métricas de sucesso**:
- Jogadores acham items rapidamente?
- Sentem frustação organizando?
- Quanto tempo spent organizing vs playing?

**Test method**:
- Implementar AMBOS (alternar entre sessions)
- Perguntar aos jogadores qual preferiram
- Medir tempo de decision-making

Métricas vs Impressões🔗

Use ambos: métricas quantitativas + feedback qualitativo.

Rapid prototype workflow🔗

Dia 1: Ideação🔗

Manhã:
- Brainstorm 5 ideias para prototype
- Escolha a mais incerto/risco

Tarde:
- Defina timebox (2 dias)
- Defina success criteria
- Setup basic project structure

Dia 2: Implementação🔗

Manhã:
- Implement MVP do mechanic
- Não polish, não extras

Tarde:
- Fix critical bugs
- Basic playtest interno

Dia 3: Test & Decide🔗

Manhã:
- 3-5 external playtests
- Collect feedback

Tarde:
- Analyze results
- Decide: Keep? Modify? Discard?
- Document learnings

Ferramentas para speed🔗

# Engines rápidos para prototypes
- Godot (2D: excellent, 3D: good)
- GameMaker (2D: very fast)
- Construct (no-code: fastest)
- Unity (3D: medium speed)
- Pygame/Custom (programmers: fastest)

Common mistakes🔗

❌ Prototype muito ambition🔗

Problema: “Vou fazer prototype de todo o jogo em 1 semana”

Realidade: Prototype de todo o jogo = não é prototype, é pré-produção

Solução: Foque em 1 pergunta, não em todo o jogo

❌ Não definir success criteria🔗

Problema: “Prototype foi divertido” — mas divertido compared to what?

Solução: Defina antes: “X or Y would be success”

❌ Apreciar attachment🔗

Problema: “Passamos 2 semanas nisso, não podemos descartar”

Solução: Se não funciona, não funciona — documented learnings e seguir em frente

❌ Prototype sem test🔗

Problema: Build prototype, guarda na gaveta

Solução: Playtest É O PONTO do prototype

Exemplo de sessão🔗

Scenario🔗

“Joguei um roguelike mobile e pensei: e se o inventario fosse colaborativo em multiplayer?”

Prototype 1 (4 horas)🔗

**Goal**: Descobrir se inventory compartilhado é divertido

**Implementation**:
- 2 jogadores
- 1 inventário comum (20 slots)
- Items aparecem aleatoriamente
- Ambos podem pegar/colocar

**Result**: Confuso — dois jogadores reaching for same item causes frustration but also excitement

**Learn**: Competition aspect could work, but needs clearer rules

Prototype 2 (2 dias)🔗

**Goal**: Refinar o concept — competitive vs cooperative?

**Implementation**:
- Adicionou "claim" mechanic (5s para pegar item)
- Score competitivo: most items wins
- 4 jogadores locais

**Result**: Muito divertido! Emergent trash-talking.

**Learn**: SHIP IT — concept works, now iterate on details

Veja também🔗

• Prototyping Techniques — técnicas específicas
• Paper Prototyping — testes sem código
• Playtesting: Métodos — como coletar feedback

Referências🔗

• Fullerton, Tracy (2004). Game Design Workshop. CRC Press. ISBN 978-0-240-80974-8.
• Sylvester, Tynan (2013). Designing Games: A Guide to Engineering Experiences. O’Reilly Media. ISBN 978-1-4493-3793-3.