Оба подхода используются с MMORPG. Хранение всего в памяти и периодическая проверка наведения на диск кажется наиболее популярным вариантом, по крайней мере, для старых игр. Его преимущество в том, что он довольно прост в реализации и достаточно хорошо масштабируется, но сделать его надежным полностью зависит от разработчика. Базы данных SQL предоставляют свойства ACID, которые облегчают надежность, но в целом сложнее в реализации и могут иметь проблемы с масштабированием.
EVE Online - это пример MMO, где все хранится в базе данных SQL. Я думаю, что он достиг примерно 60000 одновременных пользователей, и ему пришлось выделять какое-то дорогостоящее оборудование для серверов баз данных на протяжении многих лет, чтобы не отставать от нагрузки. Однако EVE хранит намного больше данных на пользователя, чем большинство MMORPG, и имеет гораздо более частые и разнообразные транзакции. Свойства ACID базы данных позволяют поддерживать целостность всей массивной и сложной базы данных.
Например, рассмотрим случай, когда кто-то передает предмет другому игроку. База данных EVE гарантирует, что даже в случае сбоя или сбоя питания предмет попадет в инвентарь только одного игрока. То есть транзакция базы данных, которая удаляет элемент из инвентаря одного игрока и добавляет его в инвентарь другого игрока, является атомарной. Сделка либо полностью завершена, либо не происходит вообще. Вы не можете оказаться в состоянии, если предмет не существует ни в инвентаре игроков, ни в обоих.
MMORPG, которая хранит данные игрока в памяти и периодически проверяет, должна ли она сама реализовывать эту атомарность. Одним из способов сделать это будет одновременная проверка данных каждого игрока, гарантируя, что новая контрольная точка будет полностью зафиксирована на диске до того, как она будет считаться самой последней контрольной точкой. Игра также должна была бы гарантировать, что данные игрока не могут измениться во время проверки. С большим количеством активных игроков, задача становится делать все это, не вызывая задержки достаточно долго, чтобы игроки заметили.
Не стоит недооценивать, насколько важна последовательность. Когда вы разрабатываете свою игру, она очень часто падает. Вам не нужно отслеживать, почему предметы исчезают и / или дублируются, а не тогда, когда проблема связана с ошибкой, приводящей к аварийному завершению игры. Более того, когда ваша игра выйдет в эфир, она рухнет намного сильнее, чем вы ожидаете. Ваш сервер, который отлично работал при тестировании, неожиданно обнаружит многочисленные ошибки при полной нагрузке и действия игроков, о которых вы не ожидали.
Обратите внимание, что большинство MMORPG используют базы данных SQL для информации, связанной с учетной записью, даже если они не для реальных игровых данных. Еще более важным, чем сохранение состояния игры в согласованном состоянии, является поддержание согласованности состояния выставления счетов. В худшем случае, если база данных игры будет повреждена, вам придется восстанавливать базу данных из ежедневной резервной копии. В худшем случае, если база данных аккаунта будет повреждена, вы обанкротитесь из-за всех возвратных платежей.
Для вашего проекта вы можете пойти в любую сторону. 1000 одновременных пользователей, вероятно, не будут расширять границы возможностей, которые SQL-сервер может обрабатывать на обычных ПК в наши дни, но многое будет зависеть от характера транзакций. Если вы знакомы с SQL и проектированием реляционных баз данных, это может сработать для вас. Вы захотите свести к минимуму количество транзакций, насколько это возможно, для чего-то вроде текущих хитпоинтов игрока вы можете лишь периодически сохранять их в базе данных, поскольку подобная статистика не обязательно должна быть согласованной. (Хотя в PvP-игре они могут ...) Вообще не храните в базе данных такие вещи, как monster HP, в большинстве игр сохраняются только данные, относящиеся к игроку.
С другой стороны, если вы не являетесь мастером SQL, вам может показаться, что хранить все данные в памяти гораздо проще для надежной работы. Базы данных SQL упрощают согласованность и надежность, но не обеспечивают автоматическую работу. Плохо спроектированная база данных может работать плохо и приводить к несоответствиям. Транзакции не будут атомарными, если вы их не сделаете. Если вы не будете религиозно использовать параметризованные операторы, вы откроете себя для атак SQL-инъекций.