Warhammer online, netcode et collision

!summons tout les Dev de Cafzone ( drealmer? )

Voilà, je lis mon joy et sa préview sur War online, et tout content je vois qu’il est prévu d’intégrer une gestion des collisions. Joie paix et félicité dans le monde, on va peut-être enfin avoir de vrais batailles tactiques !

Bon. Maintenant un truc me titille, c’est qu’il est écrit dans l’article que pour le moment c’est pas fait, que le netcode sera surement trés lourd, et que ca risque de tout faire ramer.

Et là moi je dis : " gné ? "

Donc j’aimerai quelques explications simple sur c’est que le netcode, pourquoi est-ce difficile de coder une gestion des collision et en quoi ca risque de ralentir le bouzin.

A votr’ bon coeur :stuck_out_tongue:

ah oui tiens. là pour le coup (j’ai pas lu l’article par contre) j’aimerai bien un eclaircissement, parce que dans mes souvenirs, Neocron gerais les collisions (je vous raconte pas le bordel a Pepper park le jour de l’attaque de… enfin bref) et je ne me souviens pas de lag terrible (ouais je sais ya personne qui y joue a Neocron de nos jours, mais a l’epoque, si si yavait des gens)

Bon, voilà ma vision de choses, assez basique toutefois :

  1. Le netcode c’est le code qui sert pour tout ce qui est gestion du réseau, ce qui doit être envoyé au serveur et reçu aux clients pour faire une bonne partie de réseau quoi. Voilà un “define:netcode” sur Google :
    This term refers to the application code that handles how data and instructions are passed from computer to computer during a multiplayer game, whether it’s across a LAN or modem.

  2. La gestion des collisions, ce n’est pas simple, parce que c’est bourré de calculs de maths, parce qu’il faut gérer un paquet d’informations (d’autant plus important si le nombre d’unités est grand). Ca dépend aussi de la “finesse” de cette gestion : Je veux dire par là qu’il est plus facile d’empêcher la collision entre 2 personnages en faisant ça grossièrement que si on veut faire ça au détail près, genre on veut empêcher que le bras d’un gars ne puisse pas “rentrer” dans le corps d’un autre.

  3. Maintenant, je ne vois pas pourquoi ce serait au netcode de prendre en charge la gestion des collisions. Ca alourdirait effectivement bcp le traffic des données, et, à mon avis, pour pas grand chose. Autant laisser faire ces calculs à chaque pc…

Bon, c’est juste pour donner des pistes, je n’ai jamais fait de programmation dans ce domaine en particulier…

Bah nan, ce n’est pas le netcode qui gère les collisions, mais c’est lui qui fournit la quantité effroyable d’infos nécessaire au moteur physique pour gérer ça.

Le problème vient surtout du nombre de joueurs impliqué dans un mmo, sinon d’autre jeux le gère évidemment. Mais comparez le traffic généré par un Quake, et celui généré par WoW, la différence est monstreuse.

Eve Online dans sa première version gérait les collisions, et ils les ont bien vite dégagées vu comment ça ramait dès que le nombre de joueurs devenait important, tandis que pendant la beta, il n’y avait aucun soucis.

Je ne sais pas trop de quoi ils parlent dans l’article, je n’en dispose pas. Faudrait savoir si ils parlent juste de collisions ou bien de véritables physiques en réseau. Une collision c’est quand un objet dynamique percute un autre objet, statique (décor) ou dynamique (personnage, piles de caisses…). Les physiques, c’est lorsque ces collisions déclenchent autre chose (rebond, rotation, truc qui s’écroule).

Quoi qu’il en soit, déjà dans le cas des collisions c’est chaud. La principale cause de tous les problèmes, c’est le lag. Imaginons le simple fait de tirer sur un autre joueur dans un FPS en réseau. Sur ta machine, tu vois le joueur bien au centre de ton viseur, mais à cause du lag, à ce moment précis, l’autre joueur est déjà 200 millisecondes plus loin, ce qui le met théoriquement juste en dehors du viseur. Pour contrer celà, on fait ce qu’on appelle du dead-reckoning. C’est à dire qu’on connait l’état du joueur 200 ms dans le passé, et on estime son état actuel sur base des ces informations. Genre, il se déplaçait à 5 mètres / seconde dans telle direction, on extrapole linéairement et on a la nouvelle position. Problème, ça reste une approximation, car si pendant ces 200 ms le joueur a changé de direction, ou bien s’est arrêté, l’estimation va être faussée.

Tout ça pour dire que plein de moyens sont mis en place pour estimer le véritable état du jeu (l’état de tout le monde au moment présent) malgré le lag. Donc y’a le dead reckoning, puis quand on reçoit une nouvelle séries d’informations sur les autres joueurs, on essaie de rattraper les erreurs qu’on a introduites de façon élégante (que le joueur ne le remarque pas), tout en essayant de ne pas avantager l’un ou l’autre joueur, et en évitant les possibilités de triche… Bref, c’est vachement compliqué. Rien que l’exemple du joueur qui tire sur un autre peut servir de base à tout un exposé :stuck_out_tongue:

Maintenant lorsqu’il s’agit de choses bien plus complexes que juste « est-ce que cette ligne droite touche le joueur ou pas », par exemple des objets physiques en mouvement qui rebondissent les uns sur les autres, tout devient encore bien pire. Principalement à cause du fameux effet papillon: la moindre petite erreur dans les conditions initiales peut engendrer de très grosses erreurs au niveau du résultat. Considère un personnage qui se casse la figure en ragdoll dans un escalier. Si à un moment de la chute son bras heurte une marche une fraction de seconde trop tard ou trop tôt par rapport à une autre simulation, la position qu’il aura au bas de l’escalier sera peut-être totalement différente. Si tu as joué à Trackmania, c’est un bon exemple, un petit milipoil trop à gauche ou trop à droite lors d’un virage important, et on perd 2 secondes au final.

Alors ce qui se passe dans ces cas là, c’est que pour avoir une simulation identique sur tous les ordinateurs, on exécute une simulation physique partout, et par-dessus ça on synchronise tout ce qu’on peut aussi fréquemment que possible pour corriger la quantité industrielle de petites erreurs qui se produisent partout. Et par-dessus ça on rajoute une couche de triche pour que le joueur aie l’impression que tout va bien même si y’a les 3/4 des éléments qui ne se comportent pas comme ils devraient.

Euh voilà, je ne sais pas si j’ai été clair… :stuck_out_tongue:

Alors à priori, Warhammer Online intégrera les collisions entre joueurs en pvp et non pas de système de physique (éboulement de caisses, ragdoll, etc…)
Après je n’y connais rien en programmation mais je sais que certains MMO, je pense nottament à DAoC ici pour l’avoir beaucoup pratiqué, intègre déjà des notions de positions par rapport aux autres joueurs/mobs (savoir si un sort est lançable ou pas en fonction de la distance, si un coup est bloqué/paré ou non, si un style positionnel réussi ou non).
Ce n’est surement pas suffisant pour gérer une forme de collisions, mais il faut vraiment beaucoup plus?

Le truc c’est que la collision doit etre gérée sur le serveur (pas sur le client) pour éviter toute triche (imagine, tu hackes ton client pour dire que jamais t’aura de collision avec le monde, tu deviens le passe muraille). Or, la collision c’est beaucoup de calculs mathématiques, multiplié par le nombre de joueurs.

Autant sur un FPS a 16 c’est jouable pour un serveur, autant pour des serveurs qui doivent gérer 500 joueurs et plus, ca devient ingérable.

Alors oui les collisions seront précalculées sur ton PC, mais le serveur devra faire un check (forcément) pour t’autoriser a faire ce moment dans le mur ou pas.

Le lag généré par la gestion des collisions n’est pas du lag réseau, mais du lag de calcul. C’est un abus de langage qui est utilisé. Si tu préfères, l’ajout de la gestion des collisions va faire “ramer” le serveur donc les paquets réseaux indiquants que “non t’as pas le droit de traverser le mur” seront émis plus tard, menant a un lag qui ressemble a du lag réseau.

Ok :stuck_out_tongue:

Puis-je en déduire que cela pourrait amener Mythic à limiter le nombre de joueurs en pvp, en mettant en place une espèce de système d’instance pvp à la wow par exemple?
Je ne me souviens plus précisèment de l’article de Joy mais je ne crois pas que ce soit la direction que prenne Mythic (et heureusement d’ailleurs…)

[quote=« Drealmer, post:5, topic: 28576 »]Je ne sais pas trop de quoi ils parlent dans l’article, je n’en dispose pas. Faudrait savoir si ils parlent juste de collisions ou bien de véritables physiques en réseau. Une collision c’est quand un objet dynamique percute un autre objet, statique (décor) ou dynamique (personnage, piles de caisses…). Les physiques, c’est lorsque ces collisions déclenchent autre chose (rebond, rotation, truc qui s’écroule).

Quoi qu’il en soit, déjà dans le cas des collisions c’est chaud. La principale cause de tous les problèmes, c’est le lag. Imaginons le simple fait de tirer sur un autre joueur dans un FPS en réseau. Sur ta machine, tu vois le joueur bien au centre de ton viseur, mais à cause du lag, à ce moment précis, l’autre joueur est déjà 200 millisecondes plus loin, ce qui le met théoriquement juste en dehors du viseur. Pour contrer celà, on fait ce qu’on appelle du dead-reckoning. C’est à dire qu’on connait l’état du joueur 200 ms dans le passé, et on estime son état actuel sur base des ces informations. Genre, il se déplaçait à 5 mètres / seconde dans telle direction, on extrapole linéairement et on a la nouvelle position. Problème, ça reste une approximation, car si pendant ces 200 ms le joueur a changé de direction, ou bien s’est arrêté, l’estimation va être faussée.

Tout ça pour dire que plein de moyens sont mis en place pour estimer le véritable état du jeu (l’état de tout le monde au moment présent) malgré le lag. Donc y’a le dead reckoning, puis quand on reçoit une nouvelle séries d’informations sur les autres joueurs, on essaie de rattraper les erreurs qu’on a introduites de façon élégante (que le joueur ne le remarque pas), tout en essayant de ne pas avantager l’un ou l’autre joueur, et en évitant les possibilités de triche… Bref, c’est vachement compliqué. Rien que l’exemple du joueur qui tire sur un autre peut servir de base à tout un exposé :stuck_out_tongue:

Maintenant lorsqu’il s’agit de choses bien plus complexes que juste « est-ce que cette ligne droite touche le joueur ou pas », par exemple des objets physiques en mouvement qui rebondissent les uns sur les autres, tout devient encore bien pire. Principalement à cause du fameux effet papillon: la moindre petite erreur dans les conditions initiales peut engendrer de très grosses erreurs au niveau du résultat. Considère un personnage qui se casse la figure en ragdoll dans un escalier. Si à un moment de la chute son bras heurte une marche une fraction de seconde trop tard ou trop tôt par rapport à une autre simulation, la position qu’il aura au bas de l’escalier sera peut-être totalement différente. Si tu as joué à Trackmania, c’est un bon exemple, un petit milipoil trop à gauche ou trop à droite lors d’un virage important, et on perd 2 secondes au final.

Alors ce qui se passe dans ces cas là, c’est que pour avoir une simulation identique sur tous les ordinateurs, on exécute une simulation physique partout, et par-dessus ça on synchronise tout ce qu’on peut aussi fréquemment que possible pour corriger la quantité industrielle de petites erreurs qui se produisent partout. Et par-dessus ça on rajoute une couche de triche pour que le joueur aie l’impression que tout va bien même si y’a les 3/4 des éléments qui ne se comportent pas comme ils devraient.

Euh voilà, je ne sais pas si j’ai été clair… :P[/quote]

Trés clair, tellement que j’ai rien compris :stuck_out_tongue:

Non bon, merci pour les explications, je comprend un peu mieux maintenant la difficulté de gerer un tel système. Par contre j’ai du mal à imaginer la quantité d’information que ca génère et je pensais qu’avec les débits qu’on as maintenant c’était négligeable. Je me trompe donc ?

Bah faisons un calcul bête et méchant, et disons que pour chaque objet physique, j’ai besoin d’échanger les informations suivantes entre les joueurs:

  • position : vecteur -> 3 floats
  • rotation : quaternion -> 4 floats
  • vitesse linéaire : vecteur -> 3 floats
  • vitesse angulaire : vecteur -> 3 floats

On a un total de 13 floats d’information par objet, ce qui fait 52 bytes. Maintenant, considérons que notre moteur physique tourne à 30 FPS, chaque objet génère 1560 bytes de données par secondes. Avec une connexion ADSL minimum, on uploade à 16K par seconde. Donc en gros, si on envoie continuellement les informations physiques relatives à 10 objets, on sature l’upload. Et 10 objets c’est pas énorme, et de toutes façons il ne resterait plus de bande passante pour le reste du jeu…

Bon, mes calculs sont faits à la louche juste pour donner un ordre d’idée, mais ce qui en ressort c’est que la méthode brute ne marche pas. Avoir un bon netcode qui arrive à gérer plein d’objets c’est très chaud. Le mieux qui existe pour l’instant c’est la démo de Cell Factor, qui arrive à faire bouger simultanément environ 400 objets en LAN sur 8 postes. Et ça dépote grave, soit dit en passant. Je ne sais pas trop ce que les physiques prennent en bande passante par contre.

Ah oui mais nan drealmer; tu vas pas envoyer un float pour un angle :P. 256 position d’un angle c’est amplement suffisant (donc 8bits). De même que pour la vitesse linéaire (a moins d’avoir de grande disparités dans les vitesses) tu peux coder ca sur 8 ou 16 bits. Idem pour la vitesse angulaire.

Ensuite, en général les serveurs tournent a un nombre de FPS assez bas (je crois que d’habitude, on tourne a 20Fps, 15 pour les versions low bandwidth) le reste est fait par dead reckoning.

Ensuite, ton post peut preter a confusion, on a l’impression que toutes ces données sont envoyées pour chaque objet à chaque fois. Il n’en est rien. Par exemple quand on tire une balle, à la création, on va envoyer sa position et vecteur vitesse. L’orientation peut être déduite de la position du joueur, la vitesse angulaire (s’il y en a une) est purement cosmétique et est donc gérée coté client. Par la suite, la vitesse de la balle ne va pas baisser (a moins d’être dans un jeu très spécifique), ce ne sera plus que la position qui sera envoyée. On peut encore pousser l’optimisation, connaissant la durée de vie maximum d’une balle, et sa vitesse pour savoir dans quelle type de donnée pourra etre stockée sa position: par exemple si la balle bouge de moins de 256 unités dans le jeu, et va a 1 unité par frame, on peut meme pousser le vice a stocker sa position dans un byte! (mais bonjour l’arrachage de tête après pour tout décompacter :P)

Ben premièrement j’avais dit que je faisais les calculs à la louche pour montrer que ça ne pouvait pas fonctionner sans optimisation. La compression fait partie de ces optimisations. De même que tout ce qui est culling et prédiction, on n’envoie pas tout à chaque frame.

Maintenant si on parle de physiques, et pas juste de collisions “je glisse le long du mur”, clairement 20 ou 15 fps c’est pas suffisant. Un moteur comme Novodex (Ageia PhysX) tourne à 60 FPS par défaut, en fixed step. Parce que plus on descend dans les FPS plus on ouvre la porte au tunelling, et vu que dans les jeux actuels et à venir on n’a plus trop le temps de modéliser les proxis statiques en volumes fermés, le tunneling devient un risque important. Et le CCD n’est pas une solution pour contrer un mauvais framerate, vu que premièrement c’est lourd, et qu’en plus c’est quasiment pas faisable dans le cas des rotations.

Niveau précision, même combat. Si c’est juste synchroniser les informations des objets pour qu’ils soient ok visuellement, oui on peut tailler dedans. Maintenant si c’est pour intéragir physiquement avec la simulation qui tourne en local, mieux vaut avoir une bonne précision si on ne veut pas que ça devienne instable.

Oui tu as tout a fait raison, je tenais juste a préciser certains points (et a montrer ma science aussi :P). Pour le nombre de Fps en fixed step, ca me semble par contre bizarre parce que les quake engine tourne par défaut a 20fps en ce qui concerne le réseau…