Comment organiser les appels réseau pour transmettre des mouvements fluides ?

Bien le bonjour,

Mon problème du jour concerne l'envoi de messages sur le réseau.

Comment coordonner des mouvements de personnages pour que chaque chaque joueur puisse avoir un visuel fluide ? Quel genre de message devrais-je envoyer ? A quelle fréquence ? A qui ?

Sachant qu'évidemment je n'ai pas 20 FPS réseau.

Je ne cherche pas une solution clef en main mais plutôt des idées, des réflexions, des explications de méthodes déjà employées ...

Pour l'instant je pars sur l'idée d'envoyer des ordres de mouvements et chaque joueur interprêtera ces ordres de la même manière en attendant un éventuel contre-ordre. Mais avez-vous d'autres idées plus pertinentes ?

:merci:

Dans ce genre de cas; j'opterais pour une gestion de l'animation coté client et une resynchro lancée par le server regulierement. Normalement, la difference doit aps etre tres grande.

Merci pour ta réponse.

Mais je n'ai pas forcément une archi client/serveur classique.
On va résonner sur N joueurs. L'un d'eux contrôle un personnage et le fait bouger ; les autres doivent pouvoir visualiser son mouvement de manière fluide.

Si les joueurs demandent régulièrement les coordonnées du personnage, on n'aura de loin pas 20 FPS réseau et donc pas 20 FPS graphique. Il faut forcément interpoler un peu.

Ok dans ce cas, disons que celui qui fait bouger un perso envoie les ordre qu'il donne pour faire bouger son perso sur le resau.

Sur chaque client, un "joueur reseau" repete les meme actions. de temps en temps, celui qui fait bouger sont perso envoie aussi la position a laquelle il est arrivé, afin de corriger les decaclages du au ping/aux arrondis de calcul/au framerate de chaque machine/etc . . .

Citation:

---

Envoyé par khayyam90

Comment coordonner des mouvements de personnages pour que chaque chaque joueur puisse avoir un visuel fluide ? Quel genre de message devrais-je envoyer ? A quelle fréquence ? A qui ?

Sachant qu'évidemment je n'ai pas 20 FPS réseau.

---

Je suis confronté à ce problème et je me suis déjà posé la question.
On parle de resynchro je ne vois pas trop autrement.
Elle pourrait se faire selon un "timestamp" autrement dit un identifiant horaire reçu.
Par exemple pour un client donné on interroge le serveur ou les autre pairs si le "timestamp" reçu est identique au timestamp courant alors on ne fait rien..

Sinon on peut peut-être gérer cela avec une pile d'action...

Ou bien alors gérer du multithreading ( la programmation réseau dans un jeu vidéo c'est là une utilisation pertinente du multithreading ).
Par exemple un perso et son comportement c'est un thread qu'on doit resynchroniser à chaque réception des données réseau.

En tout cas si tu trouves une solution cela serait bien de l'exposer à tout le monde :D

en fait, ce qui est fait généralement, c'est d'envoyer la position du perso, et ses info d'evolution courante (direction, vitesse...) comme ca, chaque client peut continuer à faire "évoluer" l'autre en local, jusqu'au prochain message qui lui donnera les nouvelles info.
dans le cas général, ca marche pas trop mal. Par contre, si tu a un mec qui s'amuse à avoir une trajectoire completement aléatoire, la, forcement, ca donnera un resultat etrange (perso qui se téléporte...)
après, tout dépend du potentiel réactif de tes entités...

Merci bien pour vos réponses.

L'idée de diffuser une position ainsi que le vecteur vitesse de déplacement me semble intéressante. Il faudra essayer de donner un max d'infos pour que le client puisse interpoler le mouvement tout seul avec un minimum de messages de synchro (peut-être 1 ou 2 par seconde, voire moins). Et oui, je suis dans un cas où beaucoup de personnages se déplacent en même temps ;) donc beaucoup de messages à envoyer ou alors des gros messages.

si c'est pour un RTS comme je le soupconne subtilement, tu gagnerais surement à avoir un pathfinder deterministe et à juste envoyer la position et la destination, le chemin sera calculé par le client, en plus, tu n'a à envoyer de nouveau message qu'en cas de changement d'action courante d'une unité, ce qui reduit fortement l'envoie de ces info (et une petite synchro de temps en temps bien entendu ;-)

Citation:

---

Envoyé par bafman

si c'est pour un RTS comme je le soupconne subtilement

---

Je ne vois pas du tout de quoi tu veux parler. :mrgreen:

Citation:

---

Envoyé par bafman

tu gagnerais surement à avoir un pathfinder deterministe

---

encore une idée intéressante, qui a l'avantage d'être plus légère en échanges réseau.

le probleme du pathfinder déterministe, c'est que c'est très facile à faire sur une carte à base de cases, beaucoup moins pour une carte sans case.

tout à fait d'accord, mais ça sort du cadre de l'organisation des appels réseau. Ca devient une histoire de pathfinder.

Citation:

---

Envoyé par khayyam90

Je ne vois pas du tout de quoi tu veux parler. :mrgreen:

---

tiens tiens du projet commun en l'air ?? :mrgreen:

Citation:

---

dans le cas général, ca marche pas trop mal. Par contre, si tu a un mec qui s'amuse à avoir une trajectoire completement aléatoire, la, forcement, ca donnera un resultat etrange (perso qui se téléporte...)

---

j'ai pensé à ce problème là aussi.

Sinon une autre solution : que l'un des clients devienne serveur obligatoirement....
Par exemple le premier qui ouvre une session et qui interroge les autres devient serveur ,mouline toutes les données et les renvoie aux "esclaves"

Citation:

---

Envoyé par Mat.M

Sinon une autre solution : que l'un des clients devienne serveur obligatoirement....
Par exemple le premier qui ouvre une session et qui interroge les autres devient serveur ,mouline toutes les données et les renvoie aux "esclaves"

---

même sur quake 3 qui est purement client/serveur, il y a de la prediction chez le client, car même avec un serveur qui envoie des données comme un fou, il y a toujours désynchro avec la vitesst d'affichage, il faut donc pouvoir bouger le perso du coté client.

La prédiction chez le client est le seul moyen de t'en sortir, par contre il y aura toujours des problèmes ou les personnages se "téléporteront" d'un endroit à un autre du fait même du système d'interpolation et de vitesse de mise à jour.

Il y a eu d'autres personnes qui ont posé des questions sur la synchronisation Client/Serveur. (Je n'ai pas fait une recherche exhaustive, il doit sûrement y avoir d'autres posts associés qui peuvent être intéressant et t'intéresser.)

Fluidité echange Client/Serveur

Gestion "clavier/envoi vers le serveur" en multijoueur

Client en C++ / Serveur en: hum..?