Discussion :

[Doudoupe]

Bonjour à tous,

Je travaille sur un petit jeu en utilisant JavaFX.
Je cherche un moyen de sauvegarder ou "persister" les données de ce jeu. C'est à dire travailler avec ces données lorsque le jeu est lancé et tourne, mais aussi persister toutes les données nécessaires, afin de gérer le système de sauvegarde.

Ces données sont :
- des informations sur un 'Personnage' (utilisé en tant qu'objet dans le jeu)
- des informations sur une carte/map
* un objet 'quadrillage' ou 'carte' contenant un tableau d'objets 'case'
* chaque case possède un certain nombre de champs.

J'ai aussi besoin de définir et stocker quelque part les référentiels comme tous les objets (pas au au sens Java) disponibles dans le jeu comme une montre, une planche, une épée, un arc et les attributs associés.
J'utiliserai alors ces données pour travailler avec des classes Arme, Ressource, Outil...

Mes questions sont donc :
1) Comment gérer les sauvegardes concernant le personnage, et la carte dans lequel il évolue ?
2) Comment définir mon référenciel d'objets disponible en jeu ?

J'ai pensé à crer une base de données "embarqué" mais n'est ce pas un peu lourd? Si c'est la solution (et si ça existe...) comment faire? (moi je connais les BDD héberger sur un serveurn pas embarqué à une application)

J'ai pensé aussi à des fichiers XML. Si oui, auriez vous un exemple?

Question subsidiaire, comment sont fais les fichier du genre .dat dans un jeu video? Je suppose que c'est ce genre de chose que je recherche!

Merci pour votre aide.

[kolodz]

Il y a plusieurs manière de réaliser la persistance d'objet.

Le plus simple et rapide est selon moi la sérialisation :

http://ydisanto.developpez.com/tutor...ation-binaire/

Il peut cependant y avoir des problèmes de compatibilité entre entre différentes version d'une classe. Évolution de la classe entre la sérialisation et la dé-sérialisation...

La base de donnée est aussi possible :
http://baptiste-wicht.developpez.com.../java/db/hsql/
Qui peut être stocker sous un forma lisible par un humain. (fichier csv par exemple)

Pour la solution XML, c'est une autre forme de sérialisation pour moi :
http://ydisanto.developpez.com/tutor...ation/partie2/

Cordialement, Patrick Kolodziejcyzyk.

[Doudoupe]

Merci kolodz pour ta réponse.
Et désolé de ne répondre que maintenant.

J'ai regardé la sérialisation et effectivement c'est ma solution pour les sauvegarde. Par contre j'ai cru voir quelque part qu'on ne peut sérialiser que des attributs de type primitif. Mais je n'en suis pas sûr, je vais faire quelques tests pour vérifier.

Mis à part le système de sauvegarde, il me faut un moyen de déclarer tous les types d'items du jeu (planche, ration, couteau, hache...) afin d'avoir un référentiel des items disponibles. Je pense à déclarer tout cela dans un fichier xml (voir plus bas). Serait-ce une bonne solution? Par contre, je ne sais pas trop comment passer du xml vers un objet java. La solution serait peut-etre de parser le fichier xml dans mon constructeur de ma classe Item : récupérer un item par nom puis récupérer les propriétés correspondantes et les insérer dans les attributs de mon objet?

Voici à quoi je pense comme fichier XML :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<items>
   <item>
      <name />
      <type />
      <imgPath />
   </item>
   ...
</items>

Le soucis c'est que j'aurais plusieurs type d'items : des armes (avec des propriétés particulieres (attaque, état par exemple), des vivres (bonus en point de vie, risque d'être malade...), des resources (sans propriété particuliere).

Je peux définir tout cela dans le même fichier xml comme cela ? :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<items>
   <armes>
      <item>
         <name/>
         <attaqueValue/>
         <etat />
      </item>
      <item>      <-- une autre arme
          <name>
          <attaqueValue/>
          <etat />
      </item>
   </armes>
   <nourriture>
      <item>
         ...
      </item>
   </nourriture>
<items>

[kolodz]

Bonjour,

J'ai déjà eu ce genre de réflexion. Le mieux et le plus simple est de faire un fichier/table/XML par type d'objet.
Cela te permet d'avoir beaucoup moins de complexité à gérer à la fois.
Quand tu charge le fichier arme.xml, tu n'as pas à savoir comment tu gère la nourriture.
Tes XML pourrai être :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
<armes>
      <arme>
         <name>Rapière</name>
         <attaqueValue/>
         <etat/>
      </arme>
      <arme
          <name>Durandil</name>
          <attaqueValue/>
          <etat />
      </arme>
   </armes>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
   <nourritures>
      <nourriture>
        <name>Pain</name>
         <hpRestor/>
         <weight/>
      </nourriture>
   </nourritures>

Autre(s) conseil(s) :
Pour les noms des objets ou des propriétés : Tout français ou tout anglais
Plus la solution est simple, plus tu pourra la réutiliser pour d'autres problèmes.
Focalise toi sur un seul petit problème à la fois. Tu pourra très probablement résoudre beaucoup d'autres problèmes juste après.

Cordialement,
Patrick Kolodziejczyk

[Susp3nded]

Vu ce que tu veux faire la bdd embarquee me semble etre la meilleure solution.
Avec les fichiers xml tu risque de te retrouve ennuye si tu veux faire des jointures ( genre un type de bonus sur un certain type darme). Tu risque de potentiellement devoir charger beaucoup de fichiers et tes fichiers peuvent grossir....quant a la maintenabilite, il est plus simple de modifier une requete sql qu'une methode qui parse un XML.

justement hsql est tres leger et stocke les donnees de ta base dans un fichier ( entres autres)

si vraiment tu veux utiliser des fichiers je te conseille du json, qui est human readable et a l'avantage d'etre plus leger que du xml

Enfin, les fichiers .dat, tu mets ce que tu veux dedans. Ce sont juste des fichiers qui ont une structure definie par le developpeur et affublee d'une extension arbitraire, comme les .wad, les .pak