Le contenu suivant couvre divers concepts et tactiques pour améliorer la sécurité et atténuer la triche dans vos expériences Roblox. Il est fortement recommandé que tous les développeurs le lisent pour s'assurer que vos expériences sont sécurisées et équitables pour tous les utilisateurs. Consultez la barre latérale pour des sujets de sécurité supplémentaires.
Les décisions de conception de base peuvent servir de mesures de sécurité "première étape" pour décourager les exploits. Le principe de base est de concevoir des systèmes où la triche est soit impossible, soit ne procure aucun avantage significatif, plutôt que d'essayer de détecter et de prévenir la triche après coup.
Considérez un jeu de tir où les joueurs gagnent des points pour les éliminations. Un exploiteur pourrait créer des bots qui se téléportent au même endroit pour être tués à plusieurs reprises et gagner facilement des points. Ce scénario illustre la différence entre les approches réactives et défensives :
| Approche | Résultat prévisible |
|---|---|
| Poursuivre les bots en écrivant du code qui tente de les détecter (approche réactive). | Les exploitants cherchant des points rapides trouveront un moyen de contourner votre code de détection complexe et utiliseront leurs bots d'une manière différente. |
| Réduire ou supprimer complètement les gains de points pour les éliminations sur les joueurs nouvellement apparus (approche défensive). | Un temps et des frictions supplémentaires sont désormais nécessaires pour les exploitants car ils ne gagnent aucun point pour avoir tué instantanément leurs bots. De plus, les "campers de spawn" sont découragés car ils ne gagnent plus de points pour avoir tué des joueurs nouvellement apparus. |
Scénarios de conception défensive supplémentaires :
| Scénario potentiel d'exploitation | Approche réactive (moins efficace) | Approche défensive (plus efficace) |
|---|---|---|
| (Obby) L'exploiteur se téléporte à la fin pour réclamer des récompenses | Vérifier uniquement la position finale du joueur et essayer de détecter des temps de complétion impossibles | Concevoir avec des points de contrôle obligatoires et séquentiels. Le serveur valide que chaque point de contrôle a été activé dans l'ordre avant d'accorder des récompenses. Vous pouvez ajouter une autre couche en signalant les joueurs qui complètent des étapes plus rapidement que ce qui est humainement possible. La conception de l'expérience (exigeant des points de contrôle) permet la validation efficace côté serveur. |
| (Combat) Le client rapporte des montants de dégâts impossibles | Essayer de détecter et de filtrer les valeurs de dégâts impossibles | Le serveur calcule tous les dégâts à partir des statistiques d'arme côté serveur et valide les coups via le raycasting côté serveur |
| (Économie) L'exploiteur duplique des objets via des requêtes rapides | Essayer de détecter des requêtes en double ou des motifs inhabituels | Mettre en place des temps de recharge côté serveur et valider toutes les transactions par rapport à l'état actuel de l'inventaire du joueur |
Lors de la conception d'une nouvelle fonctionnalité, demandez-vous : "Comment un exploiteur pourrait-il abuser de cela, et puis-je modifier la conception pour rendre cet abus impossible ou sans valeur ?" Au lieu d'essayer de détecter la triche après qu'elle se soit produite, concevez votre expérience de façon à ce que la triche ne puisse pas se produire ou ne procure aucun avantage significatif.