Quel moteur 3D pour Camelot Unchained ?

Belk · 04/04/2013, 19h01

Encore plus de précisions de la part d'Andrew... Je laisse aux pros le soin d'en tirer une conclusion et de nous faire une synthèse compréhensible

Citation :

@ogged451 FWIW, I was the client lead on WAR, not the server lead, so I had no direct involvement with the server code. As I understand it, the architecture was largely inherited from DAoC without a lot of core changes, so it was a little creaky and couldn't handle some of the things bolted on. If I were to do it myself, with a clean sheet of paper and the knowledge gained from indirect hindsight, the three main things I'd want do (and I sincerely hope I get to, because this is cool stuff!) are:

1. Multithreading. Use it within the main update loop to update characters in parallel. Take the processing of each individual client's networking out of that loop and handle it asynchronously.

2. Hierarchical partitioning of spatial data. Each WAR server process divided the world into coarse cells. In order to determine who was hit by a 5m radius effect (roughly 79 square meters in area), you had to start with a list of everyone in 1 to 4 of those cells (potentially over 50 TIMES the area!) and then run through all of characters going "Are you in this 5m radius?". When a lot of people show up, that's a big problem. When everyone in the bunch spams AoEs, that's a bigger problem. There are far more efficient ways of representing that (quadtrees, R-trees, etc.) so that you can start with a list of only the people very near that radius.

3. At a high level, certain large swaths of the world belonged to certain processes. There was no ability to split one of these large areas into a second process on a second machine if it got crowded and the CPU couldn't keep up.

Right now we've got working tech for 1 & 2, which you'll see in an upcoming demo. Number 3 is potentially something we'll be bringing in from outside if the KS funds.

(And as an aside, to anyone from the WAR team: This is my best recollection of the conversations we had in 2008. My sincerest apologies if I'm remembering incorrectly; feel free to call me out below and I'll apologize publicly and personally.)

Scrooge McDuck · 04/04/2013, 19h18

Citation :

Publié par Avenzoar

La taille de ton peigne ? ... désolé.

lol

Je comprends rien aux billets d'Andrew, mais c'est rare que des développeurs donnent autant de précisions

Ingilir · 04/04/2013, 19h44

Citation :

Publié par Belk

compréhensible

Très important

Dez · 04/04/2013, 19h46

En résumé :

Là il ne parle pas du tout du moteur 3D, mais de la manière dont sont gérées les données côté serveur pour éviter des ralentissements de ce dernier. Les 3 points importants pour lui :

1. Le multithreading (ou encore, la parallélisation des calculs). Je ne comprends pas trop l'idée sous-jacente... Ce que je comprends c'est le souhait de casser le synchronisme entre la mise à jour des personnages (ie, les changements d'états, dégâts, etc) et la notification de ces changements aux clients. De gérer ces deux "boucles" dans deux threads différents : pas besoin d'attendre d'envoyer au client "Tu te manges un debuff" avant de commencer à calculer combien de dégâts il va se manger sur la baffe qui arrive". (si quelqu'un comprend mieux, hésitez pas à m'éclairer!).

2. Le découpage des zones. Dans un jeu comme WAR (par exemple), pour déterminer les personnes touchées par un aoe (genre, 5m de rayon d'action), il fallait interroger tous les clients présents dans une zone (qui faisait 79m²) pour savoir si les personnages étaient ou non dans le rayon d'action de l'aoe. Ce genre de requêtes, multipliés par le nombre de personnes / le nombre d'AOE, ça cause des soucis côté serveurs.
Il y a d'autres méthodes qui sont envisageables pour résoudre ces problématiques, cf. côté des R-Tree, etc : d'autres méthodes pour accéder à des données de coordonnées.

3. La capacité de déporter des zones vers d'autres machines : des "portions" du monde (pas trop compris le terme swath dans ce contexte!) sont gérés par des processus. L'idée étant de pouvoir extraire certaines de ces portions dans des sous-process si le serveur est chargé, pour les envoyer sur d'autres instances, pour décharger le premier CPU.

Les points 1&2 sont en cours de développement, et ils devraient faire des démos dans le cadre du KS.
Le troisième cependant, sera récupéré sur un modèle déjà existant si le KS abouti (j'imagine via achat de licence, pour le coup).

Ingilir · 04/04/2013, 19h50

Merci de l'effort, même si je patauge toujours, perso

Moi, du moment où le jeu sera fluide, c'est tout bon

Shaggath · 04/04/2013, 19h53

En gros il parle de la partie serveur.

Multithreader un max les process de gestion update perso etc de la partie netcode pour éviter d'influer sur le netcode et de gérer les interactions entre les process de manière asynchrone.
En gros si il y en a un à la ramasse qui prend du temps à s’exécuter le reste fonctionne et l'info arrivera quand elle sera disponible sans tous bloquer.

Le sous jaccent c'est que dans des conditions dégradés, il peut choisir les process prioritaire, genre favorisé le netcode puis les déplacements, puis les dégats, buff calcul de xp.

Apres il parle d’améliorer la gestion des personnages sur la carte, en gros sur war pour déterminer si un aoe toucher il récupérait la liste des personnages dans chaque cellules autour du personnage et pour chaque personnages il vérifie si il est la porté.
La il veut modifier la structure de ces listes de personnages pour stocker directement autour d'un personnage la liste des personnages qui se trouve dans le rayon de l'ae.

Ce qui faut comprendre derrière c'est qu'ils vont normalisé la distance des attaques.
En limiter le nombre pour avoir directement la liste des potentiels cible plutot que des attaques ou on peut choisir exactement la distance mais derrière devoir se taper des recherches pour déterminer ce qui est à porter.
Moins il aura de rayon d'ae différent plus ca méthode sera fonctionnelle puisque sinon il doit gérer des listes différentes pour chaque rayon.

Le dernier point ca dépendra des fonds de la campagne kickstarter et ils voudraient pouvoir gérer de pouvoir splitter la gestion d'une zone sur un autre serveur si la charge est trop importante.
edit : Plus rapide dez

**Arnfiarnunn Neanias** · 04/04/2013, 19h54

Citation :

Publié par Dez

3. La capacité de déporter des zones vers d'autres machines : des "portions" du monde (pas trop compris le terme swath dans ce contexte!) sont gérés par des processus. L'idée étant de pouvoir extraire certaines de ces portions dans des sous-process si le serveur est chargé, pour les envoyer sur d'autres instances, pour décharger le premier CPU.

Je peux me tromper mais il me semble que c?est un système très similaire utilisé sur EvE (avec succès)

Dez · 04/04/2013, 20h00

C'est effectivement le principe utilisé sur EvE. Cependant, sur EvE c'est facilité par la construction de l'univers. Il est "facile" de bouger un système solaire, ce dernier étant facilement délimitable, a ses points d'accès, etc. Si lors de la migration les gens ont un léger lag, ça passera inaperçu, et les personnes en cours de loading auront juste un chargement un peu plus long, par exemple.

Sur un monde ouvert sans temps de chargement, c'est beaucoup plus délicat à gérer de manière transparente. C'est comme si tu voulais répartir un système solaire de EVE sur deux processeurs logiques en même temps. Le premier ne saurait pas ce qu'il se passe sur l'autre, ce qui complique diablement la résolution des combats. (Quel processeur va résoudre l'action de tel ship, dans quel ordre, etc ?) Il faut du coup que les processeurs communiquent entre eux au niveau de ces données, et ça rajoute une couche de complexité au bouzin.

@Shaggath : bien vu pour le coup de la normalisation des portées des aoe comme conséquence. C'est logique, en même temps.

Domhnall · 04/04/2013, 20h55

Cela n'aurait aucun sens de ne pouvoir lancer un sort qu'à une certaine distance de l'adversaire, tel que j'ai compris le post d'Andrew il évoque plutôt le fait que le check se ferait dans le sens "qui est proche de l'AE ?" et non pas "où se trouve l'AE par rapport aux personnages dans la zone ?".

Sisay · 04/04/2013, 21h21

Ça me semble logique d'uniformiser les rayons et portées des sorts, c'est effectivement une façon simple de demander moins de ressources.

Tous les pbaoe auraient la même zone, et les sorts pourraient être en 2-3 paliers seulement (Exemple de Daoc: dd skald 500 range, DD mage 1500, Mez Sorc 1750)

Domhnall · 04/04/2013, 21h30

Sauf qu'avec DAoC c'était par exemple "entre 50 et 500m" pas "juste 500m" et c'est ça que signifierait une normalisation.

Jaïna - Callista · 04/04/2013, 21h56

et surtout sur daoc, les aoe étaient dégressifs en dégats, donc encore de calculs.

Domhnall · 04/04/2013, 22h02

Et ça fonctionnait très bien sur DAoC, considérant les progrès fait dans le domaine depuis le temps je pense qu'on peut s'attendre au moins à quelque chose au même niveau. Aucune raison pour eux de faire moins bien.

Ingilir · 04/04/2013, 22h16

Pour info, le moteur de DAOC était-il aussi un moteur développé en interne ?

Avenzoar · 04/04/2013, 22h25

Citation :

Publié par Ingilir

Pour info, le moteur de DAOC était-il aussi un moteur développé en interne ?

C'était Gamebryo sur DAoC.

Durack · 04/04/2013, 22h27

Citation :

Publié par Avenzoar

C'était Gamebryo sur DAoC.

Le meme que War et Rift .

Grexor · 04/04/2013, 23h42

Citation :

Publié par Shaggath

Je pense que beaucoup en fond un flan pour rien dans le sens ou ça peut pas bouffer tellement de fluidité

Et moi je pense que certains n'ont pas compris à quoi je faisais allusion

Il ne s'agit pas de fluidité, mais de bordel monstre à l'écran, avec l'idée sous-jacente :

Et si je suis au milieu, je fais quoi ?

04/04/2013, 23h46

Citation :

Publié par Grexor

Et si je suis au milieu, je fais quoi ?

Tu ramasses tes dents.
Tu fais un /ragequit.
Et tu fais un post sur JOL pour demander le nerf de la classe en question.

seursha · 05/04/2013, 00h57

Citation :

Publié par Domhnall

Sauf qu'avec DAoC c'était par exemple "entre 50 et 500m" pas "juste 500m" et c'est ça que signifierait une normalisation.

il ne faut pas confondre aoe et un gtae j ai pas le souvenir d avoir vue des aoe de 500 m de large(champ de ronces a verifier )
l aoe est soit sur le lanceur du sort (pbae) on vas dir 15m
ou
sur la cible positioné ( 50/500) mais de 15 m aussi donc il veux juste imposer les largeur d aoe pas la distance du sort !

05/04/2013, 01h00

Citation :

Publié par seursha

il ne faut pas confondre aoe et un gtae j ai pas le souvenir d avoir vue des aoe de 500 m de large(champ de ronces a verifier )
l aoe est soit sur le lanceur du sort (pbae) on vas dir 15m
ou
sur la cible positioné ( 50/500) mais de 15 m aussi donc il veux juste imposer les largeur d aoe pas la distance du sort !

Ca change rien au caractère dégressif des sorts.
Enfin pour DAOC c'est la règle.
Tous les AE sont dégressifs : PBAE /AE /GTAE
Ou alors j'ai rien compris à la discussion. ^^

Morh · 05/04/2013, 01h01

Et j'espere que ça sera le cas sur CU ,

Scrooge McDuck [LoW] Alpha & Oméga	Citation : Publié par Avenzoar La taille de ton peigne ? ... désolé. lol Je comprends rien aux billets d'Andrew, mais c'est rare que des développeurs donnent autant de précisions
04/04/2013, 19h18

Ingilir [AnY] Alpha & Oméga	Citation : Publié par Belk compréhensible Très important
04/04/2013, 19h44

Ingilir [AnY] Alpha & Oméga	Merci de l'effort, même si je patauge toujours, perso Moi, du moment où le jeu sera fluide, c'est tout bon
04/04/2013, 19h50

Domhnall Alpha & Oméga	Cela n'aurait aucun sens de ne pouvoir lancer un sort qu'à une certaine distance de l'adversaire, tel que j'ai compris le post d'Andrew il évoque plutôt le fait que le check se ferait dans le sens "qui est proche de l'AE ?" et non pas "où se trouve l'AE par rapport aux personnages dans la zone ?".
04/04/2013, 20h55

Sisay Alpha & Oméga	Ça me semble logique d'uniformiser les rayons et portées des sorts, c'est effectivement une façon simple de demander moins de ressources. Tous les pbaoe auraient la même zone, et les sorts pourraient être en 2-3 paliers seulement (Exemple de Daoc: dd skald 500 range, DD mage 1500, Mez Sorc 1750)
04/04/2013, 21h21

Domhnall Alpha & Oméga	Sauf qu'avec DAoC c'était par exemple "entre 50 et 500m" pas "juste 500m" et c'est ça que signifierait une normalisation.
04/04/2013, 21h30

Jaïna - Callista [Tmpst] Prophète / Prophétesse	et surtout sur daoc, les aoe étaient dégressifs en dégats, donc encore de calculs.
04/04/2013, 21h56

Domhnall Alpha & Oméga	Et ça fonctionnait très bien sur DAoC, considérant les progrès fait dans le domaine depuis le temps je pense qu'on peut s'attendre au moins à quelque chose au même niveau. Aucune raison pour eux de faire moins bien.
04/04/2013, 22h02

Ingilir [AnY] Alpha & Oméga	Pour info, le moteur de DAOC était-il aussi un moteur développé en interne ?
04/04/2013, 22h16

Avenzoar Héros	Citation : Publié par Ingilir Pour info, le moteur de DAOC était-il aussi un moteur développé en interne ? C'était Gamebryo sur DAoC.
04/04/2013, 22h25

Durack Alpha & Oméga	Citation : Publié par Avenzoar C'était Gamebryo sur DAoC. Le meme que War et Rift .
04/04/2013, 22h27

Grexor Alpha & Oméga	Citation : Publié par Shaggath Je pense que beaucoup en fond un flan pour rien dans le sens ou ça peut pas bouffer tellement de fluidité Et moi je pense que certains n'ont pas compris à quoi je faisais allusion Il ne s'agit pas de fluidité, mais de bordel monstre à l'écran, avec l'idée sous-jacente : Et si je suis au milieu, je fais quoi ?
04/04/2013, 23h42

#24073 Invité	Citation : Publié par Grexor Et si je suis au milieu, je fais quoi ? Tu ramasses tes dents. Tu fais un /ragequit. Et tu fais un post sur JOL pour demander le nerf de la classe en question.
04/04/2013, 23h46

Morh Alpha & Oméga	Et j'espere que ça sera le cas sur CU ,
05/04/2013, 01h01

Quel moteur 3D pour Camelot Unchained ?

Connectés sur ce fil