Collision physique du réseau de jeu

Question

Comment simuler deux contrôlée par le client véhicules entrent en collision (raisonnablement) dans une architecture client/serveur d'installation d'un jeu en réseau? Je n'ai lu cet éminent blog post sur comment faire un réseau distribué de la physique en général (sans client traditionnel de prédiction), mais cette question est plus précisément sur la façon de gérer les collisions de la propriété des objets.

Exemple

Dire à Un client est de 20 ms à l'avance de serveur, le client B 300 ms avant de serveur (en comptant la latence et le maximum de la gigue). Cela signifie que lorsque les deux véhicules entrent en collision, les deux clients de voir l'autre comme de 320 ms derrière - dans la direction opposée à la vitesse de l'autre véhicule. Tête-à-tête sur un suédois routes, il y a une différence de 16 mètres/17.5 mètres!

Ce n'est pas pour essayer

Il est pratiquement impossible d'extrapoler les positions, puisque j'ai aussi très complexe véhicules avec des joints et des organismes de toute, qui à leur tour ont linéaire et angulaire des positions, vitesses et accélérations, pour ne pas mentionner les etats de la saisie de l'utilisateur.

Answer 1

Je ne connais pas de solution idéale, et j'ai un sentiment que l'on n'existe pas. Même si vous pouviez prédire avec précision la position du véhicule, vous seriez incapable de prévoir la manière dont l'utilisateur va actionner les commandes. Donc le problème revient donc à minimiser les effets négatifs de client/serveur lag. Avec cela à l'esprit, je l'approche de ce à partir de la position de principe de moindre étonnement (reformulation de Wikipedia):

Dans la conception de l'interface utilisateur, le principe de moindre étonnement (ou surprise) précise que, si deux éléments d'une interface de conflit, ou sont ambigus, le comportement devrait être celui qui sera le moins surprenant de l'utilisateur au moment du conflit.

Dans votre exemple, chaque utilisateur voit les deux véhicules. Leur propre, et que d'un autre joueur. L'utilisateur s'attend à leur propre véhicule pour se comporter exactement de la manière dont ils ont le contrôle, de sorte que nous sommes incapables de jouer avec cet aspect de la simulation. Toutefois, l'utilisateur ne peut pas savoir exactement comment l'autre utilisateur a le contrôle de leur véhicule, et je voudrais utiliser cette ambiguïté pour masquer le gal de l'utilisateur.

Voici l'idée de base:

1. Le serveur doit prendre la décision au sujet de l'imminence d'une collision. L'algorithme de détection de collision n'a pas à être parfait à 100%, il a juste à être assez près pour éviter les incohérences évidentes.
2. Une fois que le serveur a déterminé que les deux véhicules entrent en collision, il envoie chacun des deux utilisateurs, un message indiquant qu'une collision est imminente.
3. Sur Un client, la position du véhicule B est ajusté (réaliste) pour garantir que la collision se produit.
4. Sur le client B, la position du véhicule est ajustée (réaliste) pour garantir que la collision se produit.
5. À la suite de la collision, la position de chaque véhicule peut être ajusté, au besoin, de sorte que le résultat final est en harmonie avec le reste du jeu. Cette partie est exactement ce que MedicineMan proposé dans sa réponse.

De cette manière, chaque utilisateur est toujours en contrôle de leur propre véhicule. Lorsque la collision se produit, il ne sera pas inattendu. Chaque utilisateur va voir de l'autre véhicule se déplace vers eux, et ils auront tout de même le sentiment d'une simulation en temps réel. La bonne chose est que cette méthode réagit bien dans les bas-lag conditions. Si les deux clients ont une faible latence des connexions au serveur, le montant de l'ajustement sera petit. Le résultat final sera, bien sûr, de s'aggraver à mesure que le décalage augmente, mais qui est inévitable. Si quelqu'un est de la lecture d'un fast-paced action de jeu sur une connexion avec plusieurs secondes de retard, ils ne sont tout simplement pas allez obtenir la pleine expérience.

Answer 2

Peut-être la meilleure chose que vous pouvez faire est de ne pas la montrer ainsi la collision en temps réel, mais de donner l'illusion que les choses se passent en temps réel.

Depuis le client est derrière le serveur (gal), et le serveur a besoin de montrer le résultat de la collision, peut-être ce que vous pouvez faire, côté client, est de montrer un flash ou une explosion ou un autre graphique pour distraire l'utilisateur et d'acheter assez de temps sur le côté serveur pour calculer le résultat de la collision.. Lorsque vous avez terminé avec la prédiction, vous l'expédier vers le côté client pour la présentation.

Answer 3

Désolé de répondre avec "Ce que de ne pas essayer", mais je n'ai jamais entendu parler d'une solution qui n'implique pas prédire le résultat sur le côté client. Considérons un exemple simplifié:

Client est à l'arrêt, et de regarder le client B véhicule à l'approche d'une falaise. Le Client B du véhicule est capable de réduire la vitesse à 0 instantanément, et ce, au tout dernier moment avant d'aller sur la falaise.

Si Un Client tente de montrer le Client B de l'état en temps réel, le Client n'a pas le choix, mais de prévoir que le Client B tombé de la falaise. Vous voyez beaucoup de Mmorpg conçu de telle sorte qu'un personnage du joueur est capable d'arrêter immédiatement lors de l'exécution à grande vitesse. Sinon, le Client A pu montrer seulement le Client B de l'état comme l'état des mises à jour de venir dans, mais ce n'est pas viable, comme Un Client doit être en mesure d'interagir avec le Client B en temps réel dans votre scénario (je suppose).

Pourriez-vous essayer de simplifier la collision des modèles de sorte que l'extrapolation est possible en temps réel de prédiction? Peut-être faire votre "articulations et des corps partout" avez-processeur moins intensif des modèles physiques, comme quelques-uns des cubes ou des sphères. Je ne suis pas trop familier avec la façon d'améliorer l'efficacité de la détection de collision, mais je suppose que c'est fait par la détection de collisions entre des modèles qui sont moins complexes que les modèles visuels.

Answer 4

Quant à "ne pas juger". Vous êtes en supposant que vous avez besoin de prédire parfaitement, mais vous n'allez jamais à trouver une solution parfaite dans un jeu avec la physique complexe. Une approximation est probablement le meilleur que vous pouvez faire (par exemple, la plupart des moteurs de physique peut lancer une forme dans la scène physique et retour le premier point de la collision).

Par exemple, j'ai mis en œuvre certaines parties critiques du réseau physique pour Mercenaries 2, sous la direction de Glenn (le blog de l'affiche que vous avez mentionné). Il était impossible de pousser tout le nécessaire de la physique de l'état à travers le fil, même pour un seul corps rigide. Havok physics progressivement génère des points de contact de chaque image, de sorte que le courant de contact "collecteur" est une partie nécessaire de la physique de l'état pour maintenir la simulation déterministe. Il est aussi bien trop de données. Au lieu de cela, nous avons envoyé plus de la transformation désirée et la vitesse d'écoulement et utilisé les forces et couples pour pousser doucement les organes en place. Les erreurs sont inévitables, si vous avez besoin d'une bonne correction d'erreur système.

Answer 5

Ce que j'ai fini par faire, cela a été tout simplement ignoré la prédiction ensemble et tout simplement faire ceci:

1. Le Client a très bien dire à propos de sa propre position,
2. Serveur (ou presque) ne dit rien au sujet de la possession du client de position lors de la "haute énergie" collision qui s'est passé avec un autre objet dynamique (c'est à dire pas statique de l'environnement).
3. Le Client s' meshoffset=meshpos-physpos lors de la réception d'une position de mise à jour à partir du serveur et puis définit meshpos=physpos+meshoffset chaque image et diminue progressivement meshoffset.

Il ressemble assez bien la plupart du temps (dans une faible latence de la situation), je n'ai même pas à slerp mon quaternions pour obtenir des transitions en douceur.

Sauter prédiction donne sans doute une forte latence clients un terrible experiance, mais je n'ai pas le temps de s'attarder sur ce, si je suis jamais aller à l'envoi de ce jeu indépendant. De temps en temps c'est sympa de créer un demi-âne solution qui fonctionne assez bon, mais le meilleur. ;)

Edit: j'ai fini par l'ajout de la "propriété" de Glen Fiedler (le blogueur mentionné dans la question) a mis en œuvre pour Mercenaries 2: chaque client obtient la propriété de (dynamique) des objets qu'ils entrent en collision avec pendant un certain temps. Cela était nécessaire car le taux de pénétration n'est plus en profondeur dans latence élevée et de haute vitesse. Que soluation fonctionne tout aussi grand que vous pensez quand vous voyez la GDC vidéo de présentation, peux le recommander!