Должен ли я использовать базу данных SQL для хранения данных в настольной игре? [закрыто]

Разработка игрового движка

Я планирую компьютерную игру и ее движок. Будет трехмерный мир с видом от первого лица, и пока это будет одиночная игра. Язык программирования - C ++, и он использует OpenGL.

Решение по центру данных

Мое проектное решение - использовать архитектуру, основанную на данных, где есть глобальный менеджер событий и глобальный менеджер данных . Есть много компонентов, таких как физика, вход, звук, рендерер, AI, ... Каждый компонент может запускать и прослушивать события . Кроме того, каждый компонент может читать, редактировать, создавать и удалять данные .

Вопрос по поводу менеджера данных.

Использовать ли реляционную базу данных

Должен ли я использовать базу данных SQL, например, SQLite или MySQL, для хранения игровых данных? Он содержит практически весь игровой контент, такой как предметы, персонажи, инвентарь, ... За исключением мешей и текстур, которые еще более связаны с производительностью, поэтому я буду хранить их в памяти.

Достаточно ли быстра база данных SQL, чтобы использовать ее для чтения и записи игровой информации в реальном времени, например, позиции перемещающегося персонажа? Мне также нужно заботиться о кроссплатформенной совместимости. Помимо хранения всего в памяти, какие альтернативы у меня есть?

Преимущества будут

Преимущества использования реляционной базы данных, такой как MySQL, заключаются в ориентированной на данные структуре, которая обеспечивает быстрые вычисления. Мне не нужны объекты для представления сущностей. Я мог легко запросить данные объектов рядом с плеером, необходимые для рендеринга. И мне не нужно заботиться о данных объектов далеко. Кроме того, не было бы необходимости в сохранении игр, так как состояние «дырки» сохраняется в базе данных. И последнее, но не менее важное: расширение игры до онлайн-игры было бы относительно простым, потому что уже есть место, где хранится состояние закрытой игры.

База данных SQL не достаточно быстра, чтобы использовать ее для чтения и записи игровой информации в реальном времени. Такие данные почти всегда хранятся в памяти, в традиционных структурах данных.

Может быть некоторое преимущество использования встроенной базы данных, такой как SQLite, для определенных типов данных, например. статические данные, которые не меняются во время игры, но меняются во время разработки. Затем его можно будет развернуть как часть финальной игры, где SQLite действительно используется только при первой загрузке игры или при запуске нового уровня и т. Д.

Однако есть и много минусов - трудно исправить отдельные части данных, когда они хранятся в одном файле базы данных, это не идеально для многих типов сложных данных, которые нужны играм (и которые, как вы сказали, будут хранить снаружи - но будет иметь ссылки на вещи изнутри), он не очень гибок, когда вам нужно изменить схему, он не обязательно обратно совместим после изменения схемы и т. д.

По этим причинам большинство разработчиков игр будут использовать свой собственный формат. Профессиональные разработчики, которые заботятся о производительности, иногда делают еще один шаг и сохраняют структуру данных в памяти непосредственно на диск, чтобы ее можно было загрузить с минимальной обработкой.

И если вам действительно нужны текстовые табличные данные, которые легко редактировать, вы можете использовать простой текстовый формат, такой как CSV, XML, JSON, YAML и т. Д.

База данных не быстрая, использование базы данных намного медленнее, чем традиционный доступ к памяти. Причина проста, база данных является динамической, к ней прикреплено множество служебных данных, необходимо проанализировать запросы, вычислить хэши и выполнить другие действия.

Есть только одно преимущество от использования базы данных, и это постоянство. Вы можете запускать одно или несколько приложений с одной базой данных в течение длительного периода времени, не опасаясь потери данных. Но игровые клиенты в этом абсолютно не нуждаются.

Итак, вы хотите получить каждый объект, который находится на расстоянии менее 1000 пикселей?
Это было бы:

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

Теперь, что, по вашему мнению, будет делать база данных, если вы попросите ее удалить каждый объект менее чем на 1000 пикселей?
Было бы точно так же! Просто с кучей накладных расходов, которые сделали бы эту чрезвычайно простую операцию примерно в 100 раз больше процессорного времени (в зависимости от того, сколько у вас объектов). Базы данных не волшебство.

Не используйте базы данных ни для чего другого, кроме серверных приложений.