Discussion :

[screetch]

fork de la discussion sur la game loop multi threadée

il y a de nombreuses possibilités mais ce que disait deadalnix :
il stocke les positions des objets dans des tableaux, 8, espacés de 10ms
théoriquement il peut donc remonter le temps de 70ms (de 0ms a 70ms)

ensuite il y a la difficulté de savoir corriger

il y a de nombreux "temps" différent; pour ne pas se tromper, voila en gros comment ca marche

- il y a le présent du client
- il y a le présent du serveur; toujours en décalage avec le présent du client (lag)
- le futur du client (qui est le présent du serveur)
- le passé du serveur (qui est le présent du client)

celui qui a raison doit toujours être le serveur pour éviter le piratage, et aussi pour que tous les gens connectés partagent la même représentation du monde.

On a donc : le présent du serveur qui domine, mais le présent du client qui est ce que le joueur voit (et il ne faut pas attendre entre le moment ou tu appuies sur la touche et le moment ou tu vois ce qui se passe)

c'est très important que lorsque le client voit quelque chose, il puisse lui tirer dessus dans un FPS, sans compenser lui même le lag.

pour cela, le client utilise en général la "prédiction" et la "correction". la prédiction consiste a dire que l'on est en avance par rapport au serveur, mais que l'on peut déjà calculer avec pas mal de précision la position des ennemis puisque ceux-ci ont des vitesses et positions connues.
Mais qu'en faisant ca on est en "avance" par rapport au temps serveur, et que donc on prédit peut être quelque chose qui va changer

alors donc, si l'on suit bien, le client doit toujours être au top du top de la réactivité, mais le serveur lagge un peu derriere. Donc le client prédit ce qui se passe, puis lorsque le serveur répond, le client corrige ce qui a été mal prédit.

De plus, lorsque je tire, j'envoie au serveur mon ordre de tir (puis je prédis le tir sur le client)
le serveur va recevoir l'ordre de tir mais sait que cela c'est produit en fait dans le passé, car le temps que transite l'information toussa toussa

le serveur va donc recevoir l'ordre de tir et regarder dans son passé ce qui se passait a ce moment, va etre capable de dire si le joueur est effectivement touché ou pas et va renvoyé le statut du tir, qui sera recu plus tard par le client et qui ALORS affichera l'information que le tir a touché ou pas.

Le serveur peut (mais pas doit) appliquer une correction au passé mais c'est costaud; en cas de lag, on risque plutot de voir un delai entre le fait qu'un joueur est touché ou pas, c'est a dire que tu feras trois pas vivant avant de savoir que l'on t'a tué.


Le serveur a donc la notion de passé
le client en général ne connait pas le passé, il prédit le futur de manière a l'afficher avant qu'il n'arrive.

(C'est seulement un des designs possibles)

[screetch]

par l'exemple

Sur le client, je vois un ennemi, je tire

Au moment ou je tire, le joueur est a la position P sur le client (prédite,car on a pas recu l'info du serveur)
Je continue a prédire, je pense avoir touché mais je ne suis pas certain...
J'envoie mon info de tir
50ms plus tard, le serveur recoit l'info du tir
il va regarder dans sa table du passé me dire ce qui s'est produit il y a 50ms si il ajoute un projectile ; a t'il touché ou pas ? oui, car le lcient a bien prédit la position P
il envoie l'info "touché", et applique a son présent (ou a son passé) l'info touché, il retire des ponts de vie au joueur touché etc etc

50ms plus tard, le client recoit l'info : touché. donc, 100ms après avoir tiré il saura si c'est touché ou pas.


Il arrive parfois que le joueur s'arrête au mauvais moment, juste au moment de tirer; dans ce cas

Au moment ou je tire, le joueur est a la position P sur le client (prédite,car on a pas recu l'info du serveur)
Je continue a prédire, je pense avoir touché mais je ne suis pas certain...
J'envoie mon info de tir
10ms plus tard je recois la nouvelle position de l'autre joueur; j'applique la correction sur ce que je sais du joueur et reprédit sa nouvelle position : mince, manqué, je prédis que je le manque maintenant

90ms plus tard je recois la confirmation du serveur : manqué
durant 10ms j'ai pensé que c'etait touché a cause du lag; au pire, on peut se tromper pendant presque 50ms avec un lag de 50ms.

[nouknouk]

salut,

un post très intéressant que je vais compléter par un lien que quelqu'un du forum m'avait déjà donné il me semble (IrmatDen ?) : networked physics (en Anglais). A noter que la dicussion qui s'engage dans les commentaires à la suite de l'article est également à lire
Autre mine d'informations de 1er choix: le site de Valve qui détaille les mécanismes mis en oeuvre dans leur moteur réseau du moteur de jeu qu'ils commercialisent (celui d'Half Life 2 et de Counter Strike Source): ici et là (en Anglais, toujours).

Pour revenir au lag compensation, tout dépend également du type de jeu et du degré de réactivité qu'il nécessite (le FPS étant le plus contraignant): j'ai pu constater avec quelques tests que pour un jeu de petites voitures par exemple, on peut tout à fait imposer du lag ... artificiel !

Prenons l'exemple d'un petit jeu de voitures arcade genre micromachines. L'idée de base est que lorsque je commande ma propre petite voiture en local, les actions que je fais au temps T (appui de la touche pour tourner, accélérer) ne seront réellement prises en compte qu'au moment T + x millisecondes. Concrètement:

- au temps T, le joueur A appuie sur la flèche gauche pour tourner à ... gauche

- un paquet réseau "joueur A tournera à gauche au temps T+ x msec" va être immédiatement (ie. au temps T) émis vers le serveur qui va le faire suivre aux autres clients.

- en local, la voiture ne tourne pas tout de suite, mais commencera seulement à tourner à T+ x msec ; idem sur les clients distants: le joueur A ne commencera à tourner qu'à T+ x msec.

L'avantage est qu'avec cette méthode on laisse d'autant plus de 'mou' aux problèmes de latence.

Le cas idéal est celui ou tous les joueurs ont un ping inférieur à x msec. Dans ce cas, chacun recevra les intentions des autres joueurs avant même d'avoir à les mettre en oeuvre dans le jeu. En d'autres termes, les mécanismes de prédiction ne seront plus utilisés du tout.

Sinon, si les joueurs (ou certains joueurs) ont un ping supérieur à x msec, ça réduira d'autant (x msec) la durée de prédiction donc le risque d'erreur et l'ampleur des corrections à appliquer (pas toujours funky pour la 'user experience').

Après, tout dépend du type de jeu. Il faut faire des tests avec différentes valeurs et voir ce qui convient le mieux, genre "à proscrire pour un FPS", "150msec pour un RTS".

Perso, mes petits tests m'ont montré qu'avec 60 millisecondes dans un petit jeu de voitures 'arcade', ça donne juste un (tout petit) peu d'inertie à la voiture qu'on conduit, mais ce n'est au final absolument pas handicapant pour le gameplay et quasi indétectable par l'utilisateur.
Au pire, il sentira que la voiture a une légère inertie et adaptera instinctivement son pilotage.

[Rafy]

Bon je vais jeter plusieurs questions qui me passe par la tête...
Répondez à votre rythme :p

-> Supposons que l'on veuille compenser les lags de tous les clients.
Le serveur doit donc garder le passé pendant un temps T.
Ce temps T étant défini par le client qui lag le plus. Si on veut que l'on puisse complètement compenser, il faut que ce temps T soit au moins supérieur à deux fois le ping du client le plus lent.
Comment ça se passe "en vrai" ?
-> Es-ce qu'on calcul en permanence le client le plus lent afin de sauvegarder les états passés nécessaires, ou bien es-ce un temps fixé à l'avance ?
-> La durée de compensation est dynamique ou statique ?
-> Que ce passe-t-il dans un FPS, par exemple, si un client à un temps de lag plus long que le temps de compensation du serveur ?
-> Le serveur doit garder des états, de combien ces états doivent être espacé dans le temps ?
-> Encore une fois dynamique ou statique ?

Je sais que Deadalnix a fait le choix de pouvoir stocker 8 états qui sont séparés chacun de 10 ms, ce qui permet d'obtenir une compensation de 80ms.
Es-ce que d'autre personnes qui ont développé un peu sur ce sujet, peuvent partager leur expérience ?

Je pense personnellement que le lag compensation ne doit pas être intégré au moteur physique, car ce dernier ne doit pas être dépendant du réseau. Je pense donc que le lag compensation (et entre autre la gestion des états) doit être effectué par du code qui utilise le moteur, mais non par le moteur, qu'en pensez vous ?

Je souffle un peu et je vous laisse répondre....

[screetch]

Il y a plusieurs facons de faire, mais voila en gros mes réponses a tes questions :

on peut ajuster dynamiquement le serveur sur le client le plus lent jusqu'a une certaine limite

si un client lague trop, le problème principal sera que la prédiction sur les autres clients sera toujours mauvaise car le serveur informera les autres clients trop tard
donc si le client lague trop, on peut juste ignorer ce qu'il fait : si un paquet d'input arrive trop tard, on ne le valide pas, on fait comme si le client n'avait pas appuyé sur la touche.
cela permet aussi d'empecher les gens de tricher en "faisant" du lag sur leur machine

Le serveur doit conserver des états au rythme qui lui convient; si par exemple les états sont espacés de 50ms, tu peux interpoler les états après 25ms (gain de mémoire mais perte de temps CPU, en gros) ce qui t'autorise a garder pour 2 fois plus de temps. Tu peux garder des états séparés a différent intervalles, par exemple :
5ms
10ms
15ms
30ms
45ms
60ms
90ms

[nouknouk]

Je sais que Deadalnix a fait le choix de pouvoir stocker 8 états qui sont séparés chacun de 10 ms, ce qui permet d'obtenir une compensation de 80ms.
Es-ce que d'autre personnes qui ont développé un peu sur ce sujet, peuvent partager leur expérience ?

Personellement, je suis parti sur l'idée que pour chaque client on a la date de la dernière mise à jour qu'il a envoyée, donc qu'on peut connaître la date Tlast la plus récente pour laquelle on a les mises à jour de tous les autres clients (et qui permet de caractériser l'ensemble du 'monde' de façon complète et certaine, ie. sans prédiction).

A chaque fois que Tlast évolue, on peut alors éliminer tous les événements antérieurs à Tlast de notre historique interne (les 80ms de buffer de Deadalnix).

Exemple concret avec trois joueurs:
- heure actuelle: Th= 1680ms.
- J1, dernière mise à jour reçue à T = 1600 ms.
- J2, dernière mise à jour reçue à T = 1520 ms.
- J3, dernière mise à jour reçue à T = 1630 ms.

Dans ce cas, on connaît de façon certaine l'état du jeu à Tlast=1520ms. Donc on peut supprimer de notre historique tous les événements datant d'avant 1520ms.



Ensuite on reçoit un paquet (à Th= 1690ms) provenant de J1 pour T=1610ms. On refait le calcul ; Tlast est toujours égal à 1520ms. Rien ne bouge.

Ensuite on reçoit un paquet (à Th=1695ms) provenant de J2 pour T=1530ms. On refait le calcul ; Tlast vaut maintenant 1530ms donc on peut supprimer de l'historique tous les événements antérieurs à T=1530ms.

donc si le client laggue trop, on peut juste ignorer ce qu'il fait [...] cela permet aussi d'empecher les gens de tricher en "faisant" du lag sur leur machine

C'est également à prendre en compte.
Mais là tout dépend de la façon dont tu veux gérer ça dans ton propre jeu: les réponses peuvent varier: d'ignorer le paquet jusqu'à décider que le ping du joueur étant trop grand tu le fais brutalement quitter la partie.

Devrait-il alors y avoir un mécanisme d'annulation des actions effectués par ce joueur entre cet instant et le présent?

A mon humble avis, ton programme passe son temps à recalculer plusieurs fois la logique du jeu pour une même période à partir du dernier état 'certain' (Tlast), au fur et à mesure qu'il engrange des nouvelles infos sur cette période.
L'idée n'est donc pas d'annuler les actions postérieures, mais de calculer à nouveau, en recommençant à partir de Tlast une nouvelle fois la même période.

En reprenant mon exemple du dessus:

à Th = 1680ms, on n'avait des informations certaines que jusqu'à Tlast = 1520ms. Cela veut dire que tout ce qui a été calculé depuis cet instant là est de la prédiction.

Lorsqu'on reçoit le premier paquet à Th= 1690ms pour l'état de J1 à 1610ms, on va refaire l'ensemble des calculs entre 1610ms et 1680ms plus les nouveaux calculs pour la période 1680ms -> 1690ms.
Lorsqu'on reçoit le second paquet à Th = 1695ms pour l'état de J2 à 1530ms, on va à nouveau refaire les calculs pour l'ensemble du jeu entre 1530ms et 1695ms, etc...

A noter que tous les calculs ne sont pas forcément à refaire. Par exemple lorsqu'on reçoit des nouvelles de J1 à 1610ms, si J3 est géographiquement à l'autre bout du jeu, et qu'il n'y a aucune chance qu'ils aient pu interagir, rien ne sert de recommencer les calculs pour J3.

[Mat.M]

Prenons l'exemple d'un petit jeu de voitures arcade genre micro-machines

Je l'ai testé merci pour le lien c'est bien fait mais on sort du circuit trop facilement il n'ya pas de détection de collisions avec les bornes qui bordent le circuit
si c'était le cas donc un algo de collision plus perfectionné il y aurait peut-être plus de latences réseau
En tout cas cela m'a donné l'idée de faire ce genre de jeu.

[nouknouk]

Je l'ai testé merci pour le lien c'est bien fait mais on sort du circuit trop facilement il n'ya pas de détection de collisions avec les bornes qui bordent le circuit

Effectivement, le jeu en lui-même est largement perfectible, et n'est même pas en résau. Mon lien n'était juste là que poru donner un concept de jeu, pour parler de la même chose. Si tu veux un 'vrai' jeu de petites voitures en réseau, regarde du côté de turbo sliders.

si c'était le cas donc un algo de collision plus perfectionné il y aurait peut-être plus de latences réseau

Etant donné que les tests de collisions performants fonctionnaient très bien sur Amstrad CPC (proc. Z80 à 4MHz) il y a vingt ans, ça laisse de la marge

En tout cas cela m'a donné l'idée de faire ce genre de jeu.

Ho, pique pas mon idée, toi hein

mais ca marchera pas via internet. les moteurs reseau moderne sont en tcp.

Non, pour les jeux à très fortes contraintes temps réel (FPS notamment), l'UDP reste la seule alternative. Et ça passe très bien sur le net, même de plus en plus souvent derrière un NAT sans configuration spécifique (cf. ce post).

La gestion du lag en lui même génère pas mal de traffic (je te dis ce que je fais, je te valide ce que tu fais, je dis au autre ce que tu fais, il me valide qu'ils ont compris) la plupart de ces traffics servent aussi a se premunir des hackers...

Non: le serveur:
- dis ce que font les autres et (trèèès) rarement corrige ce que j'ai fait moi-même
- pas de validation pour 99% du traffic (sauf les événements importants, cf. la perte de vie, la mort, ...).
- la lutte contre le hacking se fait via des algo, pas en multipliant le traffic réseau.
Pour t'en convaincre, regarde du côté du moteur Valve Source (Counter Strike Source, ...) et teste par toi-même pour voir combien de bande passante une partie occupe.

tu assures la non modification du client en signant, pas en cryptant. Le cryptage permet d'eviter le hacking a la volée.

+1 avec deadalnix: le chiffrement (et non pas 'cryptage' vu que tu sembles à cheval sur les termes) ne garantira jamais que ton programme n'est pas hacké où que tu as des soucis de 'man in the middle'. Sinon pourquoi les hacks persistent sur des jeux comme CS source, malgré des techniques avancées de protection ? La protection absolue n'existe pas.

[Mat.M]

Ho, pique pas mon idée, toi hein

hum tu veux faire un jeu de course multijoueurs en réseau alors
on a hate de voir cela

[kremvax]

le serveur va donc recevoir l'ordre de tir et regarder dans son passé ce qui se passait a ce moment, va etre capable de dire si le joueur est effectivement touché ou pas et va renvoyé le statut du tir, qui sera recu plus tard par le client et qui ALORS affichera l'information que le tir a touché ou pas.

Imaginons que le joueur est touché, et meurt. Ca se passe donc dans le passé du serveur. Devrait-il alors y avoir un mécanisme d'annulation des actions effectués par ce joueur entre cet instant et le présent? Ou bien est-ce qu'on élude la question, en considérant que ce laps de temps est négligeable (après tout, les actions effectuées quelques ms après la mort peuvent être vues comme des réflexes post-mortem).

De plus, il me semble que le serveur ne devrait pas regarder dans son passé (= présent client au moment du tir), mais dans son présent à lui au moment du tir client, c'est-à-dire avec une correction d'un demi ping et non d'un ping (ping = aller+retour de l'information)

[screetch]

De plus, il me semble que le serveur ne devrait pas regarder dans son passé (= présent client au moment du tir), mais dans son présent à lui au moment du tir client, c'est-à-dire avec une correction d'un demi ping et non d'un ping (ping = aller+retour de l'information)

Il faut regarder ce qui se passait lorsque le client a tiré, pas lorsque le serveur recoit l'info
il y a donc un demi-ping de décalage sur le serveur
il doit donc regarder ce qui se passait sur le client il y a un demi-ping

[nouknouk]

il doit donc regarder ce qui se passait sur le client il y a un demi-ping

Effectivement, ça peut faire pas mal de différence: il faut que le serveur fasse le test (d'impact du tir par exemple) en fonction de ce que le client qui a tiré voyait à ce moment là. Le second lien sur le moteur Source engine de Valve, paragraphe 'lag compensation' explicite tout ça en détail.

[kremvax]

Donc si je comprends bien, le mécanisme de compensation revient à l'instant du tir en temps CLIENT, faisant en sorte donc que ce que voit le client qui prévaut sur la "réalité" du serveur - ce qui est logique pour le confort et la précision des inputs du client. C'est ce que je comprends de ce que vous dites et de la formule Command Execution Time = Current Server Time - Packet Round-Trip-Time - Client View Interpolation. Mais du coup, ça peut créer des situations absurdes non?

Par exemple, le joueur A tue le joueur B. Pendant le lag de A, le joueur B tue le joueur C. Supposons que le lag est relativement gros à cet instant pour A, mais faible pour B et C. Pendant 1 seconde, B et C verront que B a tué C. Puis le tir de A est traité, et donc C revient à la vie. Un peu bizarre, non?

[nouknouk]

Mais du coup, ça peut créer des situations absurdes non?

Effectivement, mais dans ce domaine on ne peut pas faire mieux.
Comme expliqué dans l'article de Valve, il peut par exemple arriver qu'un joueur A soit considéré comme touché par un autre joueur B car au moment du tir, A était dans la ligne de mire de B. Or entre temps, A a eu le temps de se cacher derrière un mur. A se fait donc toucher alors que B n'est plus visible.

Ce n'est evidemment pas parfait, mais de deux maux, mieux vaut choisir le moindre: cette solution est plus acceptable pour le gameplay qu'un client qui -de son point de vue- tirerait pile poil sur un adversaire et qui ne le toucherait pas.
Ca a également l'avantage de ne pas favoriser à outrance les joueurs ayant les pings les plus bas (par exemple le joueur qui héberge la partie et a donc un ping proche de zéro).

De plus, il faut relativiser: un ping moyen pour un jeu comme un FPS se situe aux alentours de 60ms et les joueurs au dessus de 100ms sont rarement acceptés.
De plus, il n'y a pas de miracles: si un joueur a un ping de 200ms, quelles que soient les techniques que tu utiliseras, ça ne pourra jamais donner un gameplay acceptable pour un FPS.

Pendant 1 seconde, B et C verront que B a tué C. Puis le tir de A est traité, et donc C revient à la vie. Un peu bizarre, non?

Non: pour les 'phases critiques' d'un jeu (par exemple le fait de tuer quelqu'un dans un FPS), le client n'utilisera jamais la prédiction et attendra une confirmation du serveur.
Si tu testes counter strike sur internet, tu pourras d'ailleurs constater que quand quelqu'un te tire dessus, tes points de vie ne sont pas réduits dans l'instant, mais il y a un petit décalage: le temps d'attendre la confirmation du serveur.

[shenron666]

juste une question en passant
est-ce qu'il faut mesurer le décalage (ping) entre le client et le serveur afin de synchroniser au mieux les prédictions ?
si le client mesure son ping et en informe le serveur ça permet de caler les prédictions sur un temps de réponse mesuré et non arbitraire

[Kalast]

Bonjour, je me permet de demander votre aide!

J'ai bien lu tout ce qui étais posté jusque là avec les liens anglais bien que j'y pige pas grand chose mais je n'avance pas dans mon jeu .. J'ai du mal à cerner comment faire pour arriver à synchroniser ne serait-ce qu'un client et le serveur ..

Bon je vais déjà poser la situation. Je veux faire un jeux style MMORPG en
side-scrolling genre Terraria pour ceux qui connaisse.

Si la communication entre le serveur et le client à une latence de 2sec, est ce que tous les packets UDP que je vais avoir envoyé depuis le client vont s'entasser sur le serveur jusqu'à avoir été tous traités par ce dernier ? (Il me semble que oui d'après mes observations mais je suis pas sûr)

Actuellement j'envoie à chaque tour de boucle de mon client les entrée claviers correspondant au contrôle du jeu sous forme de booleans dans un Packet à mon serveur. Est ce une bonne solution ou devrais je faire autrement ?

A chaque tour de boucle du serveur j'envois à tous les clients les positions actuels de tous les éléments que je souhaite actualisé ainsi que leur vecteurs de déplacement (pour le moment cela se limite au joueurs). Je suis pas du tout convaincu qu'il faille faire cela mais je ne comprends pas comment procéder ...

Voilà j'ai sûrement oublier des questions mais je vais pas vous surcharger ^^ Si vous pouviez déjà m'aider sur ces quelques point je vous en remercierais fortement

Edit : Ah oui j'ai choisi d'envoyer les Input parce que j'ai déjà vu que ça se faisait et je sais aussi que via un PacketSender on peut injecter au serveur de faux vecteur de vitesse ou de position et donc tricher d'où mon choix mais si y'a mieux je suis preneur lol..

Edit 2:

un post très intéressant que je vais compléter par un lien que quelqu'un du forum m'avait déjà donné il me semble (IrmatDen ?) : networked physics (en Anglais). A noter que la dicussion qui s'engage dans les commentaires à la suite de l'article est également à lire
Autre mine d'informations de 1er choix: le site de Valve qui détaille les mécanismes mis en oeuvre dans leur moteur réseau du moteur de jeu qu'ils commercialisent (celui d'Half Life 2 et de Counter Strike Source): ici et là (en Anglais, toujours).

Bon j'ai essayez d'analyser comment le programme se comportait dans network physics (téléchargeable en bas de la page) mais décidément le système d'historique m'échappe..
Je comprends à peu près que le serveur regarde dans le sien dès qu'il reçoit une mise à jour d'un client pour voir l'état du jeu à ce moment là (packet daté ? et comment ?) mais j'ai du mal à comprendre ce qu'il faut faire ensuite ..

Le client doit "corriger" d'après ce que le serveur lui envoie mais comment faire pour pas que les nouvelles positions provoques de saccades ? Erf je dois être mou mais j'avoue que là ... Enfin bref si vous pouviez m'aidez ça serait vraiment cool xD

Cordialement,
Kalast.

[Kalast]

Je fais un petit UP en espérant qu'on me réponde .. ^^.

SI j'envoie que les input du client au serveur, le client n'effectuant pas ses déplacement à la même vitesse, je me retrouve à des positions totalement différentes dans certaines situations.. Par exemple sur mon client je vais retrouver sur une plateforme alors que sur le serveur je passerais en dessous.

Comment faire pour palier cela ? J'envoie au serveur les inputs, ma position et mes vecteurs de vitesses et le serveur verifiera si le déplacement est correct en fonction du ping du client ? (Si la vitesse et trop élevé par rapport au ping on ignore le packet par exemple ?) Mai si le packet est ignoré, j'aurai un décalage de nouveau non ? Erf je m'embrouille de plus en plus j'ai l'impression donc si on pouvait m'aider à y voir plus clair avant que je n'explose lol.

Merci !

[shenron666]

J'envoie au serveur les inputs, ma position et mes vecteurs de vitesses et le serveur verifiera si le déplacement est correct en fonction du ping du client ? (Si la vitesse et trop élevé par rapport au ping on ignore le packet par exemple ?) Mai si le packet est ignoré, j'aurai un décalage de nouveau non ?

je te donne une idée de ce que je ferai à ta palce :
tu connait la vitesse maximale de déplacement
le client envoie une position qui n'est pas possible d'après tes calculs
tu tronques cette position par la position intermédiaire correspondant à un déplacement à vitesse maximale
et tu envoies le DELTA de cette position au client qui DOIT se repositionner par rapport à ce delta

[Kalast]

Donc pour savoir déjà, dans mon packet client -> serveur j'envoie un X et un Y.
Le serveur reçoit cette position et regarde où le joueur se situait avant la réception et il en déduit si le déplacement est réalisable ou non.

Si le déplacement est possible, le serveur enregistre la nouvelle position du client.

Sinon, il lui renvoi un packet avec la position corrigée.

Le client reçoit le packet en question et recadre sa position sur ses données.

Comme ça c'est bon ?

Ensuite les autres clients reçoivent également la nouvelle position du joueur et via un algorithme simuleront le déplacement du joueur de l'ancienne position connue à la nouvelle (pour éviter de voir le joueur se "téléporter à cause du lag").

Edit : Par contre c'est toujours valable si le client subit de grosse pertes de performances ? Par exemple un client fonctionnant à vitesse optimale va "update" sa position toutes les 16 ms, par contre si un autre client parcours sa boucle en 32 ms par exemple, il va effectuer un déplacement 2 fois plus grand et envoyer sa nouvelle position qui sera perçu comme deux fois trop rapide par le serveur non ? Car le serveur est pas censé savoir que ce client à des soucis de perfs ou on peut palier cela d'une quelconque maniere ?

Merci de m'avoir répondu en tout cas^^

[shenron666]

Si le déplacement est possible, le serveur enregistre la nouvelle position du client.
Sinon, il lui renvoi un packet avec la position corrigée.
Le client reçoit le packet en question et recadre sa position sur ses données.

Comme ça c'est bon ?

c'est bon à un détail près : comme je disais dans ma réponse, ma façon de faire serait que le serveur renvoie un delta, c'est la différence entre la position chez le client et la position que le serveur valide

Edit : Par contre c'est toujours valable si le client subit de grosse pertes de performances ? Par exemple un client fonctionnant à vitesse optimale va "update" sa position toutes les 16 ms, par contre si un autre client parcours sa boucle en 32 ms par exemple, il va effectuer un déplacement 2 fois plus grand et envoyer sa nouvelle position qui sera perçu comme deux fois trop rapide par le serveur non ? Car le serveur est pas censé savoir que ce client à des soucis de perfs ou on peut palier cela d'une quelconque maniere ?

Dans les paquets que ton client et ton serveur échangent, il doit toujours y avoir un "tick", ou si tu préfères, un indicateur de temps

à la connection, le client doit se synchroniser avec le serveur pour les échanges
et le serveur doit savoir entre 2 informations, combien de temps s'est écoulé sur le client
sinon tu ne peux clairement pas valider tes calculs