Discussion :

[skeud]

Bonjour à tous,

Je parcour depuis plusieurs jours le forum pour me renseigner et avoir toutes les billes pour mon mmorpg.
A l'heure actuelle, j'ai définis comme il fallait mon protocole et mes connections sont implémentés.
Mais après plusieurs jours de casse-tete, je me pose une question fondamentale:
Est-ce que toute les données que j'envois et reçois de mon serveur sont utiles?

Je cherche surtout des réponses sur les données qui seront échangés entre le serveur et le client:
Les item/position des joueurs/message des joueurs .... sont indispensable évidemment.
Mais lors d'un déplacement d'un joueur, est-il utile d'envoyer les coordonnnées de chaque déplacements (ie chaque case où le joueur passe) ou juste une case de départ et une case d'arrivé et c'est le client qui calcul le reste?
En gros la question principal réside surtout sur la fonction du client:
Doit-il juste afficher les données envoyées au serveur, ou doit-il quand meme effectué des calcul, comme le mouvement des joueurs, la place des items dans l'inventaire, et d'autre petit détails.
Lors d'un clique pour le rammassage d'une ressource, est-ce le client qui vérifie la position puis le serveur? ou le serveur uniquement? pourquoi faire un doublecheck?

D'où ma question principale:
Quelles données doit-on échanger entre le serveur et le clients, afin qu'un minimum d'information soit échangé, mais qu'un maximum d'action soit vérifié par le serveur?

[Emmanuel Deloget]

Bonjour à tous,

Je parcour depuis plusieurs jours le forum pour me renseigner et avoir toutes les billes pour mon mmorpg.
A l'heure actuelle, j'ai définis comme il fallait mon protocole et mes connections sont implémentés.
Mais après plusieurs jours de casse-tete, je me pose une question fondamentale:
Est-ce que toute les données que j'envois et reçois de mon serveur sont utiles?

Je cherche surtout des réponses sur les données qui seront échangés entre le serveur et le client:
Les item/position des joueurs/message des joueurs .... sont indispensable évidemment.
Mais lors d'un déplacement d'un joueur, est-il utile d'envoyer les coordonnnées de chaque déplacements (ie chaque case où le joueur passe) ou juste une case de départ et une case d'arrivé et c'est le client qui calcul le reste?

Sur ce point spécifique, la réponse est "non". Ceci dit, ta seconde solution n'est pas faisable (elle suppose que tu connais la case d'arrivée, ce qui implique qu'il te faut attendre que le joueur qui se déplace l'atteigne, ce qui crée une latence ingérable dans un jeu online).

En fait, la bonne réponse à ce problème porte un nom : dead reckoning (en frenchy : navigation à l'estime, http://fr.wikipedia.org/wiki/Navigat...%A0_l%27estime).

En gros la question principal réside surtout sur la fonction du client:
Doit-il juste afficher les données envoyées au serveur, ou doit-il quand meme effectué des calcul, comme le mouvement des joueurs, la place des items dans l'inventaire, et d'autre petit détails.

le client est un système d'affichage des informations en provenance du serveur, et un système de contrôle envoyant des requêtes au serveur. Le client n'a pas à calculer quoi que ce soit, car tout calcul qu'il pourrait faire a des chances de se révéler faux au moment où il obtiens son résultat. Les seuls opérations locales qu'il est autorisé à faire sont :
* l'affichage (qui nécessite bien évidemment des calculs, mais ces calculs sont basés sur des informations obtenues du serveur)
* la réponse aux entrées du joueur (requête envoyée au serveur, résultat récupéré et affiché)

Toute autre service rendu par le client risque d'être désynchronisé de ce qui est présent sur le serveur, et donc potentiellement faux. De plus, un client malicieux pourrait modifier l'état du jeu si trop de responsabilité est donnée au client.

Lors d'un clique pour le rammassage d'une ressource, est-ce le client qui vérifie la position puis le serveur? ou le serveur uniquement? pourquoi faire un doublecheck?

Le client commence l'animation, dit au serveur "je veux prendre cette ressource", le serveur lui réponds (oui, non, tu en récupère X) et le client termine l'action. Le double check n'a pas lieu d'être, car seul le serveur est au courant de l'état à un instant t - le client n'en a qu'une approximation, mise à jour lorsque le serveur daigne lui envoyer des informations.

D'où ma question principale:
Quelles données doit-on échanger entre le serveur et le clients, afin qu'un minimum d'information soit échangé, mais qu'un maximum d'action soit vérifié par le serveur?

Toutes les données liées au gameplay, ayant une chance d'affecter non seulement le joueur mais aussi les autres joueurs ou le monde doit passer par le serveur. Toute donnée n'ayant qu'une importante locale peut rester sur le client.

Un exemple typique : la visibilité. A un instant donné, le joueur voit tous les autres joueurs et PNJ/monstres qui sont dans son champ de vision, sauf ceux qui sont cachés par quelque chose. Ce n'est pas au client de déterminer ceux qui lui sont cachés - c'est le serveur qui le détermine - sans quoi, un joueur un peu malin va modifier tel ou tel shader pour afficher les monstres qui ne sont normalement pas visibles. Cela implique que le serveur a la même connaissance de la géométrie que le client (ce qui a un coût non négligeable en 3D).

[skeud]

D'accord, merci pour ces précisions.Dans mon cas, je pars sur un jeux dont le serveur ne doit pas avoir la connaissance de l'affichage, je veux dire par là:
Peu importe le client (2D, 2d iso, 3D), je veux que les échanges entre le serveur et le client restent les même, est-ce possible?

Ensuite pour le déplacement des joueurs, je ne comprends pas pourquoi le serveur devrait avoir connaissance de toutes les position d'un joueur, seul le mouvement entre la case de départ et la case d'arrivée me semble importante à partager.

si je devais envoyer toutes les positions intermédiaire, mon serveur serait submergé par tant d'informations.

Pour précision, les déplacements ne sont pas forcément hyper important, étant donnée qu'ils n'influe pas sur le gameplay mais seulement sur l'affichage des joueurs sur une map.

Mon jeu étant découpé en plusieurs map, chaque map fesant 10/10 cases. je pensais que lorsqu'un joueur veut passer de la case 2/2 à la case 4/4, le client envoit seulement l'information: je bouge à la case 4/4, le serveur sait donc que dans 2seconde, mon client sera à la case 4/4 (si on prend comme unité de mouvement, 1 case / seconde). Ensuite c'est au client de calculer le mouvement pour que le déplacement soit fluide à l'écran (pour éviter que mon joueur "saute" d'une case à une autre).

Lorsque je joue à des jeu de ce type, il est fréquent que mon personnage commence à se déplacer puis corrige sa trajectoire en fonction des informations du serveur, en utilisant le Dead reckoning. Qu'en penses-tu?

[Emmanuel Deloget]

D'accord, merci pour ces précisions.Dans mon cas, je pars sur un jeux dont le serveur ne doit pas avoir la connaissance de l'affichage, je veux dire par là:
Peu importe le client (2D, 2d iso, 3D), je veux que les échanges entre le serveur et le client restent les même, est-ce possible

Aucun rapport : le serveur a besoin de connaître la géométrie pour valider ce que les clients lui communique. Il se moque de l'affichage.

Ensuite pour le déplacement des joueurs, je ne comprends pas pourquoi le serveur devrait avoir connaissance de toutes les position d'un joueur, seul le mouvement entre la case de départ et la case d'arrivée me semble importante à partager.

Donc, s'il faut 30s à ton joueur pour aller de la case départ 1 à la case d'arrivée B, alors ton serveur (qui a besoin des 2 infos) aucun client ne peut tracker le joueur entre le moment où il part et le moment où il arrive. 30s d'incertitude, c'est long.

si je devais envoyer toutes les positions intermédiaire, mon serveur serait submergé par tant d'informations.

Dead reconing envoie le point de départ, le vecteur de déplacement et la vitesse (à moins que celle-ci ne soit constante, auquel cas aucun intérêt de l'envoyer). Lorsque le joueur change de trajectoire ou qu'il s'arrête, il envoie sa nouvelle position et le nouveau vecteur de déplacement (le vecteur nul pour un arrêt).

Pour précision, les déplacements ne sont pas forcément hyper important, étant donnée qu'ils n'influe pas sur le gameplay mais seulement sur l'affichage des joueurs sur une map.

Donc il est important : le joueur ne doit pas pouvoir contrôler ses mouvements (ou voir celui des autres si ceux-ci ne lui sont normallement pas visible) au delà de ce que peut lui permettre le serveur.

Mon jeu étant découpé en plusieurs map, chaque map fesant 10/10 cases. je pensais que lorsqu'un joueur veut passer de la case 2/2 à la case 4/4, le client envoit seulement l'information: je bouge à la case 4/4, le serveur sait donc que dans 2seconde, mon client sera à la case 4/4 (si on prend comme unité de mouvement, 1 case / seconde). Ensuite c'est au client de calculer le mouvement pour que le déplacement soit fluide à l'écran (pour éviter que mon joueur "saute" d'une case à une autre).

Lorsque je joue à des jeu de ce type, il est fréquent que mon personnage commence à se déplacer puis corrige sa trajectoire en fonction des informations du serveur, en utilisant le Dead reckoning. Qu'en penses-tu?

C'est du dead reckoning : point de départ (2,2) + vecteur de déplacement + vitesse (vers 4,4 dans 2 secondes).

[skeud]

Super, merci, c'est exactement le genre de réponse que je voulais. J'ai essayé d'implémenter ce type de processus, et effectivement, ça fonctionne bien , mes benchmark passent au vert .

Donc la conclusion: le serveur gère le déplacement, en envoyant une coordonnée de départ, une direction (la vitesse est constente). j'ai rajouté aussi les coordonnée d'arrivé pour éviter que mon bonhomme continues si il ne reçoit rien de la part du serveur.
De cette manière j'envois le strict minimum et mon serveur reste maitre.

Dernière question: le path finding.
J'hésite à l'implémenter coté client et que le serveur vérifie juste que le parcour soit correct. comme ça mon serveur n'a pas besoin de faire de calcul pour trouver le plus court chemin, il a juste à vérifier que le chemin demandé par le client est correct.

Bonne ou mauvaise solution?

[Emmanuel Deloget]

Super, merci, c'est exactement le genre de réponse que je voulais. J'ai essayé d'implémenter ce type de processus, et effectivement, ça fonctionne bien , mes benchmark passent au vert .

Donc la conclusion: le serveur gère le déplacement, en envoyant une coordonnée de départ, une direction (la vitesse est constente). j'ai rajouté aussi les coordonnée d'arrivé pour éviter que mon bonhomme continues si il ne reçoit rien de la part du serveur.
De cette manière j'envois le strict minimum et mon serveur reste maitre.

J'avais mal compris là où tu voulais en venir. Tu connais la position d'arrivée dès le début de trajet - c'est très bien comme ça.

Dernière question: le path finding.
J'hésite à l'implémenter coté client et que le serveur vérifie juste que le parcour soit correct. comme ça mon serveur n'a pas besoin de faire de calcul pour trouver le plus court chemin, il a juste à vérifier que le chemin demandé par le client est correct.

Bonne ou mauvaise solution?

Suffisante, je dirais. Il y a peu de chance que ça pose problème (le trajet étant validé par le serveur). Au contraire, ça peut donner des infos au serveur pour affiner le dead reckoning sans pour autant le surcharger en calcul.

[skeud]

Ok merci pour tes conseils.Je passe le sujet en résolu

[Mat.M]

Dernière question: le path finding.
J'hésite à l'implémenter coté client et que le serveur vérifie juste que le parcour soit correct. comme ça mon serveur n'a pas besoin de faire de calcul pour trouver le plus court chemin, il a juste à vérifier que le chemin demandé par le client est correct.

Bonne ou mauvaise solution?

salut pour info j'ai fait un RTS ( que j'ai distribué en freeware )et totalement terminé
J'en ai fait une version multijoueur poste-à-poste et j'ai même joué avec un collègue
Je te déconseille de placer le pathfinding côté serveur...c'est une logique qui doit rester côté client
Si tu veux faire un jeu multijoueur,le plus simple c'est que tous les traitements se fassent côté client et que le serveur redirige les actions
Par exemple si un joueur tire sur un autre, il suffit d'envoyer au message un message du genre "JOUEUR_NUM_5_TIR_30_30" avec les coordonnées de la cible du tir.
Le serveur va recevoir ce message et le renvoyer aux autres joueurs et à chaque client de mettre à jour
Il en va de même pour les déplacements et tu peux envoyer un message qui indique que ton joueur numéro 5 s'est déplacé..
parce que pour synchroniser tout cela c'est pointu

[skeud]

Si je comprend bien ton point de vue, c'est le client qui décide si il touche ou non son adversaire, un peu risqué niveau sécu non?

[SuperBidi]

Ce forum étant peu vivant, je réponds quand même aux sujets antiques.

Techniquement, la solution de Mat ne marche pas. Les actions peuvent être précalculées sur le client (pour des raisons de fluidité, on évite d'attendre une réponse serveur avant de déplacer le personnage, par exemple), mais elles doivent toutes être recalculées côté serveur. Et ce pour plusieurs raisons :
- Eviter de tricher, comme le signale Skeud.
- Eviter de planter le serveur / client. Si les calculs sont faits côtés clients et pas vérifiés côté serveur, il suffit d'envoyer au serveur une information erronées, et on crashe tous les clients de nos adversaires.
- Juste parce que ça marche pas. Si vous prenez un objet sur le sol, et qu'un adversaire fait de même, il faut bien qu'il y ait une entité qui décide qui prend l'objet. Ca ne peut pas être les clients, vu qu'ils sont soumis au ping, et pourraient donc décider tous les deux que leur joueur a pris l'objet. Donc il faut que ce soit le serveur.

Par contre, je rejoins Mat sur le pathfinder. Mieux vaut le laisser côté client, et n'envoyer au serveur que des updates de position. On laisse sur le serveur les actions qui soient demandent une validation, soient demandent de posséder des connaissances que les clients n'ont pas (unités dans le brouillard de guerre, par exemple).