Citation :Si ton serveur à 3 ticks par seconde, ça veux dire que l'objet n'a que 3 paires de coordonnées par seconde, donc ça va être chaud pour les petits projectiles de toucher une cible en déplacementComme dit précédemment: cf Continuous Collision Detection
Ton analogie ne fonctionne que si le modèle mathématique est un modèle de convergence, ce qui n'est pas forcément le cas dans tes calculs. Un exemple rapide: 1 tick = 1Hz, à chaque tick tu ajoutes 1.0 à un compteur. La valeur du compteur est donc similaire à un timestamp. Tu passes de 1Hz à 10.000Hz. Chaque tick ajoute 0.0001 donc. Or, d'après ce convertisseur, 0.0001 devient 9.9999997e-5 dans le type Float (car on ne peut pas y représenter tous les réels, et même certains fractionnaire n'existent pas). Du coup, affiner la fréquence de calcul ne va pas améliorer le résultat final: dans le 1er cas, après 1 an de jeu, le compteur affiche 31.536.000 alors que l'autre compteur affiche 31.535.999
Cela peut sembler négligeable, mais c'est un fait: augmenter le pas de calcul n'améliorera pas forcément ta simulation (le cas d'Eclerd est un bon exemple d'ailleurs ^^). Ce genre de problématique se posera si tu change d'ordre de grandeur dans la valeur du pas temporel (entre dt=30Hz et dt=50Hz, la différence est faible, mais entre 30hz et 100Hz, elle commence à apparaitre et à 1000Hz, t'es overkill).
Donc si je synthétise, Neoaxis est à 30Hz, Medal Of Honor: Allied Assault était à 20Hz (de mémoire), et je doute qu'aller au-delà de 50Hz soit utile. Pour avoir des calculs fiables, mieux vaut se référer à une timeline (ie: microtime). Si besoin, tu peux remplacer les calculs discrets (utilisant seulement l'état courant) par des calculs travaillant sur la continuité (CCD, utilisant donc l'état précédent et l'état courant).
PS: et l'affichage, t'en as parlé le premier, d'où le glissement.