Physique dans un jeu Client/Serveur

[Sutat]

Bonsoir,

J'ai un petit problème de conception pour un petit projet que j'aimerais réaliser.

Contexte
J'aimerais développer un jeu vidéo multijoueur (genre du 1v1) en arène.
Un truc bien simple.

Problématique
Pour éviter la triche (modification des paquets envoyés au serveur par exemple). Je voulais faire en sorte que ce soit le serveur qui calcule tout pour les clients :
- Valeurs des sorts
- Vie
- Déplacements
- Collisions avec le décors (et on touche le problème du doigt).

Questions
1. Est-ce pertinent de mettre mon moteur physique coté serveur, qu'il envoie les informations sous forme de vecteur de déplacement aux différents clients toutes les X millisecondes ? (par exemple)
- Les clients ne seraient que des moteurs graphiques / évènement E/S finalement.

2. OU, Je pensais faire en sorte de mettre un moteur physique pour le client et le serveur :
- Le serveur calcul si les déplacements qu'on lui donne sont bons (les corriges au besoin)

=> Si il corrige une trajectoire il renvoit la nouvelle au client défectueux (le tricheur)

- Le client a aussi son moteur physique pour que les mouvements soient plus fluide et que le jeu soit moins groumant en bande passante.

Conclusion
Si l'idée _la conception_ est bonne : Solution 1 ou 2 ?
Sinon : que me conseillez vous ?

Je suis vraiment bloqué par ce problème parce que je n'arrive pas à choisir un moteur physique en fonction de ça :/

Merci de votre aide en tout cas.

[ponce]

Tout ce qui est physique en réseau est très bien expliqué par http://gafferongames.com/, je te conseille de tout lire.

Je n'y connait rien mais d'après ce que j'ai compris les jeux en réseaux aujourd'hui choisissent ta solution 2 :
- l'état du jeu dupliqué entre client et serveur
- prédiction des autres joueurs pour contrecarrer la latence
- le client considéré comme malicieux donc on envoit que son input, et l'état serveur prime sur le sien
- l'état local peut rollbacker ses changements locaux pour appliquer ceux du serveur si un autre joueur a été mal prédit
- timestep fixe pour la physique, interpolation de l'état physique pour la partie graphique
- la physique doit être répétable sous peine de desynchronisation entre les états sur les différentes machines, à moins que le serveur envoie son état complet mais c'est souvent impossible
- du coup les calculs physique en flottants peuvent être dangereux...

[Sutat]

Merci pour la réponse.
C'est bien ce qu'il me semblait, par contre ça va me faire faire deux fois le même travail si je gère pas bien ma séparation moteur physique/moteur graphique.

J'ai pas encore lu ton lien, mais je prend. Je lirais ça quand j'aurais le temps, c'est toujours un peu plus long de lire de l'anglais pour moi :p