Reprise du message précédent :
Toutes mes confuses, j'ai raté le "pour les autres", d'où HS de goret

 
effectivement c'est le serveur qui maintiens la cohérence du monde, le minimum est envoyé au client (suivant le budget de bande-passante et le contexte du client), et le client fait des interpolations, ou fait des évaluation locales qui n'ont aucune autorité sur le jeu.
 
par exemple tu prends un fps, les bruitages, impacts de balle, gerbes de sang, sont purement locales au client, et chaque client a son propre contexte non synchronisé à ce niveau.  
par contre le serveur fait bien les tests d'impacts précis sur les joueurs et l'actualisation de l'état du monde.
et les actualisations sont envoyées (ou pas) suivant le budget de bande-passante avec un ordre de priorité (ndlr ce qui est dans le champ de vision du joueur a une priorité haute, et pas ce qui est clairement hors-champ)

Je croyais justement qu'on voulait limiter la charge du serveur, et donc faire gérer les intéractions par chaque client selon les informations (actions+cordonnées) fournies par le serveur. La remarque en gras s'applique sur l'ensemble des jeux réseau ?
 
edit: ha tiens, il y a une seconde page  

Non, on veut d'abord que le jeu fonctionne

Surtout pas, les clients de jeu en réseau doivent être, dans la mesure du possible (et impérativement pour des MMORPG) des clients légers/stupides: ils s'occupent de l'IO (affichage du jeu et obtention des actions de l'utilisateur) et c'est tout

Pour autant que ça soit possible oui, il faut bien penser que toute donnée venant du client peut être falsifiée/incorrecte et doit pourtant être crue, donc moins le client fait de chose et moins on risque de hack déstabilisant le jeu.
 
De même dans l'autre sens, moins on envoie d'infos au client et plus on diminue les chances de triche (wallhacks & autres radars).

ok, mais j'avais déjà tilté avec le post de bjone

Pour un MMORPG, je ne suis pas trop d'accord.
 
En gros :
Dans un MMORPG, la cinématique des personnages est bien plus poussée que dans un jeu type CS. C'est pas dans CS qu'on peut dancer un ballet ou se gratter les couilles. Mais dans un MMORPG, non seulement c'est possible, mais c'est très utilisé. Ca sert à rien que le serveur s'amuse à transmettre aux clients la décomposition des mouvements : le serveur n'a qu'à dire aux clients "bon, y'a MagicBuzz qui se gratte les couilles et Masklinn qui dance un ballet", et c'est aux clients qui sont dans les parages de faire le rendu des mouvements, parcequ'ils savent déjà comment c'est censé s'afficher.
 
Enfin bref, dans un MMORPG, c'est là qu'on a au contraire les clients les plus "lourds".
 
Pour le reste, effectivement, c'est au serveur de gérer toutes les actions des joueurs, et non pas aux clients, histoire d'avoir un truc cohérent à l'affichage : quand t'as 80 personnes en train de se faire atomiser par un boss, c'est le serveur qui doit gérer l'ensemble des actions, histoire de conserver un combat cohérent indépendemment des lags.
 
En revanche, il faut que les clients, indépendament des lags, continuent à afficher le combat, même si pendant 5 secondes y'a plus de signal. Même mieux, si un joueur lance un sort ou une action spéciale, les clients doivent afficher l'action, même si c'est 3 secondes plus tard, car les enchainements d'actions entre joueurs peuvent être importantes.
=> Par exemple, dans AO, un doc peut lancer un "infected wounds", mais ça ne marche que si un soldat a déjà réussi un "bleeding" sur le mob. Donc même si le doc ramme tellement qu'il n'a clairement pas pu voir l'action du soldat au moment où il l'a fait, il faut que le client affiche l'info, même avec du retard pour permettre l'enchaînement.
 
Au contraire, dans un jeu type CS, le mec, il est mort. Qu'il se soit pris 12 rockets ou un head shot avec un desert eagle, on s'en bat les couilles, il est crevé point barre : le client affiche ce qu'il reçoit, et quand il lag c'est pas bien grave, pas besoin de rattrapper les frames de retard.

La prochaine fois tu pourrais apprendre à lire avant de poster? Ou juste ne pas poster du tout.

Non parce que t'es bien gentil et bien brave, mais la décomposition et le rendu de l'action à l'écran, aux dernières nouvelles c'est de l'IO

Quand à ton petit cours sur les MMORPG, j'ai passé 5 ans à jouer à l'un d'eux, donc je ne pense pas avoir quoi que ce soit à apprendre de toi.

En résumé: ta gueule.

tu bosses dans un journal ?

Ca dépends ce que t'appelle "affichage".
 
Pour moi, l'affichage, c'est "j'ai mon sprite il est là, je le dessine". Ca ne comprends pas la décomposition des mouvements
 
Dans certains jeux, il faudra envoyer cette décomposition car elle est importante... Par exemple, localisation du touché dans un jeu à la CS : un touché à la tête peut provoquer de très lourds dégats. Si je vide mon chargeur dans l'oreille d'un gars, et qu'il a 0 dégats parceque pour le serveur, la tête n'est pas tout à fait au même endroit que sur mon écran - s'amuse à s'accroupir et se relever sans arrêt-, le jeu il va pas rester longtemps sur mon HD ça tu peux en être sûr.

L'animation fait partie intégrante du rendu aux dernières nouvelles...

Un jeu à la CS comme tu dis n'est pas dans le même cas qu'un MMORPG; il n'y a pas obligatoirement de serveur dédié, par conséquent chaque personne connectée est susceptible d'ouvrir une serveur. Donc les considérations de ce type ne s'applique pas... Et puis, c'est plus simple de traffiquer une valeur d'armure ou de PV, qu'un test de collision entre 1 vecteur pour la direction de la balle et le maillage physique représentant le perso.

Vu le nombre de hacks CS, pas vraiment non, si toute la gestion des calculs n'est pas faite sur un serveur dédié "sauf" dans un jeu comme CS c'est surtout, je pense, pour des raisons de simplicité: on utilise le moteur du jeu "offline" et on synchronise simplement les "mondes" des clients régulièrement (le rôle du serveur), donc un client CS est un client lourd (il gère son monde et pas juste l'affichage), pas un client léger, contrairement à un client de MMORPG qui ne peut pas se permettre de laisser la moindre gestion "métier" au client.

Pour les jeux types CS, je pense surtout aux serveurs dédiés. Et ils existent (CS, aux dernières nouvelles ça ne tourne pas sous Linux, et pourtant il y a des serveurs Linux).
 
Ces serveurs devraient tout gérer, à la façon d'un MMORPG, avec en plus la décomposition des mouvements. Du moins, la décomposition des frames de mouvements (à la frame X/Y du mouvement "accroupir", en ayant en plus la direction du gars, tout le monde sait exactement où se situent chaque sprites du personnage-). Ca limiterait énormément les hacks justement (seuls les hacks de déplacement et autoaim seraient encore exploitables, mais là encore le serveur devrait être capable de les détecter sans trop de difficulté -un gars qui fait un 180° + un vidage de chargeur dans la tête en 1 millième de seconde, c'est pas crédible et détectable).

J'ai dit plus simple, car ce n'est pas une simple valeur à changer

C'est un peu ce que j'essayais d'expliquer à MagicBuzz; à 2 on y arrivera peut-être

Pas du tout! Si un jeu n'est pas fait pour fonctionner avec uniquement un serveur dédié, il est obligatoire qu'il soit ce que Masklinn nomme un client lourd. Par contre, ça n'empêche pas que ce client lourd se comporte comme un client léger lorsque connecté à un serveur dédié.
Et puis ton histoire de gérer l'affichage du client... Tu imagines la puissance de calcul nécessaire pour gérer l'affichage de x terminaux sous x point de vue différents? (enfin, minimum, si on oublie la possibilité d'avoir plusieurs caméra par affichage...)

Y'a rien à m'expliquer.
 
Dans un MMORPG, combats et autres actions sont totalement indépendantes de la stature des personnages (et en grande partie de leur position). Ainsi, le serveur du MMORPG fait les calculs de combats et n'a besoin d'envoyer que très peu d'informations aux clients : nombre de points de dégats encaissés/donnés, nom des actions effectuées par les joueurs autour, et position des personnages. En gros, rien de plus.
 
Dans un FPS, le serveur ne doit pas se contenter de calculer l'interception entre un tir et la position d'un joueur. Il doit aussi s'assurer que si dans mon viseur j'ai la jambe d'un personnage, mon tir va toucher. Et pour ça, il est vital que le serveur gère aussi la décomposition des mouvements : je n'affiche à l'écran que ce que le serveur me dit d'afficher, je n'extrapole pas.

Mais je te parle pas de faire calculer l'affichage par le serveur ! Je te parle de faire décomposer les frames de mouvement. C'est pas pareil !
 
Et à ton avis, pourquoi un FPS est limité en général à 8 à 16 joueurs plutôt qu'un MMORPG qui en gère des centaines sur un même serveur ? C'est bien parceque le FPS a bien plus de choses à gérer sur le serveur, et à transmettre aux clients...
 
Ton perso court. L'animation courrir se décomposer en mettons 16 frames. Ben c'est au serveur de décider quelle frame doit s'afficher à un moment X, afin de savoir calculer l'interception d'une balle tirée à cet instant X, quelque soit le lag.
=> C'est pas au client de dire "ouais, je t'ai touché" ou "ouin tu m'as touché". C'est au serveur de dire "player 1 à touché player 2 à l'instant X", parceque d'après ses calculs, la jambe du gars était dans la trajectoire de la balle à cet instant, et c'est effectivement ce que le gars qui a tiré voyait.
 
Sinon c'est trop facile de faire un bot "god mod" ou un bot qui butte tout le monde y compris à travers les murs.
Après, que CS soit une merde en réseau, c'est une autre histoire. Moi je parle d'un jeu correctement implémenté.
 
Mais dans ce cas, l'implémentation n'a rien à voir avec celle d'un serveur de MMORPG, y'a pas une ligne de commun (mise à part peut-être celle de la couche réseau)

Le serveur s'occupe de la physique ie point d'impact, vitesses, positions. Pourquoi tu veux qu'il décide de quelle frame peut être affiché ou non ?

problème de définition du mot frame je crois hein...
 
t'a un personnage. c'est un dire un sprite, c'est à dire un ensemble de polys.
 
pour calculer un impact, il faut savoir où sont ces polys dans l'espace.
 
hors, lors d'un mouvement, le sprite se déforme selon une animation pré-calculée, découpée en "frames". pour calculer un impact, il faut donc que le serveur décide à tout moment quel frame de chaque sprite afficher, et que les clients affichent cette frame choisie.
 
quand je cours, je met mon pieds droit devant, quand qu'il touche le sol, je passe le pieds 2 en l'air, que j'anvoi en avant.quand il touche le sol, je lève le pieds gauche, que le lance en avant, etc.
 
donc si ton client affiche la frame "le pied gauche devant et le pieds droit derrière", et que je tire dans le pieds gauche, je suis censé touché.
 
si le client fait de l'extrapolation de mouvements, il est fort possible que le serveur, lui, en soit à la frame "j'ai les deux pieds au même niveau", et ainsi, lors du calcul d'impact, la balle ne touche pas.
 
donc c'est au serveur de synchroniser tout le monde, et d'empêcher les clients de décomposer eux-même les mouvements pour que tout le monde voit la même chose, histoire que quand tu touches, tu touches, tu tires pas à travers.
 
Bon, après tu peux t'amuser à faire un bounding box de 2m3 autour des personnages, à ce moment y'a plus de problème. M'enfin quand un mec est derrière un mur, et que tu le tues parceque ça bounding box dépasse de l'autre côté du mur, ça le fait pas, je ne pense pas qu'aucun jeu actuel s'amuse encore à faire de telles horreurs.
 
Sur un serveur dédié de CS, c'est en tout cas ce qu'il se passe. Ainsi, quand ça lag, tu vois les personnages se déplacer avec des mouvements assez désordonnés, car il y a problème de synchronisation entre les frames choisies par le serveur et les frames que reçoit le client. Tu vois ainsi le client se déplacer sans bouger les jambes.
 
A l'inverse, dans un MMORPG, quand il y a des problèmes de synchronisation, tu dois des gens courrir sur place, avec un beau mouvement bien fluide, parceque sa position n'a pas bougé alors que je client à reçu comme info que le gars courait.
=> Dans ce cas, c'est le client qui s'occupe intégralement de la décomposition des mouvements, puisqu'on se moque royalement de la frame en cours d'affichage, puisque ça n'influe pas du tout le calcul d'un touché.

Les animations, c'est coté client.
Si l'animation affiché est moisi c'est que les informations relatives à l'utilisateurs sont moisies. (genre il dit qu'il n'est pas en mouvement alors que c'est le cas....)
 

Et pourquoi pas 3-4 box dont il suffirait de connaître les caracs ?

Ça reste valable dans le cas de plusieurs box  

Et là, une box suffit
 
La semaine prochaine, je monte un studio  

La seule différence, c'est que la complexité de la simulation sur le serveur est plus grande dans le cas d'un FPS (il faut gérer des vecteurs de tir et les "espaces" occupés par les objets de manière plus précise puisque la gestion des collisions est plus complexe), c'est tout

Non, bougre d'âne, c'est parce que dans "MMORPG" il y a "MMO" qui veut dire "Massive Multiplayer Online", pour ta gouverne il existe aussi des MMOFPS gérant des théâtres d'opération complets, les plus connus étant World War II Online et PlanetSide qui ne sont très clairement pas limités à 16 joueurs

Donc.

Ta gueule bis

PS: la puissance de calcul dispo n'a aucun rapport entre un jeu "MMO" et un jeu "non MMO", parce qu'un serveur MMORPG tu le fais pas tourner sur ta machine perso à pleine capacité stu veux

Genre pour Everquest II la capacité maximale de l'architecture est de 116 joueurs par serveur "physique", l'archi totale étant:

Là n'est pas le problème.
 
La bounding box du personnage se déforme en fonction du mouvement. Et pour cette raison, il faut que le mouvement soit synchrone entre le serveur et les clients. C'est donc au serveur d'envoyer l'étape du mouvement aux clients, et pas aux clients de décider.

Tu peux rester courtois aussi.
 
Que certains MMO utilisent le système des FPS ne change rien au problème.
Dans ce cas, ils font de toute façon le même traîtement que sur un FPS, à savoir que c'est eux qui synchronisent les mouvements des joueurs, et pas le client qui extrapole les mouvements (avec mouvement) point barre.

C'était pas le cas sur les FPS qu'il m'a été donné de jouer (et qui ont 4-5 ans)
Mais je vois tjs pas la nécessité de le déformer. Autant en avoir un grand nombre et les faire évoluer dans l'espace par le serveur, et que le client se contente de les afficher avec le niveau de finition qui lui sied

 
bin pourtant ça se passe comme ça.
 
c'est pour ça d'ailleurs qu'en jeu online l'interêt de faire des tests au niveau triangle par rapport à des tests contre des bounding-box est mitigé car très rapidement les latences diverses créent des énormes fenêtres d'erreur. (qui sont liées aux latences et aux magnitudes de déplacement des objets mis en jeu)
après rien n'empêche de faire du test triangle, sjuste que le client risque d'être à l'ouest.

...
 
tu veux pas comprendre c'est pas possible...
 
c'est parceque c'est moi qui écrit que tu cherches absolument à trouver ça débile et pas chercher à comprendre ?
 
T'as ton putain d'enculé de perso, Masklinn on va dire.
Il est composé de centaines de polys.
 
Quand Masklinn lève une jambe, ça correspond à par exemple 5 frames distinctes de mouvement.
A ces 5 frames, le client connait les coordonnées précises de chaque poly de la jambe levée.
 
Le serveur, lui, s'en bat les couilles. Il connait la bounding box correspondant à la jambe, et sait comment lui faire faire une rotation de façon à ce qu'elle colle à la position des polys de chacune de ces 5 frames.
 
Si on en est à la frame 2 jambe est à 30% d'inclinaison, alors la bounding aussi, et et ton client reçoit "affiche la frame 2 de 'lever la jambe'". point barre.
 
Si tu tires à cet instant pécis dans la jambe levée à 30%, même si t'as un lag de 500ms qui fait que ton PC va envoyer l'info du tir lorsque la jambe sera déjà redescendue, le serveur saura que la jambe était à 30% d'inclinaison au moment du tir, car c'est lui qui l'a décidé initialement. Il pourra donc savoir si tu as touché au moment où tu as tiré, et éviter de te faire tirer à travers le joueur comme ça arrive sur les FPS de merde.
 
Tu veux un dessin ou quoi ?

Sauf que les clients interpolent ou extrapolent selon le lag, qu'il n'y a aucun besoin de synchroniser les étapes d'une animation, et nul besoin que les mesh utilisés pour rendu et détection de collision soient les mêmes.
Le serveur donne un top de démarrage de l'anim 12 pour le mesh machin instance truc au point p à un moment t0 (dans le référentiel du serveur, le seul le vrai), et tout le monde sait comment cette anim va se dérouler et quand elle se finit (t0 + dt). Le client se débrouille pour donner l'illusion de continuité et flouter les sursauts inévitables lors du déclenchement de la prochaine séquence.
 
Voir les sources de q3.

 
les animations sont aussi prise en compte coté serveur poir bien sûr faire les tests de collisions/impacts.
 
le problème des jeux modernes, c'est que le moteur physique mets énormément la pression sur la cohérence serveur/client.
 
99% du temps les personnages sont animés par keyframe (interp vertex ou par skinning, on s'en fout), et 1% on bascule le tout en ragdoll. et là le rogdoll doit être synchronisé suffisamment proprement pour que le client converge comme le serveur. (CSS à sa sortie se mettait à chuter en fps lors des ragdoll, autrement le coût d'anim est plus proche de CS classique avec le moteur de HL1)

non
EDIT : sauf si pour toi, déformation = déplacement

Sinon :
http://developer.valvesoftware.com [...] mpensation

 
oui aussi.

Que le serveur donne l'info pour chaque frame, ou qu'il donne un "top" pour un mouvement indécomposable de 12 frames, ça change rien au schmilblik hein...

C'est vrai, 12 packets à envoyer en temps voulu à tous les joueurs c'est négligeable.

tout à fait (à part l'aspect ragdoll)

 
désolé, je vais pas m'amuser à lire ton truc en entier. cite là où on dit le contraire, ce sera suffisant  
 
dans tous les cas, si valve sait détecter une colision dans une jambe de profile, alors qu'il ne détecte pas la collision quand on dire entre les deux jambes (personnage en train de courir) sans modifier la forme du bounding du personnage, je demande à voir comment ils font...
 
(ouais, je sais, tu vas me sortir "si ça tape dans la bounding on vérifie que ça touche le personnage en calculant chacun de ses poly" => euh... et c'est quoi la différence ?)

nan, mais bon arrêtez de vous prendre la tête, dans la pratique c'est un ensemble de plusieures techniques hein. et on se prends la tête à dire plus ou moins la même chose en insistant sur un détail.

C'était surtout pour offrir un complément d'information

 
je te parle pas de la phase d'optimisation, je te parle du principe bordel.
 
sur un FPS, le client ne se contente pas de dire "la position du gars bouge, donc il court, donc j'anime".
il doit savoir où il en est au niveau des frames du mouvement "courrir".
 
putain mais y'en a marre, vous être trop con. pourquoi dès que je parle faut absolument que j'aie tord ? merde à la fin, vous êtes vraiment trop cons.
 
dans un FPS, c'est pas le client gère l'anime POINT BARRE. C'est le serveur qui les synchronise, donc c'est en aucun cas le client qui la gère.

JE LA COUPE HEIN §§§

Nan mais, j'y connais que dalle, c'est loin d'être mon domaine
Maintenant j'ai déjà joué à des FPS il y a quelques années, et dans mes souvenirs, j'ai jamais croisé de bounding box déformable  
J'essaye juste de comprendre mais t'as l'air d'être assez fermé dans ton explication. Chez toi aussi, la machine à café marche plus ?

Nan, ça c'est parce que t'explique mal

Nan mais ça tu le répètes depuis tout à l'heure
C'est juste que j'ai jamais vu ce genre de phénomène dans les FPS qu'il m'a été donné de jouer. Et je vois pas trop l'avantage par rapport à des bounding box en nombre qui peuvent évoluer dans l'espace.
Libre à toi de m'expliquer ou pas, mais pour la prochaine fois, utilise un autre nom de personnage, genre "pouet" ou "mickey"
 
Cordialement,
John

il n'y a pas qu'une boite de colision par personnage : 1 a l'avant bras, etc. (je crois qu'on se comprend pas sur ce point)  
Il y en a plusieurs qui sont pour la plupart du temps rataché aux bones du personnage (du moins avec HL) donc c'est relativement indépendant du models 3D.
 
ragdoll : je connais pas du tout ce terme.

Justement, c'est plus subtil que ça, du fait qu'il n'y a que très peu de couplage contrairement à ce que tu as décrit. Notamment au niveau de la résolution des conflits: que se passe-t-il quand 2 clients laggants à mort agissent sur la même porte.

(en gros) c'est quand t 'as pas d'animation prédéfinie pour un mesh animé, et que t'as plutôt des relations mécaniques entre parties du meshe, degré de liberté; genre tu déplace l'avant bras, l'épaule va effectuer une rotation, ou tu avant le pied, la jambe suit. Là il est plus question de parler de keyframe pour l'animation des personnages.