Le contenu suivant couvre divers concepts et tactiques pour améliorer la sécurité et atténuer la tricherie dans vos expériences Roblox. Il est fortement recommandé à tous les développeurs de lire ces informations pour s'assurer que vos expériences sont sécurisées et équitables pour tous les utilisateurs. Consultez la barre latérale pour d'autres sujets de sécurité.
Cette section suppose que vous validez déjà les entrées et le contexte (voir les sections précédentes). Cet article couvre ce qu'il faut faire après qu'une demande soit techniquement valide mais que le comportement semble abusif, ainsi que comment réagir sans nuire aux joueurs légitimes.
Philosophie
- Le serveur décide. La détection et les conséquences résident sur le serveur. Essayez de ne jamais interdire en vous basant sur des détections côté client, car les exploiteurs peuvent facilement les contourner.
- Prévenir d'abord le mal. Neutralisez discrètement l'impact d'un exploit. Par exemple, si un joueur utilise un hack de vitesse, faites-le simplement revenir à sa dernière position valide au lieu de le kicker immédiatement. Punissez seulement lorsque c'est nécessaire pour protéger l'expérience ou les autres joueurs.
- Soyez proportionnel et réversible. Supposez que de faux positifs peuvent se produire. Préférez des actions que vous pouvez annuler, telles que des suspensions temporaires ou la suppression de ressources, plutôt que des interdictions permanentes.
- Conception > détection. Votre principale sécurité provient de validations robustes et de limitations de taux (couvrant Sécuriser la frontière client-serveur et d'autres sections). Les méthodes de détection ci-dessous sont censées compléter ces défenses, et non les remplacer.
Heuristiques
Les heuristiques sont des vérifications comportementales qui signalent des actions qui sont techniquement possibles mais hautement improbables pour un joueur légitime. Ce sont des "règles empiriques" pour détecter des activités suspectes qui échappent à la validation de base. Une heuristique efficace compare l'action d'un joueur à un maximum théorique ou à une norme raisonnable.
Par exemple, si un joueur prétend soudainement avoir gagné 1 milliard de pièces dans votre jeu de simulation, votre validation distante peut confirmer que la demande est structurée correctement. Mais une vérification heuristique sur le serveur saurait que gagner autant devrait prendre des semaines, pas des secondes, et signalerait la transaction comme suspecte.
Voici trois exemples classiques d'heuristiques côté serveur. Chacune valide le comportement du joueur par rapport aux règles et aux limites physiques de l'expérience, créant ainsi une défense solide contre les exploits courants.
| Heuristique côté serveur | Description | Exemple |
|---|---|---|
| Temps de complétion le plus rapide | Calculez le temps théorique le plus rapide possible pour accomplir une tâche, comme un parcours d'obstacles. Cela implique de trouver le chemin optimal et de supposer la vitesse maximale du joueur. | Dans un obby, si le record du monde est de 30 secondes, un temps de complétion de 5 secondes est un signal fort de téléportation ou d'exploits de vitesse. |
| Taux de gain | Suivez le taux maximum légitime auquel un joueur peut gagner une ressource (monnaie, expérience, objets). | Si un joueur peut légitimement gagner 100 pièces par minute, un gain soudain de 10 000 pièces en une seconde devrait être signalé. |
| Cadence d'actions | Le serveur analyse les intervalles de temps entre les actions répétées d'un joueur. Les entrées humaines ont des variations naturelles et légères dans le timing, tandis que les scripts d'automatisation simples (comme les auto-clickers) effectuent souvent des actions avec une constance robotique. | Dans un minijeu de pêche, un joueur clique pour lancer sa ligne. Le serveur enregistre l'horodatage de chaque lancé. Si le joueur lance sa ligne 100 fois de suite avec exactement le même intervalle (par exemple, précisément 2,500 secondes) entre chaque action, c'est un indicateur fort d'un macro ou d'un bot. Le timing d'un humain fluctuerait naturellement |
Un seul de ces exemples peut ne pas suffire à lui seul pour condamner un tricheur. Chacun devrait être considéré comme un signal, pas comme une preuve définitive. Une bonne pratique consiste à mettre en œuvre un score de suspicion. Lorsqu'un joueur échoue à une vérification heuristique, vous incrémentez son score. Des actions sévères comme le kicking ou l'interdiction ne devraient se produire qu'après que plusieurs détections variées ont poussé le score d'un joueur au-delà d'un seuil élevé.
Par exemple, supposons qu'un joueur habile termine votre obby avec un temps record, déclenchant votre heuristique "Temps de complétion le plus rapide". Devrait-il être banni ? Il est possible qu'il exploite, mais il pourrait également avoir découvert un passage légitime mais inattendu. Le bannir sur la base de ce seul signal serait risqué et pourrait nuire à l'un de vos joueurs les plus dévoués.
Cependant, si la course du même joueur a également signalé l'heuristique "Cadence d'actions" pour des entrées inhumainement constantes, et qu'une heure plus tard, il déclenche l'heuristique "Taux de gain" dans votre lobby, le cas devient bien plus solide. La combinaison de ces différents signaux brosse un tableau beaucoup plus fiable de la tricherie. La force de ce système réside dans la corrélation de plusieurs points de données pour établir un dossier solide avant d'agir.
Pièges à miel
Une manière de détecter les tricheurs essayant de sonder les RemoteEvents de votre expérience est d'utiliser un leurre appelé piège à miel. Un piège à miel est un RemoteEvent ou RemoteFunction qui semble légitime pour un exploiteur mais qui n'est jamais utilisé par aucun de vos scripts clients légitimes. Puisqu'aucun joueur normal ne devrait jamais être en mesure de déclencher ce remote, tout trafic qu'il reçoit doit provenir d'un exploiteur. Lorsque le serveur détecte ce remote étant déclenché, c'est un signal de haute confiance que le client manipule. La meilleure action immédiate est d'enregistrer l'incident et de kicker le joueur de la session.
Une autre variation consiste à concevoir des RemoteEvents avec des objectifs directionnels spécifiques - certains exclusivement pour la communication client → serveur et d'autres exclusivement pour la communication serveur → client. Bien que les noms des événements ne révèlent pas leur direction prévue, le serveur suit quelle direction chaque remote doit être utilisée. Si un exploiteur tente de déclencher un remote serveur → client depuis le client, cela constitue une méthode de détection fiable car le jeu légitime ne déclencherait jamais de communication dans la mauvaise direction.
Application des conséquences
Lorsque les systèmes de détection signalent un comportement suspect, envisagez soigneusement votre stratégie de réponse. Différentes expériences nécessitent des approches différentes en fonction de leur communauté, des enjeux compétitifs et de la tolérance à la perturbation.
L'échelle des conséquences - La plupart des expériences bénéficient de réponses escaladées plutôt que de sauter directement aux interdictions permanentes :
- Journalisation silencieuse - Constituez des preuves sans impact sur le joueur
- Atténuation discrète - Bloquez l'effet de l'exploit (rejeter les demandes, limiter les valeurs, synchroniser l'état correct)
- Restrictions temporaires - Limitez des capacités spécifiques (échanges, classements, matchmaking)
- Application visible - Kicks, suspensions temporaires ou interdictions permanentes
Considérations pour votre stratégie
- Retardez les conséquences visibles pour éviter d'apprendre aux exploiteurs exactement ce qui a déclenché la détection
- Faites correspondre la sévérité à la réponse - les exploits économiques mineurs peuvent nécessiter un traitement différent que les cheats de physique démontrant des ruptures de jeu
- Considérez votre communauté - les expériences compétitives peuvent nécessiter une application plus stricte que les expériences décontractées
- Planifiez des erreurs - privilégiez les actions réversibles lorsque la confiance dans la détection est plus faible
Pour les contrevenants persistants, envisagez d'utiliser l'API Ban plutôt que de vous fier uniquement aux kicks. L'API Ban empêche les joueurs bannis de revenir et fournit un meilleur suivi à travers votre univers. Versionnez vos règles de détection et suivez les taux de conséquences afin de pouvoir identifier les systèmes problématiques. Surveillez les retours des joueurs pour évaluer si votre application semble équitable pour la communauté. Le bon équilibre dépend entièrement des besoins de votre expérience et des attentes de vos joueurs.