Comment choisir comment stocker les données?

Donnez un poisson à un homme et vous le nourrissez pendant une journée. Apprenez à un homme à pêcher et vous le nourrissez toute sa vie. - Proverbe chinois

Je pourrais demander quel type de stockage de données je devrais utiliser pour mon projet actuel, mais je veux apprendre à pêcher , donc je n'ai pas besoin de demander un poisson chaque fois que je commence un nouveau projet.

Donc, jusqu'à ce que j'utilise deux méthodes pour stocker des données sur mon projet non-jeu: les fichiers XML et les bases de données relationnelles. Je sais qu'il existe également d'autres types de bases de données, du type NoSQL . Cependant, je ne sais pas s'il y a plus de choix à ma disposition, ou comment choisir en premier lieu, à part d'en choisir un arbitrairement.

La question est donc la suivante: comment choisir le type de stockage de données pour un projet de jeu?

Et je serais intéressé par le critère suivant lors du choix:

• La taille du projet.
• La plateforme ciblée par le jeu, ainsi que la plateforme de développement utilisée.
• La complexité de la structure des données.
• Ajout de la portabilité des données parmi de nombreux projets.
• Added2 Utilisation silencieuse des données entre différents projets. (c'est-à-dire les données utilisateur)
• Ajouté À quelle fréquence les données doivent-elles être consultées
• Ajout de plusieurs types de données pour une même application
• Added2 Configuration avec stockage de données multiples.
• Tout autre point que vous pensez est intéressant pour décider quoi utiliser.

EDIT que je connais. Serait-il préférable d'utiliser XML / JSON / Text ou une base de données pour stocker le contenu du jeu? , mais j'ai pensé que cela ne répondait pas exactement à mon point. Maintenant, si je me trompe, je serais heureux de montrer l'erreur dans mes voies.

EDIT2 Ajout de quelques points supplémentaires que je considérerais pertinents. En outre, je serais intéressé d'entendre quelles autres options sont disponibles, à part le stockage de fichiers plats et la base de données relationnelle. Qu'en est-il de la base de données non relationnelle, par exemple? Quand est-il pertinent d'utiliser une telle base de données par rapport aux autres options précédemment mentionnées?

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 .

Dernièrement, je me suis retrouvé contraint par la rigidité / difficulté d'ajouter des bases de données relationnelles. J'adorerais explorer des bases de données basées sur des documents (par exemple couchdb), car elles semblent très adaptées aux jeux, à l'état et à la flexibilité. Mais il n'est pas vraiment pratique de configurer plusieurs types de bases de données pour un petit projet. En conséquence, j'ai mis en place un hack similaire à l'utilisation d'un champ blob binaire dans certains champs de la base de données.

Ce que je fais, c'est utiliser des données codées json dans la base de données et un wrapper qui convertit les données en json et les recule chaque fois que cela est nécessaire. Ainsi, un profil de personnage de base pourrait ressembler à ceci dans la base de données:

{"char_id":24,"char_name":"tchalvak","level":43,"profile":"Some profile here."}

Json est toujours bien lisible dans la base de données, donc si vous travaillez à nu avec le SQL et accédez parfois directement à la base de données, il est modifiable manuellement si vous le souhaitez.

Maintenant, tout cela est un hack, et je ne conseille pas de le copier, mais voici le point global: ne vous fiez pas uniquement à un seul système. Utilisez une base de données relationnelle et truquez le système. Ou utilisez deux types différents de systèmes de stockage de données (par exemple, un fichier plat et une base de données relationnelle?), Afin que vous puissiez tirer le meilleur parti des deux. Peu importe ce que les gens suggèrent ou quel système vous utilisez, vous découvrirez des circonstances dans lesquelles une autre approche fonctionnerait mieux, alors soyez prêt à ajouter une alternative et voyez où cela vous mène.

Dans le gène RTS, les données du jeu ont été stockées dans des fichiers.

Les unités et les attributs ont été stockés dans des fichiers INI ou XML ou d'autres formats basés sur du texte, et les modèles étaient un mélange de formats binaires ou même basés sur du texte, et les textures et sons et autres médias dans des formats courants. Parfois, il a été dans un conteneur qui a un cryptage brut - le format de mixage de Westwood vient à l'esprit. Mais c'est surtout de l'obscurcissement - si vous regardez à l'intérieur, ce ne sont que des fichiers normaux dans des formats faciles à manipuler.

Avec l'avènement du jeu en ligne, il est devenu de plus en plus courant que les données du jeu soient fournies après l'installation sur Internet, bien que souvent elles soient toujours stockées sur le système de fichiers.

Pourquoi utiliser une seule méthode de stockage des données?

Dans la plupart des cas, le jeu que vous lancez dans le monde n'a pas besoin de la même fonctionnalité de stockage de données dont le jeu a besoin pendant le développement.

Voici une comparaison de certaines exigences de version / développement: -

Requirement      |  Release  |  Development  |  QA
==================================================
Multi user       |    No     |      Yes      |  No
Writable         |    No     |      Yes      |  No
Revision Control |    No     |      Yes      | Yes (but only reading)
Compact          |   Yes     |       No      |  No
Fast             |   Yes     |       No      |  No

Idéalement, alors, vous définiriez une interface avec votre module de chargement de données, puis créeriez plusieurs versions, chacune adaptée à des besoins spécifiques.

Sur un projet sur lequel j'ai travaillé il y a de nombreuses années, le chargement des données de niveau à partir du CD prenait beaucoup trop de temps (hors HD n'était pas génial non plus). J'ai donc trouvé le suivant. J'avais trois méthodes pour charger les données de niveau: -

1. Chargement normal - pour le temps de développement lorsque les actifs changent
2. Pré-version - une méthode efficace pour convertir des données normales en données à chargement rapide
3. Version - données rapides uniquement (non modifiables)

Cela a réduit les temps de chargement de quelques minutes à quelques secondes.