Discussion :

[saturn1]

Bonjour,

Dans le cadre d'un jeu de combat que je porte en reseau, je suis fasse a un petit dilemme.
Notamment sur la latence.

Contexte:

-La connection est directe donc les pings dans la moyenne vont etre de 50/60ms maximum(dans mes tests on est a 35ms avec une machine en wifi, apres tout depend de ce que fait l'utilisateur sur sa machine en meme temps).
Chaque action "peut etre decisive" c'est un jeu qui requiert beaucoup de precision.

Tests

J'ai fais plusieurs essais et je ne sais pas ce qu'il y a de mieux:

• frame de delais cote client
• rollback

Dans mes premiers tests je mets 4 frames de delais on arrive a 0.0166 * 4 = 66 ms. Ca tourne correctement cependant c'est plutot insupportable la difference entre une game local ou il n'y a pas de delai.

Du coup avec le rollback je met une frame de delai ca reste jouable cependant il peux y avoir des "glitch" graphique parfois.
Ex (4 frame de navigations reseau) :
-Le joueur A attaque a t+0 sur sa machine
-Hit a t+1 ( 1 frame de delai)
-Joueur B esquive/contre a t+4
-A t +8 le joueur A voit le joueur B esquiver et passer de Hit a Esquive.
= 7 Frame ou le joueur A voit son coup agir puis a la frame 8 il voit le joueur B rollback

Meme si on peut faire des optimisations:
Ex: le joueur qui recoit une animation la demarre avec a t+RTT

Il peut toujours y avoir des "glitch" lors d'animations courtes / instantanees...

Questions

Du coup je ne sais pas trop ce qui est le mieux, personnellement je prefere une frame de delai et de temps en temps des glitchs(rollback)

Si vous avez des conseils, retours d'experiences ?


Bien cordialement,

[Bousk]

Salut,

dans l'idéal les animations devraient commencer immédiatement mais l'effet (hit, dégâts) se ressentir à t+RTT, mais dans un jeu de combat ça doit être moins évident à camoufler et se resentir plus. Encore que même 60ms de latence devraient être absorbé par l'animation ou pourraient l'être.
Un rollback sur un jeu de combat je ne vois pas comment y parvenir de manière un peu smooth et non choquante pour le joueur. A choisir j'opterais plutôt pour smoother la perte de vie des coups suivants si y'a une erreur - ce qui devrait rester assez rare en pratique.
Comment est implémentée ta couche réseau ? Est-ce du TCP ? De l'UDP ? Comment est-il géré si UDP ?
Globalement pour un jeu de combat, je partirais sur un truc à l'instar des RTS : un flot continu d'inputs.
Tu peux regarder cet article http://gafferongames.com/networked-p...stic-lockstep/ il y avait aussi un talk GDC à ce sujet de Glenn Fiedler il y a quelques années. L'ensemble de sa série est vraiment bonne http://gafferongames.com/networking-...e-programmers/ et disponible en traduction ici-même http://bousk.developpez.com/#page_traduction ou https://jeux.developpez.com/tutoriel...gafferongames/
Même si Glenn est plus dans le FPS, la quasi totalité des articles reste valable et applicable.

Tu peux aussi te renseigner sur comment ils ont fait marcher les vieux street fighter online via je ne sais plus quel surcouche. J'ai pas plus de nom à donner malheureusement

[saturn1]

Bonjour et merci pour ta reponse.

Oui les hits c'est beaucoup mieux si c'est instantanee (sinon la frustration..^^)

J'utilise UDP avec la couche unity Unreliable Sequenced (Vais je gagner beaucoup plus en unsequenced? et fragmented?)

Autre question :
Quand on parle de RTT ca correspond a quel channel, je pense que c'est TCP mais du coup quand on envoie un message en UDP c'est donc cense etre bien plus rapide? ou juste RTT/2?


Cordialement,

[Bousk]

C'est pas une question de mieux ou pas, tu fais un jeu online, tu dois avoir une expérience online et c'est tout le boulot d'un programmeur online de camoufler la vérité aux joueurs qui croient que leur coup est instantanné.. qui de toutes façons ne le sont jamais, ne serait-ce que pour l'animation.
Je n'ai jamais utilisé Unity, donc regarde leur doc. D'après les noms tu veux sûrement du sequenced reliable, s'ils fournissent ça. Si tu stream un flot d'inputs tu pourrais presque te contenter de l'UDP classique.
UDP ne sera pas plus rapide que TCP pour envoyer des données...
Quel rapport entre RTT, channel et TCP ? Kamoulox gagnant ? Qu'appelles-tu channel d'ailleurs ?

[saturn1]

Bonjour et merci pour ta réponse.

Le round-trip delay time (RTD) ou round-trip time (RTT) est, dans les réseaux informatiques, le temps que met un signal pour parcourir l'ensemble d'un circuit fermé.

Cette valeur est importante, car elle intervient de façon cruciale dans l'efficacité de nombreux systèmes : par exemple, lors du chargement d'une page web en utilisant le protocole HTTP, le téléchargement de chaque élément de la page nécessite l'ouverture et la fermeture d'une connexion TCP ; la durée de téléchargement de l'élément est donc nécessairement supérieure à 2 RTD : le handshake TCP (SYN et SYN-ACK), puis la requête HTTP.

en lisant rapidement:

http://gafferongames.com/networking-...rs/udp-vs-tcp/

Je vois que UDP est plus rapide mais plus de perte.

Donc le RTT est calculé avec le protocole(channel) TCP. qu'en est-il pour l'udp? en terme de différence de vitesse?


Merci à toi.

[Bousk]

Et bien relis moins rapidement et essaye de comprendre.
Non UDP n'est pas plus rapide, ça n'a aucun sens dit comme ça, puisque c'est de toutes façons au matériel d'envoyer les données et à la couche IP qui est commune.
UDP n'a pas forcément plus de perte, c'est juste un protocole (et non un channel, je n'ai jamais entendu ce terme pourça) différent, qui gère différement les échanges de paquets.
Et le RTT n'est pas lié à TCP. Si tu veux le calculer sur ton protocole FTP ou n'importe quel autre c'est pareil. Le RTT c'est en gros le ping...
Dans ton post initial tu parles de démarrer à T+RTT, donc tu es en TCP ?
Mais tu parles aussi de connection directe... en TCP ??
Je ne vais pas expliquer l'ensemble des articles ici, articles qui ont été traduits pour dvp et sont donc disponibles en français qui plus est. Commence donc par lire et comprendre ces articles.