O conteúdo a seguir abrange vários conceitos e táticas para melhorar a segurança e mitigar trapaceiros em suas experiências no Roblox. É altamente recomendável que todos os desenvolvedores leiam isso para garantir que suas experiências sejam seguras e justas para todos os usuários. Confira a barra lateral para tópicos adicionais de segurança.
Esta seção assume que você já valida entradas e contexto (veja seções anteriores). Este artigo aborda o que fazer depois que uma solicitação é tecnicamente válida, mas o comportamento parece abusivo, além de como responder sem prejudicar jogadores legítimos.
Filosofia
- O servidor decide. A detecção e a consequência ocorrem no servidor. Tente nunca banir com base em detecções do lado do cliente, pois os exploradores podem facilmente ignorá-las.
- Prevenir danos primeiro. Neutralize silenciosamente o impacto de uma exploração. Por exemplo, se um jogador está usando hack de velocidade, simplesmente leve-o de volta à sua última posição válida em vez de expulsá-lo imediatamente. A punição deve ocorrer apenas quando necessário para proteger a experiência ou outros jogadores.
- Seja proporcional e reversível. Assuma que falsos positivos podem acontecer. Prefira ações que você possa reverter, como suspensões temporárias ou remoção de recursos, em vez de bans permanentes.
- Design > detecção. Sua principal segurança vem de validações robustas e limites de taxa (cobertos em Garantindo a fronteira cliente-servidor e outras seções). Os métodos de detecção abaixo são destinados a complementar essas defesas, não substituí-las.
Heurísticas
Heurísticas são verificações de comportamento que sinalizam ações que são tecnicamente possíveis, mas altamente improváveis para um jogador legítimo. Elas são "regras práticas" para capturar atividade suspeita que escapa à validação básica. Uma heurística eficaz compara a ação de um jogador contra um máximo teórico ou uma linha de base razoável.
Por exemplo, se um jogador de repente afirma ter ganhado 1 bilhão de moedas em seu jogo simulador, sua validação remota pode confirmar que a solicitação está estruturada corretamente. Mas uma verificação heurística no servidor saberia que ganhar tanto deveria levar semanas, e não segundos, e sinalizaria a transação como suspeita.
Aqui estão três exemplos clássicos de heurísticas do lado do servidor. Cada uma valida o comportamento do jogador em relação às regras e limitações físicas da experiência, criando uma forte defesa contra explorações comuns.
| Heurística do lado do servidor | Descrição | Exemplo |
|---|---|---|
| Tempo de Conclusão Mais Rápido | Calcule o tempo teoricamente mais rápido possível para concluir uma tarefa, como um percurso de obstáculos. Isso envolve encontrar o caminho ótimo e assumir a velocidade máxima do jogador. | Em um obby, se o recorde mundial é de 30 segundos, um tempo de conclusão de 5 segundos é um forte sinal de teletransporte ou exploração de velocidade. |
| Taxa de Ganho | Acompanhe a taxa máxima legítima na qual um jogador pode ganhar um recurso (moeda, experiência, itens). | Se um jogador pode ganhar legitimamente 100 moedas por minuto, um ganho repentino de 10.000 moedas em um segundo deve ser sinalizado. |
| Cadência de Ação | O servidor analisa os intervalos de tempo entre as ações repetidas de um jogador. As entradas humanas têm variações naturais leves no tempo, enquanto scripts de automação simples (como auto-clickers) frequentemente executam ações com consistência robótica. | Em um minigame de pesca, um jogador clica para lançar sua linha. O servidor registra o timestamp de cada lançamento. Se o jogador lança sua linha 100 vezes seguidas com o mesmo intervalo exato (por exemplo, exatamente 2,500 segundos) entre cada ação, é um forte indicador de um macro ou bot. O tempo de um humano naturalmente flutua. |
Qualquer um desses exemplos pode não ser suficiente por si só para condenar um trapaceiro. Cada um deve ser tratado como um sinal, não como prova definitiva. Uma boa prática é implementar uma pontuação de suspeição. Quando um jogador falha em uma verificação heurística, você aumenta sua pontuação. Ações severas, como expulsão ou banimento, devem ocorrer apenas após múltiplas detecções variadas terem elevado a pontuação de um jogador além de um alto limite.
Por exemplo, suponha que um jogador habilidoso termine seu obby com um tempo recorde, acionando sua heurística de "Tempo de Conclusão Mais Rápido". Eles devem ser banidos? É possível que estejam explorando, mas também podem ter descoberto um atalho legítimo, mas não intencional. Banir com base nesse único sinal seria arriscado e poderia prejudicar um dos seus jogadores mais dedicados.
No entanto, se a corrida desse mesmo jogador também acionou a heurística de "Cadência de Ação" por entradas consistentemente não humanas, e uma hora depois eles acionam a heurística de "Taxa de Ganho" em seu lobby, o caso se torna muito mais forte. A combinação desses diferentes sinais pinta um quadro muito mais confiável de trapaça. A força desse sistema reside na correlação de múltiplos pontos de dados para construir um caso confiável antes de tomar uma ação.
Armadilhas
Uma maneira de detectar trapaceiros tentando sondar os RemoteEvents da sua experiência é usar um dispositivo de disfarce chamado armadilha. Uma armadilha é um RemoteEvent ou RemoteFunction que parece legítimo para um explorador, mas nunca é usado por nenhum dos seus scripts de cliente legítimos. Como nenhum jogador normal deve ser capaz de disparar essa remota, qualquer tráfego que ela receba deve vir de um explorador. Quando o servidor detecta essa remota sendo disparada, é um sinal de alta confiança de que o cliente está interferindo. A melhor ação imediata é registrar o incidente e expulsar o jogador da sessão.
Outra variação é projetar RemoteEvents com propósitos direcionais específicos - algumas exclusivamente para comunicação de cliente → servidor e outras exclusivamente para comunicação de servidor → cliente. Embora os nomes dos eventos não revelem sua direção pretendida, o servidor acompanha qual direção cada remota deve ser usada. Se um explorador tentar disparar uma remota de servidor → cliente a partir do cliente, isso serve como um método de detecção confiável, pois a jogabilidade legítima nunca acionaria a comunicação na direção errada.
Aplicando consequências
Quando os sistemas de detecção sinalizam comportamentos suspeitos, considere cuidadosamente sua estratégia de resposta. Experiências diferentes requerem abordagens diferentes com base em sua comunidade, apostas competitivas e tolerância à interrupção.
A escada de consequências - A maioria das experiências se beneficia de respostas escalonadas em vez de pular diretamente para bans permanentes:
- Registro silencioso - Crie evidências sem impacto no jogador
- Mitigação silenciosa - Bloqueie o efeito da exploração (abortando solicitações, limitando valores, sincronizando estado correto)
- Restrições temporárias - Limite capacidades específicas (comércio, tabelas de classificação, emparelhamento)
- Aplicação visível - Expulsões, suspensões temporárias ou bans permanentes
Considerações para sua estratégia
- Atrase consequências visíveis para evitar ensinar aos exploradores exatamente o que acionou a detecção
- Combine a severidade com a resposta - explorações econômicas menores podem justificar um tratamento diferente do que trapaças que quebram o jogo
- Considere sua comunidade - experiências competitivas podem precisar de aplicação mais rigorosa do que experiências casuais
- Planeje para erros - prefira ações reversíveis quando a confiança na detecção for menor
Para infratores persistentes, considere usar a Ban API em vez de confiar apenas em expulsões. A API de Ban impede que jogadores banidos se juntem novamente e proporciona um melhor rastreamento em todo o seu universo. Versione suas regras de detecção e rastreie as taxas de consequência para que você possa identificar sistemas problemáticos. Monitore o feedback dos jogadores para avaliar se sua aplicação parece justa para a comunidade. O equilíbrio certo depende inteiramente das necessidades da sua experiência e das expectativas de seus jogadores.