Anticheating côté client dans le jeu multijoueur 1vs1


8

Je développe un jeu de cartes simple, où il y aura un système de matchmaking qui vous opposera à un autre joueur humain. Ce sera le seul mode de jeu disponible, un 1vs1 contre un autre humain, pas d'IA.

Je veux éviter autant que possible de tricher. J'ai déjà lu beaucoup de questions similaires ici et je sais déjà que je ne peux pas faire confiance au client et je dois faire toutes les vérifications côté serveur. J'ai l'intention d'avoir un serveur (j'en ai besoin de toute façon pour le matchmaking) et j'ai l'intention de faire quelques vérifications côté serveur mais si je veux tout vérifier côté serveur, mon serveur pourra suivre l'état de tous les jeux actuels et vérifiez chaque action, et je n'ai pas l'argent / l'infrastructure pour prendre en charge ce serveur.

Mon idée est de faire vérifier et vérifier par les clients certaines des actions effectuées par leur adversaire * et s'ils trouvent une action illégale, notifiez la tricherie possible au serveur et faites-le vérifier. Cela nécessitera toujours que mon serveur garde une trace de tous les jeux en cours, mais cela économisera des ressources en vérifiant uniquement certaines choses qui ne peuvent pas être vérifiées côté client (comme l'ordre des cartes dans le jeu) et en vérifiant uniquement d'autres choses lorsqu'elles sont réellement erronées.

* (seulement ceux avec lesquels ils peuvent vérifier sans se permettre de tricher! par exemple: ils ne peuvent pas vérifier si la carte jouée était en main car ils auront besoin de connaître toutes les cartes en main)

En résumé, mes questions sont les suivantes : est-ce une approche viable? vais-je réellement économiser des ressources en faisant cela ou la complexité supplémentaire du serveur et du client pour échanger ces messages ne vaut-elle pas la peine? connaissez-vous un jeu qui a réussi ou échoué une approche similaire?

Merci à tous d'avoir lu et répondu


Bien sûr, alors vous auriez besoin de valider ces contrôles côté client ...
ThorinII

oui, l'idée est de sauvegarder certaines validations en vérifiant uniquement ces vérifications côté client, pas toutes les actions. Mais comme l'a dit Philip, c'est probablement une optimisation prématurée
garcianavalon

Réponses:


8

Selon la complexité de votre jeu, vérifier si une action est légale ou non peut nécessiter de revenir en arrière sur de grandes parties du jeu. Un exemple: le joueur A dit que le joueur B ne peut pas jouer cette carte pour le moment car il n'a pas de ResourceX. PlayerB dit qu'il a beaucoup de ResourceX. Qui a raison? Pour découvrir, vous simuleriez à nouveau le jeu entier du début à la fin pour compter le ResourceX que le PlayerB a en ce moment. Donc, seulement vérifier les actions des joueurs quand on crie "faute" pourrait ne pas être vraiment une optimisation.

Mais l'effort en vaut-il vraiment la peine?

Je pense que vous pourriez avoir un cas d' optimisation prématurée ici. Bien que je ne sache pas exactement ce que vous faites, un jeu de cartes n'est généralement pas si cher en termes de calcul côté serveur.

Les jeux de cartes sont généralement conçus pour être joués sans support informatique, de sorte que leurs mécanismes de jeu sont généralement suffisamment simples pour être exécutés par des humains *. De plus, les joueurs humains prennent généralement plusieurs secondes pour faire un mouvement, ce qui ressemble à l'éternité pour le serveur. Cela signifie que votre serveur n'a qu'une tâche légère à effectuer toutes les quelques secondes par partie. Je ne sais pas combien de joueurs simultanés vous attendez, mais tant que vous êtes encore à l'échelle d'un projet de loisir non commercial, je doute que même le serveur le moins cher que vous puissiez trouver ne pourra pas le gérer. Sur la prémisse, bien sûr, que vous savez programmer efficacement.

*) tant que vous excluez la prise de décision des joueurs. La plupart des jeux partent du principe que la stratégie gagnante idéale peut théoriquement être calculée, mais cela est si complexe que les joueurs et souvent même les ordinateurs ne sont pas en mesure de le faire, ils doivent donc utiliser l'intuition. Mais vous avez dit que vous ne vouliez pas d'intelligence artificielle et que vous vouliez seulement joueur contre joueur, donc cela sort du cadre de cette question. Mais cela fait aussi penser à un autre aspect de la triche: avez-vous envisagé qu'un joueur utilise un programme pour l'aider à prendre des décisions? Comme celui qui leur dit la probabilité exacte que l'adversaire ait une certaine carte en main?


Je pense que vous avez raison, j'essaie d'éviter de surcharger le serveur avant de surcharger réellement. Le fait que vous ayez répondu à ma question avec la même question (l'effort en vaut-il vraiment la peine) résume-t-il assez bien
garcianavalon

Pour les autres visiteurs, notez que, à moins qu'il ne s'interface réellement avec le code du jeu (et potentiellement même alors), la capacité de détecter un programme externe fournissant une aide `` probabiliste '' est essentiellement nulle.
Clockwork-Muse

4

"Je veux éviter autant que possible de tricher." - Alors disons-nous tous. :)

Une approche plus sensée consiste peut-être à ne pas perdre de temps à faire quoi que ce soit au-delà des mesures anti-triche raisonnables et généralement efficaces.

Ce sont: un double test de bogues qui permettrait aux joueurs d'effectuer des actions illégales, et l'envoi de données chiffrées uniquement (via https ou un chiffrement personnalisé), et le chiffrement de l'application elle-même pour rendre le piratage plus difficile. C'est ça.

Les joueurs sont plus susceptibles de tricher à travers des bugs dans le jeu qu'autre chose.

Vous pourriez simplement faire mieux, en termes de développement, d'attendre que vos joueurs se soucient vraiment de tricher. Si l'application n'est pas dans un "top 500" figuratif et que la tricherie n'est pas simple (les bugs, par exemple), les joueurs ne se soucieront pas suffisamment de perdre leur temps à essayer de tricher à travers d'autres mesures, telles que la modification du flux IP ou le piratage du app.

À moins bien sûr que vous n'utilisiez de l'argent réel et des prix réels ici.

Si votre application réussit et que la triche devient un problème, c'est à ce moment que vous devez vous y attaquer. Mais à ce stade, ce sera un jeu de chat et de souris, et les tricheurs gagneront toujours.

Fondamentalement, ce que je dis, c'est que 100% de vos joueurs ne tricheront pas si ce n'est pas possible grâce à un bug reproductible et / ou si votre application n'est pas très populaire. Si votre application devient très populaire, moins de 1% de vos joueurs tricheront d'une manière que vous ne pouvez même pas imaginer.

En ce qui concerne la triche, vous devez vous protéger contre les tricheurs évidents (bogues, chiffrer à la fois l'application et le flux IP) et ne réagir qu'aux tricheurs réels dont vous avez connaissance et les traiter directement. Ce que vous voulez vraiment, c'est consigner toutes les actions des joueurs, les faire vérifier sur le serveur et si vous trouvez une action illégale qui se produit assez souvent, découvrez pourquoi. Cela pourrait être un bug, un exploit, un piratage technique.

La mesure anti-triche la plus importante est d'apprendre que les joueurs trichent et comment.


merci, une très bonne réponse aussi. Cela n'a aucun sens de passer du temps à essayer de faire la meilleure solution anti-triche tout en ayant des bogues exploitables, je travaillerai avant dans les choses essentielles que chaque jeu a besoin de protection et ensuite résoudre les problèmes qui apparaissent, plutôt que l'inverse!
garcianavalon

0

Je pense que vous rencontrez d'autres problèmes ici. Que faire si le joueur fait semblant d'être un client normal (en simulant votre trafic réseau) et utilise pour corrompre votre jeu par une mauvaise validation?

Au lieu d'essayer de construire un système client à l'épreuve des balles, ce qui vous mènera à la correction et à l'interdiction continues des bogues / exploits, j'essaierais de simplifier le système du serveur. Je ne connais pas assez votre mécanisme de jeu, mais peut-être pouvez-vous réduire au minimum les informations sur le serveur.

En général, vous devez supposer que le client avec lequel vous parlez peut déployer n'importe quel code et mécanisme de jeu qu'il a l'impression de déployer. Et cela rend la validation côté client presque impossible


0

Cela dépend un peu de ce que vous considérez comme de la triche. Utilise-t-il un outil pour effectuer / calculer les mouvements? Est-ce pour changer le jeu de cartes pendant le jeu? La première chose sera difficile à aborder. Pour le second, vous pouvez penser à ce que chaque utilisateur insère ses cartes et crée un code de hachage affiché des deux côtés. À la fin, le serveur peut calculer le hachage avec les cartes jouées et les cartes restantes. Si un hachage ne correspond pas, l'utilisateur a triché. Si les règles n'ont pas été respectées, vous pouvez également vérifier cela sur votre serveur. Vous pouvez le faire à la demande d'un utilisateur pour économiser des ressources. Aucune information sur les cartes n'est disponible. Pour rendre la génération du hachage un peu plus unique / complexe, vous pouvez inclure le nom d'utilisateur dans le hachage.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.