Wi en fait, je n'ai jamais écrit de protocole réseau dans la pratique, mais c'est ce qui ressort de tous les articles. Quand la vitesse est bien plus importante que la précision de l'information, alors c'est l'udp qu'il te faut. Or c'est clairement le besoin dans la plupart des jeux, et un jeu de voiture en particulier.
Pour l'udp, le truc, ce n'est pas que ça "souffre de perte de paquet", c'est juste que tout est à faire. C'est un protocole quasi vierge. Mais rien ne t'empêche de créer tes propres acquittements, et ton propre système d'ordonnancement des paquets (l'ordre des paquets et les acquittements donc l'assurance d'arrivée du paquet étant les 2 caractéristiques principales du tcp par rapport au udp). Le seul truc, c'est que toi tu n'en as pas besoin constamment.
En effet, la plupart du temps, tu t'en fous de perdre des paquets. L'important, c'est qu'un nombre suffisant de paquet arrive (évidemment si trop de paquet n'arrivent pas à destination, c'est que la connexion client-serveur est vraiment trop mauvaise, et donc tu coupes. Or pour cela, le tcp n'y aurait rien changé, sinon encore plus de désagrément peut-être). Evidemment les paquets absents sont "remplacés" par des prédictions comme indiqué plus haut. D'ailleurs dans le cas de véhicule, je pense que ça doit même être plus facile et on doit pouvoir avoir des algos prédictifs plus robustes que -- par exemple -- des personnages, car y a bien plus d'inertie (alors qu'un bonhomme peut tourner à 180° et réaccélérer immédiatemment dans l'autre sens en un rien de temps).
Ensuite, le point important de l'acquittement, disons qu'il n'est pas nécessaire constamment comme on vient de le voir, par contre dans certains cas ça peut être nécessaire. Par exemple, les trajs de ton jeu de 4x4, on a vu qu'il est juste important d'avoir un nombre de paquet suffisant. Donc pas d'acquittement. Par contre, si jamais le joueur veut envoyer un message à un autre joueur, là il faut de l'acquittement, parce qu'on veut être sûr que le serveur a reçu le message à transmettre (dans un jeu, on n'imaginerait pas un système de comm qui marche aléatoirement :p). C'est vrai aussi pour toute possibilité du jeu qui soit ponctuelle en fait, et donc qu'on ne puisse absolument pas prédire. Par exemple, si ton jeu incorporait des armes sur les véhicules, il serait évident -- je pense -- que les tirs soient acquittés (on veut être sûr que le serveur sait qu'on tire, il peut pas le "deviner")... à moins évidemment que ce soient des tirs en rafale (mitraillette). Là évidemment, c'est pas grave si le serveur reçoit des coupures dans le tir, il imaginera un temps de latence de l'arme suffisant pour que le tir soit continu en recevant des informations incomplètes, quoique suffisamment proche (y a alors acquittement partiel par exemple).
Une autre idée d'acquittement est d'en faire, mais limitée en nombre de tentatives. Par exemple certains paquets peuvent demander un acquittement, mais pas une seconde fois (le tcp redemande tant qu'il n'a pas confirmation. Donc ça peut boucler très longtemps, alors que les infos reçus seraient obsolètes depuis longtemps et il aurait mieux valu les oublier pour la fluidité du jeu).
Pour l'histoire de l'ordre des paquets, c'est pareil. Tout dépend vraiment de tes souhaits. Là l'exemple précédent serait inversé par ex, je pense. Par exemple, pour tout ce qui est mouvement de véhicule, l'ordre a quand même son importance. Par contre, un tir d'arme, j'imagine que ça va dépendre de l'effet qu'on souhaite en cas de léger lag.
Idéalement évidemment les paquets sont reçus instantanément, donc l'ennemi nous voit tirer au moment où on le veut. Mais si jamais y a latence, soit avec de l'ordonnancement, on va dire que le tir est à un moment précis qui est déjà passé... dans ce cas, on fait quoi? Les joueurs en avance subissent un retour en arrière du jeu pour qu'ils puisse assister au tir?
Ou alors sans ordonnancement, le tir est effectué au moment où il est reçu. A ce moment, c'est plus fluide, car les autres joueurs voient bien le tir sans saute dans le temps, mais ce dernier n'a pas forcément l'effet escompté par le joueur qui tire.
Evidemment, ce sont des "pires-cas", mais c'est bien le principe de ces protocoles, essayer d'amoindrir l'effet des mauvais cas pour tous les joueurs (dans l'idéal, y aura pas besoin d'acquittement ni d'ordonnancement :p), et repérer les cas vraiment trop mauvais où on coupe la connexion.
On peut aussi imaginer des ordonnancements "approximatifs". C'est à dire qu'il ne faut pas être trop précis, et ainsi imaginer des intervalles où on considère que l'info reçue est suffisamment ordonnée pour ne pas gêner le jeu, et d'autre où l'info doit soit être réordonnée, soit carrêment oubliée (par ex trop vieille).
En fait, tout est imaginable selon ce que tu souhaites. C'est l'avantage du udp vis à vis du tcp. Le tcp est "trop parfait", et par conséquent, il est lent. Le udp est vierge, t'en fais ce que tu veux, et c'est donc à toi de décider ce qui doit absolument arriver à destination, ce qui serait bien d'arriver à destination mais pas indispensable, ce qui n'est pas une info primordiale du tout, ce qui doit arriver avec un minimum d'ordre ou pas, etc. Le tout, c'est de ne jamais bloquer le jeu. Et pour ça, le tcp c'est mauvais (boucle d'acquittement, attente d'un paquet manquant parce que tenant trop compte de l'ordre, et donc lag énorme). Mieux vaut faire ton protocole perso basé sur l'udp réglé selon les spécificités uniques de ton jeu.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: premiere idée
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Rendre un jeu jouable en réseau. Évalué à 10.
Pour l'udp, le truc, ce n'est pas que ça "souffre de perte de paquet", c'est juste que tout est à faire. C'est un protocole quasi vierge. Mais rien ne t'empêche de créer tes propres acquittements, et ton propre système d'ordonnancement des paquets (l'ordre des paquets et les acquittements donc l'assurance d'arrivée du paquet étant les 2 caractéristiques principales du tcp par rapport au udp). Le seul truc, c'est que toi tu n'en as pas besoin constamment.
En effet, la plupart du temps, tu t'en fous de perdre des paquets. L'important, c'est qu'un nombre suffisant de paquet arrive (évidemment si trop de paquet n'arrivent pas à destination, c'est que la connexion client-serveur est vraiment trop mauvaise, et donc tu coupes. Or pour cela, le tcp n'y aurait rien changé, sinon encore plus de désagrément peut-être). Evidemment les paquets absents sont "remplacés" par des prédictions comme indiqué plus haut. D'ailleurs dans le cas de véhicule, je pense que ça doit même être plus facile et on doit pouvoir avoir des algos prédictifs plus robustes que -- par exemple -- des personnages, car y a bien plus d'inertie (alors qu'un bonhomme peut tourner à 180° et réaccélérer immédiatemment dans l'autre sens en un rien de temps).
Ensuite, le point important de l'acquittement, disons qu'il n'est pas nécessaire constamment comme on vient de le voir, par contre dans certains cas ça peut être nécessaire. Par exemple, les trajs de ton jeu de 4x4, on a vu qu'il est juste important d'avoir un nombre de paquet suffisant. Donc pas d'acquittement. Par contre, si jamais le joueur veut envoyer un message à un autre joueur, là il faut de l'acquittement, parce qu'on veut être sûr que le serveur a reçu le message à transmettre (dans un jeu, on n'imaginerait pas un système de comm qui marche aléatoirement :p). C'est vrai aussi pour toute possibilité du jeu qui soit ponctuelle en fait, et donc qu'on ne puisse absolument pas prédire. Par exemple, si ton jeu incorporait des armes sur les véhicules, il serait évident -- je pense -- que les tirs soient acquittés (on veut être sûr que le serveur sait qu'on tire, il peut pas le "deviner")... à moins évidemment que ce soient des tirs en rafale (mitraillette). Là évidemment, c'est pas grave si le serveur reçoit des coupures dans le tir, il imaginera un temps de latence de l'arme suffisant pour que le tir soit continu en recevant des informations incomplètes, quoique suffisamment proche (y a alors acquittement partiel par exemple).
Une autre idée d'acquittement est d'en faire, mais limitée en nombre de tentatives. Par exemple certains paquets peuvent demander un acquittement, mais pas une seconde fois (le tcp redemande tant qu'il n'a pas confirmation. Donc ça peut boucler très longtemps, alors que les infos reçus seraient obsolètes depuis longtemps et il aurait mieux valu les oublier pour la fluidité du jeu).
Pour l'histoire de l'ordre des paquets, c'est pareil. Tout dépend vraiment de tes souhaits. Là l'exemple précédent serait inversé par ex, je pense. Par exemple, pour tout ce qui est mouvement de véhicule, l'ordre a quand même son importance. Par contre, un tir d'arme, j'imagine que ça va dépendre de l'effet qu'on souhaite en cas de léger lag.
Idéalement évidemment les paquets sont reçus instantanément, donc l'ennemi nous voit tirer au moment où on le veut. Mais si jamais y a latence, soit avec de l'ordonnancement, on va dire que le tir est à un moment précis qui est déjà passé... dans ce cas, on fait quoi? Les joueurs en avance subissent un retour en arrière du jeu pour qu'ils puisse assister au tir?
Ou alors sans ordonnancement, le tir est effectué au moment où il est reçu. A ce moment, c'est plus fluide, car les autres joueurs voient bien le tir sans saute dans le temps, mais ce dernier n'a pas forcément l'effet escompté par le joueur qui tire.
Evidemment, ce sont des "pires-cas", mais c'est bien le principe de ces protocoles, essayer d'amoindrir l'effet des mauvais cas pour tous les joueurs (dans l'idéal, y aura pas besoin d'acquittement ni d'ordonnancement :p), et repérer les cas vraiment trop mauvais où on coupe la connexion.
On peut aussi imaginer des ordonnancements "approximatifs". C'est à dire qu'il ne faut pas être trop précis, et ainsi imaginer des intervalles où on considère que l'info reçue est suffisamment ordonnée pour ne pas gêner le jeu, et d'autre où l'info doit soit être réordonnée, soit carrêment oubliée (par ex trop vieille).
En fait, tout est imaginable selon ce que tu souhaites. C'est l'avantage du udp vis à vis du tcp. Le tcp est "trop parfait", et par conséquent, il est lent. Le udp est vierge, t'en fais ce que tu veux, et c'est donc à toi de décider ce qui doit absolument arriver à destination, ce qui serait bien d'arriver à destination mais pas indispensable, ce qui n'est pas une info primordiale du tout, ce qui doit arriver avec un minimum d'ordre ou pas, etc. Le tout, c'est de ne jamais bloquer le jeu. Et pour ça, le tcp c'est mauvais (boucle d'acquittement, attente d'un paquet manquant parce que tenant trop compte de l'ordre, et donc lag énorme). Mieux vaut faire ton protocole perso basé sur l'udp réglé selon les spécificités uniques de ton jeu.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]