Escrevendo crítica que desenvolvedor lê sem defesa

Uma crítica que o desenvolvedor lê sem se defender não começa pelo veredicto; começa pela reprodução. Se qualquer pessoa do estúdio consegue repetir o que você descreveu, o texto vale. Se não consegue, é opinião vestida de análise.

Descreva o incidente, não o sentimento

"A missão três é confusa" não diz nada. "Na missão três, o objetivo aparece no mapa a 200 metros, mas o caminho marcado leva a uma porta trancada, e o jogador descobre depois de oito minutos que precisava escalar" descreve um incidente reproduzível: lugar, tempo, caminho, custo. O sentimento de confusão decorre do incidente e não precisa ser anunciado.

Separe os três níveis

• Erro factual: número errado, interface que não responde, progresso perdido. É verificável e corrigível.
• Decisão de design: dificuldade, ritmo, monetização. É escolha; você discorda com argumento, não com tom de defeito.
• Gosto pessoal: tema, estética. Declare como preferência, sem disfarçar de problema técnico.

Misturar os níveis é o que faz um texto parecer ataque em vez de relatório.

Traga o contexto do custo

Um jogo feito por cinco pessoas em dois anos não pode ser julgado com a régua de um estúdio de trezentas. Mencionar escopo não é proteger o jogo; é calibrar a comparação. A crítica fica mais forte, não mais branda, porque aponta o que faltou dentro do possível.

Feche com o que salvaria

Todo texto crítico termina melhor com uma frase prática: "um marcador no início da missão resolveria". Se você não tem a sugestão, tudo bem, mas diga o que verificou e o que não conseguiu testar. Honestidade sobre limites é o que faz o autor parecer alguém com quem vale conversar.