Discussion :

[gusgus]

Bonjours.

Je réfléchit un petit programme en réseau avec de la physique,et j'ai une question qui reste pour le moment sans réponse.

Imaginons un FPS. Quand un joueur se connecte,il doit recevoir la position de tout les joueurs,etc. Or le temps que le serveur lui envoi tout sa, les joueurs auront déjà bougés , ce qui désyncronise pas mal de trucs. Comment faire pour que sa reste a peu près syncro?

[yamashi]

Envoyer 30 position revient a envoyer 30 x 6 float (3 pour la position, 3 pour la rotation) et ensuite tu verras pour les emats.
Ce qui donne 180 x 4octets = 720 octets ce qui n'est pas énorme tu peux tout mettre dans un paquet UDP. Donc le réseau n'est pas un gros problème, surtout dans un FPS car si tu perds un paquet en route ce n'est pas grave car tu vas en recevoir un plus récent dans les quelques milisecondes qui suivent.

En revanche le problème est le lag compensation, il est clair que au dessus de 150ms ce n'est pas faisable. Je pars sur le principe que personne n'aura au dessus de 150ms.
Dans un FPS tu envoie des commandes au serveur et celui-ci confirme ou non si tu peux effectuer l'action, mais le problème est que si un joueur clique "tire", il envoie au server "je veux tirer tu en pense quoi ?" le serveur peut répondre "Oui,oui vas-y" mais avec la latence et le ping le joueur va tirer 150ms plus tard, il faut donc mettre en place un système de client prediction, le client va ce dire "je vois pas pourquoi il refuserait alors je fais", résultat le client vas tirer et si il ne pirate pas il n'y a pas de raison que le serveur refuse. Donc la grosse difficulté dans les commandes c'est de mettre en place une fausse confirmation chez le client.

Ensuite pour les joueurs certes ils seront décalé par rapport a leur réel position mais le serveur garde les anciennes position pour vérifier en fonction de la latence des deux joueurs.
Je pense qu'une image illustrera mieu mes propos :


Image tiré de l'article de valve sur le lag.

Si tu as besoin d'autres précision n'hésite pas.

PS : si tu es bon en anglais : Regarde l'article de Valve

[gusgus]

En faite je connais *bien* les algo de lag compensation(j'ai déjà lu l'article que tu montre).Mais je doute que je puisse tout envoyer dans un même packet UDP. En effet je n'envoy pas que la positionet la rotation, il y a plein d'infos en plus(le nom du joueurs,etc),ce qui augmente pas mal la taille du packet...

Edit: en fait tu a raison,on est pas obliger d'envoyer toutes les infos(genre le nom) dans le même packet. il suffit d'envoyer les coord en dernier.Par contre, quelle est la taille maximal d'un packet UDP pour qu'il transite rapidement (<150ms par exemple)? Et comment faire avec un nombre elevé de joueurs?

[yamashi]

Pour ce qui est de la taille du paquet UDP je pense qu'il ne vaut pas mieu dépassé 1500octets pour éviter des pertes ou des paquets cassé. Mais ce qui génère réellement le ping c'est le nombre de saut entre les joueurs et le serveur donc il vaut mieux avoir un serveur connecté directement connecté au routeur principaux mais la on rentre côté hardware.

Le nom tu le broadcast par TCP avec un id lors de la connexion du client.
Pour ce qui est d'un grand nombre de joueurs après pas mal de test et de recherche j'ai trouvé que le mieux c'est de représenté le joueur comme une sphère côté serveur ayant comme centre la position du joueur et de tester si les joueurs sont visible (donc dans la sphère) et ainsi envoyé seulement la position de ce qui est présent dans la sphère, mais c'est assez coûteux de calculer ça donc j'utilise CUDA pour ce genre de chose.

[gusgus]

Ok merci!

[shenron666]

représenté le joueur comme une sphère côté serveur ayant comme centre la position du joueur et de tester si les joueurs sont visible (donc dans la sphère) et ainsi envoyé seulement la position de ce qui est présent dans la sphère, mais c'est assez coûteux de calculer ça donc j'utilise CUDA pour ce genre de chose.

CUDA pour calculer si un joueur est proche ou éloigné d'un auter joueur ?
après le bazooka pour tuer une mouche, le lance missiles intercontinental à ogives nucléaires pour détruire l'oeuf de la mouche

sérieusement, CUDA pour calculer une distance entre 2 points c'est abusé
d'autant plus qu'il n'a même pas besoin de calculer la racine carrée, et à la limite tu peux te limiter à la position 2D (tu ignores la coordonnée verticale)