[UDP] temps-réel dans un jeu - stratégie à adopter ?

Résolu
Signaler
Messages postés
13
Date d'inscription
vendredi 17 décembre 2004
Statut
Membre
Dernière intervention
7 avril 2006
-
Messages postés
13
Date d'inscription
vendredi 17 décembre 2004
Statut
Membre
Dernière intervention
7 avril 2006
-
bonjour a tous,





imaginons le cas de figure suivant :





j'ai 2 programmes, client et serveur.


- le premier écoute les evenements d'un joystick et envoie les coordonées des axes par UDP au second


- le second les reçoit et les utilise.





l'udp est utilisé afin de garantir une transmission temps réèl (comme dans les jeux en réseau style FPS)





mon seul probème est de savoir quelle stratégie adopter pour envoyer ces paquets. Voici celles que j'ai envisagées :





1 - Les envoyer simplement avec un sento() à la suite les unes des
autres, à chaque réception d'un evenement joystick. Mais cela ne permet
pas de garantir que la dernière coordonnée est arrivée.




2 - Envoyer en permanence avec un sleep de 5 millisecondes les
coordonnées joystick. Un peu bourrin et surtout pourquoi 5
millisecondes et pas un autre nombre, cela dépendrait de la qualité du
réseau.




3 - Envoyer les coordonées avec un identificateur unique, puis
attendre une réponse avec ce meme identificateur pour en renvoyer un
autre. Oui mais si la réponse ne reviens jamais, le programme se
bloque. On peut alors penser à un timeout à partir duquel les
coordonnées sont réémise. Et encore une fois, quelle valeur pour ce
timeout ?




voilà, j'ai pas d'autres idées pour le moment. En fait jaimerais
bien m'inspirer des jeux existant genre counter-strike, ou ceux
open-source pour aller voir comment ils procèdent.


Si certain ont déjà eu l'occasion de travailler sur le problème....





Merci


bye

4 réponses

Messages postés
627
Date d'inscription
mercredi 16 juin 2004
Statut
Membre
Dernière intervention
24 juillet 2011
2
Pourquoi pas une connection en TCP/IP ? Au moins les paquets seront automatique numérotés. Le protocole garantit (si je ne dis pas de bétise) la réception des données en répondant à l'emetteur.
Les clients se connectent donc au serveur en TCP/IP et c'est lui qui gère les transmissions de paquets.

Counter-Strike utilise l'udp il me semble (peut-etre pour ça que tu as voulu le faire en udp?)...avec paquets numérotés il me semble. Il envoie des paquets à temps régulier dépendant de ton cl_cmdrate et recoit des paquets en fonction du tickrate du serveur et de ton cl_updaterate. De plus, le paquet ne contient que des mises à jour...pour éviter qu'il ne fasse une taille trop imposante.


Je me suis interessé il y a peu de temps à l'utilité du tickrate sur counter strike et j'ai trouvé ce superbe article...il pourrait peut-etre t'aider à comprendre le fonctionnement du jeu pour t'en inspirer : http://www.darkgamers.fr/articles/42/Le-netcode-de-CSS-Tout-est-dit-ici.html (c'est assez long; n'hésite pas à scroller )

Tiens moi au courant
Have a good day
Messages postés
2023
Date d'inscription
mardi 24 septembre 2002
Statut
Membre
Dernière intervention
28 juillet 2008
5
C'est pour ca que a mon avis, envoyant les coordonnées des axes n'est
pas suffisant. Tu peux pas plutot directement envoyer une position ou
une donnée mieux définie de facon à ce que meme si une trame disparait,
la suivante permet un rafraichissement correcte.
Messages postés
13
Date d'inscription
vendredi 17 décembre 2004
Statut
Membre
Dernière intervention
7 avril 2006

luhtor : dans ce cas je peux très bien renvoyer à intervale régulier les coordonnées des axes, ca reviens au même qu'une position. 2ème choix dans ce que j'ai écris.

Gendal67 : Je connais bien TCP et j'ai d'ailleurs commencé par implémenter ce protocole pour faire ça, mais le problème est que c'est super lent. En fait oui les paquets non-reçus sont automatiquement re-transmis et remis dans l'ordre, de façon transparente. Mais celà implique une entete beaucoup plus longue qu'en UDP, ainsi que de devoir attendre les données pour les classer (et en gros plein d'autres trucs couteux en temps).

J'ai fait des tests là, et en UDP c'est vraiment plus rapide. En fait je dois utiliser un réseau tout pourri (GSM), c'est pourquoi je ne peux pas utiliser TCP pour du temps-réel. Et pour counter-strike les developpeurs ont surement eu le même raisonnement. Enfin de toute façon en règle générale TCP n'est pas prévu pour du temps réel c'est à dire streaming vidéo, audio, jeux temps-réel, etc...
Pour info le DNS fonctionne en UDP car TCP serait bien trop lourd et surchargerait les serveurs.

En tout cas merci pour le lien, jvai lire ça bien à fond et jte tiens au courant de l'évolution, pas de souci ;)

bybye
Messages postés
13
Date d'inscription
vendredi 17 décembre 2004
Statut
Membre
Dernière intervention
7 avril 2006

bon
après une lecture assidu de cet article, super interressant d'ailleurs, j'en ai conclu qu'il faut utiliser la méthode 2, c'est à dire envoyer en permanence toutes les x millisecondes. Cette valeur devant être determinée en fonction de :
1 - la taille de chacun des paquets
2 - la bande passante
de façon a éviter le 'choke' (voir article) c'est à dire qu'un nouveau paquet commence à être envoyé tandis que le précédent n'a pas encore fini d'etre envoyé. (ce qui crée un retard dans les envois qui augmente à chaque fois)

je ne pense pas utiliser la numérotation étant donnée qu'elle ne sais qu'à calculer le nombre de paquets perdus, information peut utile dans mon cas. Quoique ça peut servir si en réception 2 paquets sont inversés, on prend en compte que le premier et on laisse tomber le 2ème.

je part en phase testing ;)