Compensation de décalage avec les jeux 2D en réseau

Je veux faire un jeu 2D qui est fondamentalement un jeu de bac à sable / activité basé sur la physique. Il y a quelque chose que je ne comprends vraiment pas. D'après les recherches, il semble que les mises à jour depuis le serveur ne devraient être que toutes les 100 ms environ. Je peux voir comment cela fonctionne pour un joueur car ils peuvent simuler simultanément la physique et compenser les décalages par interpolation.

Ce que je ne comprends pas, c'est comment cela fonctionne pour les mises à jour des autres joueurs. Si les clients ne sont informés des positions des joueurs que toutes les 100 ms, je ne vois pas comment cela fonctionne car beaucoup de choses peuvent se produire en 100 ms. Le joueur aurait pu changer de direction environ deux fois pendant cette période. Je me demandais si quelqu'un aurait un aperçu de cette question.

Fondamentalement, comment cela fonctionne-t-il pour le tournage et des trucs comme ça?

Merci

Résumé pour ceux qui n'aiment pas les réponses longues ...

Cela peut être fait mais il est impossible de faire une physique multijoueur parfaite s'il y a une latence. La raison pour laquelle la latence affecte la physique est expliquée, puis des conseils pour réduire l'impact de la latence sur votre simulation physique sont proposés.

La création d'un jeu de physique multijoueur peut être lourde de dangers. Il est impossible de créer une expérience physique multijoueur en ligne "parfaite". Il y a des choses que vous pouvez faire pour l'améliorer, mais il n'y a aucun moyen de rendre la physique parfaite en supposant une latence.

Le problème est que la physique doit être rapide et réactive pour être réaliste, mais en même temps doit être calculée sur la base des actions combinées de TOUS les facteurs - c'est-à-dire les actions combinées de tous les joueurs. Et s'il y a une latence, cela ne peut pas se faire en temps réel.

C'est à vous, en tant que développeur, de décider si vous pouvez garder les différents facteurs sous contrôle et de comprendre que l'expérience du joueur se dégradera si la latence devient trop élevée. Si vous pouvez vivre avec cela (et vos joueurs le peuvent), alors allez-y. Voir vers la fin de ce post pour quelques notes sur la façon dont vous pouvez continuer à fonctionner plus facilement.

Un exemple pour montrer comment les choses peuvent être gâchées

Imaginez un jeu où deux joueurs (clients) sont connectés à un serveur. Il faut 100 millisecondes (1 / 10e de seconde) pour qu'un message passe sur Internet du client au serveur. Lorsqu'un joueur fait quelque chose, un message est envoyé au serveur indiquant ce qu'il a fait. Le serveur diffuse ensuite le message aux autres joueurs afin qu'ils sachent tous ce que le joueur agissant a fait.

Créez maintenant un scénario où deux joueurs ont une caisse au sol qui est un objet physique. Le joueur A le frappe d'un côté, l'envoyant se déplacer dans une certaine direction. Mais en même temps, le joueur B le frappe d'un autre côté, lui envoyant une autre direction.

Examinons différentes façons de gérer cela et quels seraient les résultats ...

Et si la physique est calculée uniquement sur le serveur?

Supposons que la physique soit calculée uniquement sur le serveur. Le joueur A envoie un message "J'atteins la caisse de cette façon" au serveur, 1 / 10e de seconde plus tard, le serveur reçoit un message. Le joueur B envoie son message "J'ai frappé la caisse de cette autre manière". Le serveur calcule le changement physique à partir de la combinaison des deux actions, et envoie un message aux deux joueurs en disant: "OK, ça bouge comme ça." Une physique parfaite est réalisée, basée sur les actions des deux joueurs combinés.

Mais le problème est qu'il faudra 2 / 10e de seconde avant que l'un des joueurs ne voie la caisse réagir. Les messages des deux joueurs prennent 1 / 10e de seconde pour atteindre le serveur, puis encore 1 / 10e de seconde pour que les résultats du calcul des serveurs soient envoyés pour les deux joueurs.

Bottom line, gameplay laggy.

Et si la physique est simplement calculée sur le client?

Supposons que la physique soit calculée uniquement sur le client. Voyons cela du point de vue du joueur A. Le joueur A frappe la caisse et il commence immédiatement à aller dans sa direction. Un message est également envoyé au serveur indiquant ce que le joueur A a fait.

En même temps cependant, B a fait son coup et a vu la caisse aller dans leur direction et a envoyé un message au serveur sur ce qu'ils ont fait.

2 / 10ème de seconde plus tard, un message arrive du serveur aux clients. On dit à A ce que B a fait et à B ce que A a fait. Le problème est, disent les deux clients, "Eh bien, le joueur X a peut-être fait ce coup à cet endroit, mais il n'y a plus de caisse à cet endroit, donc son coup n'a rien fait."

En bout de ligne, deux jeux non synchronisés et les joueurs n'ayant pas d'expérience partagée. Quel est l'intérêt du multijoueur s'ils voient tous deux des choses différentes?

Et si la physique est calculée à la fois sur le client et sur le serveur?

Dans ce cas, la physique est calculée sur le client afin que les joueurs voient une réaction immédiate sans décalage, mais elle est également calculée sur le serveur afin qu'elle soit "correcte" pour tous les joueurs.

Les deux joueurs frappent la caisse dans leurs directions respectives et chacun voit la caisse se déplacer en fonction de son coup seulement. Mais ensuite, le 2 / 10e de seconde plus tard, le serveur revient et dit: "Eh bien, en fait, vous vous trompez tous les deux. La caisse a suivi cette voie." Soudain, les deux joueurs voient la caisse changer radicalement de direction et se déplacer vers un nouvel emplacement.

En bout de ligne, c'est un jeu glitchy.

Conclusion

Fondamentalement, il n'y a aucun moyen de créer un jeu de physique parfait avec plusieurs joueurs lorsque n'importe quel type de latence existe. Vous pouvez faire un très bon jeu, mais vous aurez toujours le risque d'une latence excessive créant une mauvaise expérience pour certains joueurs. Cependant, vous pouvez faire certaines choses pour que votre expérience de jeu soit bonne.

Ce que vous pouvez faire pour que le jeu multijoueur fonctionne bien

Utilisez des volumes de collision simples. Ne vous embêtez pas à modéliser chaque détail d'une forme avec la physique quand une simple forme de cube fera l'affaire. Une balle spikey n'a pas à être modélisée comme une balle spikey pour la physique. Au lieu de cela, modélisez-le simplement comme une sphère.

Faites de petits objets sans importance des éléments réservés au client. Un exemple pourrait être des morceaux de verre cassé d'une fenêtre cassée. Vous pouvez laisser chaque client le simuler par lui-même, et cela n'aura pas vraiment d'importance s'il est différent.

Ne fabriquez des objets objets physiques que s'ils doivent être des objets physiques pour maintenir le nombre d'objets physiques actifs bas.

Exécutez votre jeu au ralenti lorsque vous faites de la physique multijoueur. Pensez peut-être au "bullet time". Les jeux au ralenti compensent la latence et permettent à plusieurs joueurs d'interagir ensemble avec la physique.

Permettre aux joueurs de configurer une situation quelconque ensemble, puis sur un signal, la physique est simulée pour les deux joueurs et les deux regardent le résultat de leurs actions combinées. Les joueurs ne peuvent pas interférer avec la séquence tant qu'elle n'est pas terminée.

Séparez les phsys des joueurs afin qu'ils ne puissent pas interférer les uns avec les autres. Ce serait formidable pour un jeu comme le bowling ou le billard, où un seul joueur à la fois a le contrôle, ou chaque joueur a son propre "bac à sable" (comme une piste de bowling).

Si vous ne pouvez pas les battre, rejoignez-les et faites en sorte que le retard physique fasse partie de votre jeu. Imaginez une histoire d'être dans un univers glitch avec des lois de physique brisées ou quelque chose :)

Annexe: Comment les jeux de tir y font face

Les jeux de tir y font face en ne faisant pas de physique trop complexe. Ils utilisent les effets secondaires du client pour que les joueurs voient les choses rapidement, mais ensuite le serveur fait le dernier appel sur ce qui s'est passé.

Imaginez un scénario où le joueur A tire sur le joueur B. Votre jeu de tir typique fera quelque chose comme ça ...

1. A calculera localement s'ils frappent B, et s'il semble qu'il y ait un coup, il joue un effet "coup" comme une bouffée de sang. Cela se fait côté client afin que le joueur voit immédiatement une réaction à son action. Si vous ne le faites pas, le jeu semble lent.
2. A envoie également un message au serveur disant: «J'ai tiré le long de ce vecteur»
3. Lorsque le serveur reçoit le message, il regarde où le service informatique pense que les joueurs se trouvent et décide si le vecteur de tir de A atteint B.
4. Si le serveur décide un hit B, il décide que B est hit et envoie un message aux DEUX clients disant ce qui s'est passé.
5. Si le serveur décide que A n'a PAS touché B, B va bien et A "rate". Cela peut ressembler à A comme ils ont frappé ("J'ai vu la bouffée de sang!") Mais c'est l'appel des serveurs qu'ils ont raté.

Alors, comment A pourrait-il manquer B quand on aurait dit qu'ils les avaient frappés? Parce que B a peut-être déménagé, mais A ne l'a pas encore vu car le serveur n'a pas encore envoyé de message "B déplacé ici" au client.

Valve a une bonne rédaction sur leur site à ce sujet. Voir http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

J'ai écrit une série d'articles sur le sujet ici: http://www.gabrielgambetta.com/fpm1.html

Les trois premiers articles traitent d'une introduction au sujet, de la prédiction côté client, de la réconciliation du serveur et de l'interpolation d'entité (c'est la partie qui répond à votre question spécifique). Le 4ème article (à venir bientôt) traitera des "trucs de tournage" :)

La réponse de Tim Holt est à peu près cela. Mes articles contiennent quelques diagrammes qui peuvent vous aider à comprendre ce qui se passe, mais Tim et moi disons essentiellement la même chose.

Il n'est pas déraisonnable de faire une prédiction complète sur votre propre personnage pour la réactivité et d'avoir des autres personnages en retard de 100 ms pour la cohérence. Si cela semble mauvais, alors envisagez d'avoir un décalage de votre propre personnage pour les garder synchronisés. Quoi qu'il en soit, vous aurez toujours besoin de mécanismes de correction pour lisser les prédictions incorrectes en cas de pointes de décalage, et ce système traitera des situations comme celle que vous décrivez. Peu importe que la latence soit de 100 ms ou de 1 ms - votre client est toujours `` en retard '' dans un certain sens et doit donc toujours agir comme s'il traitait des anciennes données et appliquer des effets cosmétiques tels que l'interpolation pour le rendre raisonnable.

En fin de compte, il s'agit de se contenter des ressources réseau disponibles. Idéalement, nous vivrions dans un monde sans latence et tout peut être parfaitement synchronisé. De façon réaliste, vous mettez à jour les clients toutes les 100, 200, 300 ms et dans le client, il doit y avoir une logique en place pour rendre ce qui s'est passé fluide. La "fluidité" est très importante, au final le jeu a juste besoin d'être fluide même si à l'arrière il y a une synchronisation chaotique entre le client et le serveur.

Un bon article et une meilleure réponse peuvent être trouvés:

Comment écrire un jeu en réseau?

Le problème n'est pas vraiment la latence. Il peut être compensé et prévu assez bien pour masquer les problèmes causés. La perte de paquets n'est pas un problème non plus - le système de mise en réseau doit être écrit pour être robuste et tolérable pour la perte de paquets. Cependant, le problème réside dans les pointes de décalage et la latence imprévisible. Paquets sortant de la synchronisation, certains d'entre eux étant abandonnés uniquement en raison des fluctuations de latence, incapacité de prédire et d'interpoler en raison des variations de latence, etc.