Le jeu est calculé à une fréquence de 30Hz (je ne parlerai pas de "FPS" ça fait trop "affichage"). Chaque calcul génère un état du jeu X auquel est associé sa date de calcul t, donc X(t). Quand le client veut afficher le jeu, il demande l'état du jeu au serveur, qui lui répond par le X(t). Maintenant, le client veut afficher le jeu à la date t', différente de t.
Ensuite, le client attend de recevoir X(t+dt), le prochain état calculé par le serveur, et il fait alors l'interpolation entre X(t) (état passé mais récent) et X(t+dt) (état actuel), pour avoir une image affichée fluide.
Il peut aussi exister une autre approche, consistant à utiliser seulement X(t) pour prédire les prochaines positions à afficher (donc, des positions futures). Le client affiche donc X+dX. Puis, quand le client reçoit X(t+dt) (la vraie position), il refait ses prédictions en se basant sur X(t+dt) (≠X+dX). Pour éviter une saute d'image due à l'écart entre X(t+dt) et X+dX, le client peut effectuer un second lissage.
C'est plus compliqué à mettre en place, mais cela permet d'être toujours "à jour" par rapport au serveur (dans le 1er cas, bien plus simple, le client a 0 à 1/30e de seconde de retard sur le serveur, puisqu'à chaque fois qu'il reçoit X(t+dt), il affiche en pratique X(t) et fait le lissage pendant la durée dt).
Note que cette approche prédictive est adaptée aux réseaux: dans le cas de la 1ere approche, si le client ne reçoit pas X(t+dt), son affichage se freeze car il n'aura pas les points à interpoler.
Mais bon, tout cela (interpolation de l'affichage du client) est une problématique différente de celle proposée dans ton 1er message (fréquence des ticks coté serveur et calcul du monde du jeu coté serveur).
PS: Cette problématique de l'interpolation, tu ne devrais pas avoir à la traiter d'ailleurs, car si tu es sur un jeu classique, temps réel, alors tu devrais avoir un moteur/SDK qui se charge de ce travail
Ensuite, le client attend de recevoir X(t+dt), le prochain état calculé par le serveur, et il fait alors l'interpolation entre X(t) (état passé mais récent) et X(t+dt) (état actuel), pour avoir une image affichée fluide.
Il peut aussi exister une autre approche, consistant à utiliser seulement X(t) pour prédire les prochaines positions à afficher (donc, des positions futures). Le client affiche donc X+dX. Puis, quand le client reçoit X(t+dt) (la vraie position), il refait ses prédictions en se basant sur X(t+dt) (≠X+dX). Pour éviter une saute d'image due à l'écart entre X(t+dt) et X+dX, le client peut effectuer un second lissage.
C'est plus compliqué à mettre en place, mais cela permet d'être toujours "à jour" par rapport au serveur (dans le 1er cas, bien plus simple, le client a 0 à 1/30e de seconde de retard sur le serveur, puisqu'à chaque fois qu'il reçoit X(t+dt), il affiche en pratique X(t) et fait le lissage pendant la durée dt).
Note que cette approche prédictive est adaptée aux réseaux: dans le cas de la 1ere approche, si le client ne reçoit pas X(t+dt), son affichage se freeze car il n'aura pas les points à interpoler.
Mais bon, tout cela (interpolation de l'affichage du client) est une problématique différente de celle proposée dans ton 1er message (fréquence des ticks coté serveur et calcul du monde du jeu coté serveur).
PS: Cette problématique de l'interpolation, tu ne devrais pas avoir à la traiter d'ailleurs, car si tu es sur un jeu classique, temps réel, alors tu devrais avoir un moteur/SDK qui se charge de ce travail