[UDP] temps-réel dans un jeu - stratégie à adopter ?
Résolu
docteur_re
Messages postés
13
Date d'inscription
vendredi 17 décembre 2004
Statut
Membre
Dernière intervention
7 avril 2006
-
12 mars 2006 à 11:20
docteur_re Messages postés 13 Date d'inscription vendredi 17 décembre 2004 Statut Membre Dernière intervention 7 avril 2006 - 12 mars 2006 à 15:38
docteur_re Messages postés 13 Date d'inscription vendredi 17 décembre 2004 Statut Membre Dernière intervention 7 avril 2006 - 12 mars 2006 à 15:38
4 réponses
Gendal67
Messages postés
627
Date d'inscription
mercredi 16 juin 2004
Statut
Membre
Dernière intervention
24 juillet 2011
2
12 mars 2006 à 11:42
12 mars 2006 à 11:42
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
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
luhtor
Messages postés
2023
Date d'inscription
mardi 24 septembre 2002
Statut
Membre
Dernière intervention
28 juillet 2008
6
12 mars 2006 à 11:36
12 mars 2006 à 11:36
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.
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.
docteur_re
Messages postés
13
Date d'inscription
vendredi 17 décembre 2004
Statut
Membre
Dernière intervention
7 avril 2006
12 mars 2006 à 14:41
12 mars 2006 à 14:41
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
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
docteur_re
Messages postés
13
Date d'inscription
vendredi 17 décembre 2004
Statut
Membre
Dernière intervention
7 avril 2006
12 mars 2006 à 15:38
12 mars 2006 à 15:38
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 ;)
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 ;)
