Sistema de Recompensa em Jogos: Por Que Eles Viciam e Como Projetar o Seu

Um sistema de recompensa em jogo é o motivo de alguém abrir o seu game pela segunda vez. A primeira sessão você ganha com arte, trailer e curiosidade. A segunda, a décima e a centésima você ganha com a pergunta que fica na cabeça do jogador depois que ele fecha o jogo: "o que eu vou destravar amanhã?".

E aqui mora um detalhe que muita gente ignora: recompensa não é o item. É o ciclo inteiro. A antecipação antes do baú abrir, o som do drop, a raridade do que caiu, e o que aquele item permite fazer em seguida. Designer que pensa só no item entrega loot. Designer que pensa no ciclo entrega motivo pra voltar.

Nesse artigo eu vou abrir esse ciclo: por que recompensa variável prende tanto, como implementar uma drop table de verdade em GDScript, o que é pity system e onde fica a linha entre design bom e manipulação.

Como funciona um sistema de recompensa em jogo

Todo sistema de recompensa responde três perguntas: o quê o jogador ganha, quando ganha e quanto custa ganhar.

O "o quê" se divide em dois tipos que funcionam de formas bem diferentes:

• Recompensa extrínseca: o jogo te dá algo. Item, moeda, XP, skin, conquista. É mensurável e fácil de balancear.
• Recompensa intrínseca: a atividade em si é gostosa. O pulo bem executado, o combo que conecta, o quebra-cabeça que finalmente fez sentido. Não aparece em nenhum inventário.

Jogos que duram anos acertam nas duas. Se o seu jogo só tem recompensa extrínseca, ele vira planilha: o jogador faz uma tarefa chata pra ganhar um número maior. Funciona por um tempo, mas o dia em que o número para de subir rápido, o jogador some. Se só tem intrínseca, falta estrutura de progressão pra quem gosta de meta e objetivo.

O "quando" é onde o design fica interessante, porque é aí que entra o cronograma de entrega.

Recompensa fixa vs recompensa variável

Existem dois jeitos básicos de entregar recompensa:

• Fixa: a cada X ações, recompensa garantida. Mate 10 inimigos, ganhe o item. Complete a fase, ganhe 3 estrelas.
• Variável: cada ação tem uma chance de recompensa. Mate o inimigo e talvez caia o item raro. Abra o baú e talvez venha a skin lendária.

A recompensa fixa é previsível e justa, e por isso mesmo perde força com o tempo. O jogador sabe exatamente o que vai acontecer, então a expectativa morre. Recompensa variável faz o oposto: como você nunca sabe se dessa vez vai cair, cada tentativa carrega expectativa. É a mesma estrutura de uma máquina caça-níquel, e essa comparação não é exagero retórico, é literal.

Isso vem da psicologia comportamental. Os experimentos clássicos de condicionamento do B.F. Skinner mostraram que reforço em intervalo variável produz o comportamento mais persistente de todos os cronogramas testados: o sujeito continua repetindo a ação mesmo quando a recompensa demora, justamente porque a próxima tentativa sempre pode ser a premiada.

Dopamina: o jogador não fica viciado no item

Aqui vale desfazer um mito comum. A leitura popular é "ganhar o item libera dopamina, então o jogador busca o item". A pesquisa em neurociência aponta pra algo mais sutil: a dopamina está fortemente ligada à antecipação e à previsão de recompensa, não só ao recebimento. O pico de interesse acontece antes e durante a incerteza, naquele momento em que o baú está abrindo e o resultado ainda não apareceu.

Na prática de design, isso muda tudo:

• A revelação precisa ter tempo. Baú que abre instantâneo desperdiça o momento mais valioso do ciclo. Animação de abertura, brilho que indica raridade antes do item aparecer, som que cresce. Jogos de cartas e gachas inteiros são construídos em cima desses dois segundos.
• Quase-acerto é combustível. O drop raro que não veio, mas o brilho indicou que quase veio, mantém o jogador no loop. É também a ferramenta mais fácil de usar de forma abusiva, e eu volto nisso na parte de ética.
• A incerteza é o produto. Se o jogador souber com precisão o que vai receber, a abertura do baú vira transação. A graça está em não saber.

Você não precisa de jogo de azar pra usar isso bem. Um roguelike que sorteia upgrades a cada sala, um RPG de ação com drops raros de chefe, um jogo de fazenda em que a colheita pode vir com qualidade extra: tudo isso é recompensa variável aplicada de forma honesta.

Implementando uma drop table em GDScript

Chega de teoria, vamos pro código. O coração de qualquer sistema de loot é a drop table com pesos: cada item tem um peso, e a chance dele cair é o peso dele dividido pelo peso total. Esse é o padrão que praticamente todo jogo com loot usa, do indie ao AAA.

extends Node

# Quanto maior o peso, mais comum o item.
# Chance real = peso do item / soma de todos os pesos.
var drop_table = [
    {"item": "ouro", "peso": 60},
    {"item": "pocao", "peso": 25},
    {"item": "equipamento_raro", "peso": 12},
    {"item": "equipamento_lendario", "peso": 3},
]

func sortear_drop() -> String:
    var peso_total = 0
    for entrada in drop_table:
        peso_total += entrada.peso

    var sorteio = randi_range(1, peso_total)
    var acumulado = 0
    for entrada in drop_table:
        acumulado += entrada.peso
        if sorteio <= acumulado:
            return entrada.item

    return drop_table[0].item

Com esses pesos, o total dá 100, então fica fácil ler: 60% ouro, 25% poção, 12% raro, 3% lendário. Mas os pesos não precisam somar 100. Pode ser 6, 2 e 1, e a conta continua funcionando. Isso facilita muito o balanceamento: quer deixar um item duas vezes mais comum, dobra o peso dele e pronto, sem recalcular o resto da tabela.

Duas decisões de design que valem mais que o código:

Separe tabela por contexto. Chefe tem uma tabela, inimigo comum tem outra, baú escondido tem outra. Misturar tudo numa tabela só com modificadores vira um nó impossível de balancear depois.

Logue os drops durante o desenvolvimento. Rode mil sorteios num loop e imprima a distribuição. Intuição humana é péssima com probabilidade: aquele "3% tá de boa" pode significar que um jogador médio termina o jogo sem ver o item lendário nem uma vez.

Pity system: protegendo o jogador do azar extremo

Probabilidade pura tem um problema cruel: ela não tem memória. Com 3% de chance, existe jogador que vai tirar o lendário na primeira tentativa e jogador que vai ficar 150 tentativas sem ver nada. O primeiro nem percebe; o segundo desinstala o jogo se sentindo roubado, mesmo que a matemática esteja certíssima.

O pity system (sistema de piedade, em tradução direta) resolve isso garantindo um teto pro azar: depois de N tentativas sem o item raro, ele vem garantido. Genshin Impact popularizou o termo, mas a ideia aparece em vários jogos com loot, às vezes disfarçada de "chance que aumenta a cada tentativa".

const PITY_LIMITE = 40

var contador_pity = 0

func sortear_com_pity() -> String:
    contador_pity += 1

    # Estourou o limite de azar: entrega o raro garantido.
    if contador_pity >= PITY_LIMITE:
        contador_pity = 0
        return "equipamento_lendario"

    var item = sortear_drop()
    if item == "equipamento_lendario":
        contador_pity = 0  # sorte natural também zera o contador

    return item

Repare que o contador zera nos dois caminhos: quando o pity dispara e quando a sorte natural entrega o item antes. Esquecer o segundo caso é um bug clássico que deixa o sistema mais generoso do que o planejado.

Pity system é uma daquelas mecânicas que custam dez linhas de código e salvam a experiência de uma fatia real dos seus jogadores. Se o seu jogo tem qualquer drop raro que importa pra progressão, considere ter um.

A linha ética: onde design vira manipulação

Tudo que eu descrevi até aqui é ferramenta. E ferramenta de recompensa variável é poderosa o suficiente pra ter atraído regulação de governo: a Bélgica, por exemplo, passou a tratar loot boxes pagas como jogo de azar em 2018, e vários países seguem debatendo o tema. Não é pânico moral à toa. A diferença entre um roguelike divertido e uma máquina de extração está em algumas escolhas concretas:

Recompensa variável + dinheiro real é outra categoria. Drop aleatório que custa tempo de jogo é design. Drop aleatório que custa cartão de crédito é aposta, e o público inclui adolescente. Se o seu modelo de negócio depende disso, você precisa encarar essa conversa de frente, não fingir que é "só cosmético".

Probabilidade escondida é desonestidade. Se o jogador paga (em dinheiro ou em grind pesado) por uma chance, ele merece saber a chance. Alguns mercados já obrigam a divulgação das taxas de gacha. Mesmo onde não é lei, esconder o número é escolher o lado errado.

Quase-acerto fabricado é manipulação. Uma coisa é o azar natural de quase tirar o item. Outra é programar a animação pra parecer que quase veio com mais frequência do que a probabilidade real produziria. Isso é técnica documentada de caça-níquel, e importar ela pro seu jogo diz muito sobre o que você está construindo.

Pergunta honesta de auto-teste: se o jogador soubesse exatamente como o seu sistema funciona por dentro, ele se sentiria respeitado ou enganado? Sistema de recompensa bom sobrevive à transparência. Sistema abusivo depende do escuro.

Minha posição, depois de anos vendo esse mercado: use recompensa variável pra deixar o jogo mais vivo, use pity pra proteger quem tem azar, mostre as taxas, e mantenha dinheiro real longe de sorteio. Você abre mão de um modelo de receita agressivo e ganha uma base de jogadores que confia em você. No longo prazo, esse é o ativo mais difícil de comprar.

Fechando

Sistema de recompensa não é polimento de fim de projeto, é estrutura. Decide se o jogador volta amanhã e com qual sentimento ele fecha o jogo hoje.

O caminho prático: misture recompensa intrínseca e extrínseca, use variabilidade pra manter expectativa viva, implemente a drop table com pesos (e teste a distribuição com sorteios em massa, não com intuição), coloque um pity system em qualquer drop que importe, e passe tudo pelo filtro da transparência.

Se quiser fixar o conteúdo, pegue os dois scripts desse artigo, jogue num projeto Godot vazio e rode dez mil sorteios imprimindo a distribuição com e sem pity. Ver os números de verdade ensina mais sobre balanceamento de loot do que qualquer texto, inclusive esse.