Analyse XVII Le re-retour du retour : Stockage des données du jeu

J'ai pas mal parlé des données du jeu dans les posts précédant, mais il reste quand même le principal à définir : la manière selon laquelle cela peut être organisé. Déjà, il y a plusieurs sortes d'informations à stocker :
- terrains (nom et image associée surtout)
- unités (caractéristiques, images associées)
- cartes (détail des terrains la composant)
- scénario (carte dans laquelle se déroule le scénario, et liste des unités de départ)

On pourrait mettre tout ça directement dans le code, mais c'est le mal absolu ! Devoir modifier le code à chaque modification du gameplay, c'est bof quand même ! Il faut donc stocker tout ça dans des fichiers, et là, pas mal de choix nous sont permis (texte brut ? xml ? et avec quelle organisation des données ?). Ça pourrait donner ça pour l'arborescence (pas joli à voir, je préviens) :

Donnees
___ Images
______ Unites
_________| fantassin_leger.png
_________| archer.png
______ Terrains
_________| plaine.png
_________| montagne.png
_________| pont.png
___ Unites
______| fantassin_leger.cfg
______| archer.cfg
___ Cartes
______| carte1.map
______| carte2.map
___ Terrains
______| plaine.cfg
______| foret.cfg
___ Scenarios
______| scenario1.cfg
______| scenario2.cfg

Et ça pour les fichiers qui la composent (exemples) :

plaine.cfg :
##################
id=Pl // Utilisé pour identifier le terrain au sein des fichiers .map, et de ceux décrivant les unités (pour connaître leurs capacités de déplacement)
nom=Plaine
image=plaine.png // Sous réserve que le programme sache que les images de terrains ne peuvent se trouver que dans le dossier Donnees/Images/Terrains
##################

fantassin_leger.cfg :
##################
id=Fl // Utilisé dans les fichiers .map pour reconnaître les types d'unités présentes
nom=Fantassin léger // le nom utilisé dans le jeu
image=fantassin_leger.png
HP=800 // Valeurs à la con juste pour l'exemple
ATQ=54545 // idem
DEF=146 // idem
pointsDeplacement=5 // Peut se déplacer de 5 cases au maximum
cout_Pl=1 // Un déplacement d'une case en plaine coûte 1 pt
cout_Mt=1.25 // Un déplacement d'une case en montagne coûte 1.25
[...]
##################
Note pour fantassin_leger.cfg : si le coût de déplacement sur l'un des terrains existants n'est pas renseigné, alors c'est celui par défaut qui doit s'appliquer, cad 1

carte1.map (exemple d'une carte toute pourrie avec 4x4 cases montagneuses au milieu de plaines)
##################
id=carte1
nom=Carte 1
largeur=12 // 10 cases utiles + 2 pour la bordure façon wesnoth sur les côtés
hauteur=12 // idem

Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl
Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl
Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl
Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl
Pl,Pl,Pl,Pl,Mt,Mt,Mt,Mt,Pl,Pl,Pl,Pl
Pl,Pl,Pl,Pl,Mt,Mt,Mt,Mt,Pl,Pl,Pl,Pl
Pl,Pl,Pl,Pl,Mt,Mt,Mt,Mt,Pl,Pl,Pl,Pl
Pl,Pl,Pl,Pl,Mt,Mt,Mt,Mt,Pl,Pl,Pl,Pl
Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl
Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl
Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl
Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl,Pl
##################

scenario1.cfg :
##################
nom=Scénario bidon
carte=carte1 // sous réserve qu'une carte ne puisse se trouver que dans le dossier /Donnees/Cartes

1,1,Cdt,1,1 // Dans l'ordre : position x, position y, id de l'unité (commandant ici), nombre d'unités, numéro de l'équipe la contrôlant
2,1,Ar,100,1 // 100 archers en (2,1), contrôlés par l'équipe 1
1,2,Ar,100,1
2,2,Fl,200,1
10,10,Cdt,1,2
9,10,Ar,100,2
10,9,Ar,100,2
9,9,Fl,200,2
##################

Bon bien sûr, c'est juste pour donner une idée générale à débattre...

pk pas tout stocker en hsqlbd ? ^^ le texte brut me tente pas du tout, le XML a la rigueur mais j'aime pas trop ...

Toujours très clair, très compréhensible. Encore une fois, je n'ai aucune expérience du domaine, je suis bien incapable de dire qu'est-ce qui est le plus facile/efficace entre texte brut, XML ou autre chose. Désolé :/

Bah un truc tel que je l'ai fait là, c'est plutôt facile à parser. Une BDD, ça permet de lire plus facilement des données telles que ce que j'ai mis sous la forme "clé=valeur". Par contre, lorsqu'il est question de lire la matrice de cases d'une carte, on n'échappe pas aux troupeaux de requêtes... Mais ça, c'est pas bien grave.

Par contre, les vrais inconvénients :
- Si on a une BDD, comment fait-on pour ajouter une carte ? On est obligés de faire une requête pour créer la table, puis n² requêtes INSERT pour une matrice de cases n*n, en récupérant au passage l'identifiant de la carte ajoutée, etc.
- Comment fait-on pour modifier la matrice ? On doit commencer par la visualiser pour bien voir ce qu'on veut changer. Mais on ne peut pas le faire directement. On est obligé de faire un SELECT suivant les bons critères pour récupérer un ensemble de tuples, qu'il faut ensuite organiser de manière à avoir une matrice ressemblant à quelque chose à l'œil. Au final, on galère autant à chaque fois qu'on veut modifier une carte, que ce que l'on n'aurait eu qu'une seule fois en parsant du texte :p

ps : j'oubliais de dire qu'avant de faire ça, il faut déjà se connecter à la BDD etc, ce qui est quand même bien plus chiant qu'un rien du tout à changer dans un fichier texte :p

oui y a que la carte qui dérange, mais pour le reste ca irait sans problème. Mais bon c'est vrai que l'un ou l'autre...

Euuuuuuh, une BDD juste pour remplacer des couples clé-valeur, ok ça passe, mais c'est vraiment pas le rôle d'une BDD :s
Même en ignorant le côté surdimensionné de la chose, il est carrément plus facile de parser que d'avoir recours à des requêtes...

ps : d'autant plus que dans ces cas là aussi, modifier un fichier texte est quand même plus "user-friendly" que de se manger du SQL

voui mais c'est juste que j'ai eu un mauvais souvenir du système de fichier comme ça avec mon projet de l'année dernière et java qui nous avais un poil cassé les burnes donc j'ai tendance à l'éviter comme la pestes sans trop de raisons :p

C'est sur que de faire tout en fichier txt que dans le code, c'est plus propre surtout qu'on peut le modifier facilement (et cheater aussi :p).
Je suis ok !

Petite modif qui ne gênera personne je suppose : donner un attribut "altitude" aux terrains, et supprimer les modificateurs de portée des fichiers de description des unités. Ça rend les choses plus simples : si un groupe A qui se trouve sur un terrain X vise le terrain Y, alors :
porteeOk ssi (portee(A) + altitude(X) - altitude(Y)) >= distance(X,Y)

intéressant mais il faut pouvoir l'afficher simplement et efficacement. Comme ca on pourra avoir une petite colline en plein milieu d'une plaine sans que ce sois une case montagne

Pas tout compris là... Soit on a du plat, soit une montagne non (avec le fort pouvant être entre les deux) ? Si on commence à vouloir faire comme Wesnoth et mettre une dizaines de skins distribués aléatoirement pour chaque terrain, ça va faire chier :p (il y a déjà de la prise de tête en perspective au niveau des transitions entre terrains :s)

Bah si on a une altitude pourquoi ne pas mettre que un terrain en plaine peut être a altitude 3 tandis qu'un terrain un peu plus loin a une altitude 1 pour simuler une "colline". Après comme j'ai dis reste à voir si on peut afficher simplement cette différence.

Ok. Ce à quoi je pense, c'est bien plus con que ça :
plaine | marais | forêt => altitude 0
fort => altitude 1 (ou 0 aussi ?)
montagne => altitude 2

donc montagne vers plaine => portée +2, etc. Je parle d'altitude parce que c'est ce qui le représente le mieux, mais en fait ça n'a d'altitude que le nom. Vu qu'on n'a pas un terrain continu, de toute manière faire plus compliqué nous ferait juste dépenser des calories pour rien (avoir des bonus de portée de 1.3 cases, on s'en fout )

ps, histoire de vraiment répondre à ton post : impossible, il faudrait créer nos propres images, les transitions, etc...