Bad lag ufc 3

http://forums.shoryuken.com/discussi...etwork-results

GGPO, abréviation de « Good Game, Peace Out » est une bibliothèque de réseau écrite par Tony Cannon (de shoryuken.com et Evo), et c’est ce que Skullgirls utilise pour le jeu en ligne. Personnellement, je crois que c’est l’avenir des jeux de combat en ligne, mais certains joueurs se sont plaints de l’expérience en ligne dans le récent Street Fighter 3 : Third Strike Online Edition , qui utilise également GGPO. Certaines personnes ont même été assez déçues pour me demander si nous pourrions changer Skullgirls pour utiliser autre chose. Il me semble que les gens blâment GGPO pour ces problèmes, alors qu’en fait, on ne leur a pas correctement enseigné comment en tirer le meilleur parti.
Qu’est-ce que c’est que ce « décalage » ? Le décalage est tout retard supplémentaire dans la réponse du personnage au-delà de ce qui est normal pour le jeu.

Le « décalage d’entrée » en termes de conception de jeu fait référence à tout laps de temps qui s’écoule entre l’entrée d’un joueur et la réponse du personnage correspondante. Tous les jeux en ont, et en fait, la plus petite quantité de décalage réalisable est de 3 images à 60 FPS (dont l’explication dépasse le cadre de cet article). Cependant, jouer à un jeu en ligne ajoute un délai supplémentaire car les informations doivent être échangées sur Internet, et c’est ce que les joueurs appellent communément "Le retard d’Internet n’est jamais nul, même si vous jouez quelqu’un dans la pièce voisine. Disons qu’Alex joue Bob dans la dernière version de Fightman Game : INJURY MAXIMUM , et que les informations mettent 80 millisecondes (un temps raisonnablement moyen) pour passer de la console d’Alex à celle de Bob. Cela signifie que le jeu doit gérer 5 images de retard Internet - si Bob appuie sur un bouton sur l’image 10, la console d’Alex ne saura pas qu’il appuie sur ce bouton avant l’image 15. Ainsi, si Alex appuie sur un bouton sur l’image 10, le jeu l’enregistrera et l’utilisera sur l’image 15, en même temps que l’entrée de Bob à partir de l’image 10. Malheureusement pour Alex, cela signifie que son propre personnage répond lentement à ses commandes, et donc que le jeu semble « lent ». Tout décalage d’entrée supplémentaire signifie de mauvaises nouvelles pour le jeu Jeux de combat - Cela peut signifier que vous ne pouvez pas réagir aux repères visuels, que vous ne pouvez pas effectuer correctement les lancers techniques ou que vous ne pouvez pas effectuer de combos difficiles... et dans le pire des cas, cela peut modifier les propriétés du jeu, comme rendre certains Supers imblocables après le Super-Flash. Si vous vous entraînez en ligne, vous pouvez certainement vous habituer à jouer avec le décalage, mais ce n’est pas non plus l’idéal - cette pratique ne s’appliquera pas aussi bien aux matchs en personne ou aux tournois, car le décalage supplémentaire n’est pas là hors ligne. Tout le timing de votre combo sera désactivé, réagir aux choses vous semblera plus difficile, et certaines astuces ou tactiques que vous avez apprises ne fonctionneront tout simplement plus parce que l’autre joueur n’est pas en mesure de réagir correctement à temps.

Mais si le décalage est toujours là en ligne, comment GGPO peut-il « se débarrasser du décalage » ?

Il ne peut pas réellement « se débarrasser du décalage », mais il peut permettre au jeu de se dérouler comme s’il y avait n’en était aucun. Avec GGPO, dans notre exemple ci-dessus, Alex peut choisir le nombre d’images que le jeu retarde sa saisie sur sa propre console, ce qui signifie qu’il peut choisir de faire réagir le jeu instantanément. Ainsi, pour son propre personnage, il ne connaît aucun décalage d’entrée. Cela signifie que tous ses combos, liens, technologies de lancer et autres éléments sensibles au timing seront exactement les mêmes que si Alex jouait hors ligne, ce qui rendra son expérience infiniment plus utile.



Mais n’oubliez pas que le retard d’Internet est toujours là. Donc, si Alex choisit zéro décalage d’entrée et appuie sur un bouton sur l’image 10, le jeu réagira instantanément... mais il doit deviner ce que Bob faisait. Alex voit peut-être son attaque toucher à la 12e manche, mais le jeu ne sait pas encore si Bob bloquait. Ainsi, lorsque l’entrée de l’image 12 de Bob arrive sur l’image 17, le jeu peut éventuellement devoir voyager dans le temps pour se réviser et montrer à la place que Bob a bloqué l’attaque sur l’image 12. Ainsi, sur l’image 17, il est maintenant en Block Stun plutôt qu’en Histun Hitstun. Ce « retour en arrière » se traduit par des saccades visuelles, qui s’aggravent avec des connexions plus faibles, car le jeu doit se réviser plus fréquemment.

Tout dépend donc de ce que vous voulez du jeu - GGPO permet aux utilisateurs de choisir de faire l’expérience de n’importe quoi entre zéro et huit images de décalage d’entrée. Ceux qui veulent vivre une véritable expérience de tournoi peuvent choisir le zéro décalage et obtenir une formation qui s’appliquera tout aussi bien hors ligne, mais ils devront s’habituer à faire face aux retours en arrière.

Alternativement, les joueurs qui veulent des visuels plus fluides mais qui peuvent tolérer un peu de décalage d’entrée peuvent choisir 2 à 4 images de décalage, ce qui est généralement acceptable pour la plupart des gens et aura moins de bizarreries visuelles sur les connexions moyennes. Et les joueurs occasionnels peuvent choisir 5 à 8 images de décalage, ce qui signifie que le jeu aura l’air super fluide mais que le gameplay sera assez lent mors.

Presque toutes ces plaintes sont probablement dues à un manque d’informations appropriées dans le jeu expliquant ce que ce choix signifie pour le joueur - sans explication adéquate, beaucoup de gens choisiront zéro simplement parce que cela sonne mieux alors que cela ne correspond peut-être pas à leurs priorités ou à leur connexion. Nous envisageons maintenant de prendre des mesures pour résoudre ce problème dans Skullgirls en communiquant sur le fonctionnement réel de ce paramètre, ainsi qu’en proposant éventuellement des options supplémentaires pour les aider à mieux personnaliser l’expérience en ligne à leurs goûts.
Pour résumer - GGPO permet aux joueurs de choisir entre un gameplay sans décalage avec des visuels parfois saccadés en fonction de la connexion, ou des visuels plus fluides avec plus de décalage de jeu. Le code réseau traditionnel n’offre pas d’autre choix que des visuels fluides avec un gameplay plus éparpillé en fonction de la connexion, et bien que cela semble Bien, l’option d’avoir un gameplay sans décalage est une expérience en ligne beaucoup plus instructive si les joueurs choisissent de l’utiliser.
> En plus de pouvoir voir le ping de chaque joueur (au lieu de simplement vert/jaune/rouge), le jeu vous recommandera également un délai GGPO à activer avant le début du match. Ce qui signifie que si vous jouez contre quelqu’un avec un ping élevé, il vous demandera de changer votre délai GGPO en disons 3 ou 4 afin que vous obteniez moins de téléportations que tout le monde déteste au prix d’un délai d’entrée plus important comme le netcode traditionnel.

Pourquoi War Thunder surpasse-t-il BEAUCOUP les autres jeux en ligne lorsque l’internet est pauvre ? Comment avez-vous fait cela ? Anton : « Lorsque nous avons planifié War Thunder, nous avons d’abord essayé d’aborder la connectivité et la mise en réseau. Il existe deux approches principales dans l’industrie : 1) « basée sur le client » (comme la plupart des jeux multijoueurs), où même s’il existe un serveur de jeu dédié, il doit « faire confiance » à la position des données d’un client (peut-être avec une certaine validation) ; 2) le « client léger », où tout se passe sur le serveur dédié et où le client ne fait qu’envoyer des contrôles et visualiser les données (peut-être avec une prédiction basée sur l’entrée de contrôle). Les deux approches ont leurs inconvénients - la première est très sensible à la fois à la perte de connexion du client et à la triche (mais bien sûr, nécessite beaucoup moins de serveurs !) et peut (selon la mise en œuvre) mettre les clients avec pire connexion dans une meilleure position ; Le second est très sensible à la connexion, sinon il est « lent » voire injouable. C’est particulièrement visible dans les véhicules rapides dotés d’une physique sophistiquée - une simple extrapolation ne fonctionne pas vraiment très bien et la latence des commandes est très importante - disons que vous êtes dans un plan qui décroche presque !

Nous avons donc inventé une toute nouvelle approche.

Tout se passe sur le serveur, mais chaque client de jeu simule également entièrement son propre monde physique (mais en envoyant ses commandes avec une certaine redondance au serveur). Le serveur applique ensuite des contrôles et simule le monde du client _back dans le past_ (rembobinage de son temps), de sorte que même quelques pour cent de paquets perdus ne sont pas cruciaux, puis l’envoi de la position réelle réelle, de la vitesse, etc. Le client rembobine également l’heure et réapplique ses commandes les plus récentes, si la position passée n’était pas synchronisée. Dans un monde idéal, et sans autre L’interaction du joueur, tout serait synchronisé même avec un ping de 700 ms, car le serveur et le client simulent le même état avec les mêmes contrôles en même temps - mais toute tricherie est impossible, car le client ne peut que changer sa position locale, ce qui n’affectera pas le serveur ou les autres joueurs, et le serveur renverra alors la position correcte de toute façon. La seule discontinuité (qui ressemble à un « saut ») peut se produire si un autre joueur a réellement interagi avec vous (sur le serveur) - mais c’est inévitable avec n’importe quel modèle de réseau. Ainsi, le contrôle de votre véhicule est devenu indépendant de la latence ! Vous n’avez besoin que d’un ping _stable_ et d’une connexion pas très perdante pour contrôler votre véhicule.

Le seul inconvénient de notre approche est qu’elle nécessite plus de puissance de calcul de la part des serveurs et des clients avec une grande latence, mais le client ne calcule que sa propre position, tandis que le serveur doit reconstituer le monde entier !

Nous avons reçu des plaintes et des malentendus sur la façon dont les véhicules entrent en collision avec d’autres véhicules dans l’environnement de jeu, Anton (notre PDG et développeur principal) a pris le temps d’essayer d’expliquer exactement comment notre jeu interprète virtuellement la physique du monde réel.

Un petit rappel du fonctionnement du net-code/physique dans War Thunder.

• Le client applique des contrôles qui simulent la physique et envoie des contrôles au serveur. Le serveur reçoit les contrôles et les applique dans le passé (en raison de ping, les contrôles qui ont été envoyés se sont produits quelque part dans le passé).
• Le serveur envoie ensuite « l’état d’autorité » au client - c’est-à-dire la position « réelle ».
• Bien sûr, lorsqu’il arrive chez le client, il est déjà en passé (obsolète) en raison du ping. Ainsi client, réapplique tous les contrôles qui ont été appliqués/pressés depuis ce temps à cette « ancienne » position (mais réelle, vérité du serveur).
• Cela donne une « nouvelle » position.

Bien que difficile à comprendre et très coûteux en calcul (comparé, par exemple, au code net de Battlefield, qui se produit essentiellement dans le passé), cela donne un très bon résultat sur n’importe quel ping de latence raisonnable lors du contrôle d’un véhicule. Cela donne un très bon niveau de contrôle, une qualité solo-hors ligne-temps réel, si trois conditions sont remplies :

• Le ping est stable. Comme vous pouvez le voir sur l’algorithme, le serveur et le client dépendent tous deux de l’obtention de certaines informations à temps. Et si un ping est très instable, les résultats seront instables. Ainsi, un 100 ms stable est parfois meilleur que 50 ms « moyen » s’il s’agit en fait de 10..110 ms.
• Perte de paquets raisonnable. C’est pourquoi il est préférable de Jouez filaire, plutôt sans fil. Bien sûr, toutes les données sont envoyées avec une certaine redondance. Mais si tous les contrôles du client à sectionner sont perdus dans la fenêtre de 700 ms, ils deviennent fondamentalement trop obsolètes pour être réappliqués (rappelez-vous, le client n’est pas seul au monde, il y a d’autres clients, et ils ont besoin de « voir » et d’interagir avec la position de quelqu’un, donc nous ne pouvons pas permettre la réapplication des contrôles à partir du dernier, disons, 10 secondes - cela se traduira par une « téléportation » importante sur le serveur et donc sur tous les autres clients). Cependant, si vous avez une perte de paquets raisonnable (3-5%), cela devrait aller. Gardez également à l’esprit que la perte de paquets que le jeu affiche dans les statistiques n’est pas la perte complète de paquets subie par un client, elle est mesurée uniquement sur la base du trafic « fiable », car pour le trafic non fiable, nous ne pouvons pas réellement déterminer si le paquet a été perdu. De plus, même 5 % en moyenne ne signifie pas que vous n’avez pas perdu tous les paquets (redondants) avec, par exemple, des commandes.
• Il n’y a aucune interaction avec les autres joueurs. Bien sûr, ce n’est pas vrai dans le jeu. Cependant, la plupart du temps, 99,9 % des interactions n’ont pas lieu et 99 % de toutes les interactions sont des prises de vue. Le tir est vraiment cool (pour l’interaction immersion/code net des joueurs), car la plupart du temps, il ne fait rien du tout (raté ou ricochet) ou fait de vrais dégâts, donc une sorte de désynchronisation (petite téléportation si vous avez bougé de 100 ms alors qu’en réalité votre piste a été endommagée il y a 200 ms) semble correcte et ne gâche pas l’immersion.

Bien sûr, parce que tout le net-code dans WT fonctionne de cette façon, vous « voyez » l’autre joueur en temps extrapolé - c’est-à-dire que nous connaissons leur ancienne position, leur vitesse et leurs commandes et nous prédisons la position future sur cette base, car les véhicules sont hautement prédictifs et inertiels, c’est bien la plupart du temps.
Pour autant que je sache, ce net-code a été inventé dans War Thunder. La norme industrielle pour les jeux de tir est en train de se montrer chaque client interpolé dans le passé (Battlefield, CS) - mais cela met toute personne ayant un ping plus élevé dans une meilleure position (et ne fonctionne pas si bien avec les collisions physiques non plus, pour des raisons évidentes - ces mouvements ont déjà eu lieu) ou aucune interpolation (supplémentaire) du tout (Q3) où vous devez prédire votre ping et tirer devant un ennemi (ce qui ne fonctionne pas bien non plus avec les collisions), et met également toute personne ayant un ping élevé dans une très mauvaise position). Il existe une solution évidente qui s’appelle « client léger » où nous ne montrons que ce que le serveur envoie et prédisons/compensons le décalage/latence en appliquant tous les contrôles dans « future » (c’est-à-dire avec un certain délai). C’est ainsi que fonctionnent de nombreux MMORPG (et d’autres jeux), mais ce n’est pas acceptable pour les véhicules à grande vitesse avec des états instables critiques, tels que les avions et parfois même les véhicules au sol (mouvement à grande vitesse sur l’angle de pente), car il effectue des contrôles « léthargique » et moins réactif.
Il n’y a pas de solution idéale pour un jeu en ligne (bien sûr, si nous pouvions « faire confiance » aux clients, nous pourrions améliorer considérablement la collision pour chaque client), mais notre solution fonctionne extrêmement bien pour les véhicules dans la plupart des conditions.
La principale (et évidente) exception où cela ne fonctionne pas aussi bien est les collisions physiques entre véhicules (en particulier contrôlés par le joueur).
Résoudre les collisions dans la physique du jeu est, généralement, l’une des tâches les plus difficiles, mais cela devient particulièrement difficile, lorsque vous essayez de recréer des événements de sorte que, non seulement il s’agit de résoudre correctement les collisions, mais aussi d’essayer de « faire confiance » aux contrôles de l’utilisateur (et non à la position de l’utilisateur !) dans le passé (c’est-à-dire en les réappliquant pour la période de ping du dernier client).
Bien sûr, lorsque vous observez cette collision depuis l’autre client (replay), elle devient encore plus étrange - non seulement parce qu’un client réappliquera ses commandes après une collision réelle dans le passé, mais aussi parce que vous voient une position extrapolée, future, du véhicule ennemi, qui fait la même chose (réappliquer des commandes sur le serveur).
Dans certains exemples qui nous ont été donnés, la collision elle-même pourrait très bien se produire. Les chars se retournent, même sur un sol plat sans l’aide d’autres chars (vous pouvez rechercher sur Google des vidéos d’essais de chars/biathlon de chars, etc.).
Mais le « comportement observé » conduisant à des résultats naturels peut sembler non naturel, en partie parce que vous ne voyez jamais ce qui s’est réellement passé (sur le serveur) et en partie parce que le serveur lui-même doit recréer les événements (contrôles) dans des conditions très spécifiques.
Dans notre jeu, le serveur de diffusion positionne , pas contrôle, de sorte que personne ne dépend du client « le plus lent ». Habituellement, avec un meilleur ping, vous aurez une meilleure conscience et une meilleure visée. Mais les commandes de votre propre véhicule ne dépendent pas du ping (uniquement de la perte de paquets), si vous n’entrez pas en collision avec d’autres véhicules. Étant donné que le contrôle est la norme, et les collisions sont rares (il n’y a en fait pas de bonne solution en ligne pour une solution de collision de toute façon, si ce n’est pas en forçant « lent » (latence dans les contrôles) ou le « client léger »).
Cela nous permet d’offrir une bonne expérience globale et permet aux joueurs du monde entier de jouer ensemble.
Je voudrais terminer par la recommandation de garder votre espacement et d’essayer de ne pas entrer en collision avec vos coéquipiers avec désinvolture. Après tout, en réalité, cela peut causer de graves blessures à l’équipage et des dommages à tous les véhicules et à votre belle peinture.