[UDP] temps-réel dans un jeu - stratégie à adopter ?
docteur_re
Messages postés13Date d'inscriptionvendredi 17 décembre 2004StatutMembreDernière intervention 7 avril 2006
-
12 mars 2006 à 11:23
cs_zibong
Messages postés35Date d'inscriptionmardi 27 juillet 2004StatutMembreDernière intervention21 juillet 2008
-
20 oct. 2006 à 21:23
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....
on utilise TCP pour des données sensible dont l'integritée est trés importante.
UDP serat utiliser pour les données dont l'integritée est aleatoire et peut etre facilement corrigée.
c'est pour cela que sur les jeux Online (connexion UDP) il y a :
le GrabLag (perte de paquet des coordonnées du personnage),
le CrazyJump (paquets de coordonnées du personnage erroné),
le Dupe (duplication d'items),
le CK (Char Killer) (modification du personnage le rendant invincible et pouvant tuer d'autre joueur),
le HighLev (personnage mis au maximum des possibilitée en modifiant les paquets),
le FullDrop (permet de dropper que de bon objet ou le meme type d'objet a chaque fois),
le DupeDrop (permet de dropper plusieurs drop identique en une seule fois (l'or ou les munitions generalement)),
le BeWarp ou BrutClip (permet de passer dans une zone bloquée ou non accessible sur la map),
le BoomShoot ou OSOD (One shoot one death) (permet de tuer un ou plusieurs NPC en un seul coup) ect...
autant d'effets indesirable inerant de l'utilisation d'un protocol peu fiable.
La plupart du temps on utiliseras les deux en meme temps, UDP pour la position des elements animé (npc, bullet, zone d'effet, personnage, coéquipier, sort, tir ect...) et le protocol TCP pour les elements qui n'ont pas besoin d'etre "sus" rapidement et qui ont besoin d'etre un minimum securisé tel les drops, items echangés, achetés, ramasés, changement de zones, transfert de données importante (mises a jours, informations clients/serveur ect...).
on peu egalement transmettre un control des données toute les X secondes sur TCP pour pallier au problemes survenus en UDP.
<hr size="2" width="100%">La theorie c'est quand on sait tout, mais que rien ne fonctionne.
La pratique c'est quand tout fonctionne, mais que personne ne sait pourquoi.
<hr>