Este post foi originalmente escrito em italiano por Paolo Gambardella. Foi traduzido por um agente de inteligência artificial e pode conter imprecisões.
Andrew Kelley, o criador da linguagem de programação Zig, abriu uma palestra com uma pergunta incômoda: para quem serve de verdade o software que desenvolvemos? A palestra se chama “Don’t Take the Black Pill” e foi feita para uma plateia de desenvolvedores, não de game designers. Mas é exatamente a pergunta que deveríamos nos fazer toda vez que projetamos um sistema de progressão.
Uma régua mais honesta do que “fun”
A Self-Determination Theory de Deci e Ryan diz que uma pessoa está bem — num jogo ou na vida — quando três necessidades estão satisfeitas: autonomia (minhas escolhas importam), competência (estou melhorando, e consigo ver isso) e pertencimento (não estou sozinho). Um sistema pode ter métricas de retenção impecáveis e mesmo assim negar as três. Isso também tem nome: coercive retention. A progressão existe, mas o jogador volta por causa de um timer que expira ou uma notificação que o chama de volta, não porque está com vontade de entrar no jogo.
Coercionware, além dos jogos
Kelley chama essa categoria de “coercionware”: software cujo objetivo não é servir quem o usa, mas manipulá-lo. Os exemplos que ele traz não vêm dos jogos — notificações push não solicitadas, testes A/B que otimizam o clique e não a experiência, algoritmos de recomendação que perseguem o engajamento em vez do valor. O ponto que me pegou é que ele descreve tudo isso como uma escolha de design, não um efeito colateral. Alguém, numa reunião, decidiu que tava tudo bem assim.
O mesmo problema, outro nome
Nos jogos, chamamos isso com outros nomes: gacha, eventos por tempo limitado, season pass que criam pressão. Mas é o mesmo mecanismo: tira-se autonomia para garantir o retorno. Escrevi sobre isso na semana passada falando de dopamina e ocitocina — o “pertencimento” da Self-Determination Theory é, no fundo, o mesmo papo da ocitocina. Um jogador que volta para estar num mundo ou com outras pessoas não precisa ser preso por um timer.
O hábito que ajuda
Tem um hábito simples que uso quando avalio uma feature nova: fazer o advogado do diabo comigo mesmo. Assumir que vai falhar e me perguntar por quê. Geralmente a lista de motivos inclui coisas como “confunde o jogador” ou “não converte o suficiente”. Vale a pena adicionar mais um: falha porque manipula em vez de servir. Essa pergunta não aparece sozinha numa reunião de roadmap. Ela precisa ser feita de propósito, antes de lançar.
Na próxima vez que uma feature melhorar os números, a pergunta certa não é se funciona. É se o jogador a escolhe — ou se ficou preso nela sem perceber.