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 ...
- 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.
- A envoie également un message au serveur disant: «J'ai tiré le long de ce vecteur»
- 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.
- 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é.
- 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