Anti-Cheat em Jogo Online Indie: O Que Fazer na Prática

Você lançou seu jogo online, as primeiras partidas estão rolando, e aí aparece o jogador que atravessa paredes, dá dano infinito ou farma mil moedas por minuto. A pergunta que todo dev indie faz nesse momento é: que anti-cheat eu consigo implementar de verdade, sem equipe de segurança e sem orçamento de estúdio grande? A resposta honesta é que a maior parte da defesa não é um software misterioso, é arquitetura: decisões que você toma no design do seu servidor e que custam mais disciplina do que dinheiro. Este post é 100% defensivo, do ponto de vista de quem quer proteger o próprio jogo.

Por que cheat destrói um jogo online

Antes da técnica, o motivo. Trapaça em jogo online não é um incômodo pontual, é um veneno que age em três órgãos vitais do jogo ao mesmo tempo.

Primeiro, a economia. Se o seu jogo tem recursos, moedas ou itens, um único jogador duplicando ou farmando em velocidade impossível infla a economia inteira. O esforço dos jogadores honestos perde valor, porque o que levava dez horas pra conquistar agora circula de graça. Economia quebrada não se conserta com patch, se conserta com wipe, e wipe irrita todo mundo.

Segundo, o ranking. Um placar competitivo só tem valor enquanto os jogadores acreditam nele. No dia em que o topo da tabela é ocupado por contas suspeitas, o jogador honesto para de competir, porque competir contra trapaça não é competir. Se você mantém um ranking online no seu jogo, ele é o primeiro alvo e a primeira vitrine do problema.

Terceiro, e mais grave, a retenção. Jogador que perde partidas pra cheater não abre ticket de suporte, ele desinstala. E antes de desinstalar, comenta na review. Jogo online pequeno vive de uma base de jogadores que já é apertada; cada partida arruinada por trapaça empurra gente pra fora de um pool que você precisa desesperadamente manter cheio, inclusive pro matchmaking continuar formando partidas em tempo razoável.

O princípio número 1 do anti-cheat: nunca confie no cliente

Se você levar uma única frase deste post, que seja esta: o cliente está na máquina do adversário. Todo o código que roda no computador do jogador pode ser lido, alterado e enganado por ele. Não importa o quão escondida está a sua variável de vida, o quão ofuscado está o seu binário: quem controla a máquina controla o programa.

A consequência prática é o modelo de servidor autoritativo. O servidor é a única fonte da verdade. O cliente não informa fatos, ele pede intenções: quero andar pra cá, quero atacar aquele alvo, quero comprar aquele item. O servidor recebe o pedido, verifica se ele é possível dentro das regras, executa a simulação e devolve o resultado oficial. O cliente exibe.

Compare com o modelo ingênuo, que é como a maioria dos primeiros protótipos multiplayer nasce: o cliente calcula o próprio dano e avisa o servidor, o cliente diz onde está e o servidor acredita, o cliente informa que pagou o custo da habilidade. Nesse modelo, trapacear não exige engenharia reversa sofisticada, exige mandar um número diferente. Você não tem um jogo online, tem um sistema de honra.

Servidor autoritativo tem custo: você paga pela máquina que roda a simulação e aceita a complexidade de predição e reconciliação pra esconder a latência. Esse custo entra na conta do projeto desde o início, e o post sobre quanto custa manter um servidor de jogo online ajuda a dimensionar. Mas pra qualquer jogo em que trapaça importa, esse é o preço do ingresso.

Validação no servidor: o que conferir em cada pedido

Autoridade do servidor só funciona se o servidor de fato valida. Quatro categorias cobrem a maioria dos cheats clássicos:

Posição e movimento. O servidor conhece a velocidade máxima do personagem. Se um jogador afirma ter se movido mais longe do que a física permite naquele intervalo, o pedido é inválido. Isso mata speedhack e teleporte na raiz.

Dano. O cliente nunca informa quanto dano causou. Ele informa que atacou, e o servidor calcula o dano a partir dos atributos que ele mesmo guarda: arma equipada, buffs ativos, distância, linha de visão.

Recursos. Toda transação de moeda, item ou material acontece no servidor, contra o inventário que o servidor guarda. Comprar algo sem saldo, vender item que não existe, receber recompensa duplicada: tudo isso é o servidor que impede, conferindo o estado antes de aplicar.

Cooldowns e taxas. Se a habilidade tem 5 segundos de recarga, o servidor guarda o timestamp do último uso e recusa qualquer ativação antes da hora, não importa quantas vezes o cliente peça.

Em Godot, uma validação de movimento server-side fica assim, com tipagem explícita:

const MAX_SPEED: float = 300.0
const TOLERANCE: float = 1.15  # folga para latência e arredondamento

var player_positions: Dictionary = {}
var flagged_moves: Dictionary = {}

func _validate_move(peer_id: int, new_pos: Vector2, tick_delta: float) -> bool:
    var current_pos: Vector2 = player_positions.get(peer_id, Vector2.ZERO)
    var distance: float = current_pos.distance_to(new_pos)
    var max_allowed: float = MAX_SPEED * tick_delta * TOLERANCE

    if distance > max_allowed:
        # Não aceita a posição e registra a ocorrência para telemetria
        var count: int = flagged_moves.get(peer_id, 0) + 1
        flagged_moves[peer_id] = count
        return false

    player_positions[peer_id] = new_pos
    return true

@rpc("any_peer", "call_remote", "unreliable")
func request_move(new_pos: Vector2) -> void:
    if not multiplayer.is_server():
        return
    var peer_id: int = multiplayer.get_remote_sender_id()
    if not _validate_move(peer_id, new_pos, get_physics_process_delta_time()):
        # Reenvia a posição oficial: o cliente é corrigido, não obedecido
        correct_position.rpc_id(peer_id, player_positions.get(peer_id, Vector2.ZERO))

Repare em dois detalhes de projeto. A tolerância existe porque latência e arredondamento geram pequenas divergências legítimas; validar com folga zero pune jogador honesto com conexão ruim. E a resposta a um movimento inválido não é banir na hora, é recusar, corrigir e registrar. Falso positivo acontece, e a punição vem da repetição do padrão, não de um evento isolado.

Detecção client-side: útil, mas nunca sozinha

Detecção client-side é o software que roda na máquina do jogador procurando sinais de trapaça: processos conhecidos de cheat, alteração de memória do jogo, injeção de código. É a parte que a maioria das pessoas imagina quando ouve anti-cheat.

Ela tem valor real: aumenta o custo de trapacear, barra as ferramentas mais populares e desencoraja o trapaceiro casual. Mas ela tem um limite estrutural que nenhum produto elimina: roda em território inimigo. Quem controla a máquina pode, com esforço suficiente, cegar ou enganar qualquer coisa instalada nela. É uma corrida armamentista permanente entre quem detecta e quem esconde.

Por isso a regra de dependência só funciona em uma direção. Servidor autoritativo sem client-side ainda é um jogo defensável: o trapaceiro fica limitado a automatizar ações que continuam válidas pelas regras. Client-side sem validação de servidor é teatro: no dia em que alguém contorna a detecção, e alguém sempre contorna, o servidor crédulo aceita qualquer absurdo. Construa a fundação primeiro, adicione a camada depois.

As camadas práticas que um indie consegue montar

Anti-cheat bom é cebola: várias camadas baratas, cada uma imperfeita, que juntas tornam a trapaça cara e arriscada. Estas estão todas ao alcance de um dev solo:

Autoridade do servidor. A fundação, já discutida. Sem ela, o resto é decoração.

Validação de input. Além de validar o resultado, valide o próprio pedido: o formato está correto, os campos fazem sentido, a ação existe, o alvo está ao alcance. Pedido malformado se descarta sem processar.

Rate limiting. Limite quantas mensagens por segundo cada conexão pode enviar, por tipo de ação. Humano nenhum ataca 80 vezes por segundo. Isso barra automação grosseira e de quebra protege o servidor de flood.

Sanidade de valores. Defina limites duros pra tudo que é numérico: dano máximo possível por hit, ouro máximo por transação, pontos máximos por partida. Valor fora do envelope físico do jogo é rejeitado e registrado, sem discussão.

Telemetria e replays. Grave métricas por jogador e por partida: dano por minuto, precisão, recursos por hora, distância percorrida. Cheater é, por definição, um outlier estatístico; quem fica com precisão de 98% enquanto a população inteira fica entre 20% e 60% merece revisão. Se o seu jogo grava os inputs da partida, um replay assistível é a melhor ferramenta de revisão manual que existe.

Report de jogadores. Um botão de reportar dentro do jogo transforma sua comunidade em sensor. Reports individualmente valem pouco, mas agregados apontam exatamente quem investigar primeiro. Cruze com a telemetria: reportado e outlier é prioridade máxima.

Bans progressivos. Escale a punição: aviso ou kick na primeira detecção fraca, suspensão temporária na reincidência, ban permanente com evidência forte. Progressividade protege você do falso positivo e ainda cria efeito dissuasório. Uma tática que funciona bem em jogos pequenos: em vez de banir na hora, agrupe os bans em ondas periódicas, porque o cheater que não sabe qual ação o entregou não sabe o que corrigir.

Soluções prontas: EAC, VAC e quando adotar

Você não precisa construir a camada client-side sozinho, e provavelmente não deveria.

O Easy Anti-Cheat, da Epic Games, é oferecido gratuitamente aos desenvolvedores como parte do Epic Online Services, inclusive pra jogos distribuídos fora da loja da Epic. Ele cuida da detecção client-side, o jogo conversa com o serviço via SDK, e você herda uma base de detecção mantida por uma equipe dedicada, coisa que nenhum indie consegue manter sozinho. O custo real é a integração: trabalho de engenharia, processo de cadastro e suporte a plataformas que você precisa conferir na documentação atual.

O VAC, Valve Anti-Cheat, vem com o Steamworks pra jogos publicados na Steam. Ele detecta trapaças conhecidas e aplica banimentos na conta Steam do infrator, o que dói mais do que ban num jogo só. A integração é menos intrusiva que a do EAC, e o alcance de detecção também é mais conservador.

Quando adotar? Uma régua simples: adote uma solução pronta quando o seu jogo for competitivo o bastante pra atrair cheater dedicado e grande o bastante pra você não conseguir revisar casos manualmente. Antes disso, servidor autoritativo, telemetria e report cobrem a esmagadora maioria dos incidentes de um jogo pequeno. E lembre da direção da dependência: essas soluções somam à validação server-side, nunca a substituem.

O trade-off: quanto anti-cheat o seu jogo precisa

Anti-cheat custa tempo de desenvolvimento, atrito de instalação pro jogador e manutenção contínua. Gastar demais é tão erro quanto gastar de menos, então calibre pelo estrago que a trapaça causa no seu jogo específico.

Um cooperativo pequeno, de sessões privadas entre amigos, tolera bastante: o trapaceiro só estraga a própria mesa, e o anfitrião resolve com um kick. Validações básicas de servidor bastam, e instalar um anti-cheat de kernel nesse contexto seria atrito sem benefício.

Um jogo com economia persistente ou compartilhada já não tolera: um exploit de duplicação afeta todo mundo, mesmo quem nunca cruzou com o cheater. Aqui a validação de recursos e a telemetria de economia são inegociáveis.

Um competitivo ranqueado é o caso extremo: a integridade do placar é o produto. Cheat impune em ranqueada mata o jogo em semanas, porque a notícia se espalha mais rápido que o patch. É o cenário que justifica todas as camadas, incluindo solução client-side pronta e revisão ativa de reports.

A síntese cabe em três linhas. Nunca confie no cliente: essa decisão de arquitetura é 80% do seu anti-cheat e não custa licença nenhuma. Empilhe camadas baratas: validação, limites, telemetria, report, bans progressivos. E dimensione pelo dano: proteja com mais força aquilo que, quando quebrado, quebra o jogo pra todo mundo. Trapaceiro procura alvo fácil; seu trabalho não é ser imbatível, é ser caro o suficiente pra ele ir incomodar outro jogo.