Проектирование хранилища для очень большого игрового мира

Question

Я снова начинаю программировать игры.10 лет назад я делал игры на qbasic и с тех пор не занимался программированием игр, так что я довольно сильно подзабыл.Хотя я все время программировал, сейчас я веб-разработчик / администратор базы данных / .У меня есть несколько вопросов, но я собираюсь ограничить их одним на пост.

Игра, над которой я работаю, будет большим, очень большим миром.Это будет чем-то похоже УРВ, но мир еще больше и больше похож на "RPG".

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

У кого-нибудь есть какие-либо советы о том, как мне следует поступить с этим, или идеи для других методов хранения?

Вот требования к моей игре:

• Мне нужен полный случайный доступ к spot в игровом мире (NPC, монстры, животные будут активны все время).
• Я использую Stackless Python 3.1, возможности довольно ограничены, если я не выполняю много работы.
• Нужно уметь обращаться с очень большим миром.
• Поддержка параллелизма была бы плюсом, но я не думаю, что она мне понадобится.

Answer 1

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

Посмотрите на Python's pickle, отложить на полку.

Стеллаж готовится быстро и хорошо масштабируется.Это устраняет беспорядочное преобразование между представлением на Python и не-Python.

---

Редактировать.

Более важный совет.Не увязайте в выборе технологии.Получите локации, предметы, персонажей, правила и т.д.Для работа.На языке Python.Как можно проще и корректнее.

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

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

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

Answer 2

Это звучит так, как будто то, о чем вы просите, является своего рода пространственный индекс.Для очень большой 2d-игры я бы рекомендовал использовать квадродерево.Quadtree хорошо работает, когда у вас большая территория и активность, как правило, происходит в локализованных регионах этой области, что характерно для большинства игр типа RPG.Это снизит ваши требования к хранилищу и, надеюсь, также ускорит обнаружение столкновений.

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

Answer 3

Я использую нереляционную базу данных для хранения больших объемов данных.Если вы можете работать на 64-битном оборудовании, MongoDB с его Драйвер Python это действительно очень хорошо.Я не знаю, нормально ли это с Stackless, но это возможно.