Discussion :

[Thorna]

Bonjour.
Petite question dans le domaine des jeux vidéo client-serveur mais en me plaçant cette fois côté serveur. Exit donc les moteurs 3D, les Blender ou 3DSMax etc.
J'aimerais avoir quelques idées (ou quelques liens) sur la meilleure manière d'organiser, sur le serveur, les données correspondant à l'univers 3D qu'explore le client. En d'autres termes, quel format de données utiliser pour stocker le minimum vital de données 3D, et surtout quelles données stocker et lesquelles ne pas stocker.
Le but, c'est essentiellement de pouvoir décider si ce que fait le client est possible ou non (traverser les murs, voir à travers un obstacle, etc.). Je me rappelle le jeu DAoC dans lequel le serveur faisait une demande au client pour savoir si un objet était visible ou non par le joueur, ce qui avait donné lieu à tout un tas de petits patchs bizarroïdes... C'était à l'époque où on ne connaissait pas encore la loi "don't trust the client!"
Merci

[nouknouk]

salut,

quelques propositions à vérifier (je n'ai jamais concrètement travaillé sur un serveur de jeu en 3D):

en me plaçant cette fois côté serveur. Exit donc les moteurs 3D

Non, justement, il faut faire une distinction entre la partie 'moteur 3D' en tant qu'entité capable d'opérer des calculs dans un 'monde' en 3 dimensions et la partie 'moteur de rendu' qui elle se charge de faire le rendu sous forme d'image du contenu du monde.

En d'autres termes ce n'est pas parce que le serveur n'affiche rien qu'il n'a pas un moteur 3d qui tourne derrière. Par exemple, pour les déplacements des joueurs, les trajectoires de tirs, etc... il doit être en mesure de savori si une position est valide ou non ou encore ce que le tir va atteindre (=> détection de collision).

Donc le moteur 3D reste indispensable côté serveur.
De plus, pour garantir que les calculs (collision, ...) qui se feront côté cliet et côté serveur seront rigoureusement identiques, il est plus qu'indiqué que clients et serveur partagent le même code pour le moteur 3D.

Je sais par exemple que le moteur 3D Java JMonkeyEngine propose justement un mode 'headless' (ie. sans rendu) qui est très orienté 'moteur pour un serveur' (les autres moteurs proposent certainement le même genre de chose mais JMonkeyEngine est le seul que j'ai utilisé quand j'ai touché un peu à la 3D).

[...]quelles données stocker et lesquelles ne pas stocker. Le but, c'est essentiellement de pouvoir décider si ce que fait le client est possible ou non

Exactement: il faut que le client et le serveur partage une partie des données, toujours pour que le serveur puisse avoir une 'vision' identique à celle du client sur ce qui se déroule dans la partie.
Dans le même esprit, si on veut que clients et serveur en arrivent aux même conclusions après un calcul, il me paraît primordial que ces derniers partagent le même code pour les données qu'ils ont en commun.
Les concepts de la programmation orientée objet prennent alors ici tout leur sens (héritage, spécilisation, composition, ...) pour utilsier un socle de code commun et qui est étendu pour les spécificités de chaque entité (client/serveur).

Dans ce domaine, j'imagine qu'il faut être avant tout pragmatique et que cela dépend entièrement de ton projet:

1- commencer par recenser l'ensemble des fonctionnalités dont le serveur aura besoin (détection de collision, ...)

2- en déduire pour chacune d'entre elles les données en entrée dont le serveur aura besoin et celles inutiles, par exemple
* les textures me semblent superflues dans la plupart des cas
* certaines parties de la scène en 3D qui n'apporteront rien et qui pourront être 'oubliées' par le serveur pour ne pas alourdir inutilement sa charge de calculs (genre des décors uniquement 'cosmétiques', inatteignables par le joueur, skybox, ...).

3- adapter ton modèle de données en fonction des points 1 et 2.

le jeu DAoC dans lequel le serveur faisait une demande au client pour savoir si un objet était visible ou non par le joueur

Effectivement, ce n'est plus vraiment la démarche conseillée désormais

[yamashi]

Pas besoin de moteur 3D cote serveur, c'est aberrant de dire qu'il en faut un...
Il existe dans les moteurs physique (je suppose que tu en utilise un) un systeme pour construire un mesh sous un format propre au moteur physique a partir de ce que tu as charger dans le moteur physique.
Tu peux donc coder un petit logiciel qui exporte tes modeles sous formes de fichier physiques pour le serveur (et aussi pour le client ca t'eviteras de convertir les mesh 3D en mesh physique a chaque fois), ensuite tu dois avoir coter serveur TOUT les fichiers du client meme si ils ne te servent a rien...
Pourquoi ? Tout simplement pour vérifier l'intégrité du client, dans le cas ou le checksum d'un fichier serveur diffère de celui du client, tu peux envoyer le fichier au client.

[Thorna]

Bonjour et merci pour vos réponses.
Bon, je comprends bien qu'il faut un minimum de données côté serveur, mais je me dis que si je fais tourner le "moteur 3D" (ou demi-moteur, ou décimoteur... ) sur le serveur pour chaque mouvement, déplacement ou action de quelque personnage ou entité que ce soit, ça risque de prendre du temps... Bref, de rendre le serveur encore plus lent que le client! C'est le pourquoi de ma question: quel est le minimum nécessaire.
D'un autre côté, je veux bien admettre aussi qu'il faut que le serveur possède tous les fichiers du client pour pouvoir en assurer l'intégrité, mais ce n'est pas encore mon sujet
Pour l'instant, je reste un peu sur ma faim: j'ai du mal à imaginer que pour chaque décision que doit prendre le serveur, il va être obligé de farfouiller dans des fichiers .x ou autre format! Il faudrait que je me replonge dans des émulateurs pour voir comment ils ont fait, je n'ai jamais trop étudié cette partie. Mais ceux que j'ai pu examiner sont soit runuo (qui n'a rien à ce sujet), soit dol (qui n'a rien non plus vu que c'est le client qui décide).
Encore merci.

[Sivrît]

Ça va aussi dépendre du type de jeu et de ses besoins en termes de physique (et aussi ce qu'il peut se permettre).

Pour un FPS, on ne plaisante avec les tests de collisions. Le serveur devra en permanence avoir les modèles servant aux tests de collision sous la main, et connaitre leurs animations. Donc exit le rendu, les textures et les mesh détaillés, mais il faut quand même en garder pas mal.

Pour un MMO, par contre, la physique est très limités (voir inexistante). Notamment, tout ce qui est mesh et animations tient de la décoration, et donc ne sert pas au serveur. En fait, il me semble que pour World of Warcraft il n'y a carrément que la distance qui compte (peut être aussi l'orientation). Ça limite les besoins

[nouknouk]

Pas besoin de moteur 3D cote serveur, c'est aberrant de dire qu'il en faut un... Il existe dans les moteurs physique [...]

Non, c'est bien loin d'être aberrant !
D'une part parce que j'ai bien fait un distinguo dans mon explication entre la partie 'moteur de rendu' et la partie capable de faire du calcul dans l'espace en 3 dmiensions.

D'autre part parce que - certes - l'appellation "officielle" pour cette seconde partie est bien 'moteur physique', mais il n'empêche que certains moteurs 3D tels que JMonkeyEngine intègrent une partie capable de couvrir les besoins basiques en matière de calcul 'physique' (typiquement le calcul collisions).

D'ailleurs, si un moteur 3D ne sert qu'à faire du rendu, pourquoi le framework de JMonkeyEngine propose en standard la possibilité de coder des applications sans rendu (cf. BaseHeadlessApp) ?

Pour un MMO, par contre, la physique est très limités (voir inexistante)

Et justement, les fonctionnalités basiques de calcul physique de certains moteurs 3D prennent alors tout leur sens car elles peuvent être suffisantes pour ce qu'il y a à faire.

[yamashi]

Et justement, les fonctionnalités basiques de calcul physique de certains moteurs 3D prennent alors tout leur sens car elles peuvent être suffisantes pour ce qu'il y a à faire.

Mais le code physique d'un moteur 3D n'est pas aussi optimisé que celui d'un moteur physique. Fais des tests, affecte 8000 cubes de la gravité avec collision au terrain avec ton moteur puis fais la meme chose avec un moteur physique...
Tu seras surpris de la différence qui est énorme. Un moteur physique sera optimisé pour les SIMD alors que le moteur ne le sera pas forcément, les algo proposé par le moteur physique sont bien plus rapide que ceux du moteur 3D.
Mais je suis d'accord oui ca peut marcher avec un moteur physique embarqué dans un moteur 3D mais ce n'est pas fait pour ca...
Tant qu'a le faire il vaut mieu le faire correctement.

[nouknouk]

Les quelques mmorpg que j'ai eu l'occasion de tester me semblaient uniquement basés sur du calcul de collisions (hors effets 'cosmétiques' qui ne s'exécutent qu'en local car n'ayant aucune incidence sur la 'logique du jeu').

Mais le code physique d'un moteur 3D n'est pas aussi optimisé que celui d'un moteur physique.

Ca me parait logique. Relis mon message: je n'ai jamais dit qu'un moteur 3D était la panacée pour les calculs de physique, mais plutôt qu'étant donné que chaque type de moteur a pas mal de fonctionnalités en commun (la capacité de faire des calculs dans un espace en 3D), certains moteurs en profitent pour ajouter quelques bribes de physique dans leur moteur 2D, car ça ne coûte quasiment rien à ajouter, l'essentiel étant déjà là.

Fais des tests, affecte 8000 cubes de la gravité avec collision au terrain avec ton moteur

D'où ma précision: "couvrir les besoins basiques en matière de calcul 'physique' (typiquement le calcul des collisions)."

Mais je suis d'accord oui ca peut marcher avec un moteur physique embarqué dans un moteur 3D mais ce n'est pas fait pour ca... Tant qu'a le faire il vaut mieu le faire correctement.

Non: tant qu'à le faire, autant être pragmatique. Et si les besoins couverts par le moteur 3D sont suffisants, pourquoi s'embêter avec un deuxième moteur alors qu'un seul peut déjà faire le boulot ?
- augmentation de la charge côté client (deux moteurs qui tournent au lieu d'un => utilisation CPU & mémoire en hausse)
- nécéssité de convertir les meshes pour le moteur physique
- nécéssité d'apprendre deux APIs différentes
- etc...