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

9

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

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

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

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

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

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

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

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

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

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

Данияр
источник
Возможно, вы захотите рассмотреть объектные базы данных поверх реляционных баз данных, которые решают некоторые из проблем, упомянутых в принятом ответе о хрупкой схеме и тому подобное.
ashes999
Если у вас есть процессы, лучше подходящие для реляционной базы данных, вы можете использовать встроенный SQL с гибридным доступом к памяти. Это обойдёт многие проблемы, которые делают традиционные базы данных SQL неподходящими для требований к производительности игр.
Ровыко

Ответы:

11

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

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

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

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

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

Kylotan
источник
2
В итоге я использовал SQLite для сохранения состояния игры. Поскольку я использую систему сущностей, это вполне логично: все, что у меня есть, это свойства. Каждый тип свойства имеет свою таблицу в базе данных, а сущности связаны своим (глобальным уникальным) идентификатором. Но, скажем, в базах данных систем наследования не было бы особого смысла, я думаю.
Данияр
1
Да, я думаю, что использование SQLite для сохранения игрового состояния - хорошая идея, если вы планируете делать это с самого начала. Я бы не хотел, чтобы БД была главным местом, где хранятся игровые данные во время игры.
Kylotan
5

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

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

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

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

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

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

API-Beast
источник
2
SQL-сервер имеет пространственные индексы. Он не будет перебирать все записи, но будет использовать умный индексный подход
MichaelD