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.

[MoDDiB]

Aucun doute sur ce que tu dis Bousk pour la théorie.

Cependant en pratique sur les 2-3 implémentations d'API réseau que j'ai pu toucher, le unreliable UDP avait un ping jusqu'à 2x plus rapide en moyenne que le TCP.

Pour en revenir à ton soucis tu t'y prends vraiment tard, c'est à penser dès le début du jeu, et souvent le mieux c'est de construire le jeu avec cette contrainte.

Au final ce qu'il te faut c'est un mix des 2 :
- un léger frame délai ( le maximum acceptable, je dirai 32ms vu ton jeu )
- la possibilité de rollback ET rejouer toutes les frames depuis le rollback jusqu'a la frame actuelle de manière invisible pour le joueur : une fois la nouvelle frame calculée il faut des blends propres d'animation, les accélérer durant un court instant et des fxs qui peuvent disparaître de manière naturelle : le plus gros du travail est là, et c'est difficile.

Par contre tu utilises la physique de Unity ? Parce qu'elle n'est pas déterministe du tout et si tu n'envois que les inputs ça peut diverger.
Pareil si tu vises des plateformes différentes tes floats ne vont pas se comporter de la même manière.

Sur Chibis Bomba c'était juste un frame delai de 50ms, mais c'est beaucoup moins nerveux.

Vidéo à voir absolument sur le sujet :

http://www.gdcvault.com/play/1022195...ers-Networking

[saturn1]

Salut et merci

MoDDiB: Effectivement j'avais teste chibi bombas et j'avais bien remarque la difference entre local et online ce qui etait plutot frustrant.

D'ailleurs j'avais vu que vous aviez eu le greenlight, qu'en est-il aujourd'hui?

Par contre tu utilises la physique de Unity ? Parce qu'elle n'est pas déterministe du tout et si tu n'envois que les inputs ça peut diverger.

Merci de l'info.


PS: Etant novice en reseau j'ai opte pour du client to client. Car avec un serveur ca rajoute pleins de complications (surtout financieres^^).


Merci bien a vous deux.

[MoDDiB]

Effectivement j'avais teste chibi bombas et j'avais bien remarque la difference entre local et online ce qui etait plutot frustrant.
D'ailleurs j'avais vu que vous aviez eu le greenlight, qu'en est-il aujourd'hui?

Non la frustration venait du fait qu'on te bottais les fesses

Le jeu est enterré, peut être un jour après mes 12 projets en tête il reviendra
Le "post-mortem" : http://moddib.blogspot.fr/2013/02/ho...about-our.html

PS: Etant novice en reseau j'ai opte pour du client to client. Car avec un serveur ca rajoute pleins de complications (surtout financieres^^).

Tu t'attaques vraiment à un très gros morceau, va au plus simple, ça sera déjà très très bien !

[Bousk]

Cependant en pratique sur les 2-3 implémentations d'API réseau que j'ai pu toucher, le unreliable UDP avait un ping jusqu'à 2x plus rapide en moyenne que le TCP.

L'éventuel "meilleur ping" est dû à la gestion des paquets perdus et à leur renvoi (ou pas)
Plus la qualité de la ligne est médiocre, et les pertes de paquets acceptables et interpolations possibles, meilleur sera ton ping.

Pour en revenir à ton soucis tu t'y prends vraiment tard, c'est à penser dès le début du jeu, et souvent le mieux c'est de construire le jeu avec cette contrainte.

Selon votre moteur réseau, switcher de TCP à UDP va de trivial à (quasi)impossible.

Par contre tu utilises la physique de Unity ? Parce qu'elle n'est pas déterministe du tout et si tu n'envois que les inputs ça peut diverger.
Pareil si tu vises des plateformes différentes tes floats ne vont pas se comporter de la même manière.

Faut voir ce que implique l'utilisation de la physique et pour quoi vous l'utilisez.
Si vous les déplacez selon cette physique sur une map, ça sera pas bon. Un joueur finira fatalement par se retrouver derrière l'autre chez l'un et pas chez l'autre ou tout autre truc chelou de la sorte.
Si c'est uniquement pour les animations, et que vous utilisez également une machine à état qui reset le tout sur timer ou permet de retomber sur ses pattes par défaut, ça peut marcher.

PS: Etant novice en reseau j'ai opte pour du client to client. Car avec un serveur ca rajoute pleins de complications (surtout financieres^^).

Ca nous dit toujours pas si c'est TCP ou UDP, ni comment tu as mis quoi en place.
Unity propose du hole punching ? Du Nat traversal ? Du relay ?

[saturn1]

Bonsoir,

Bousk:
J'utilise UDP pour envoyer en flot continue les donnees comme positions animations etc...
Unity a une surcouche reseau tres dev friendly.

Et TCP pour les pertes de vies/mana...(pas de ressenti gameplay instantane)

Unity propose du relay par defaut mais je favorise la connexion direct avec un plugin que j'ai trouver sur l'asset store qui permet de faire du hole punching.

Merci pour vos reponses