Je prévois actuellement un simple jeu multijoueur en ligne. Et voici la question. Est-il judicieux de créer toute la logique du jeu sur le serveur et d'envoyer simplement l'entrée du client au serveur? Quels sont les avantages et les inconvénients ou y a-t-il des raisons pour lesquelles je ne devrais pas faire cela?
Réponses:
Vous ne voulez pas envoyer d'entrée de lecteur au serveur. Ce que vous voulez probablement faire, c'est envoyer une représentation abstraite de ce que le joueur veut faire au serveur, puis exécuter la logique là-bas.
De même, vous ne voulez pas nécessairement renvoyer tout ce que le client doit faire. Par exemple, vous pouvez envoyer une sorte de message disant "NPC X est mort" et le client détermine les animations / sons à jouer. Des trucs comme ça.
L'astuce consiste à trouver la ligne où la bande passante et la puissance de traitement (sur le serveur) sont trompées en empêchant les gens de tricher. Habituellement, vous prenez n'importe quelle décision faisant autorité qui change la donne sur le serveur uniquement, et vous laissez tout le matériel visuel auxiliaire au client.
Il y a beaucoup de questions plus spécifiques sur ce sujet partout dans le site. Par exemple:
Qui fait les calculs d'IA dans un MMO?
L'hôte du jeu devrait-il être l'autorité ou un autre client stupide?
Eh bien, vous avez des réponses, mais votre vraie réponse est «essayez-vous». Les choses diffèrent d'un jeu à l'autre.
J'ai fait quelques jeux multijoueurs pour un cours de conception de jeux en réseau distribué. Le plus difficile était de faire un jeu d'action en temps réel où de nombreux joueurs étaient impliqués et envoyaient des contributions comme l'enfer. À ce stade, tout devient problématique. Comme vous voyez le premier lien envoyé par Tetrat, même la détermination d'une collusion devient un problème. Et vous lirez-entendrez des termes comme décalage, interpolation, extrapolation, prédiction ... Mais si vous ne vous êtes jamais essayé à coder à partir de zéro, vous n'accepterez que ces mots et vous ne sauriez pas ce qu'ils signifient vraiment.
Ma recommandation est:
Étape 1
Commencez avec une conception basée sur serveur entièrement autorisée pour l'instant. Comme vous l'avez dit, il suffit d'envoyer des entrées utilisateur au serveur et de laisser le serveur faire tout et les clients obtiennent les résultats. Votre jeu fonctionnera parfaitement. Mais quand vous regardez vos clients, vous remarquerez des retards, des problèmes de téléportation, pas de mouvement en douceur ... ect.
Étape 2
Commencez à résoudre les problèmes côté client. Les problèmes de téléportation par exemple. Votre personnage était à (0,0) et le serveur a dit que vous étiez maintenant à (100,100). Votre personnage se téléportera juste à (100,100), ce qui n'est pas agréable. Voici l'interpolation. Vous devriez avoir un code côté client qui fera glisser le caractère de (0,0) à (100, 100) de manière fluide. Oui, vous déplacerez votre personnage de (0,0) à (100,100) mais à quelle vitesse? Pour l'instant, vous pouvez simplement utiliser le décalage horaire entre chaque mise à jour du serveur. Si votre serveur envoie 10 paquets en une seconde, cela signifie un délai de 100 ms entre chaque paquet.
Étape 3
Maintenant, votre jeu est déjà bon pour les réseaux rapides où il y a un retard de (1-50) ms. Mais il est condamné s'il y a une perte de paquets, une latence élevée ou un calcul long sur le serveur ... ect. Dans ces situations, vous remarquerez que lorsque vous appuyez sur la flèche gauche, vous verrez votre personnage se déplacer vers la gauche avec un retard de 200 ms. Le délai entre votre paquet va au serveur, le temps de calcul et vous revient avec votre dernière position. C'est mauvais, le pire inconvénient de la conception autorisée par le serveur. Le joueur veut que son personnage se déplace vers la gauche dès qu'il appuie sur la gauche, vous ne pouvez pas le faire attendre. Heureusement, le client a également le même code que le serveur, alors pourquoi ne pas l'exécuter immédiatement sur le client et fixer le résultat final avec la réponse du serveur? C'est ce qu'est fondamentalement la prédiction d'entrée. Le client appuie sur la gauche, le code de son côté le déplace vers la gauche, après un certain temps, disons 200 ms, la position réelle provient du serveur et le client corrige sa position avec lui. Si tout s'est bien passé, le client ne remarquera rien, "l'étape 2" nous aidera également avec cela.
Eh bien, net a de nombreux tutoriels et des choses sur ce sujet. Mais il y en a 2 que j'aime beaucoup:
Vraiment bien, couvre les taches sombres: Réseau multijoueur du moteur source-valve
Type d'histoire, amusant à lire et qui en vaut la peine: 1500 Archers sur 28.8 ,
Avantages:
Les inconvénients:
La logique côté serveur crée également des problèmes d'évolutivité - vous devez faire tout le travail pour tous les clients de votre serveur - des versets permettant à chaque client de faire sa propre part du travail total.
Cela dépend du jeu que vous souhaitez créer et de la partie du jeu. Si vous développez un RTS (ou n'importe quel jeu avec un modèle verrouillé), vous ne devez certainement envoyer que l'entrée et quelle étape de simulation l'entrée a été reçue.
Si vous voulez faire un jeu de tir, vous pouvez utiliser à la fois des fonctions d'entrée et des fonctions abstraites. Si vous prenez Unreal Tournament 3 comme le cas, ils ont créé le multijoueur principalement via des appels de fonction répliqués.
Pour le mouvement, ils prennent l'entrée du joueur (compressée en un seul bit pour chaque action) rotation delta, accélération et horodatage et l'envoient au serveur.
À d'autres fins, comme les armes, ils se synchronisent lorsque vous tirez (AFAIK, n'a pas encore examiné cette partie en profondeur).
Pour des valeurs plus statiques / moins souvent modifiées comme la santé, ils envoient la variable au client ou au serveur en fonction de ce que le programmeur a spécifié.
Et pour les jeux non RTS, souvenez-vous de la prédiction client.