La plupart des erreurs de débutant rencontrées dans la programmation de jeux multijoueurs / en ligne?

Question

Quel genre d'erreurs de débutant vous avez vu et quels sont les remèdes?

C’est ce qui se produit encore et encore si le client n’est pas comparé au serveur.

Par exemple:

• L'utilisateur décompile une source de jeu flash ou écoute le trafic réseau et voit où vont les données de score élevé.
• L'utilisateur utilise trainer et obtient un objet qui peut même ne pas apparaître au niveau actuel. Cela a été envoyé au serveur comme "le client X a reçu l’article Y". et le serveur accepte simplement cela.

La solution simple est bien sûr de gérer le client de jeu uniquement en tant qu’API vers le serveur. Ensuite, l’utilisateur peut utiliser autant de formateurs que de mémoire, mais le serveur dit simplement que vous ne pouvez pas le faire. Pensez serveur comme une base de données sur laquelle vous pouvez interroger des objets avec des règles de jeu.

Par exemple

• Client: démarre le jeu
• Client: se connecte au serveur
• Client: interroge le montant d'argent disponible sur le serveur
• utilisateur: active l'entraîneur qui définit l'argent à l'infini
• Client: server.buyItem ('très cher')
• Serveur: vérifie le statut du joueur (l'utilisateur peut acheter des objets maintenant). Vérifie le joueur [0] .money - > pas de bonus.
• Client: server.buyItem ('peut l'obtenir')
• Serveur: vérifie le statut du joueur (l'utilisateur peut acheter des objets maintenant). Vérifie le joueur [0]. Argent, ok. player [0] .items.add ('peut l'obtenir') ce qui réduira le coût du joueur [0] .money. Ensuite, informez le client d’envoyer (joueur [0], "éléments", "peut obtenir ceci"); envoyer (joueur [0], 'argent', joueur [0]. argent).

L’autre méthode consiste à enregistrer les mouvements du client et à les envoyer au serveur avec les scores les plus élevés, où le serveur les lit. Bien sûr, cela peut conduire à ce que le disque est très gros.

Answer 1

Sans aucun doute, une confiance aveugle du client. Dans un jeu sur lequel je travaille, nous conservons désormais toute la "logique métier". côté serveur, et les machines clientes ne nous envoient que les commandes qu’elles font; Par exemple, "le joueur B veut aller à droite". - mais le serveur calcule jusqu'où ils se sont déplacés vers la droite. Cela entraîne une surcharge de performances (et bien sûr des problèmes de décalage qui pourraient être mieux gérés), de sorte qu'un moyen terme pourrait consister à effectuer les calculs lourds côté client, tout en maintenant des contrôles en place sur le serveur; par exemple, vérifier si le lecteur du client bouge plus qu'il est supposé possible entre les mises à jour; c’est-à-dire si la vitesse maximale du lecteur est de 200 unités / seconde, si vous obtenez une mise à jour au bout de 0,5 seconde indiquant qu’ils ont déplacé 150 unités, démarrez-les.

Bien sûr, cela n'empêche pas nécessairement quelqu'un de coder un bot pour envoyer ces touches, il existe donc d'autres moyens de se prémunir contre cela. Cependant, ne pas avoir de validation du tout est une erreur de débutant (dont j’étais coupable quand j’ai pris des raccourcis)

Answer 2

L’approche adoptée par Valve (du moins à un moment donné) consistait à faire en sorte que les clients et le serveur simulent le jeu de manière indépendante. Ensuite, le serveur effectue la simulation faisant autorité et envoie des mises à jour de statut à tous les clients pour corriger leurs erreurs / tentatives de piratage.

E.g. si vous appuyez sur la flèche gauche, votre personnage se déplacera immédiatement à gauche; il n'y a pas d'attente pour que le serveur dise 'OK'. Mais s'il s'avère que vous vous êtes piraté à travers un mur, la prochaine mise à jour du serveur vous fera apparaître juste à côté du mur, car le serveur le voit comme solide.

De même, si un client voit un personnage avancer, il supposera qu'il continuera à avancer jusqu'à ce que le serveur revienne avec une réponse faisant autorité.

Cette approche annule les tentatives de piratage lorsque le serveur prend les décisions principales (et effectue des vérifications de cohérence dans le processus de simulation). Elle traite également les retards lorsque les clients font des prédictions jusqu'à ce qu'ils reçoivent un message du serveur.

Une autre grosse erreur liée à la "confiance du client" est de penser que votre protocole réseau ne peut être falsifié. Les gens ont tendance à penser que s’ils envoient des morceaux binaires au serveur, ils ne feront jamais l’objet d’une ingénierie inverse et que personne ne tentera de jouer avec les données pour voir ce qui se passe. Cela a conduit à toutes sortes de problèmes.

Answer 3

Vous avez pratiquement couvert tout ce qui peut mal se passer avec les clients qui font confiance au serveur. Je ne peux penser à aucun autre problème réel.

Au lieu de vous dire ce qui peut mal tourner, regardez ce qui peut bien se passer.

Valve a consacré beaucoup de travail à son netcode . Lisez-le