Pourquoi certains jeux en réseau utilisent-ils l'interpolation et certains utilisent le pathfinding pour le déplacement à distance?

C'est une question un peu ouverte, mais j'aimerais voir quelqu'un apporter un bon raisonnement pour les deux.

Pour un exemple rapide des deux:

Modèle d'interpolation

Pensez au modèle Valve où le client reçoit fréquemment des mises à jour de position et les télécommandes mettent à jour leurs positions en utilisant l'interpolation sur ces données.

Trouver son chemin

Dans ce modèle, pensez que l'utilisateur envoie une destination et que tout le monde s'y rend.

Quels types de jeux conviennent à chacun et quand doit-on les utiliser chacun?

J'ai travaillé sur le code réseau pour deux jeux en réseau AAA en temps réel, un pour les smartphones et un pour une console portable.

Pour répondre directement à votre question "pourquoi", eh bien, certains jeux utilisent l'un ou l'autre car il leur convient mieux que l'autre. Cela dépend non seulement du type de jeu, mais aussi du type de réseau dont nous parlons (les armoires d'arcade liées ont des conditions différentes par rapport aux jeux qui sont censés être joués en 3G). Certains jeux utilisent en fait les deux, voire complètement différentes approches pour synchroniser les données!

Je voudrais généraliser et considérer non seulement les données de position, mais à peu près tout type de données que vous pouvez synchroniser entre deux clients en réseau.

Au lieu de deux possibilités, je voudrais proposer un spectre entre les mises à jour matérielles et logicielles.

• Très dur mises à jour sont des événements discrets qui changent immédiatement l'état sur l'autre client, sans aucun type d'interpolation, soit parce que les données sont de nature critique (un joueur est décédé), car ce n'est pas un type de données pour lequel l'interpolation s'applique (un en ligne jeu d'échecs, messages de chat, etc.), ou parce que votre réseau vous permet de le faire (pensez aux armoires d'arcade liées où l'envoi fiable de tout l'état du jeu 60 fois par seconde est tout à fait possible).

  Avec cette méthode, les retards sur le réseau apparaîtront invariablement comme des mises à jour retardées et se manifesteront comme des personnages sautant.

• Les mises à jour dures avec inter / extrapolation sont similaires aux mises à jour très dures, mais pour des données en constante évolution, pour lesquelles il n'est pratiquement pas possible d'envoyer les données de manière fiable à chaque fois qu'elles changent. Pensez à envoyer une position et un vecteur vitesse; vous devriez pouvoir interpoler des données entre deux points et les extrapoler après eux. Vous devriez avoir un plan d'urgence si les données entrantes sont en désaccord avec vos extrapolations. Je dirais que la plupart des jeux qui nécessitent des mises à jour de position utilisent cette méthode.

• Difficile avec les mises à jour de synchronisation est similaire au dur avec inter / extrapolation, mais ne nécessite que rarement une synchronisation. Vous devriez l'utiliser pour des données qui sont vraiment triviales pour inter / extrapoler, comme l'horloge dans un jeu de combat (une fois réglée des deux côtés, il n'est pas vraiment nécessaire de se synchroniser à nouveau par la suite)

• Les mises à jour matérielles différées sont similaires aux mises à jour matérielles, mais ce que vous voyez ce sont des données dans le passé. Je soupçonne que dans de nombreux jeux d'arcade musicaux au Japon où vous pouvez jouer une chanson contre quelqu'un d'autre, vous jouez réellement contre des données de joueur enregistrées dans le passé, peut-être des heures ou même des jours avant. Bien sûr, ce type de mises à jour n'est utilisable que lorsque vous n'interagissez pas vraiment avec l'autre joueur.

• Les mises à jour logicielles consistent à envoyer des données de planification et à exécuter le plan sur tous les hôtes. C'est ce que vous appelez le "pathfinding". La quantité de données nécessaires pour synchroniser des données comme celle-ci est beaucoup plus faible; vous pouvez utiliser ces types de mises à jour lorsque vous pouvez vous en sortir avec certaines différences dans la façon dont les données sont présentées à l'utilisateur, comme lors de la synchronisation de centaines d'ennemis.

  La planification des mises à jour des données elles-mêmes peut également être aussi dure / souple que vous le souhaitez.

• Des mises à jour très douces sont utilisées lorsque le résultat d'une action peut être calculé de manière fiable bien avant qu'elle ne se produise. Vous envoyez simplement le résultat et l'autre client le lit. Par exemple, certains jeux de navigateur et de smartphone vous permettent de combattre d'autres personnes, mais la bataille réelle prend des heures à résoudre (pensez aux jeux de type Travian). Il est très possible que ces jeux calculent le résultat au moment même où la bataille est lancée, et vous ne voyez que les résultats de cette bataille.

  Un autre exemple non mis en réseau de cela serait dans Civilization 4 avec des animations de combat activées. Lorsque vous attaquez quelqu'un, le résultat de la bataille est immédiatement calculé, mais vous pouvez voir une animation de celui-ci en cours de lecture. Je peux vous assurer que la bataille n'est pas calculée car elle est animée.

Comme vous pouvez le voir, il existe de nombreuses façons de synchroniser les données, et je suis sûr que vous pouvez en imaginer beaucoup d'autres. Tous les jeux en ligne, sauf les plus simples, utiliseront très probablement un mélange de ces méthodes, en fonction du type de données qu'ils synchronisent, du type de jeu et même de l'état du réseau (utilisez des mises à jour matérielles lorsque le décalage est faible et continuez). pour des mises à jour plus douces lorsque le décalage augmente).

Je n'ai aucune idée du processus de développement de Valve, c'est donc purement mon avis, mais:

Interpolation : je dirais que ce serait mieux pour les jeux au rythme rapide, comme les FPS par exemple, où il est important d'avoir une position cohérente pour un ennemi à temps entre les joueurs. L'interpolation signifie que, même si certains paquets sont abandonnés (AFAIK, la plupart des FPS multijoueurs utilisent UDP au lieu de TCP / IP, ce qui ne garantit ni l'intégrité ni l'ordre dans lequel les paquets arrivent), vous aurez un mouvement fluide sur l'écran.

recherche de chemin : si le temps n'est pas un élément crucial de votre gameplay, et que votre algorithme trouve un chemin cohérent lors de sa réexécution, la recherche de chemin pourrait être intéressante car elle ne nécessite pas que vous envoyiez des mises à jour fréquentes et donc lourdes avec la position de chaque single entité. Je dirais que cela semble adapté pour un système au tour par exemple, où vous pouvez ensuite limiter la quantité de demandes réseau (une au début du tour, une à la fin du tour pour vous assurer que tous les clients sont dans un "bon sens"). " Etat.

Encore une fois, je n'ai jamais travaillé sur un jeu en réseau ou pour un grand studio de jeu, mais d'après ce que j'ai lu parfois, c'est comme ça que j'allais procéder :)

La réponse de Panda Pyjama est plutôt bonne.

Fondamentalement, la question se résume à quelle est la quantité minimale de données que vous pouvez envoyer qui mettra plusieurs clients dans le même état de conscience les uns des autres, et comment gérez-vous le décalage où, pendant ce décalage, les clients pourraient être dans un état différent.

Généré de manière procédurale, où toutes les interactions sont connues à l'avance, c'est plus facile, car si toutes les variables sont connues, le résultat est connu. Par exemple, isoler quelqu'un dans une pièce dont vous connaissez les méthodes de traitement et lui donner un ensemble de données, vous pouvez prédire avec précision les résultats. Par conséquent, vous pouvez donner les résultats à tous les autres clients sans avoir à attendre que ce client termine son calcul.

Cependant, il n'a mentionné aucune méthode. Résultats forcés.

Si le système attend une action d'une entité et que d'autres actions dépendent de cette action et que d'autres calculs prennent en compte cette action et ont déjà été prétraités avec le résultat attendu. Ensuite, pour maintenir la synchronisation, l'ensemble du système est arrêté tandis que la seule entité qui n'est pas au bon endroit est correctement remise sur son chemin.

Un exemple réel est toutes les autres entités dans un schéma d'attente pour s'assurer que la compensation appropriée m'est envoyée.