Dois-je utiliser une base de données SQL pour stocker des données dans un jeu de bureau? [fermé]

Développement d'un moteur de jeu

Je prévois un jeu vidéo et son moteur. Il y aura un monde en 3 dimensions avec une vue à la première personne et ce sera pour le moment en solo. Le langage de programmation est C ++ et il utilise OpenGL.

Décision de conception centrée sur les données

Ma décision de conception est d'utiliser une architecture centrée sur les données où il y a un gestionnaire d'événements global et un gestionnaire de données global . Il existe de nombreux composants comme la physique, l'entrée, le son, le rendu, l'IA, ... Chaque composant peut déclencher et écouter des événements . De plus, chaque composant peut lire, éditer, créer et supprimer des données .

La question concerne le gestionnaire de données.

Utiliser ou non une base de données relationnelle

Dois-je utiliser une base de données SQL, par exemple SQLite ou MySQL, pour stocker les données du jeu? Celui-ci contient pratiquement tout le contenu du jeu comme des objets, des personnages, des inventaires, ... À l'exception des maillages et des textures qui sont encore plus liés aux performances, je les garderai donc en mémoire.

Une base de données SQL est-elle assez rapide pour l'utiliser pour lire et écrire des informations de jeu en temps réel, comme la position d'un personnage en mouvement? Je dois également me soucier de la compatibilité multiplateforme. En plus de tout garder en mémoire, quelles alternatives ai-je?

Les avantages seraient

Les avantages d'utiliser une base de données relationnelle comme MySQL seraient la structure orientée données qui permet un calcul rapide. Je n'aurais pas besoin d'objets pour représenter des entités. Je pouvais facilement interroger les données d'objets proches du lecteur nécessaires au rendu. Et je n'ai pas à me soucier des données d'objets éloignés. De plus, il n'y aurait pas besoin de sauvegardes car l'état du jeu de trous est enregistré dans la base de données. Enfin, étendre le jeu à un jeu en ligne serait relativement facile car il existe déjà un endroit où l'état du jeu de trous est stocké.

Une base de données SQL n'est pas assez rapide à utiliser pour lire et écrire des informations de jeu en temps réel. Ces données sont presque toujours conservées en mémoire, dans les structures de données traditionnelles.

Il peut être avantageux d'utiliser une base de données intégrée telle que SQLite pour certains types de données, par exemple. données statiques qui ne changent pas pendant le jeu mais qui changent pendant le développement. Cela pourrait ensuite être déployé dans le cadre du jeu final où SQLite n'est vraiment utilisé que lors du premier chargement du jeu, ou lors du démarrage d'un nouveau niveau, etc.

Cependant, il y a aussi de nombreux inconvénients - il est difficile de corriger des parties individuelles des données lorsqu'elles sont stockées dans un seul fichier de base de données, ce n'est pas idéal pour de nombreux types de données complexes dont les jeux ont besoin (et que vous avez dit que vous stockeriez extérieur - mais aura des références vers et à partir de choses à l'intérieur), il n'est pas très flexible lorsque vous devez changer le schéma, il n'est pas nécessairement rétrocompatible après avoir changé le schéma, etc.

Pour ces raisons, la plupart des développeurs de jeux utiliseront simplement leur propre format. Les développeurs professionnels soucieux des performances vont parfois plus loin et enregistrent la structure de données en mémoire directement sur le disque afin de pouvoir la charger avec un minimum de traitement.

Et si vous avez vraiment besoin de données tabulaires textuelles faciles à modifier, vous pouvez utiliser un format texte simple, tel que CSV, XML, JSON, YAML, etc.

Une base de données n'est pas rapide, l'utilisation d'une base de données est beaucoup plus lente que l'accès à la mémoire traditionnel. La raison est simple, une base de données est dynamique, il y a un tas de frais généraux attachés à elle, les requêtes doivent être analysées, les hachages doivent être calculés et d'autres choses.

Il n'y a qu'un seul avantage à utiliser une base de données et c'est la persistance. Vous pouvez exécuter une ou plusieurs applications avec une seule base de données sur une longue période de temps sans avoir à craindre de nombreuses données. Mais les clients de jeux n'en ont absolument pas besoin.

Donc, vous voulez obtenir tous les objets à moins de 1000 pixels de distance?
Ce serait:

List<Entity> retVal;
for(entity in entities)
  if(Distance(entity.pos(), to) < 1000)
     retVal.append(entity);
return retVal;

Maintenant, que pensez-vous qu'une base de données ferait-elle si vous lui demandiez de retirer tous les objets à moins de 1000 pixels?
Cela ferait exactement la même chose! Juste avec un tas de frais généraux qui rendraient cette opération extrêmement simple coûter environ 100 fois le temps du processeur (selon le nombre d'entités que vous avez). Les bases de données ne sont pas magiques.

N'utilisez pas de bases de données pour autre chose que des applications serveur.