[Cleanse]

[En provenance du sujet " Le développement de Camelot Unchained"]

Citation :

Nota Bene 1 "Traduction vs Interprétation":
La première partie du résumé est plus une synthèse de ce que moi, perso, j'ai capté par rapport à mon niveau de compréhension de l'anglais, qui est plutot satisfaisant. Cela-dit il peut exister des erreurs d'interprétation purement linguistique, mais aussi des erreurs tout bêtement sur la programmation, ou le gameplay.
N'hésitez donc pas à clairfier, corriger, simplifier même, les interprétations que je liste ici.
La seconde partie est plus à 90% de la traduction pure. J'ajouterais "MOI :" ou un astérisque "*" pour préciser quand c'est mon interprétation qui parle.

Nota Bene 2 "Sémantique / Vocabulaire":
Au niveau de la sémantique, c'est un peu flou, et il peut m'arriver de changer de terme, mais en gros, j'essais d'utiliser le mot "aptitude" (parfois "sort") pour tout ce qui se rapporte aux skills qu'on peut craft.
Il est à préciser qu'au delà des skills pure, le systèmes qu'ils ont mis en place leur permet à priori facilement de "node-ifier" le monde et ses items. Il leur suffit d'ajouter un node à un objet quelqu'il soit, pour lui donner soudainement une caractéristique qui lui permettra d'interagir (physiquement ou pas) avec l'environnement. Les nodes listés ici ne sont donc pas forcément attachés aux sorts, mais sont simplement des mécaniques développées qui peuvent ensuite être attaché à des items du monde pour leur donner une caractéristique particulière afin qu'ils interagissent d'une façon donné avec l'environnement.
Même s'il existent des Nodes dans les aptitudes, c'est la différence avec les "modifiers" qui eux sont liés aux sorts et permettent de les "calibrer" selon le style de jeu du joueur qui créé le skill.

En vrac :
- Les Buff / Debuff sont fonctionnels sur les statistiques (Primaires / Secondaires / Dérivés ) | sur les Boon / Bane | sur les heals/dégâts.
- Les "recovery time" sont en place, les animations qui permettront au joueur de savoir visuellement où ses commandes en sont ne sont pas encore en place et sont en WIP.
- Ils vont éviter que dans CU existent des "animation cancel" (un truc de gameur "hardcore pro" comme dans BDO par exemple) qui est souvent utilisé pour enchainer des aptitudes qui sont normalement pas censé être "cyclées" comme ça. En gros le gameplay n'est pas dicté par les animations, mais les animations sont dictées par le gameplay. Si ça a un sens pour qqun -_-.
- Les résistances sont en place et peuvent être buff/debuff.
- Les resist d'armure (pénétration) peuvent etre buff/debuff.
- Les coûts en Stamina et Blood peuvent être buff/debuff.
- Petite note sur les "ressources" spécifique aux classes : il n'y en a pas de prévues pour le moment.

Features physiques :
- Les projectiles : healer stones, arrows, fireballs, les potion du healer Arthruien, les rocher des armes de sièges, orbs (un choix de cast des casteurs) ont leur structure codés et sont fonctionels.

- A côté on a les "kinematics", là où les "projectiles" sont des objets mouvant qui sont influencés par leur environnement (par exemple un projectile qui va rebondir, s'il n'explose pas, sur un mur ou un tron d'arbre), les kinématics eux font l'inverse : ils influencent leur environnement, par exemple un mur de pierre casté par un mage sous un autre joueur va le soulever à mesure qu'il s'ériger.

Du coup d'après ce que j'ai capté si on prends l'exemple des pierres de soin des healeurs vikings, au moment du lancé de la pierre, c'est considéré comme un projectile, et au moment où il touche le sol, il devient un "kinématic".

Les "kinématics" ont leur propre barre de vie, et donc peuvent être détruit.

Listage de quelques composants / nodes / fonctionalités terminé(e)s (attention : pas les "modifier" / "modificateur") :
-Tous les sorts sont terminés pour les 9 classes prévues à la béta1.
En tout cas, tout ce qui est des sorts de bases fonctionnel, du genre : ce sort heal, ce sort fait des dégâts.
Reste à implémenter les "modifiers" (modificateurs), du genre : "ceci augmente le soin du sort de 10% mais augmente le cout du sort de 10%", ou "ceci augmente la vitesse de votre fleche de 10%, mais son traçage est réduit de 10%", (exemple de moi "ce composant réduit le temps de cast du sort qui vous êtes en train de créer de 50%, mais réduit sa barre de vie d’interruption de 50%", etc...).

- Ils parlent du fait que maintenant que les fonctionnalités sont implémentées il est, et il sera bien plus facile et rapide d'implémenter / modifier / calibrer les sorts et modificateurs selon les retours de test béta, ou même d'en ajouter d'autres par rapport à ce qui était prévus.

- Ça permet aussi de rajouter également des choses extrêmement facilement à mesure que le développement général du jeu avance. Comme par exemple ajouter des sorts spécifiques aux groupes. Système de groupe qui n'a été implémenté dans le système que récemment.

Les "Triggers" (Déclencheurs)
- Genre de node qui se déclenchent selon où vous êtes. Dépendant de "zone" du coup.
Par exemple, je suis dans l'eau depuis x-temps ou x-kilomètre de la rive : je me noie.
Où, je suis dans une "place of power", j'ai le buff "X".

- Déclenche cet événement sur mon personnage quand un certain truc se passe. Par exemple le Mjolnir à un sort qui pose un debuff sur sa cible et le prochain coup porté fait un autre "truc" (ou "évènement").

Les "Traumas"
Il y a les HP de base.
Ensuite les "blessures" qui en gros bloc votre barre de vie, aucun heal ne peut être reçus si la blessure n'est pas soignée.
Puis il y a les "traumatismes" qui sont en gros des debuffs : par exemple "j'ai un trauma à la jambe, je vais moins vite", "j'ai un trauma à la tête, je lance mes sorts plus lentement".
Ces exemples sont purement illustratifs, comme le système est en place et est fonctionnel, c'est à Ben de décider quel trauma fait quoi selon d'autres paramètres comme la race/la classe/la zone, etc... Un trauma à la jambes n'est pas forcément synonyme de "vitesse réduite", même si c'est ce à quoi on pense logiquement en premier.

- Les knock-back sont fonctionnels.
- Les "téléportes" sont fonctionnels : pas ceux de voyage, il donne l'exemple d'un sort du stone healeur qui peut inter-changer de place avec une pierre qu'il a lancé au sol.
- Les statistique de "physique" sont en place : vitesse / masse / accélération / virage, et donc peuvent être buff/debuff.


Là ça parle de technique :
En gros ils parlent du fait qu'avant la re-abilitation, les choses étaient codé (en gros comme gravé dans le marbre), alors qu'aujourd'hui les choses sont scriptés (plus "dynamiques").
L'avantage, c'est que le système n'a pas à allé chercher un truc pour le recopier et le re"calculer", ya juste à piocher les script et les ajouter aux évènements, et ces scriptés sont modifiables "à la volé" par les designer.

Exemple plus concret : avant une arme "A" faisait "X" dégâts et à chaque "influence" de l'environnement il fallait recalculer l'item. Maintenant tout est scriptable et c'est plus facile/rapide/léger avec le système en place de faire du genre "le jour du mois, fois cb de méchant autour de moi, fois 0.7, moins cb de blessure j'ai, par rapport aux boons que j'ai, pendant la nuit, etc....".

Retour sur les nodes / composants :
- Les "périodiques" sont en place et fonctionels : les DoT, HoT, n'importe quel autre événement périodique.

- Les ressources sont en place et fonctionnels : blood /stamina / leur coût aussi / leur regen/dégen.

- Les pierres du stone healeur ont un barre de vie. Pas de certitude sur le fait qu'elles soient "ciblable" mais sont "détruisable" par des zone d'effet par exemple.
Annecdote : au moment où la pierre se transforme de projectile à "kinétique", c'est en fait un item qui sort du sol, et comme pour le moment sous le "niveau 0" du jeu les "choses" meurent, une fois complètement sorti du sol, la pierre se retrouve avec une barre de vie entamée.

Les "conditionnels"
- La pénétration d'armure.
Exemple : je veux faire un coup perforant (piercing/slashing/blunt à la DAoC pour référence) à un mec, mais son niveau d'armure est plus élevé que mon niveau de pénétration, du coup je lui fait un dégat contondant à la place.

Les "requis"
- Tu peux utiliser ce sort que si t'as X stamina/blood
- Tu peux utiliser ce skill que si t'as une épée.
- Tu peux utiliser ce skill que si c'est l'Hiver.
etc...

Les "requête spéciales"
- Affecte toutes les personnes qui sont dans un cube / une sphère / un cone autour de toi ou de qqch d'autre (les pierre du stone healer par exemple)

Illustration de la complexité du système dans son ensemble toujours avec le stone healeur : "Lance un projectile qui créé un kinématic qui pose une barre de vie sur lui-même et un buff sur lui-même qui fait un AoE "requête spéciale" qui heal tout le monde dans cette zone, périodiquement.

- Les spécificités de groupe sont en place (rappel, on parle pas du système de groupe lui-même, mais de tout ce qui s'en rapporte lors d'événements : heal de groupe, buff de groupe, concidionnels de groupe, requête spéciales de groupe, etc...).

- Les filtres
Par exemple : "Affecte toute les personnes autour de moi qui ne sont que dans mon groupe / ou les "alliés" et fait des dégats aux ennemis".

- Les stats des armes.
Temps de Préparation et Recovery / dégat primaire, dégat de "recours"/"rechange" (au cas où l'arme échoue sa pénétration), valeurs de dégat.
Les requis pour utiliser une arme (ex: il faut 20 en force pour utiliser cette arme).

- Le système de déviation
Périodiquement une arme ou un bouclier va dévier une attaque en réduisant la puissance d'une attaque ou/et les dégats d'une attaque (ça sera expliquer plus profondément dans un prochain stream).

- Les "coefficient"
Fait X% de dégat de ton arme avec cette attaque.

- Les "entités"
Tous les "composants d'entités" sont disponibles et prêt à etre intégrer comme par exemple, si Ben le voulait il pourrait donner à un projectile de la vie, une faction, en faire un membre d'un grp, lui donner un inventaire... etc...

- Les logs de combats sont en place
- Les log de débogage sont en place (un combat log avancé en gros)
Les timeurs, prép, recov, coûts, etc..

- Le "circuitage des aptitude" (Skill tracking ?) dans le sens "mettre sur des rails/sur un fil continue")
En gros ils veulent donner aux joueurs la possibilité de lancer plusieurs aptitudes en meme temps à condition qu'elles ne fasse pas partie de la même "catégorie".
Par exemple : un personnage avec une épée une main et un bouclier pourrait utiliser les deux au meme moment, mais un personnage avec une épée à deux main bloquerait ses 2 bras/main et donc ne pourrait pas les utiliser, mais si il est un skald / ménestrel ou barde il pourrait chanter en meme temps, etc...
Du coup le premier fil/circuit pourrait être la main droite, le deuxième la main gauche et le troisième la voix.
Tant qu'une aptitude est utilisé dans un fil/circuit "#1" un autre peut etre lancé sur un circuit "#2" à condition qu'il en fasse parti. (l'exemple des armes 1h / 2h est plus parlant )

- Les "limitations" pas encore completé
Tu peux pas buff ta vitesse de déplacement négativement.
Tu peux pas buff tes dégat négativement pour qu'il deviennent des heal du coup..etc..

- Les interruption et stabilité
Est-ce que cette chose est interrompue par le mouvement...
Combien d’interruption par mètres..

- Les nodes de ressources (crafting) sont proches d'être implémenté.

Work In Progress :
- Banes and Boons
- Les spécificités du gameplay des archers ne sont pas terminé au niveau du bandage de l'arc, du tir, etc.. notamment les animations (mais certains composants sont là). (pas bien compris cette partie).
- Les "cap" (empilage d'effets), ou comment de nouveaux effets (buff/debuff) interagissent avec ceux déjà en place.
- Les stances (posture, particulièrement les tanks ?)
- Les armes de sieges. Pour lesquels ils veulent leur donner des skills propres.
- Le système de progression et le déblocage de nouveaux composants/parties..
- Les effets sonores / visuels / animations.
- L'encombrement due à l'équipement & l'inventaire.

Le "Layer Arithmetic Expression"LAE" :
Qui permet en gros d'encapsuler des statistique pour facilité/accélérer/désencombrer le calcul. A l'image de "calque" qui se superposent. Ainsi, aucun reel ordre de calcul n'est pas reellement impératif entre l'amont et l'aval. Comme pour les calques (grosso merdo hein, c'est pas forcément vrai ^^) peut importe l'ordre dans lequel vous les superposés, le résultat donne la même chose.

Dans le jeu, avant de pouvoir savoir "Quel dégât cette chose fait", entrent en interaction tout un tas de paramètres qu'il faut prendre en compte dans la grande "équation" qui calcul les dégâts finaux.
Par exemple : Cette arme possède des statistiques qu'il faut extraire, Les modificateurs de ce skill possèdent des statistiques qu'il faut extraire, A-t-on des Buffs / Debuffs que notre personnage possède ? Puis ça va sur le personnage qui est ciblées qui lui-même à des Buffs et Debuffs, de l'armure, de la déviation, etc..etc...
Tout ça arrive dans un ordre spécifique.

L'idée générale est de simplifier ce procédé et de faire en sorte que, quelque soit l'ordre de ces expressions dans la grande équation, le résultat soit toujours le même.

Le système fonctionne à base de Calques (Layer) qui font de l'arithmétique (Arithmetic). Chaque calque est indépendant et est remonté à chaque étape du calcul selon les données extraites (vraiment pas sûr de la trad là). Le fait qu'ils soit ainsi indépendant permet de réduire en théorie les chances de bug, mais aussi d'ajouter des expressions particulière, comme, soudainement, maintenant les phases de Lune influence cette expression en particulier, etc...

Par exemple, en prenant un personnage avec armure ciblé par un dégât quelconque, les claques illustrent même la logique "physique" du procédé. D'abord le calque de "pré-armure" qui représente les buff et débuffs ou effets magiques qui sont appliqué sur votre personnage, ses effets réduisent ou amplifient les dégâts reçu et transféré au calque suivant qui est le calque d'armure. Ce calque reçoit donc un chiffre de dégât déjà modifié par le calque pré-armure, à qui il va donc ajouter toute les caractéristiques propres à l'armure elle-même, qui peut d'ailleurs recevoir des buff et des débuffs aussi, puis ça arrive au calque du personnage où les dégâts sont encore modifiés en fonction des caractèristiques propre comme les stats primaire/secondaires/dérivées, les boons et les banes, etc...

Note de moi-même : Ça contre-dit en partie ce que Rob dit sur la non-importance de l'ordre du calcul. Ou j'ai pas capté un truc. Mais juste après Marc insiste sur le fait que cette indépendance d'ordre de calculation est très important dans la flexibilité générale du système.



Q&A

- Avec toutes ces aptitudes finalisées pour la Beta1, les animations sont-elles prêtes à être connectées ?
TIM : La plupart de nos animations sont prêtes pour la plupart de nos collections d'animations. Une "collection d'animation" est ce qui représente l'ensemble des animations pour une arme spécifique par exemple. Toutes les animations relatives aux épées 2mains, au bouclier, etc...
Rien n'est encore fait, mais techniquement tout est en place pour que les animations une fois prêtes soient "raccordées" aux aptitudes.
C'est la prochaine grosse étape de tout cette "re-abilitation".

- Avec les "Kinematic", peut-on écraser un joueur contre un toit si l'on invoque une pierre en-dessous d'eux ? Faisant des dégâts au joueur...
ROB : Non, la physique de l'écrasement n'existe pas pour le moment, mais l'effet pourrait être un changement dans la vitesse du joueur.

- Le fait d'avoir autant de ces calculs dynamiques à-la-volé (JIT scripts : Just In Time compilation) n'implique-t-il pas des coûts significatifs en terme de performance ?
MOI (résumé*) : Non, pas du tout.
TIM : L'impacte se fait sentir un peu au moment où le personnage apparaît pour la première fois dans le monde, après ça tout est comparable à du code C# classique.

- Le système d'aptitude est-il construit de sorte que, si un Dev veut ajouter une nouvelle feature comme le Combat Navale dans un extension, il soit plus facile de le faire ? (en tout cas les aptitudes en rapport à cette feature).
TIM : Le système est construit comme un moteur extensible avec lequel il est possible de faire des multitudes d'extensions, de prototypes, etc..
MARC : Faut bien comprendre* que le système que nous avons mis en place est totalement détaché du "code-coeur" du jeu ce qui implique qu'on peut ajouter tout plein de chose très facilement sans influencer le code-coeur lui-même.
Les 4 : C'est totalement flexible.

- Comment est-ce que les rendements décroissants fonctionneront avec le nouveau système ?
BEN : Il n'en existe pas. Le problème est plutôt gérer de façon à ce que par exemple un sort de ralentissement de 75% sur une personne fera toujours 75% de ralentissements, mais ce qui va empêcher que cette personne soit ralentie de façon permanente vont être les cooldowns, les coût en ressources, et au-dessus de ça il y a aussi les immunités et les "cures" / "removales" / "cleanses".
Les discutions dans l'équipes sur ce sujet sont toujours en cours mais Ben insiste sur le fait qu'il n'en est pas fan et qu'il préfère jouer avec des mécaniques moins directes qui approfondissent le gameplay général.
Par contre un système de timer d'immunité pourrait exister.

- A propos des "transferts terrestres", en tant que StoneHealer, si je lance une pierre et qu'ensuite je me transfert à sa place pendant qu'elle est encore à mi-parcours, vais-je continuer le chemin de vole que la pierre avait ou ma masse va-t-elle influencer ce chemin de vole (ou la pierre sort-elle simplement du sol) ?
TIM : Pour le moment ce que ça ferait maintenant au stade de développement actuel : Le StoneHealer bouge à la place de la pierre avec sa propre physique et vitesse, et la pierre bouge à la place du StoneHealer avec sa propre physique et vitesse. Du coup : si le StoneHealeur était immobile à ce moment, il apparaîtra à la place du la pierre lancée à mi-parcours et tomberait en ligne droite, tandis-que la pierre elle apparaîtra à la place du StoneHealer et continuerait l'arc de sa course.

- Le système de partie du corps va-t-il changé ? Le but est-il à terme de séparer les parties gauche et droite (jambe/bras). Aussi, le torse sera-t-il toujours la partie du corps ciblée par défaut ou cela va-t-il devenir aléatoire ?
BEN : Le torse est la partie du corps par défaut. Tout ce que le jouer ne désigne pas spécifiquement comme cible sera toujours le torse.
En ce qui concerne Gauche ou Droite c'est quelque chose qu'on aimerait implémenter pour dépendre du positionnement, ce qu'on a pas encore implémenté.

- La capacité d'encombrement va-t-il influencer la distance sur laquelle un personnage va être poussé ? Si je porte beaucoup de chose, je serais poussé sur une plus courte distance.
BEN : l'encombrement non, mais la masse oui. Et l'encombrement influence la masse.
MOI : donc oui.*

- Allez-vous limiter le montant des type de DoT (Damage over Time = Dégâts sur le Temps) qu'un jouer peut avoir sur lui ?
MOI* : D'après ce que j'ai capté la réponse résumée est : NON.
Mais Ben explique que les type de dégâts sont en réalité catégorisés par type d'effet. Si sur un joueur 3 DoT sont lancés, il n'a en réalité qu'en effet "DoT" dont les dégâts augmentent et grossisssent à mesure que d'autres DoT lui sont appliqués. Si un healeur utilise un sort qui cure les DoT, une partie des dégâts de ce type d'effet diminuera mais l'effet globale ne sera pas "cure-é" / ne disparaîtra pas.

- Au moment de lancer un sort, le fait d'être stun(étourdit) ré-initialise-t-il le cooldown du sort ?
BEN : Oui. Si la durée du stun est plus court que le cooldown du sort lancé, il faudra attendre, le cooldown est déclenché. Si la durée du stun est plus longue que le cooldown du sort lancé, évidement, le sort est sorti de son cooldown et pourra être lancé.

Discussion à propos de cette mécanique :
Un "lancé de sort" se décompose en plusieurs "timers".
- Le préparation timer. (pour l'exemple ci-après : 1seconde)
- Le recovery timer. (pour l'exemple ci-après : 1s)
- Le cooldown timer. (pour l'exemple ci-après : 5s)
D'après ce que j'ai capté donc

C'est pas très clair dans ce que Ben dit parce qu'il parle de "then" comme si le cooldown se déclenchait après le préparation time. Bref, si qqun peut préciser.

En plus des timer, un sort à une barre de vie de stabilité.
Et les attaques ont toutes des dégâts "bruts" appliqués au personnage ciblé, mais aussi des dégâts d'interruptions appliqué à cette fameuse barre de vie de stabilité. Si cette dernière arrive à 0, le sort est annulée et doit être relancé de zéro.

Plus tard dans le développement Ben explique qu'il pourra être ajouté des particularités à certains sorts qui sont interrompus. Il prend l'exemple d'une boule de feu qui est interrompue, au lieu de simplement annulée le sort, la boule de feu en préparation pourrait très bien exploser dans les mains du lanceur. Il y aura donc certains sorts très puissants dont on ne voudrait absolument pas qu'ils soient interrompus.

- Avec ce nouveau système d'aptitude, il semble plus aisé de pister les bug par rapport à avant, est-ce correcte ?
Oui.
Plus facile d'implémenter aussi.
La log-abilisation du système est très facile et permet un traçage de ce qui se passe bien plus aisé.
Le système a été construit avec ce soucis en tête.

- Nous avons vu une variété de sorts de mur, peut-on changer / façonner (via les modificateurs je suppose*) leur hauteur et largeur ?
TIM : C'est possible dés maintenant.
BEN : Les murs font partis des "kinématiques", faudra juste qu'on ajoute un élément visuel dessus. Ce n'est cependant pas une priorité pour nous car ces sorts font partis des aptitudes de mages, et ils ne sont pas prévu pour la Beta1. Mais les mages auront la possibilité de faire bien plus de chose d'aire / de zone persistants et truc comme ça, comme les murs qu'ils pouvaient avant. Donc nous implémenteront bien plus de choses folles du même type une fois que nous nous pencheront sur l'implémentation des classes de mage et que nous pousserons le système d'aptitude encore plus loin que ce que nous pouvons faire pour le moment.

- Les Contrôles de Foules (CC = Croud Control) seront-ils attachés aux calques (voir LAE système) ? Pouvez-vous dire en quoi les rendements décroissants entreront en jeu dans tout ça ? (pas sûr de la traduction*)
MOI (résumé*) : Il n'existe pas de claques "spécifiques" aux CC. Dans la "chaîne de calcul" certaines caractéristiques influeront sur l'effet du CC en bout de chaîne.
Par exemple si un Boon de resistance au Froid entre en jeu, le résultera donnera une réduction de l'importance du ralentissement/des dégâts, mais si en cours de route d'autres buff/debuff sont cumulés au Boon, le résultat changera "en cours de calcul" pour donner un résultat encore inférieur à ce qu'il aurait été si le Boon uniquement avait été pris en compte.

- Est-il possible grâce a ce système de script (LAE* je suppose) de mettre à jour sans maintenance ?
MOI* : Pas compris, mais à priori, à terme : Oui.

- Les CC seront-ils directement connecté via les aptitudes ou seront-ils pour la plupart par les "traumatismes" ?
TIM : Il n'existe pas tant de CC via traumatisme que ça.
BEN : Ça dépend de ce que tu appelles "CC". Si tout ce qui affecte négativement les performances de ton personnage est un CC, comme : "est-ce que la réduction de la vitesse de déplacement est un CC ?", alors oui, en quelque sorte. Parce que ça contrôle la capacité d'un personnage à bouger, et si il est blessé à la jambe, il bougera plus lentement. Est-ce que perdre de la vitesse d'attaque en ayant une blessure au bras est un CC ? Hum... pas si évident.
Les traumatismes disparaissent le moment où la blessure est guéries.

Ensuite blablatage sur les CCs en général.
MOI* : En gros la vision catégorique de celui qui pose la question de s'applique pas réellement avec le système prévu dans CU. Il existera des CC "natifs" ou plutôt, je dirais "directes", provenant de certaine classes (comme le mezz d'un barde de DAoC) et des CC "indirectes" provenant des blessures qui induisent des traumatismes.
BEN précise que dans son design de class, il est bien plus favorable à des slows par exemple opposés à des roots, ou à une réduction de la vitesse d'attaque opposée à des choses comme des sorts de désarmement ou de silence, de façon à ce que le joueur subisse des pénalités plutôt qu'une mise "hors-jeu" totale.
TIM ajoute qu'il pourrait être intéressant par contre d'avoir un silence qui s'appliquerait qu'à un fil/circuit spécifique (voir "Traçage de skill" plus haut).

- Dans le meilleure / pire des cas, quel pourrait être le scénario que vous envisagez d'un One-Shot ?
BEN : Pour le moment l'importance d'un coup que peut recevoir un personnage sans armure représente jusqu'à a peu prêt un quart de sa barre de vie. Mais un personnage avec une armure peut avoir un buff d'une réduction de 75% des dégâts. Donc si on prend en compte l'armure, plus les buffs, plus les boons, les heals et tout ça, ça devrait vraiment réduire significativement les dégâts reçus. Donc je ne pense pas à l'heure actuelle qu'il existe un scénario dans lequel un personnage puisse être One-Shot par une aptitude unique. Si un personnage portant une armure légère se retrouve dans la melée focus par tout le monde, il va mourrir très rapidement, mais ça sera toujours le cas de toute façon.

- Qu'est-ce que vous préférez dans le nouveau système actuellement, et dans ce qui est encore à y ajouter ?
ROB : Le fait de scripter, parce que j'ai tellement peu de scriptage à faire.
MARC : La façon dont nous avons prototypé le système au jour le jour et le fait qu'on puisse maintenant produire en 30 minutes l'équivalent d'une demi-journée de travail avant. C'est bien plus rapide.
BEN : Je le répète mais, nous n'avons pas vraiment changé le design de base du jeu avec cette ré-écriture, simplement simplifié la technique. Comme Marc, pour moi, c'est la vitesse à laquelle nous créons maintenant les choses, même pour le calibrage et le partage dans la chaîne de production entre les Developpeurs de l'équipe.
TIM : J'ai fais bcp de prototypage avec ce système et j'aime vraiment les petites et rapides itérations. Mais pas seulement à propos de la vitesse. J'ai vu, à mesure que le système à muri, une fois qu'on eu des choses comme le scriptage et le LAE, il y a eu quelques soucis qui avaient besoin de gros "re-façonnage" mais une fois traversé ces problèmes, pour des ajouts d'autres fonctionnalités spécifiques, il était bien plus facile de les implémentés sans avoir à ré-inventer toute la matrice autour. Donc pas seulement la vitesse mais aussi le cadre de ces itérations ont pu être amélioré. Ce qui permet ainsi, que plusieurs personnes peuvent très bien travailler sur plusieurs choses en même temps sans qu'ils se marchent les uns les autres sur les pieds. Ca a permis un esprit et un travail d'équipe renforcé au lieu d'une gène.

Edit 1 : mise en forme.
Edit 2 : ajout du Q&A.
Edit 3 : dernière question traduite.

[Aeodo]

Citation :

Publié par Cleanse

Banes and boons

Depuis le temps, ça prouve que Ben n'en fait pas du tout une priorité, même si annoncés comme une feature phare du jeu.

Citation :

Publié par Cleanse

Les armes de siège. Pour lesquelles ils veulent donner des skills propres.

Genre donner aux artisans des compétences pour les utiliser ou associer des compétences propres à chaque arme (exemple avec une catapulte : choix du projectile, charger, tirer)?

[Gorthor]

Merci pour ce compte rendu pleins de choses intéressantes du coup a voir sur le terrain.

[Gwanelle]

Citation :

Publié par Cleanse

- Ils vont éviter que dans CU existent des "animation cancel" (un truc de gameur "hardcore pro" comme dans BDO par exemple) qui est souvent utilisé pour enchainer des aptitudes qui sont normalement pas censé être "cyclées" comme ça. En gros le gameplay n'est pas dicté par les animations, mais les animations sont dictées par le gameplay. Si ça a un sens pour qqun -_-.

C'est LE truc essentiel sans quoi tout le système s'écroulerait , dans tout système inspiré de ryzom à quoi celà servirait (par exemple) de mettre un composant réduisant le tps d'incantation si de toute manière il dépendrait de l'anim . Surtout que CU à l'air d'aller bien plus loin dans les possibilités offertes que ryzom .

Citation :

Publié par Aeodo

Depuis le temps, ça prouve que Ben n'en fait pas du tout une priorité, même si annoncés comme une feature phare du jeu.

je pense que l'ordre dans lequel les choses sont faisables n'a pas de rapport avec la priorité . implémenter et tester des bonus tant que tout sur quoi s'appliqueront ces bonus n'est pas encore fait c'est difficile .

[Cleanse]

Edit 2 : Ajout de la partie Q&A (manque la dernière question, mais je fais une pause. )

[Cleanse]

Citation :

Publié par Aeodo

Genre donner aux artisans des compétences pour les utiliser ou associer des compétences propres à chaque arme (exemple avec une catapulte : choix du projectile, charger, tirer)?

Une très bonne question à poser lors d'un Q&A du vendredi.
Comme moi je l'ai compris : donner aux crafteurs la possibilité de créer les aptitudes des catapultes, et ainsi les "typer" / "spécialiser" : genre un CrafteurA vend des catapulte spécialisée "Froid" un autre CrafteurB vend des catapultes de "Lave", un 3e des catapulte d'AoE ou de dégâts physique contondant, etc...

Citation :

Publié par Gorthor

Merci pour ce compte rendu pleins de choses intéressantes du coup a voir sur le terrain.

Avec plaisir. <3

Citation :

Publié par Gwanelle

C'est LE truc essentiel sans quoi tout le système s'écroulerait , dans tout système inspiré de ryzom à quoi celà servirait (par exemple) de mettre un composant réduisant le tps d'incantation si de toute manière il dépendrait de l'anim . Surtout que CU à l'air d'aller bien plus loin dans les possibilités offertes que ryzom .

Comme moi je l'ai saisie par rapport à ce que tu dis, réduite le temps d'incantation d'un sort est possible, il suffit que l'animation "attachée" à une aptitude ai un "node" multiplicateur dans ses caractéristique. L'animation sera alors accélérée en rapport au modificateur choisi par le joueur.
Mais ce dont on parle ici, n'est pas vraiment lié à la fabrication de sort pure, c'est une mécanique d'ensemble qui existe dans bcp de jeu, une sorte de "faille tolérée" qui permet de manipuler les animations des personnage pour réduire l'espacement de l'enchaînement des aptitudes d'une classe. En gros c'est un exploit bug toléré qui est souvent détecté par certains gamer "hardcore", qui ont le temps de les remarquer et qui ont "l’œil" pour les détecter.

Personnellement j'espère bien qu'ils donneront la possibilité aux joueur de réduire ou même augmenter le temps de cast d'un sort même si ça revient à accepter de fait une contre partie (ou bonus pour l'augmentation). Comme dans mon exemple, je vois bien la contre-partie d'un sort plus facilement "interrompable" pour la réduction. On peut imaginer à côté une augmentation de la puissance des dégat pour un allongement du temps de cast.

[Cleanse]

Edit 3 : ajout dernière question.

Message supprimé par son auteur.

[Parseis]

merci Cleanse!

[guedgued]

Sacré taf quand même
Merci à toi même si certaines choses sont pas mal floues mais c'est pas de ta faute

[Cleanse]

Citation :

Publié par guedgued

Sacré taf quand même
Merci à toi même si certaines choses sont pas mal floues mais c'est pas de ta faute

Merci.
Hésite pas à poser des questions, autant pour le Q&A c'est à 95% de la traduction, autant pour la première partie il y a une grosse part d'interprétation (80%).

Donc le Q&A je doute qu'il contienne de grosses erreurs.
Par contre la première partie peut en avoir, et j'invite ceux qui l'ont remarqué à le dire ici, n'hésitez pas à préciser ou m'interpeller sur une partie que j'aurais mal compris.

[Clark]

Merci d'avoir pris le temps. C'est une lecture intéressante.

[Bloodkissou]

Super compte rendu que tu nous as fait là Cleanse, un grand merci !

Bon ben y avait longtemps qu on avait pas eu des trucs intéressants liés au gameplay à lire, ça fait plaisir.
je sais pas si c'est une fausse vision de ma part, mais les Stonehealer, ça va être très technique à jouer ! Mais bon je suppose que les 2 Heals "equivalents" auront un gameplay plus ou moins aussi technique ?

[Arnfiarnunn Neanias]

Merci pour le résumé, j'avais un peu la flemme de tout écouter! ^^

Citation :

Publié par Bloodkissou

Super compte rendu que tu nous as fait là Cleanse, un grand merci !

Bon ben y avait longtemps qu on avait pas eu des trucs intéressants liés au gameplay à lire, ça fait plaisir.
je sais pas si c'est une fausse vision de ma part, mais les Stonehealer, ça va être très technique à jouer ! Mais bon je suppose que les 2 Heals "equivalents" auront un gameplay plus ou moins aussi technique ?

L'Empathe devrait être potentiellement surpuissant si joué avec courage.
LE physician quant à lui semble beaucoup plus classique à moins qu'on nous garde une surprise.

[Shachi]

+1 merci beaucoup Cleanse et je suis pressé de voir cela ingame !!

Ce n'était pas le sujet mais dommage qu'il n'ait pas donné d'eta pour la beta 1 ...

[Cleanse]

Il y a des tests en ce moment, mais, c'est pas très convaincant. Par exemple pour l'Empath, il manque certain composant pour certains sort et les Cure ne fonctionnent. Meme lorsqu'une partie du corps est spécifié, c'est encore buggé.
Bref...

Merci sinon.

Et pour un ETA dela Beta1, en fait, il y en a bien un : "Quand ils seront prêt."
Andrew laisse sa barbe pousser tant que la Beta1 n'est pas 100% parfaite comme il le veut.
Donc si un jour on le voit rasé sur le stream, et qu'il n'ont encore rien annoncé, on pourra se dire que c'est bon !

Après bon, pour moi, la Beta1 yen a pas avant 2017.

[Scrooge McDuck]

Merci Cleanse pour ce gros boulot

[Aeodo]

Dieu merci ils ont arrêté de donner des ETA.

[algweln-thorum]

Citation :

Publié par Bloodkissou

Super compte rendu que tu nous as fait là Cleanse, un grand merci !

Bon ben y avait longtemps qu on avait pas eu des trucs intéressants liés au gameplay à lire, ça fait plaisir.
je sais pas si c'est une fausse vision de ma part, mais les Stonehealer, ça va être très technique à jouer ! Mais bon je suppose que les 2 Heals "equivalents" auront un gameplay plus ou moins aussi technique ?

pour ces classes de healers, j'ai l'impression que MJ a voulu proposer 3 gameplay aux joueurs soigneurs dans l'âme, là où la plupart des autres MMOs voit le soins comme une action plutôt réduite dans sa manifestation.

le stonehealer, avec ses pierres, se jouera comme un "ground controller", en truffant l'aire de jeu de pierre à zone d'effet, lui permettant de permuter avec l'une ou l'autre, pour des déplacements instantanés, et ainsi attendre la périphérie de son périmètre d'action, très mobile, diffusant du soins sur la durée, plus que de l'instant heal; il devra placer ses pierres rapidement dès le début du combat, quitte à overheal au départ, et anticiper les déplacements du combat éventuels.

le physician, lui, fonctionnera plus comme un "bolt mage", lançant ses potions, pour attendre ses patients. placé en retrait du groupe, sur leurs arrières, pour éviter les interruptions, mais surtout les interceptions de ses projectiles, par l'ennemi, pour ne pas soigner l'adversaire.Il sera plus certainement sur du gros instant heal et du "HOT" mono-cible.

L'empathe, quand a lui, se jouera probablement comme un "soigneur de contact", il sera plus au milieu de son groupe, au plus prés des combats; gérant son propre pool de vie, et donc par extension celle de son groupe, en "leechant" de quoi ce régénérer sur les cibles de ses patients.

de ce fait, les soigneurs auront pour une fois, un vrai choix de gameplay à faire, en fonction de leur confort/ habitudes de jeu, au moins aussi important que le feeling de la faction.

[Cleanse]

C'est marrant, je ne vois pas du tout l'Empath comme tu le décris.
Je le voit plus comme un Healeur classique qui a ses ressources basics à gérer + sa propre barre de vie.
Etant donné qu'il s'inflige des dégât lui-même en guérissant les autres, je le voit mal close combat et risquer de se prendre des dégâts + les dégât provenant de ses heals.

Sinon, oui, sans aller aussi loin que algweln-thorum, les classes de heal vont être assez technique à jouer, et c'est extrêmement intéressant. J'ai vraiment très hâte de test l'Empath une fois "terminé", sans doute pour ça que je desespère aussi rapidement sur l'avancement du jeu en général. :/

[algweln-thorum]

c'est justement parce que sa barre de vie fera de grand yoyo, qu'il ne pourra pas s'éloigner de son groupe, au risque d'être pris isolé par un furtif, juste après un heal couteux.

De plus, lorsque je vois le "death curse" de l'empath (exploit pain), il lui faut mourir au plus près de son groupe, pour que tous les membres de son groupe en bénéficie.

Après, ça va dépendre grandement de la portée de ses sorts.

[Cleanse]

Heu, c'est un peu antagoniste ce que tu dis.
Qu'il soit à l'arrière ou dans la mêlée ou entre les deux, il va de toute façon se faire focus, et le fait que sa barre de vie fasse du yoyo n'augmente pas plus ou moins ses chances de mourir plus vite dans l'une ou l'autre de ces positions.
Il y a aussi des spéculations sur le fait qu'il pourrait avoir un sort de grappin pour sortir ses alliés ou membre de groupe d'une mêlée.

Du coup voilà, je pense que ça sert à rien de spéculer de toute façon sur des positionnement alors qu'on ne connait pas encore les sorts et leur personnalisation.

Par contre le Blessed Crow, là, oui. Je le vois plus dans la mêlée ou très légèrement en arrière, mais c'est un hybride, pas du tout l'Empath.

[algweln-thorum]

si il se fait focus, cela signifie que ces coéquipiers ne subissent pas de dégâts, donc, sa barre de vie ne subira pas l'effet de yoyo de ses soins, mieux, en lançant un soin sur un coéquipier full life, l'empathe se soigne.Donc, il a tout intérêt à rester proche de son groupe.

au milieu de son groupe, ses alliés peuvent interrupt/intercepter des coups qui lui sont destinés. si il est hors de la mêlée, isolé; pas d'alliés pour le faire; ces coéquipiers sont alors les cibles, il devra focaliser sur leurs barres de vie, probablement enchaîner plusieurs soins, sans pouvoir régène sa vie via un coéquipier full life (hors de portée ou masqué au milieu d'autres alliés blessés/ennemis et donc in-ciblable pour son régén), de plus les fufus ayant des attaques basées en grande partie sur l'interruption pourrait rapidement l'empêcher de heal efficacement son groupe, et de se régénérer.

De plus, n'oublie pas qu'il peut utiliser "le simulacrum" pour créer un double de lui, une sorte de leurre, qui prodigue certains sorts/effets de même type que les alliés qui l'entoure.

EN gros, soit l'empathe est la cible du focus, et il a tout intérêt à rester au milieu de ses coéquipiers pour qu'ils le débarassent de ses assaillants; soit ce sont ces coéquipiers qui sont les cibles, et il doit rester à proximité pour pouvoir les cibler que se soit pour les soigner, comme pour se régénérer sur un coéquipier full life.

autre élément à prendre en compte , le schéma de bataille idéale pour les tuathas qui semble se détacher des différents skills vu lors des présentations de classes, apparait être le "hit and run". frappe et repli, une mécanique très mobile, vive à changer de direction, du coup, l'empath ne peut pas prendre le risque d'être trop statique ou éloigné, au risque de ce retrouver hors de portée de heal.

mais tu as raison, il est encore un peu tôt pourdébattre de cela, étant donné que les skills communiqué pour le moment sur les classes, ne sont pas assurées de figurer au final à la release telles quelles .

[Cleanse]

Qui te dit que s'il se fait focus, il n'aura personne d'autre à heal ? Et les AoEs ? Et les mages isolés qui se feraient attaquer par des assassins ? Et l'autre membre du groupe assassin qui "a raté son backstab" et doit fuir pour se recamoufler ? Etc ...

S'il faut ne pas être en dehors de la mêlée, je plein les mages. Même si eux n'ont pas leur barre de vie qui fait le yoyo, il sont théoriquement plus fragile encore qu'un Empath. Du coup ça veut rien dire.

Bref, je m'arrête là, tu fais des projections assez précises, trop précises, sur le gameplay sans qu'on est la moindre idée de celui-ci globalement. Les distances, les proportions, les rôles, les synergies, etc.., etc..., sont encore inconnus.

Tu vas même jusqu'à dire que les TDD auraient un gameplay global de hit&run, en te contre-disant encore, puisqu'à priori, ce genre de gameplay demande d'avoir du poke, et donc de la distance.

Bref, tu vas beaucoup trop loin.

[Arnfiarnunn Neanias]

Surtout que les classes mêlées TDD y'en a pas énormément...