Sympas comme analyse, ça sort même de la conception de bot, c'est juste de la théorie sur le jeu. Donc moi je trouve ça cool, et si tu dit dès le début que c'est pas spécialement pour la création de bot, tu as moins de risque face à ankama.
Sinon le format Json est pas mal car il y a déjà des lib pour le parse et il est lisible humainement.
Par contre il faut prendre en compte les résultats de chaque action aléatoire (retraite de pv, de pa, de PM, de %res etc..) sinon tu n'as pas l'état complet du mob et évidemment les actions du mob dépendent de cet état au cours de la partie. Je pense qu'il faut vraiment récolté toutes les infos relative au combat.
Par contre dans le format proposé je pense que la gestion des invocations peut être un peu complexe, il faudrait bien définir tout ça ;)
Edit (oui l'edit est plus long que le message :))
Je présent qu'une proposition pour le format JSON car je le pense préférable.
Du coup, je reprend la proposition de @nowis13 avec mes propositions de changement:
{
"version_log": "0.1",
"version_game": "2.41.26",
"date": 1321231,
"map": [ {
"x": 0, "y": 0,
"walk": true,
"sight": true
}, {
"x": 1, "y": 0,
"walk": false,
"sight": true
}, {
"...": "..."
}
],
"entitys": [ {
"id": 1,
"team": 0,
"position": [3, 5],
"...": "...",
}, {
"id": 2,
"team": 1,
"position": [2, 5],
"...": "...",
} ],
"turns": [ {
"entity" : 1,
"moves": [ {
"action": "move",
"position": [1, 1]
}, {
"action": "attack",
"position": [1, 2],
"effects": [ {
"target": 33,
"pdv" : -500000000,
} ]
}, {
"action": "spell",
"position": [2, 1],
"effects": [ {
"target": 32,
"pdv" : -5,
"PA" : -1
}, {
"target": 31,
"pdv" : -5,
"PA" : -1,
"state": [ {
"name": "un super buff",
"turn_count": 5,
"effect": { }
} ]
} ]
} ]
} ]
}
Concertant la map :
- la placer dans un autre fichier serait peut-être intéressant
- Il faut prendre en compte la ligne de vue je les appels 'sight' (j'ai mis walk a la place de wall pour une raison de logique avec sight, pour qu'un true ai le même sens dans les 2 cas)
- on peut biensur eviter de lister toutes les cellules si on s'y prend bien en ne parlant que des case non marchable par exemple (dans ce cas, wall ou walk a plus d'utilité)
- on pourrait utiliser une position sous la forme d'un tableau plutôt que x, y (c'est souvent plus court et aussi claire et plus consistant)
j'ai renommé players en entitys pour que cela sois plus claire.
- On placera aussi les invocations dedans.
- chaque entity a une id (on peut aussi utiliser la position dans la liste mais c'est pas toujours super)
- tous les entitys présente au debut de la partie ont une position (on peut savoir que c'est une invocation si elle a pas de position au debut), la position utilise la notation sous forme de tableau [x, y]
- il faut listé toutes les stats d'un perso, et son cac si il en a un (mais je connais pas assez les nouvelle version pour savoir tous ce qu'il faut listé ...)
J'ai renommé states en turns ce qui est plus claire. Et le contenu d'un tour est très différant de celui de @nowis13 cette fois. Car je pense que le tour d'un joueur/monstre ne peut pas etre jouer dans tout les sens, et le sens des actions a une importance pour comprendre l'ia (pour les joueur c'est pas utile c'est vrai).
chaque tour est un objet, qui contient l'id de l'entity qui joue. (on peut aussi la déterminer en fonction de l'ordre des tour, mais avec l'appel d'invocation cela complexifie le problème, donc je pense qu'on gagne en clarté de cette manière)
Il contient une liste moves qui correspond aux actions de jeu (pas au mouvement, pas encore):
- chaque move a une propreté action, une position ciblé, et des effects.
- une effects est une liste d'effet, qui contient une target qui precise l'entity id touché (pour gérer les effet de zone), et et toutes les states modifié. ou les buff ajouté.
Voila ma proposition amélioration. Elle est évidement imparfaite et encore un peu vague sur plein de points.
Je vous invites vivement à proposer des améliorations en plus ou de critiquer mes choix !
A+