Gestion des données d'une application

Salut,

Je cherche à réaliser un petit jeu en Java pour m'entraîner. Le jeu se présente sous la forme d'un jeu en lignes de commandes dans le style "Livres dont vous êtes le héros" pour ceux qui connaissent ou encore l'indémodable "Donjons & Dragons". L'univers du jeu est entièrement textuel (c'est l'imaginaire du joueur et la qualité de la rédaction qui font la différence). Les interactions avec l'univers se font à l'aide de multiples commandes comme "regarder", "écouter", "aller au nord", etc... Pour ce qui est de la gestion des interactions, ça, c'est pas un problème, ce qui me bloque c'est l'accès aux données du jeu.

En effet, il y a beaucoup de données à sauvegarder et je voudrais avoir des conseils sur comment faire pour gérer convenablement l'accès aux données du jeu.

Pour donner un ordre d'idée des données à stocker voici ce que je pense faire. Au lancement du jeu le joueur peut se créer une sauvegarde (une instance unique du jeu), cela va donc créer un monde, qui contiendra des régions, qui contiendront des zones (par exemple un donjon, une maison, une grotte, etc...), qui contiendront des salles (zone indivisible où se feront toutes les actions du joueur). Chacune de ces salles possédera une description précise, ses salles voisines, des objets emportables ou non, des pnj, des ennemis, etc... Il sera possible de créer de façon générique tous les objets et les différents personnages du jeu, j'entends par là que tous ces "objets" seront écris une seule fois et je me contenterai de faire "pointer" mon environnement vers ces objets en cas de besoin. Bon voilà, pas la peine de décrire en détails.

Venons en au fait, je voudrais avoir des conseils sur la façon de stocker et d'accéder à ces données. Pour l'instant j'ai envisagé deux hypothèses :

1 - J'ai réalisé un Modèle Conceptuel (MCD) des données à représenter et je me disais que ça serait pas mal de créer une base de données pour l'application (qui tournera en local). Je pense que ce serait l'idéal mais le problème c'est que je ne sais pas quelle SGBD choisir, sachant que si je prend par exemple mysql il me faudra un serveur, j'ai pensé également à SQLite mais au premier abord il m'a vraiment l'air limité (d'où le "lite" :D). Donc si vous pensez qu'une base de données s'impose j'aurais vraiment besoin de conseils.

2 - Passer par des fichiers XML. L'avantage est que c'est très facile à réaliser une fois la grammaire mise au point mais le problème c'est que la lecture/écriture me paraît être vachement lourde. Par exemple si je dois charger une salle, je dois parser un fichier en entier, et si je dois prendre un objet il faut supprimer une ligne dans le fichier et le ré-écrire, donc je trouve ça un peu "sale", me trompe-je ? ^^

3 - A vous de me dire si vous voyez d'autres solutions :D

Conclusion, à votre avis qu'est-ce que je devrais et comment le faire ??

Merci d'avance,

AwaX

Par expérience, pour avoir travaillé avec ça dans un lointain passé: un fichier par carte (en gros), les cartes reliées entre elles, les cartes recopiées sur le disque non pas dès que tu change quelque chose, mais quand tu les quitte (ou quand tu "sauve"). Le reste du temps, simplement en mémoire.

Un parseur bien écrit devrait être assez rapide pour ne pas être remarqué par l'utilisateur. D'accord le XML c'est verbeux, mais des cartes bien découpée et tu n'aura jamais plus de quelques 10aines de Ks de données à lire / écrire à chaque fois.

Bonjour,
pour la persistance de tes données, tu as au moins 2 bonnes alternatives à XML :
YAML (assez lisible, moins verbeux que XML, mais aussi efficace pour structurer les données) et JSON (assez compact lui aussi).

SQLite n'est pas un mauvais choix non plus. Il implémente en grande partie la norme SQL-92, les triggers, transactions... Je ne dirais pas qu'il est limité, même s'il a des limites (comme tous). Je crois que le nommage SQLite vient surtout du fait qu'il est serverLess, et permet d'embarquer la BDD.

Pour le choix entre ces 4 solutions, je dirais que ça indiffère. Le tout est de rester propre avec la solution choisie, et de séparer la couche d'accès aux données du reste, pour pouvoir par exemple faire évoluer la partie persistance de ton prog en ajoutant par la suite XML ou SQLite sans nécessité de modifier les classes métier...

Plop,

Pour le SGBD je te déconseille SQLite, prend plutôt H2 ou HSQLDB. Il n'y a toujours pas de driver JDBC officiel pour SQLite, alors que H2 et HSQLDB sont faites en Java, donc il faut juste les inclure dans le classpath (en plus de fournir plus de fonctionnalités).

Ensuite, bien que XML soit verbeux, les libs permettant de travailler dessus sont assez avancées par rapport à JSON / YAML (Je pense à JAXB, ...). Ou JSON avec Jackson.

J'éviterais de mettre quand même un énorme monde sur une base de donnée.

Typiquement, tu as une structure en arbre. Le mondes et fait de zone, faites d'objets, eux même pouvant contenir des objets, eux même pouvant contenir d'autres objets, etc. Bien que ça puisse être facilement traduit en SQL (une colonne containerId), sql ne permet pas facilement de récupérer tout ton arbre d'un coup, donc ut va faire plein d'aller retour. J'ai peur que si tu augmente fortement ta quantité de données, sql devienne très lent par rapport à des fichiers bien organisés.