Newsletter du 16 novembre

Lors du stream de CSE de cette semaine, nous avons encore eu le droit à la présence d'Andrew et Ben. Il y a eu donc pas mal d'informations techniques ainsi que sur les mécaniques de gameplay qui ont été abordées ! Il y a eu environ plus d'1h de discussion à ce sujet, je vais donc faire un résumé ci-dessous.

Pour information, j'ai ajouté 4 vidéos pour illustrer les propos d'Andrew sur la gestion des décombres. A la base, ce ne sont pas des vidéos mais des images animés (.gif) que Andrew a mis sur son compte Twitter. Twitter bloque le lien pour ces images pour pas qu'on puisse les ajouter directement sans passer par Twitter, j'ai donc dû les extraire sous format vidéo mais ce ne sont pas des vidéos tirées du jeu. La qualité n'est donc pas représentatif de la qualité en jeu.

 Andrew a indiqué qu'actuellement la version gérant les décombres a été mis à disposition sur Hatchery (le serveur des IT). Il espère pouvoir mettre à dispo cette version dans la semaine pour les Alpha/Beta. Andrew a indiqué avoir corriger le bug de désynchronisation entre le client qui effectuait l'action, les données sur le serveur et les données envoyées aux autres client. Maintenant, tout le monde voit bien la même chose. Vous pouvez voir un exemple de gestion de décombres dans la vidéo ci-dessous. Dans cette vidéo, Andrew retire des morceaux du bâtiments avec l'éditeur de construction en jeu. Quand le moteur de jeu s'aperçoit que la tour n'est plus stable, elle se détache de la construction et devient un décombre qui tombe au sol.

Même si Andrew a mis aux point la gestion des décombres (stabilité, création des objets physiquement dans le monde, etc...), Andrew a indiqué qu'il manquait encore plusieurs améliorations sur lesquels il doit encore travailler. Ces améliorations sont les suivantes :

• l'interaction entre les décombres. Par exemple quand 2 décombres entrent en contact, quels sont les dégâts que chaque décombre reçoit ?
• amélioration de la gestion de la physique pour y intégrer la friction, la masse des objets et l'absorption des chocs selon les matériaux du décombre
• intégration de la gestion de la vitesse et des momentum

Par exemple, dans la vidéo ci-dessous vous pouvez voir un archer qui tire une flèche sur un décombre. Ce décombre réagit en conséquence en étant propulsé. Andrew indique qu'actuellement la réaction est disproportionnée par rapport à une simple flèche (même si c'est marrant à voir !). En réglant tous les points ci-dessus, le comportement de la flèche et des décombres sera plus réaliste.

Quand tous ces rajouts seront finalisés, Andrew veut aussi ajouter cette gestion de la physique sur les corps des joueurs et sur les objets (équipement ou sort créant un objet physique en jeu) qui seront au sol. De cette façon, quand un décombre touchera un joueur, cela aura un effet sur ce joueur (dégâts, projection, etc...). Par contre pour ne pas avoir d'impact négatif sur les performances du jeu, certaines choses ne seront pas calculées par le serveur mais uniquement par le client du jeu. Par exemple si un corps est projeté, le serveur va indiquer au client la trajectoire de ce corps. Mais le client aura entièrement la main sur le calcul des mouvements des jambes/bras pendant cette trajectoire.

Le but est de faire quelque chose de logique mais pas 100% réaliste. Par exemple dans la vidéo ci-dessous, vous pouvez voir un exemple concret. Tim est positionné sur un débris qui tient en équilibre. Un soigneur Viking lance un sort qui crée une Pierre de Guérison juste en dessous de ce débris. Lorsque la pierre apparait en grandissant vers le haut, elle pousse le débris et projette Tim. Même si cet exemple est exagéré, CSE veut aussi laisser la place à quelques trucs fun dans ce genre.

 Pour finir, j'en profite aussi pour mettre un vieil exemple de destruction d'un mur avant la gestion des décombres (pour avoir des décombres, il faut bien détruire quelque chose !) pour les personnes ne l'ayant pas encore vu :

La plus grosse partie du stream a été la discussion et les questions à propos du travail de Ben sur le design des classes et en particulier sur les classes de Support. En effet, la semaine dernière Ben a fini de travailler sur le design des Supports et vient de commencer à travailler sur les Spirit Mages.

Ben a rappelé qu'actuellement tout ce travail est fait sur papier et pas directement en jeu. De même, hormis le Mage qui sera la prochaine classe à intégrer la Beta 1, l'ordre des classes sur lequel travaille Ben n'indique pas l'ordre où les classes arriveront pendant la Beta. Le but est de préparer le terrain et d'avoir le maximum d'information pour les développeurs. De cette façon, ils pourront prévoir les besoins aussi bien au niveau de l'éditeur que des différentes mécaniques qui devront être mises en place. Les développeurs pourront aussi anticiper s'il y a un besoin de créer de nouvelles technologie dans le jeu pour gérer une compétence ou un effet particulier par exemple.

Ben a expliqué un peu le fonctionnement des classes Supports. Pour rappel, les 3 classes Supports sont le Minstrel pour les Arthurians, le Dark Fool pour les TDD et le Skald pour les Vikings. Les classes Supports sont conçues principalement autour de la gestion des buff/debuff et de la gestion des effets actifs. Donc si notre groupe n'a pas de support, on sera très désavantagé par rapport à un groupe qui a un Support (surtout au niveau des purges, cleanse, etc...). Si on prend l'exemple d'un groupe de 8 joueur contre un autre groupe ayant la même composition de classe à l'exception d'une classe remplacé par un Support, Ben estime que cela impliquera les choses suivantes :

• le groupe avec le Support aura plus de mobilité grâce au buff de vitesse de déplacement. Le groupe pourra donc fuir plus facilement, engager un combat plus facilement et désengager/éviter un combat facilement
• le groupe aura plus de contrôle sur la gestion des buffs et des debuffs en particulier sur les mécaniques de Terror et de Panic.
• le groupe aura plus davantage car il aura accès des purges, cleanse, etc...

Les buffs de zone des Support seront principalement des buffs de groupe mais il existera aussi quelques sorts ciblés. Ces sorts ciblés auront une longue portée donc il ne sera pas forcément nécessaire d'être à côté d'un Support pour en recevoir. Il sera possible d'aider des personnes en dehors de notre groupe si on le souhaite mais cela sera limité. D'une part, le but est d'éviter d'avoir des buffbot comme à l'époque de DAoC (il était possible d'avoir un second compte avec un personnage qui pouvait buff une personne ou un groupe car les buffs avaient une durée illimité et une portée illimité). Les buffs auront une portée maximale. Avoir un buffbot sera donc plus compliqué car cela impliquera de l'amener dans la zone de combat et le buffbot se fera vite tuer. CSE pense à la notion des buffbot dès la conception pour les limiter le plus possible et que cela ne soit pas facile à faire. Il ne sera pas possible de gérer tous les cas car les joueurs sont très inventifs pour détourner les choses. Pour les cas non prévu, CSE prévoira des règles du jeu pour l'empêcher. Le second but est aussi de pouvoir gérer le concept de zerg (voir plus bas pour plus de détails).

Ben a répondu à une question en indiquant que les certaines classes Support auront un (ou des ?) sort de type contre-sort classique. Les sorts de type "vol de sort" sont plus délicat à faire donc cela sera peut être ajouté aussi mais pas sûr. Les sorts de type "renvoie de sort" ne sera par contre pas dispo sur les classes Supports mais peut être sur d'autres type de classes.

A la question d'Andrew demandant quelle était pour lui la compétence la plus cool pour chacun de ces 3 Supports, Ben n'a pas pu répondre. Il a indiqué qu'il y avait beaucoup de composants et de possibilités pour la création des compétences. Donc il ne pouvait pas donner à l'improviste une réponse sans réfléchir. Par contre, il a indiqué que de son avis personnel le Minstrel était le plus sympa du fait dont la classe va fonctionner au niveau des mécaniques générales !

Les Minstrel auront 3 niveaux de combinaisons pour leurs chants. Les 3 niveaux seront les suivants :

• un effet ayant une longue portée
• un effet ayant une courte portée
• un effet unique ciblé

 Il faudra combiner ces 3 niveaux sur une seule compétence. Cela sera intéressant car le joueur devra décider comment il voudra mixer les dégâts et les debuff à différente portée sur différents personnes. Certains composant permettront de modifier certain niveau comme par exemple augmenter les dégâts, augmenter la zone d'effet, prolonger l'effet, etc... Pendant que le Minstrel utilise un chant, il ne pourra pas utiliser d'autres techniques comme des coups d'épée, etc... En effet, il est en train de jouer d'un instrument donc il ne peut pas tout faire en même temps !

 Pour les personnes ayant l'habitude de jouer des classes à chant, la gestion générale des chants leur sera familière. L'effet des chants pourra être dans une de ces 4 catégories :

• l'effet persistera encore quelques secondes après l'arrêt du chant. Cela permettra à certains effets de se chevaucher.
• l'effet ne persistera pas à l'arrêt du chant.
• l'effet sera plus rentable en laissant s'arrêter entièrement plutôt que de le rafraîchir tout le temps.
• 2 effets différent qui se chevauchent pourrait déclencher un nouvel effet. Cela dépendra principalement des tests qui seront faits sur cette fonctionnalité. Ben veut voir si cette 4ème catégorie sera bien en pratique ou pas.

Dans tous les cas, le Minstrel devra faire un choix sur l'effet qu'il veut avoir car il sera obliger de lancer ce sort pendant un certain temps afin de profiter de l'effet souhaité.

Les chants sont de type "Mind" au niveau de la Magie. Donc tous les effets A.I.R qui interagissent avec les effets Mind pourront donc interagir avec les chants.

 Le Dark Fool aura beaucoup de manipulation de Blood.

Cette classe aura plusieurs cris et un peu de chant. Les cris et les chants ne sont pas sur les mêmes CD ou timing d'utilisation. Les cris sont plus orientées en mélée et les chants à distance. Le joueur pourra donc selon ce qu'il souhaite ou selon ce qui arrange le groupe s'orienter plus vers l'un ou l'autre. Mais comme il y a une séparation entre les 2 mécaniques, le Dark Fool pourra faire des choses que les autres supports ne pourront pas. Par exemple, contrairement au Minstrel, le Dark Fool ne sera pas limité à un seul effet car même s'il a un chant en cours, il pourra décider d'utiliser un cri afin de pouvoir réagir à quelque chose sans annuler l'effet en cours. Cela va permettre d'ajouter de la flexibilité avec cette classe et d'avoir des timings intéressant en combat.

Dans la description de la classe à son annonce, il était indiqué que le Dark Fool pouvait utiliser des illusions. Ben aimerait pouvoir arriver à faire cela. Actuellement, il n'y a pas la partie technique codée qui permet de gérer les illusions et de tester ce concept en pratique. Mais lors de la conception de la classe, Ben a prévu cela. Il y a par exemple un sort qui permet de faire une copie de soi-même afin de distraire les ennemis et empêcher de se faire tuer. Afin de confirmer à 100% de ce genre de design, Ben veut faire des tests pour voir si cela n'a pas d'impact sur les performances du jeu ou sur le gameplay général du jeu.

Le Skald a été la classe la moins abordée lors de ce stream (il n'y a pas eu de questions dessus). ben a indiqué que cela serait un support orienté plus en mélée que les autres car il n'a pas besoin d'instrument mais juste besoin d'une arme. Il n'aura donc pas de gestion sur 3 niveaux comme le Minstrel mais il y aura les mêmes idées de gestion buff/debuff. Par contre, le Skeld pourra attaquer en même temps. Donc il pourra par exemple de donner lui-même des buffs en frappant l'ennemi ou par exemple donner des buffs sur les alliées proches de lui.

Lors des conceptions, CSE pensent toujours aux mécaniques d'anti-zerg. Il n'y a pas une solution miracle à cela mais plein de choses qui vont rendre le zerg le moins optimal possible même si cela sera toujours possible de le faire ponctuellement. CSE donne des exemples des choses qui sont déjà prévues pour limiter les zergs :

• les soins et les buffs de zone sont limités aux groupes comme indiqué sur une newsletter précédente.
• le design des objectifs obligera à prendre plusieurs petits objectifs différent. Cela forcera un Royaume à se séparer et pas à rester grouper en bus en permanence.
• les récupérations d'objectifs seront plus faciles s'il y a des combats pendant la prise de cet objectif (cela permet aussi d'éviter les prises d'objectifs en "mode PvE").
• les classes de Supports et de Scouts sont faites pour favoriser les groupes

 Au niveau de la conception général, Ben a donné les informations suivantes :

• une personne a demandé s'il était possible de se débrouiller pour mettre des explosifs sur son corps afin de pouvoir les déclencher  à sa mort. Ben a répondu que certains personnages peuvent le faire ! Par exemple le Flame Warden a dans sa liste de Bonus (passif choisi lors de la création de son personnage) un effet qui fait cela ! C'est le principe de "Death curse" dont CSE avait parlé dans le passé.
• une personne a demandé si certaines classes sur lesquelles Ben a travaillé récemment ont changé depuis leurs descriptions lors des annonces de l'époque. Ben pense que oui. Cela n'a pas forcément changer entièrement de direction mais Ben étant maintenant plus dans les détails de chaque classe, il pense que certains exemples indiqués à l'époque ne sont pas forcément aussi représentatif de la classe (mécanique, etc....) qu'à l'époque.
• la limite de stockage d'une personnage est gérée par l'encombrement mais aussi par certaines limitations. Ces limitations ne sont toutefois pas aussi restrictives que dans les autres jeux.
• au début, CSE voulait faire des spécialisations entièrement différentes pour chaque classe. En travaillant sur les classes, Ben s'est aperçu que les classes en elle-même étaient déjà très différentes. Il n'y avait donc plus besoin d'avoir des gameplay différent entre les spécialisation d'une même classe. Il ne sera donc pas possible de se spécialiser de façon à avoir un rôle différent que celui prévu par notre classe d'origine. Cela est plus ou moins vrai selon les classes par contre. Par exemple, les archers ont des compétences pour les arcs (donc à distance) mais ne pourront pas avoir des compétences pour se transformer en classe corps à corps (exception pour le Winter's Shadow !) ou un Soigneur ne pourra pas devenir une classe de dégâts. Au contraire le Devout qui est un hybride Mage/Soigneur pourront se spécialiser plus d'un côté ou de l'autre.

En excluant les points déjà abordés au-dessus, CSE indique avoir travailler sur les points suivantes la semaine dernière :

•  le travail sur le client 64 bits (ainsi que l'éditeur interne de CSE) et sur Coherent a continué. Cela a surtout été des corrections des bugs. CSE ne fera pas de build séparé pour les personnes ayant un accès Beta. Ces personnes verront tout arriver en même temps (avec la gestion des décombres aussi). CSE espère pouvoir faire ces tests avec les joueurs Beta cette semaine.
• le travail sur l'éditeur de création de compétences continue toujours. Plusieurs personnes ont travaillé sur ce sujet pour aider Ben à créer plus simplement les composants et les compétences nécessaire aux différentes classes.
• Michelle une première passe d'exploration sur des concepts de baguettes pour le Flame Warden et des sceptres pour le Druid. La semaine prochaine, elle travaillera sur les gants pour le Wave Weaver. Ces objets sont conçus assez grand pour être visible dans la main ainsi que pour supporter les composants en 3 parties pour les armes. Pour informations, ces armes ne devraient pas être les seules possibles pour les Mages. Ci-dessous, vous pouvez voir des exemples de ces concepts :

• Afin d'avoir un meilleur support performant pour le système de navigations des PNJ (et des caravanes), CSE est en train de prend ces "Mesh Simplification" et de les faire fonctionner avec les terrains. De cette façon, CSE pourra utiliser le moteur physique afin d'être plus précis sur les déplacements. Cela devrait aussi rectifier un nombre de problèmes rencontrés par les joueurs comme être bloqué sur un bout de terrain, certains glitchs et le fait de voir son personnage bouger tout seul sur un terrain.
• le travail sur le Personnage continue toujours ! Jon et Dionne ont fini de travailler sur le fait d'avoir un même UV pour les modèles masculins et féminin. Jon a aussi travaillé sur les textures des sous-vêtements et sur la mise à jour de certaines textures afin de prendre en compte les dernières modification sur les UV. Dionne a aussi travaillé sur six groupes d'armures afin d'aider Jon à mieux les animer sur les modèles. Concernant la mise à jour de ces armures, vous pouvez voir ci-dessous 4 captures. Les 2 premières captures représentent les armures légères, moyennes et lourde pour les Arthurian vu de dos et de face. Les 2 autres captures représentent dans l'ordre les armures légère et moyennes des TDD et l'armure légère des Vikings vu de dos et de face :

• Wylie a fini son travail sur la gestion des Particules. Les Particules prennent maintenant moins de place mémoire mais surtout le CPU les gère beaucoup mieux. Comme indiqué sur les précédentes newsletter, le plus gros problèmes de performances étaient dû aux particules. Le problème n'était pas tant la mémoire utilisé mais surtout que les coeurs des CPU mettaient trop de temps à attendre que les particules soient en mémoire cache au niveau du CPU avant de faire les calculs. Wylie a optimisé cela pour régler ce problème d'attente.
• le travail sur Animation 2.0 suit son cours. Scoot a fini les animations communes pour les Mage (animation des projectiles, AoE, invocation, etc...). Ce n'est pas les animations définitives mais cela permettra de pouvoir commencer les tests du Mage. Joe a commencé à faire une passe sur le système de pondération. Le but est de "coller" les os géométriquement durant les animations afin de rendre les animations meilleures. Une mise à jour des animations existantes a aussi été faite pour s'adapter au nouveau squelette des modèles.
• Dionne et Joe ont travaillé sur un modèle de trébuchet générique. Dionne a aussi créer plusieurs textures pour les besoins de terrains de nouvelles zones. Vous pouvez voir 2 exemples ci-dessous :