Remplissez-vous toutes vos données de jeu dans d'énormes tableaux Excel? Existe-t-il une meilleure méthode?

Je veux vraiment savoir combien de concepteurs de jeux préfèrent travailler avec une énorme table pour tous les objets, une autre table pour toutes les compétences, et même une autre table pour tous les mobs dans un MMORPG. Et ces tables peuvent atteindre plusieurs centaines de Mo avec des milliers d'enregistrements, mais la plupart des enregistrements n'utilisent que quelques champs dans une table.
Je sais que certains concepteurs de jeux fonctionnent de cette façon. Existe-t-il une meilleure méthode?

Je ne voulais pas répondre ici, mais quand j'ai vu une autre réponse / commentaires, j'ai changé d'avis. SQL n'est pas une très bonne solution à cela. SQL définit des tables et insère de nombreuses données dans ces tables. Ce n'est pas le cas. Lorsque vous créez / testez la conception d'un jeu, vous devez surtout vérifier si l'énorme système est équilibré. Cela signifie beaucoup de tableaux qui s'affectent. Rien de bon pour SQL - ou ce n'est pas facile à gérer, car vous devez faire une programmation qui n'est pas nécessaire. Et le concepteur de jeux n'a pas à le savoir.

En tant que programmeurs / développeurs de jeux, nous pouvons dédaigner Excel et son utilisation pour n'importe quoi, mais c'est un très bon outil pour ce cas, surtout lorsque le concepteur de jeux peut bien l'utiliser et que le document est bien créé.

Je ne peux pas recommander un autre outil, mais je peux dire que je connais des concepteurs de jeux professionnels qui utilisent aussi Excel. Je suppose donc que c'est un outil commun.

Je suis d'accord avec la plupart des répondeurs que parfois les feuilles de calcul peuvent faire des outils de développement décents, en particulier pour les concepteurs.

Si vous souhaitez approfondir cette approche, le programme de feuille de calcul Resolver One utilise python pour les scripts, ce qui facilite la configuration d'une feuille de calcul pour les concepteurs qui à la fois effectue une modélisation complexe et exporte vers un format de données convivial. Je trouve qu'il est beaucoup plus facile de travailler avec le VBScript d'Excel.

Excel est une excellente solution. Je me demandais comment procéder. Mais en y réfléchissant, Excel est un outil très populaire et tout à fait adéquat pour cette tâche, je ne recommanderais pas cette pratique. De plus, la base de données réelle, comme le suggère @notabene, apporte beaucoup de frais supplémentaires dont vous n'avez vraiment pas besoin. Je vois quelques options, dont l'une s'apparente à l'utilisation d'Excel:

• Open Office Calc: gratuit. Il y a aussi un téléchargement de connecteur MySql (open source je crois) pour Calc.
• données sérialisées: XML ou binaires (cryptées)

... de toute façon, gratuitement et vous avez un contrôle total.

Personnellement, je serais enclin à utiliser des données binaires sérialisées et cryptées . Deux raisons:

• les données du jeu ne peuvent pas être facilement modifiées
• Je peux travailler avec des tables de données plutôt qu'avec la sérialisation Xml des ensembles de données, c'est-à-dire que j'ai l'option.

Existe-t-il un besoin pour une véritable bibliothèque de données dédiée au jeu ? Peut-être ... à moins que quelqu'un ne connaisse une telle bibliothèque qui existe déjà.

Au point de la question de l'OP, regardez chaque fichier csv de page comme une table de données unique - semblable à une table dans une base de données. Chaque page par fichier doit contenir des données connexes:

• Compétences, ou
• Gear, ou
• Statistiques des PNJ

Cela vous aide à maintenir un haut niveau d'organisation, ce qui sera très important à mesure que le contenu des données augmente, que le contenu du jeu se développe, etc.

Modifier
Après avoir réellement essayé d'utiliser .ODS (fichier OpenOffice Calc) et se connecter à partir d'une application, cela n'est en fait pas possible, comme l'indiquent les publications initiales sur le site OO. Je n'ai rien trouvé montrant spécifiquement le code sur la mise en œuvre.

En outre, l'utilisation de fichiers Excel peut être acceptable lors du développement d'un jeu afin que les données puissent être modifiées sans surcharge à partir d'une base de données. Toutefois, et cela est important, si vous prévoyez de le faire, vous devez avoir installé MS Office pour pouvoir référencer Microsoft Excel Interop COM. Cela peut être bénéfique au début, mais je ne voudrais pas supprimer ou modifier un tas de code pour préparer une application pour Alpha, Beta ou RC. Une bibliothèque très simplifiée demanderait plus d'efforts que je ne le verrais utile.

Je vais utiliser des fichiers .CSV pour le stockage de données à un stade précoce. Il y a quelques inconvénients, mais dans l'ensemble, je pense que c'est une bien meilleure option. Tout est contenu dans mes bibliothèques. .Net a des classes très utiles pour lire ces fichiers texte. De plus, en tant que fichiers .CSV, les données sont facilement manipulables; et, pour les étapes ultérieures du développement, tout ce que je dois faire est de sérialiser mes fichiers de données en XML, puis plus tard en binaire chiffré sérialisé.

Tant que la nature de vos données permet de les stocker dans une feuille de calcul sans passer par trop de cercles, cela constitue un très bon format, en particulier pour les travaux de développement. En fin de compte, vous voudrez peut-être le stocker dans d'autres formats pour l'utiliser, mais la feuille de calcul vous donne un éditeur très puissant qui peut être TRÈS agréable si vous décidez de changer la façon dont vous gérez quelque chose!

Si vous utilisez Excel, procurez-vous une copie des utilitaires ASAP - cela transforme la feuille de calcul en un éditeur encore meilleur.

Eh bien, pour moi, je pense que les programmes speartesheet ne peuvent pas gérer ces choses correctement et efficacement. RDB a été conçu, en fait, pour gérer d'énormes données et tables. Les RDB modernes ont été conçus pour gérer le genre de choses «énormes» et ils le font très bien.

Le point est, pour obtenir la meilleure sortie du RDB dont vous avez besoin pour concevoir votre base de données de la bonne manière. Si votre schéma de données était médiocre ou ne couvrait pas toutes les données de votre projet, vous obtiendrez de très mauvais résultats, performances et résultats.

L'idée de RDB est de décomposer un grand tableau en plus petits afin d'améliorer les performances et la lisibilité. Si vous avez une très grande table (en termes d'attributs ou même d'enregistrements) ou de nombreuses répartitions, et que vous n'en utilisez pas la plupart, cela signifie que votre conception de la base de données comporte des erreurs.

Dans votre question Huang F. Lei, si on me demandait de concevoir une base de données MMORPG, je n'ajouterais pas toutes les compétences dans une table et tous les mobs dans une table. Je vais diviser les compétences en fonction de leurs classes et de leur utilisation en plusieurs tables. Chaque type de compétence aura sa propre table ou même des tables. Pour les foules, je les diviserai selon leur type ou selon leur emplacement dans différents mondes. Etc.

De cette façon, je peux réduire la taille des tableaux, faciliter le suivi des données et améliorer les performances de la base de données.

Dans Excel, en revanche, toutes les données seront «ramassées» en un seul endroit. et trouver une donnée est presque infranchissable, épiquement quand vous avez des données répétées. De plus, à mesure que la taille des données augmente, le temps d'ouverture du fichier augmente.

À la fin, Excel - à mon avis - est un très mauvais moyen de gérer d'énormes données connexes.