Serait-il préférable d'utiliser XML / JSON / Text ou une base de données pour stocker le contenu du jeu?

Je réfléchis à la façon de mettre en œuvre un jeu basé sur des composants, car cela semble être la chose la plus intéressante et j'aime l'idée d'une conception si flexible. L'une des caractéristiques d'une telle conception est que l'ajout de nouvelles choses au jeu peut se faire par le biais de données, souvent présentées comme du chargement de contenu via des fichiers texte tels que XML. Cela a l'avantage d'être lisible par l'homme et facilement modifiable dans n'importe quel éditeur de texte. À la baisse, le texte peut être plus lent à traiter et vous devez gérer une grande collection de fichiers de données. Des formats textuels similaires comme JSON ou des fichiers de configuration auraient des avantages similaires.

De l'autre côté, il existe de petites bases de données portables comme SQLite ou Tokyo Cabinet. Bien qu'ils ne soient pas directement lisibles par l'homme, ces fichiers sont faciles à interfacer, et j'imagine qu'une sorte d'outil d'édition serait préférable pour la conception de contenu de jeu de toute façon. L'utilisation d'une base de données permet un stockage cohérent des informations de configuration et une récupération facile. Vous pouvez également sérialiser des données dans une base de données pour sauvegarder des parties.

En termes de performances, je pense que XML est généralement plus rapide pour les petits fichiers, mais une base de données s'adapte mieux à de grandes quantités de données. J'imagine que tout vrai jeu aura beaucoup d'objets de jeu.

Donc la question: quelle est l'approche préférable? Je penche vers la base de données, mais je veux savoir s'il y a des pièges cachés ou des avantages réels importants pour les fichiers texte. Ou s'il y a d'autres alternatives que celles-ci (sérialiser au format binaire je suppose?)

Cela peut ne pas arriver autant pour un petit jeu personnel, mais un problème difficile en ce qui concerne les données de jeu est l'édition / versionnage multi-utilisateurs. Nous utilisons beaucoup de petits fichiers texte qui se transforment en un petit nombre de blobs binaires par un processus de construction. Cela facilite la vie des concepteurs, car ils ont beaucoup de flexibilité dans leur flux de travail. CCP, comme contre-exemple, utilise une base de données d'édition centrale à laquelle tous les concepteurs se connectent. Cela rend l'étape de construction inutile (ou au moins beaucoup plus simple), mais cela signifie que vous devez implémenter vous-même toutes les fonctionnalités de gestion des versions et de flux de travail, de sorte qu'elles sont nécessairement plus simples que d'autres outils. Vous pouvez gérer les performances dans les deux cas, la vraie question est donc de savoir ce que vous voulez pour un flux de travail de concepteur et comment y arriver?

JSON est très léger et facile à comprendre. Je pense que c'est mieux adapté pour un match. cJSON est vraiment sympa. il sera également intégré à votre source de la même manière que SQLlite.

Les fichiers XML sont plus difficiles à modifier pour les utilisateurs que vous ne le pensez. si vous suivez cette voie, vous voudrez peut-être créer un éditeur que les gens pourront utiliser pour les aider à éviter les pièges courants.

Je suis en retard à la fête ici, mais j'ai passé BEAUCOUP de temps à faire des recherches à ce sujet.

D'abord pourquoi je n'utilise pas ce qui suit:

XML: excessivement verbeux. Des tonnes de redondance. Répétition des noms de champs? BRUT

JSON: Je pense que JSON est idéal pour une mise en page d'interface utilisateur, mais pour une base de données, non. Il aura les mêmes problèmes que XML, la redondance et l'imbrication profonde. BRUT.

SQL : C'est une excellente option, si vous gérez les maux de tête liés à sa configuration. J'ai créé des jeux mobiles où nous stockons les données de jeu en ligne dans une base de données SQL. Le format du tableau est sympa. Le problème était que nous devions récupérer la base de données en ligne et la configurer peut être un problème. Mais SQL est une solution décente. Unity ne prend pas cela en charge de manière native, et les plugins que j'ai essayés ont rencontré des problèmes majeurs (en particulier lorsqu'ils essayaient de le faire fonctionner avec le contrôle de version).

Enfin, voici la solution que j'ai choisi d'utiliser (et je l'adore).

CSV : simple. Me permet d'utiliser le format de tableau et j'ai un point de référence facile lorsque je dois le mettre à jour. Je peux avoir un tableau pour toutes mes armes, des colonnes pour tous les attributs et des lignes pour chaque type d'arme.

Vous pouvez utiliser Microsoft Excel mais il crache ces stupides avertissements à chaque fois que vous devez enregistrer. Vous pouvez utiliser des macros pour le remplacer, mais je vous dis de vous éviter les ennuis et d'obtenir LibreOffice . Son gratuit, prend en charge l'édition CSV, et lorsque vous ouvrez le fichier, il charge la largeur de colonne pour correspondre au nom (Excel ne le fait pas et cela m'a rendu fou).

Ensuite, il vous suffit d'analyser les fichiers CSV dans votre jeu. J'utilise Unity donc tout ce que j'avais à faire était d'utiliser cet astucieux analyseur C # CSV que j'ai trouvé:

Exemple d'analyseur CSV

Vous convertissez les fichiers CSV en vos objets de données de jeu et vous êtes prêt à partir. Avec Unity, vous pouvez les transformer en ScriptableObjects . Mon workflow est donc: Mettre à jour CSV -> Analyser CSV en objets scriptables -> Utiliser les données de ScriptableObjects pour mon jeu

La réponse à cela dépend de la langue que vous utilisez pour le jeu.

Si vous utilisez C ++, il serait judicieux d'utiliser l'une des bibliothèques XML existantes (telles que TinyXml ou eXpat ).

En revanche, si vous utilisiez PHP, vous pourriez très facilement utiliser un serveur de base de données tel que MySQL ou SQLite. (Gardez à l'esprit que si vous suivez cette voie, vous aurez besoin de plus de ressources car le serveur de base de données s'exécutera en tant que processus séparé et les applications de base de données plus grandes comme MySQL peuvent consommer beaucoup de RAM lors de l'exécution.)

JSON gagne beaucoup d'élan et est certainement le meilleur choix si votre application est écrite en utilisant plusieurs langues.

En bref, cela dépend de ce qui est facilement utilisable dans votre langue.

Si vous souhaitez rester dans le domaine des choses XML, vous pouvez utiliser XML binaire pour aider à augmenter les performances de charge.

Par exemple, Fast Infoset est une implémentation de XML binaire

On peut penser à Fast Infoset comme gzip pour XML, bien que FI vise à optimiser à la fois la taille du document et les performances de traitement, tandis que gzip optimise uniquement la taille. Bien que la mise en forme d'origine soit perdue, aucune information n'est perdue lors de la conversion de XML en FI et de retour en XML.

Je conçois des bases de données et joue avec de nombreuses idées de jeux depuis des années. Mon préféré pour le moment est un format basé sur du texte et lisible par l'homme pour les configurations, mais en analysant ensuite ces "scripts lents" en quelque chose de plus exécutable. Tout comme JAVA et .NET est compilé en bytecode d'exécution.

La même idée va ici. J'ai une version "source" des composants, puis un pré-compilateur / analyseur les traverse. S'ils occupent trop de mémoire, vous pouvez les mettre dans une base de données SQL rapide ou les enregistrer sous forme de fichiers binaires. Mais mon point est, utilisez la mémoire ou la base de données SQL comme espace de travail / cache afin de ne pas avoir à analyser les scripts encore et encore. Vous pouvez créer le compilateur, déplacer les fichiers analysés dans une "source-lib" et laisser ainsi le précompilateur faire le versioning également (en conservant les fichiers précédents à des fins de restauration).

S'il s'agit d'un "espace de disque dur illimité", inscrivez-vous à quelque chose comme Dropbox ou Amazon S3 et synchronisez avec eux.

Donc, le plan pour moi est actuellement:

1. Config / scripts / xml (certains formats lisibles par l'homme) en tant que fichiers texte (tout comme le code source)
2. Analyseur / validateur qui exécute de nouveaux scripts et vérifie qu'ils respectent les règles
3. Compilateur qui crée des lignes binaires ou SQL à partir des fichiers d'origine, afin qu'ils soient rapides à récupérer + rapides à exécuter.

En ce qui concerne la stabilité, je construis actuellement la base de données pour qu'elle soit "hébergée conjointement" et la synchronisation automatique entre plusieurs emplacements également, de sorte que s'il y a une panne de réseau / matériel à un emplacement, les autres sites devraient être en mesure de gérer le même trafic / gamestates.

Si vous utilisez couchdb, vous enregistrerez essentiellement tout sous forme de structure JSON. Couchdb se chargera de répliquer plus ou moins facilement les données de vos (multiples) utilisateurs.

Vous pouvez trouver une procédure dans Unity Wiki avec PHP, MySQL et C # / JavaScript, et cela fonctionne bien pour son objectif.

Il se compose de trois étapes

1. Créez une base de données MySQL vierge et une table.
2. Créer un script côté serveur PHP (cela se connectera à la table MySQL, recevra les données d'un script Unity (étape 3) et interrogera la base de données (les exemples donnés sont soit l'insertion de données, soit la sélection))
3. Créez le script du contrôleur Unity (cela se connectera au script PHP créé à l'étape 2)