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

Question

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

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

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

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

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

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

Answer 1

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

Посмотрите на полку Питона pickle, .

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

---

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

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

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

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

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

Answer 2

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

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

Answer 3

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