Discussion :

[hedo888]

Voilà, je developpe un petit jeu en réseau avec TV3D et j'aimerai savoir qu'elle était la meilleurs approche pour envoyer les infos (position joueur, tir) du client vers le serveur (qui me les renvoie me permettant d'updater mon propre perso à l'écran).

Pour l'instant, j'envoi au serveur toutes les 2 ms un paquet (UDP) contenant le message suivant "déplacement_avant_arriere+deplacement_lateral+tir".

Par exemple, si j'ai appuyé sur la flèche UP, le paquet contiendra le message "1+0+0", voulant dire que la variable déplacement_avant est sur 1), le personnage avance (tout seul grâce à la "loop" de mon jeu) jusqu'au prochain paquet reçu contenant le message "0+0+0" car j'ai relaché la touche UP, stoppant l'avancée du joueur.(ensuite même chose pour le déplacement latéral, puis presque la même chose pour le tir)

Donc dans mon jeu, il n'y a pas de prédiction, cet à dire que mon propre perso à l'écran n'avance que par les messages retournés du serveur, je n'anticipe pas le mouvement ou l'action sur mon PC. Donc, j'appui sur la touche T -> envoi au serveur -> le serveur me retourne mon propore ordre "T" -> mon perso tir sur mon écran. Il y a donc une latence du au trajet.

Ce modèle fonctionne pas trop mal pour l'instant sur mon PC en "localhost" mais j'ai un doute sur sa perénité en vrai réseau où le délai sera parfois plus long entre client -> serveur-> client.

Dans les jeux actuels, il y a de la prédiction, est-ce obligatoire pour un jeu plus modeste.

Tout celà afin de peser le niveau de difficuté et savoir si je persevère ou j'arrête le online pour plus abordable.

[Ti-R]

La direction semble bonne.
Plusieurs questions, tu utilises une bibliothèque qui gère l'udp et donc les doublons, les traitements d'erreur etc ?

Pour l'instant, j'envoi au serveur toutes les 2 ms un paquet (UDP) contenant le message suivant "déplacement_avant_arriere+deplacement_lateral+tir".

Moins bonne idée, il vaut mieux envoyer un message que lorsqu'il y a une action, avec un message de temps en temps pour simuler un "keep alive", car sinon cela prend beaucoup de bande passante pour rien et entraîne sûrement des problèmes de latence à terme sur un plus gros système.

Sinon le système d'architecture de communication client->serveur->tous-les-clients me semble bon, c'est sur qu'il y a toujours un décalage, mais dans tous les jeux c'est pareil, donc il faut pas s'en faire, c'est logiquement "normal".

[hedo888]

La direction semble bonne.
Plusieurs questions, tu utilises une bibliothèque qui gère l'udp et donc les doublons, les traitements d'erreur etc ?

Oui, la petit librairie (lidgren : http://www.lidgren.net/wiki/doku.php...ibrary.network) que j'utilise gère tout celà (reliable, élimination des doublons etc.). (Librairie qui ne regorge pas de documentation en revanche).

Moins bonne idée, il vaut mieux envoyer un message que lorsqu'il y a une action, avec un message de temps en temps pour simuler un "keep alive", car sinon cela prend beaucoup de bande passante pour rien et entraîne sûrement des problèmes de latence à terme sur un plus gros système.

Ma première architecture était de ce type, puis après avoir lu un article sur le fonctionnement reseau de base d'un FPS, j'ai finalement ajouté une boucle (dans le thread client) qui envoie régulièrement le message qu'il y ai redondance ou non du message .... mais effectivement il serait plus judicieux de faire une vérification de redondance avant l'envoie à chaque "TICK client" du paquet pour alleger le traffic vers le serveur. Comment font les jeux actuels basés sur un débit ADSL ? (envoi à chaque TICK ou envoi que si changement).

Sinon le système d'architecture de communication client->serveur->tous-les-clients me semble bon, c'est sur qu'il y a toujours un décalage, mais dans tous les jeux c'est pareil, donc il faut pas s'en faire, c'est logiquement "normal".

En fait, je suis un piètre programmeur du dimanche (je suis plutôt un artiste qui s'est mis à la programmation,d'où le choix de TV3D) et j'ai un peu peur de perdre mon temps à programmer une chose qui n'aboutira pas à cause d'une trop grande complexité que je n'avais pas vu au départ. D'où je preferai tout de suite trouver l'épine insurmontable s'il y en a une me permettant de me rabattre à l'offline (à contre coeur tout de même).

Donc en clair, pour un FPS moyennement rapide (que du tir sniper et mortier) regroupant 10 joueurs,

- aurai-je besoin de prédiction (et ses équations de recalage de la prédiction client du perso sur sa vraie position serveur, ....équations qui ne me tentent pas du tout)

- sentira t on l'absence de prédiction (la latence client->serveur(+traitement de l'info reçu)->retour au client) sera de combien de millisecondes, environ ? )

- est-ce que le PC d'un joueur pourra faire eventuellement office de serveur, à défaut, un serveur gratuit sera t il suffisant ?

[Ti-R]

- aurai-je besoin de prédiction (et ses équations de recalage de la prédiction client du perso sur sa vraie position serveur, ....équations qui ne me tentent pas du tout)

Justement "que du tir sniper et mortier", c'est presque 2 cas totalement différent.

Soit pour le sniper, tu essayes une version "non-réaliste", et tu fais un lancer de rayon locale à la machine, lorsque le tir à lieu, le test est effectué, et donc le test local sera envoyé au serveur comme instruction (sniper à toucher joueur n), soit tu envoies l'information au serveur qui calcule le tout, mais il peut se produire un "gros" décalage, et tu rates ta cible.

Pour le mortier, le test peut s'effectuer côté serveur, car le tir mettra un certain temps à "atterrir", donc le temps de transfert de ton pc au serveur qui va recalculer l'heure de départ du tir et son arrivé, devrait être mieux géré, car le serveur connaîtra au moment X la place de chaque joueur.

Mais le test peut être fait en local aussi pour "coller" à ton affichage.

- sentira t on l'absence de prédiction (la latence client->serveur(+traitement de l'info reçu)->retour au client) sera de combien de millisecondes, environ ? )

Tout dépend de l'architecture, mais oui on sent toujours un peu de latence et tout dépend de la connection de la personne à internet et ou se trouve le serveur.

- est-ce que le PC d'un joueur pourra faire eventuellement office de serveur, à défaut, un serveur gratuit sera t il suffisant ?

Oui pas de problème !
Pour 10 joueurs cela devrait aller si l'architecture réseau est bien conçus et événementielle (1 action /1 message ou n-actions/1 message mais pas n-messages pour 1 action), mais au dessus... cela commencera peut être à faire juste.

[hedo888]

C'est là que tout ce complique, car si je gère le lancer de rayon au niveau du serveur, il me faut des déplacements de mesh au niveau serveur pour calculer l'impact du rayon, donc il va falloir que le serveur passe du rôle de simple relais passif dispatcheur d'evenements (déplacements, tir) à un rôle actif de synthèse complet du champ de bataille (création des meshs ("virtuels" car non rendus sur l'écran serveur), reception des evenements claviers joueur, calcul des deplacements, calcul des impacts (voir même des collisions)..puis retour des résultats vers les clients.

Le client ne sera qu'un lanceur d'evenement et recolteur de résultat. Ce qui condamne un peu le fait qu'un PC puisse hoster une partie car il devra alors calculer les deplacements, impacts etc. des 10 joueurs de la partie plus les propres déplacements de son perso. Il faudra alors plutôt un serveur independant relativement puissant.

Ca me chiffonne tout celà.

Il est vrai que si on cantonne le serveur à un simple dispatcheur des infos de déplacement, ordre de tir (réduisant déjà légerement les décalages eventuels)..... mais que les impacts, collisions sont calculés chez chaque client la chose est relativement simple à coder (et la charge de calcul est bien repartie).. mais il va y avoir du décalage dans l'air. A moins d'adapter un gameplay très lent (tir au mortier exclusivement, déplacements lents) absorbant les eventuels décalages... mais est-ce vraiment sérieux comme perspective, je me le demande.

[Ti-R]

Oui c'est la question de quoi mettre dans le serveur.
Je pense que si la connection est très bonne chacun peut faire tous les test en locals. Et le serveur dispatch les diverses informations.

[hedo888]

Oui, j'espère, donc je part sur l'idée de gerer le lancer de rayon en local pour l'instant quite à revoir le gameplay du jeu pour plus de lenteur.

Par contre, je viens de m'apercevoir que chaque client devra envoyer par moment sa véritable position X,Z, un recalage régulier sera necessaire car le fait d'envoyer la direction et la vitesse de son perso induit que si, sur un PC client, le message d'arrêt du mouvement (par exemple) arrive legerement en retard, le mesh sur ce client aura avancé trop loin par rapport aux autre client (aura des coordonnées X et Z differentes des autres client). Ces petits décalage s'accumuleront au fur et à mesure du temps jusqu'à une aberration totale de la position du mesh d'où un recalage (c'est le glissement vers la nouvelle position qui va poser problème pour éviter un accoup).

[Ti-R]

Oui cela se voit par exemple sur le jeu CounterStrike... dès qu'un joueur à un mauvais ping, il se déplace et se "téléporte" régulièrement car sa vitesse varie au cours du temps et donc comme tu le dis très bien, doit être repositionné au bon endroit régulièrement.

[orelero]

J'me demandais si le serveur ne pouvais pas enregistrer le pathtrack de chaque joueur des 100 dernières millisecondes par example.
Ainsi, un sniper ayant un temps de réponse de 200ms tire au temps t, le serveur reçoit l'info à t+100, il remonte le temps grâce aux infos du pathtrack et fait ses calculs de collisions.

[Ti-R]

A tester, mais effectivement cela pourrait fonctionner, à condition que les informations de client ne soit pas trop décalé avec celle du serveur.

Car avec 200 ms de ping, le client il a reçu une information il y a 200 ms, la trajectoire des autres clients à pu être interpolé sur 100 ms. Donc l'information arrive au serveur, qui retourne 200 ms dans le temps, et interpole sur 100 ms comme à fait le client.

Le problème étant de savoir comment "retourner dans le temps", avec un moteur physique par exemple et sélectionner ce qu'il faudrait retourner dans le temps, car à chaque tir, retourner tout le jeu 200 ms en arrière; cela ne doit pas être léger.