Votre question est vraiment large en raison du grand nombre de genres, mais voici la perspective d'un développeur de logiciels professionnel.
Vous avez fourni une liste de critères que vous souhaitez utiliser pour déterminer le mécanisme de persistance des données que vous utilisez. Ceux-là étaient:
- La taille du projet.
- La plateforme ciblée par le jeu.
- La complexité de la structure des données.
- Portabilité des données parmi de nombreux projets.
- À quelle fréquence les données doivent-elles être consultées
- Plusieurs types de données pour une même application
- Tout autre point que vous pensez est intéressant pour décider quoi utiliser.
Nous devons d'abord déterminer quelles options s'offrent à nous. Comme vous n'avez pas spécifié de langue ou de technologie, il est difficile de dire exactement, mais vous essayez probablement de choisir entre XML et le stockage de base de données relationnelle .
Une distinction importante à faire est que XML n'est pas vraiment un mécanisme de stockage autant qu'une technique de sérialisation. C'est un moyen de représenter les structures en mémoire de votre jeu. Cela dit, vous parlez vraiment de stockage de fichiers plats par rapport à un stockage de bases de données relationnelles . Ce ne sont pas les seules options, mais ce sont les plus courantes, donc je vais les utiliser.
Pour les fichiers plats:
- XML
- JSON
- YAML
- XAML
- Texte brut
Pour les bases de données:
- serveur SQL
- MySQL
- DB2
- Oracle
- Beaucoup plus
EDIT: Vous avez posé des questions sur d'autres types de mécanismes en dehors des fichiers et des bases de données relationnelles. Le seul autre type notable de base de données que j'ai vu utiliser régulièrement est celui des bases de données "de type Berkeley", qui sont essentiellement basées sur des valeurs-clés. Ceux-ci ont tendance à utiliser des arbres B pour structurer les données afin que les recherches soient rapides. Celles-ci sont idéales pour la recherche de configuration / paramétrage où vous savez exactement ce que vous voulez (par exemple, donnez-moi toutes les données de télémétrie pour "Niveau 1").
Maintenant que nous avons éliminé toutes les bases, abordons certains de vos critères.
La taille du projet.
Certains pourraient être en désaccord, mais la taille de votre projet n'aura pas nécessairement un impact énorme sur votre mécanisme de persistance des données. Vous souhaiterez créer une bibliothèque réutilisable de fonctions qui stockent / chargent des données à partir du mécanisme de votre choix. Je suggérerais même d'implémenter une couche d'abstraction (consultez le modèle d'adaptateur ) afin que vous puissiez facilement changer votre mécanisme de persistance si vous en avez besoin.
Cela dit, pour les petits projets, l'utilisation de XML sur le système de fichiers peut potentiellement bien fonctionner, mais vous voudrez résoudre certains de vos problèmes de sécurité (par exemple, le cryptage) afin que les joueurs ne puissent pas modifier les données à volonté.
La plateforme ciblée par le jeu.
La plate-forme ne sera pas non plus un problème majeur. Vous devriez vous préoccuper davantage de votre plateforme de développement que de la plateforme cible. La raison en est que certains langages gèrent certains types de balisage ou de bases de données mieux que d'autres prêts à l'emploi. Cela ne veut pas dire que vous ne pouviez utiliser aucun des éléments ci-dessus dans presque toutes les langues, mais il est parfois préférable d'utiliser les outils pris en charge à votre disposition. Toute plate-forme prendra en charge les fichiers plats et analysera le XML, mais sur les plates-formes mobiles, vous voudrez peut-être envisager la sérialisation binaire si possible, ou au moins optimiser votre XML pour le stockage.
La complexité de la structure des données.
C'est en quelque sorte délicat. Les bases de données relationnelles sont idéales pour cela ... le stockage des entités et de leurs relations. Vous avez une meilleure capacité à appliquer la structure à l'aide d'un référentiel de stockage relationnel qu'avec des fichiers sur un système de fichiers. Tenez compte des types de relations entre vos entités ainsi que de la fréquence à laquelle vous les modifiez ou recherchez des entités liées. Pour les structures extrêmement complexes, je suggère de suivre la voie de la base de données.
Portabilité des données parmi de nombreux projets.
En ce qui concerne la portabilité, vous devez tenir compte du fait que les bases de données sont naturellement plus lourdes que les fichiers. Il y a des frais généraux d'installation et de configuration, différentes bases de données seront disponibles pour différentes plates-formes, etc. SQLite est un très bon moyen de contourner cela. Cependant, en ce qui concerne la portabilité, vous aurez probablement plus de facilité avec des solutions basées sur des fichiers comme XML.
EDIT: Il y a d'autres préoccupations que vous avez mentionnées au sujet de la portabilité dans l'un de vos commentaires. En fin de compte, vous ne voulez pas que vos données soient couplées trop étroitement à un produit ou à un type de fichier. Il est finalement préférable que vous puissiez stocker des données de stock (niveaux, ennemis, etc.) dans une sorte de format abstrait (fichiers délimités par des tabulations, XML, etc.) que vous pouvez facilement analyser et stocker dans une base de données / système de fichiers lors de la compilation ou du chargement temps. Cela signifie que vous pouvez échanger votre mécanisme de stockage sur un coup de tête et réécrire simplement la pièce d'analyse.
À quelle fréquence les données doivent-elles être consultées
Beaucoup d'accès aux données signifie beaucoup d'E / S, sauf si vous disposez d'une sorte de mécanisme de mise en cache. Les bases de données gardent les structures en mémoire et sont idéales pour la manipulation et la récupération de données. Si vous persistez vraiment des données en permanence, vous voudrez peut-être s'en tenir à une base de données.
Plusieurs types de données pour une même application
Le volume est certainement une considération, mais à moins que vous ne parliez de la persistance de milliers ou de millions d'objets, le système de fichiers sera toujours acceptable comme solution.
Type de jeu
Le type de jeu que vous créez peut avoir une énorme influence sur la plate-forme que vous choisissez. Oui, pour la plupart des jeux solo uniquement pour les clients, vous allez bien utiliser une solution basée sur un système de fichiers compressé ou crypté. Si vous parlez de jeux avec un composant en ligne, ce serait fou. Suivez l'itinéraire de la base de données et évitez les maux de tête. Laissez le serveur gérer toutes vos données à l'aide d'un cluster principal.
J'espère que certains de ces commentaires vous aideront. Ce n'est en aucun cas complètement complet, et la décision vous appartient en fin de compte, mais mon commentaire devrait vous donner quelques éléments de réflexion.
EDIT: Il y a des moments où adopter une approche hybdrid a beaucoup de sens. Par exemple, supposons que vous développez un MMORPG. Côté client, vous pouvez stocker des données en cache sur d'autres joueurs dans une base de données non relationnelle (comme mentionné ci-dessus). Côté serveur, vous stockez toutes les données de jeu dans une base de données relationnelle pour les conserver. Et puis du côté client, vous stockez probablement des données de journal, des données de configuration, etc. dans des fichiers XML / plats pour une accessibilité plus facile.
Une autre affiche a également mentionné qu'il est parfois agréable, même si vous stockez des données pour la production dans une base de données, d'avoir un moyen d'utiliser à la place des fichiers plats pour le développement ... il peut simplement être plus facile de supprimer un autre produit du mélange .