FR EN ES PT
Naviguer dans les forums 
Trackers Ankama

Accessibilité des sorts, contenu textuel

Par ugalo 24 Juin 2020 - 10:32:29
AnkaTracker

Bonjour par ici,

Je suis en ce moment en train de faire un petit outil de builder en C++ et pour le moment j'ai réussi à faire un peu tout ce que je voulais avec les données proposées par Ankama via les fichiers Json.

Cependant j'en suis arrivé à un point où j'aimerai bien ajouter tout ce qui est passif et sorts (une simple description des effets de manière textuel, avec l'icon, pas plus, je compte régler au cas pas cas si il y a un impact sur les statistiques) cependant rien n'est à dispo niveau Json.

Du coup, je n'ai pas trop d'autre solution que de récupérer tout 1 à 1 sur l'encyclopédie pour le moment.
Sauf que à la moindre MàJ qui impact les effets des sorts, faut tout revoir.
Donc est il dans les projets d'Ankama de mettre à disposition ce genre d'information ?

Merci d'avance !

Mankio

0 0
Première intervention Ankama

Salut,

Pour ce qui est des traductions, sans les effets, des sorts de classe, c'est envisageable à court ou moyen terme.

Pour ce qui est des effets, une réponse en anglais est disponible ici, il n'est en l'état pas envisageable de les partager.

[Enio].

Voir le message dans son contexte
Réactions 4

Salut,

Pour ce qui est des traductions, sans les effets, des sorts de classe, c'est envisageable à court ou moyen terme.

Pour ce qui est des effets, une réponse en anglais est disponible ici, il n'est en l'état pas envisageable de les partager.

[Enio].

Score : 291

Merci pour la réponse [Enio]

Même une simple description de chaque ligne d'effet de la même manière que les effets des items n'est pas envisageable ? Typiquement par sort, un tableau de locales + lot de paramètre pour évaluer les valeurs numériques en fonction du niveau ?

Merci dans tous les cas du boulot fournis pour la création de cette API !

Mankio

0 0

Justement, le système de critères pose souci de ce côté là.

Par exemple, un sort modifié par un passif peut typiquement avoir :

- Groupe d'effet + critère "N'a pas le passif Machin"
-- Effet 1 + critère "A l'état Chouette"
-- Effet 2 + critère "N'a pas l'état Chouette"
- Groupe d'effet + critère "A le passif machin"
-- Effet 1 + critère "A l'état Chouette"
-- Effet 2 + critère "N'a pas l'état Chouette"

Ceci étant un exemple simple, mais on peut trouver certaines saisies sur des mécaniques complexes où on parle de critères de plus de 8 membres. Et nous approchons des 500 critères différents (sans compter leurs variantes de paramètres).
_____
[appartéCritères]

J'en profite pour expliciter un peu plus la problématique des critères de façon générale par rapport aux données que nous voulons/pouvons vous exposer. Un exemple de critère pris au hasard sur un effet (et nombres modifiés au cas où ce soit un critère sensible) : IsTargetCellFree(True) and GetEnnemyCountInRange(1, 6, "target", True) > 0 and GetSpecificEffectAreaCountInRange("target", 1234, 0, 1) < 1 and GetSpecificEffectAreaCountInRange("caster", 1234, -1, -1, True) < 6

GetSpecificEffectAreaCountInRange étant une version plus ciblée de GetEffectAreaCountInRange, leurs paramètres sont identiques mais la mécanique pas exactement. Les paramètres pourraient se représenter de la manière suivante (notation TypeScript parce que ça s'y prête) :
target: string, effectAreaTypeId: number, minRange: number, maxRange: number, ownAreaOnly: boolean = false
Sachant que dans ce cas, target est typé "string" pour la compatibilité avec le parsing, mais revient à "target" ou "quelque chose d'autre et dans ce cas là on met le booléen qui l'utilise à false" 
Sachant que maxRange < 0 permet de compter la zone quelle que soit la distance
Sachant que effectAreaTypeId est utilisée comme un type dans GetEffectAreaCountInRange mais comme un ID de zone spécifique dans GetSpecificEffectAreaCountInRange

GetEnnemyCountInRange est une variante de GetFightersCountInRange, qui lui même a 9 variantes et 6 signatures. Dans ce cas précis, on cherche les ennemis (du caster) de 1 à 6 cases de la cible (qui doit être une case libre, la cible est donc une cellule et pas un personnage/monstre) et qui soient en ligne, mais sans forcément une ligne de vue.

Cet effet ne se jouera donc que s'il est lancé sur une case libre, case qui a au moins un ennemi aligné sans prise en compte de la ligne de vue dans les 6 cases autour, si la zone d'effet 1234 n'est pas présente sur la case ciblée ou sur une case adjacente, si le caster a moins de 6 zones d'effet 1234 présentes sur le terrain

On notera par ailleurs que ce critère n'est pas forcément affiché dans le client, que certains critères ont une traduction et d'autres non, et qu'il existe tout un tas de spécificités de notation pour moduler ce qui est affiché ou ce qui ne l'est pas, et comment il l'est.

[/appartéCritères]
____

Implicitement, si nous fournissons "tel quel" les effets sans les critères, c'est incompréhensible
Ce qui peut à la rigueur être envisageable, c'est de générer les descriptions "Tel qu'en jeu" lors de l'export JSON... mais ça demande un temps conséquent pour faire ça bien, en plus de ne vous fournir qu'une description. Par extension, ça rend très complexe la réalisation de choses telles qu'un calculateur de dégâts, notamment s'il prend en compte la modulation par les passifs, etc.

En l'état, il est plus probable que dans un premier temps on fournisse les traductions des sorts, la classe liée et peut-être quelques informations "de base" (niveau d'évolution/quête à valider, coût/portée de base, en ligne/diagonale, sans ligne de vue, maximum par tour/cible, etc... qui sont pour une partie au moins des données qui peuvent varier selon des critères), mais que les effets restent de côté pour un certains temps encore.

[Enio].

Score : 291

Merci Enio pour la réponse détaillée,

Je saisi un peu mieux la problématique liée aux critères et la difficulté de les traduire en informations compréhensibles et utilisables dans un fichier Json.

Idéalement ce sont les descriptions "Tel qu'en jeu" qui m'intéressent, car un degré de complexité plus élevé est certe intéressant pour faire un calculateur de dégâts complet, mais c'est plus de l'ordre de la simulation que du builder ou même du theorycraft. Donc pour le moment, bien que je trouverai ça super intéressant à faire, je ne compte pas y toucher.

Cependant je me doute que au vu de la complexité de l'architecture derrière, ça ne doit pas être simple à mettre en forme. Donc je serai patient, et je ferai avec ce qu'on me donnera smile

Merci encore du temps que tu nous consacre Enio !

Mankio

0 0
Réagir à ce sujet