Moteur physique et réseau

[Nyx]

Bonjour,

J’ai quelques problèmes pour déterminer la place du moteur physique dans un jeu multijoueur.

Petite description du jeu :
Des voitures armées s’affrontent sur un grand terrain désertique. C’est un mélange entre un FPS et un jeu de course. A partir des ordres (avancer, tirer etc…) passés par l’utilisateur et l’IA, le moteur physique calcule la nouvelle position et le nouvel état des véhicules en prenant en compte les collisions.

Pour le multijoueur, je ne sais pas si chaque joueur doit précalculer sa position avant de l’envoyer, si le réseau ne s’occupe que de transmettre des ordres pour permettre au moteur physique de n’avoir qu’un type de donnée en entrée, si un serveur héberge une partie du moteur physique par exemple pour les IA ou les collisions. En bref je ne sais pas où placer le moteur physique de façon à ce qu’il ne soit pas trop fragmenté et de façon à éviter les désynchronisations et les lags.

EDIT: oups. Je n'avais pas remarqué le sous-forum sur la physique, un modérateur peut-il déplacer ce topic ?

[rogma]

Si tu choisis la solution "envoyer les odres pour que les autres simulent eux aussi la position des voitures" alors oui, ton moteur physique n'a qu'un seul type d'entrées (qui viennent du clavier et du réseau), par contre il faut absolument que tu garantisse que les données arrivent et dans le bon ordre (par exemple en utilisant TCP)

Tu as d'autres solutions, comme celle que tu évoques aussi "chaque joueur envoie sa position et les autres placent les objets respectifs en fonction de ces positions", je ne pense pas que ca *casse* ton moteur physique, les objets des autres joueurs sont tout simplement "placés" et non pas simulés; l'avantage c'est que tu peux te permettre de louper quelques paquets et d'utiliser UDP comme protocole pour peu que les envois soient assez fréquents

Calculer les collisions au niveau du serveur est aussi une solution classique; notament vu que c'est un seul pc qui calcule ces collisions, bein il est toujours d'accord avec lui même (ca peut ne pas etre le cas si tous les pcs calculent les collisions)

Il Y a pleins de solutions différentes, toutes ont leur avantages inconvénients, à toi de voir.


un petit lien sur ces questions :

http://lists.gnu.org/archive/html/nel-all/2002-01/msg00100.html

[Laeti²x]

au debut je pensais que j'avais rien a dire la dessus mais en cherchant j'ai trouve : je precise au passage que j'ai pas fait de reseau depuis 5 ans hein, c'est pas frais la.

le pb est sans pb presque si il s'agit du perso avec le decor : les 2 solutions sont envisageable, le design is up to you (mais comme d'habitude, je peux me tromper)

dans le cas des collisions entre 2 persos, comment faire si c'est le client qui gere son deplacement ? ca me semble insolvable

est ce un serveur et ses petits enfants clients ? (j'ai pas encore tout oublie)
ou un espece de peer to peer ? j'elimine la 2eme a priori.
c'est clair que je ne connais pas les problematiques d'un jeu reseau, vous m'avez totalement demasque...

edit il a l'air sympatoche ton lien rogma

[Nyx]

Il Y a pleins de solutions différentes, toutes ont leur avantages inconvénients, à toi de voir.

Compte tenu de ce que vous avez dis et ce que je viens de lire sur d’autres sites, j’ai retenu deux solutions :

1) A chaque fois que je change d’ordres, j’envois (TCP) mes nouveaux ordres au serveur. Si je n'envois rien le serveur utilise les anciens ordres. Le serveur calcule les nouvelles positions en tenant compte des collisions. Le serveur renvoi (UDP) les positions de tout les joueurs à intervalle régulier.
Ici le serveur s’occupe intégralement de la physique sur toute la carte, ne risque-t-il pas d’être surchargé ?
Ca pose un pb de combiner TCP et UDP ?

2) A intervalle régulier, j’envois (UDP) ma position, mon vecteur vitesse et mon vecteur accélération au serveur qui redistribue (UDP) ces données aux autres joueurs. Les autres joueurs se synchronisent puis le moteur physique de chacun d'eux conjécture (localement) la position des autres joueurs jusqu’à la prochaine réception de données.
Ici je trouve que c’est le moteur physique des clients qui occupe une place trop importante, l’interpolation n’est peut-être pas assez fiable en cas de collision ?

[Laeti²x]

Effectivement, si le serveur s'occupe de la physique,
il pourra plus facilement imaginer les positions presumés des clients si il y a du lag.

Ici je trouve que c’est le moteur physique des clients qui occupe une place trop importante, l’interpolation n’est peut-être pas assez fiable en cas de collision ?
je ne comprends pas la derniere phrase :/
C'est clair que l'idée c'est que le client prenne en charge sa cinetique perso,
Et le serveur la gestion de collision.

Par contre, je me demande si les collisions perso perso que je gere differement des perso decors se trouve dans le client ou le serveur.

Pour ce qui est de la charge du serveur, je ne crois pas que ce soit genant.
apres tout dans un jeu standard il peut y avoir une course avec pleins de voitures sur une seule machine et tout est gere en local. Attention je ne parle pas d'un mmorpg ! c'est totalement autre chose ! (il doit falloir un cluster !)

[Nyx]

je ne comprends pas la derniere phrase :/
C'est clair que l'idée c'est que le client prenne en charge sa cinetique perso,
Et le serveur la gestion de collision.
Ben justement, je ne vois pas comment le serveur peut gérer les collisions avec la deuxieme solution. Entre deux envoi/redistribution des données, il peut y avoir une collision et ça le serveur ne peut pas le savoir.

apres tout dans un jeu standard il peut y avoir une course avec pleins de voitures sur une seule machine et tout est gere en local
Oui tu as raison.