réseautage multijoueur avec la physique

Je suis curieux de voir comment la mise en réseau multijoueur avec la physique est mise en œuvre dans les jeux de course. Nous avons un monde physique avec plusieurs véhicules rapides contrôlés par différentes personnes. Disons que les véhicules ont des armes et peuvent se tirer dessus (Twisted Metal, Vigilante v8)

Je suis inquiet des coups et des collisions. Serveur faisant autorité ou meilleure alternative?

physics networking synchronization

— Vitali Kotik
source

Habituellement, un serveur est employé, stockant l'état de «vérité» qui est périodiquement partagé avec les clients. Les collisions se produisent indépendamment dans les clients et les serveurs, les états des clients étant estimés à partir des états précédents en utilisant un processus similaire à ce qu'on appelle généralement Dead Reckoning . Lorsqu'un état de serveur atteint un client, s'il existe des différences, le client effectue une transition de son état actuel à celui qui vient d'être reçu principalement par interpolation.

Cependant, avec de nombreux objets, les collisions peuvent être un vrai problème, par conséquent, ce qui est généralement fait est de garder le temps simulé des clients un peu en retard par rapport au temps simulé du serveur pour permettre divers degrés de flexibilité supplémentaires. Cet article sur le netcode de Source Engine de Valve est assez explicatif. De plus, si vous n'êtes toujours pas certain du middleware / bibliothèque réseau à utiliser, je vous suggère de vous pencher sur RakNet et son composant "ReplicaManager3" .

— Neenster
source

Vous pouvez faire plusieurs choses.

Vous pouvez centraliser tous les objets physiques sur le serveur et synchroniser les coordonnées avec les objets des joueurs sur tous les clients. C'est le plus simple et fonctionne sans beaucoup de défauts, mais il utilise beaucoup de ressources et nécessite beaucoup de bande passante. Vous pouvez optimiser l'utilisation de la bande passante en envoyant uniquement des valeurs au joueur d'autres joueurs qui se trouvent dans un certain rayon.
Vous pouvez faire comme Neenster l'a mentionné et faire simuler la physique par le serveur et les clients, de temps en temps le serveur corrige les clients. Cela signifie que tous les clients calculent leur propre physique pour chaque joueur, et vous synchroniseriez les événements de frappe sur le serveur en donnant la trajectoire de chaque joueur sur chaque client. Chaque, disons, 5 secondes, le serveur diffuse sa simulation physique et tous les clients acceptent le changement. Cela peut créer de légers décalages qui sont la plupart du temps imperceptibles, mais pendant le décalage du réseau et la perte de paquets (inévitable avec un trafic UDP élevé), vous remarquerez que votre lecteur et / ou d'autres joueurs glitch autour de l'écran et changent de position rapidement et de manière saccadée (est-ce un mot?).
Vous pouvez demander à chaque client de calculer sa propre physique et de synchroniser ses coordonnées. Cela rend difficile la simulation de la physique sur des objets partagés entre les clients. C'est un concept assez complexe à implémenter si vous voulez faire quelque chose de chic, car certains objets n'appartiennent pas nécessairement à un client.

Le premier est probablement le plus simple et devrait vous permettre d'avoir environ 4 à 5 joueurs avec peu de décalage. Il faudrait que chaque correspondance ait son propre serveur. Si vous faites des correspondances LAN, c'est la voie à suivre.

Le second est probablement le plus pratique, mais il peut être difficile à mettre en œuvre. Il est également assez ingénieux d'exécuter des simulations physiques sur le serveur. Si vous avez des serveurs centralisés, vous devrez probablement équilibrer la charge sur plusieurs machines, peut-être autoriser 10 correspondances par serveur, charger de nouvelles correspondances sur le serveur avec le moins de correspondances.

Le troisième est certainement le moins stressant sur le serveur et est probablement la meilleure solution si vous faites un schéma de réseau peer to peer. Comme je l'ai mentionné, il peut être difficile de synchroniser des objets autres que votre objet joueur car ces objets sont également modifiables par d'autres clients.

Je ne peux pas vous dire lequel utiliser car je ne sais pas comment fonctionne votre jeu. Tout ce que je peux faire, c'est vous donner les faits. Si vous avez d'autres questions, n'hésitez pas à commenter.

— tsturzl
source

Vous suggérez que de laisser les clients faire sa physique est une solution acceptable, mais vous n'avez rien à voir avec la tricherie.

— cubuspl42

@ cubuspl42 Pour l'effort de rester sur le sujet, j'ai omis les détails. Je pense que le PO peut explorer davantage la solution pour explorer les moyens potentiels d'atténuer la tricherie.

— tsturzl

une de ces manières consiste à permettre que l'écart de ce que chaque client fournit soit limité à un seuil. Par exemple, la plupart des clients disent qu'un objet donné est à la position 5,8 ou 6,9 mais l'un rapporte 12,19 comme coordonnée, qui pourrait tomber hors d'un seuil par rapport à sa déviation par rapport aux autres clients. Ce n'est qu'une solution partielle, mais la plupart des jeux n'offrent que des solutions partielles à la triche, d'où la raison pour laquelle cela se produit toujours. Cette solution ne signifie pas qu'ils trichent, mais signifie que leur positionnement doit être corrigé et leur apparaîtrait comme un retard.

— tsturzl

Eh bien, je suis légèrement en désaccord. Certains types de tricheurs sont réparables, d'autres non. Par exemple, à mon avis, c'est une mauvaise conception de jeu si l'on peut faire un speedhack pour un tireur en ligne compétitif. Ou un hack fou qui vous permet de voler autour de la carte avec un mode divin et des munitions infinies (je pense que c'est arrivé dans Crysis 1 à un moment donné). Ceux-ci sont réparables, il suffit de concevoir votre jeu correctement. Des trucs comme wallhack sont presque impossibles à réparer (cela nécessiterait d'énormes ressources du serveur). Aimbot est pratiquement impossible à réparer. Votre solution n ° 3 augmente le risque de ce pire type de triche.

— cubuspl42

@ cubuspl42 Je pense que vous manquez l'idée de ce qu'est un exemple. L'option 3 peut éviter exactement le problème dont vous parlez. Vous aurez généralement un TCP qui partage la vitesse, puis vous pouvez facilement vérifier la vitesse entre les clients et former un consensus, vous pouvez également faire quelques calculs simples pour déterminer si les coordonnées de l'UDP sont plausibles compte tenu de la vitesse fournie en supposant que vos clients ont un horloge synchronisée (peut être établie lors de la connexion à partir de l'horloge matérielle).

— tsturzl