Каждая зона хранится отдельным файлом, и содержит в себе свои внутренние локации и связи.
Межзональные связи хранятся в ближайшем общем владельце, например связь между городом и домом хранится в зоне города, так как зона дома является вложенной в нее. А прямая связь между двумя городами может быть в зоне страны, в которой находятся оба города. Если они не в одной стране, то в зоне материка. И т.д.
Редактор зон должен поддерживать такое понятие, как «открытые связи». Это вход или выход, имеющий один конец в текущей зоне, но где будет второй конец, пока неизвестно. Это поможет внешне представить зону, не зная, куда именно она будет присоединена. Например, можно описать внешний вид дома, вход в него и выход из него, но куда будет поставлен этот дом — дело того, кто занимается городом и его улицами.
Редактор должен позволять вкладывать другие зоны, и привязывать их открытые связи к локациям текущей зоны или открытым связям другой вложенной зоны.
Разрешены лишь просмотр локаций и связей вложенной зоны, и перемещение всей зоны в целом. Для редактирования зоны нужно открыть ее как текущую.
В самом Нереале организация вложенности зон может быть реализована двумя способами. У каждого есть свои плюсы и минусы.
1. Глобальная коллекция зон с глобальной же идентификацией. В свойствах зоны есть ссылка на вышестоящую зону, или отсутствие ссылки, если это корневая зона.
Плюсы — простота хранения (один каталог с множеством файлов, по файлу на зону), простота поиска по идентификатору (всего одна коллекция), меньшая длина ссылочных идентификаторов.
Минусы — необходимость следить за глобальной уникальностью идентификаторов зон.
2. Глобальная коллекция содержит только корневые зоны, все вложенные зоны содержатся в коллекциях внутри вышестоящих зон.
Плюсы — уникальность идентификаторов зон нужно поддерживать лишь на одном уровне вложенности, а так вполне могут быть две зоны school в разных городах. Более того, можно даже прикрепить одну и ту же зону в разные места, не меняя ее собственного идентификатора (шаблон школы или трактира).
Минусы — большая длина полных идентификаторов (например Nereal/Vadelon/Arvest/school), более долгий поиск, ограничения файловой системы на совпадение имен файлов (поэтому надо как-то раскидывать по каталогам)..
Замечания — хоть полные идентификаторы и длиннее, идентификаторы самих зон, наоборот, короче (просто school вместо arvest_school). Поиск по идентификатору необходим только при загрузке мира, и его скорость не так критична, да и по полному идентификатору мы знаем, где искать. В процессе работы же везде хранятся прямые ссылки, и обращается по ним же, потому поиск не важен. Единственный существенный минус — это файловая система, но и для него наверняка можно найти подходящее решение.
Добавить новую зону достаточно просто, надо положить файл от редактора зон в то место, откуда их сможет прочесть Нереал, и ввести специальную команду в Нереале. Скорее всего, кроме добавления самой новой зоны, придется обновить вышестоящую зону, дабы соединить открытые связи.
Обновление зоны может быть четырех видов:
1. Кардинальная перестройка. В этом случае производится просто удаление старого варианта зоны и добавление нового.
2. Изменение/поправка расположения локаций, вложенных зон, или свойств локаций и связей. Тогда у зоны обновляется все это, но не затрагиваются вещи и персонажи, находящиеся в ней.
3. Изменение вещей/персонажей в зоне. Это просто обновление шаблонов вещей и персонажей, никак не затрагивающее саму зону. Производится из редактора шаблонов и требует подключения к Нереалу.
4. Добавление или удаление вещей/персонажей в зоне. Производится из редактора зон и требует подключения к Нереалу. Состоит из цикла: запрос текущего списка вещей или персонажей, работа над ним, и отправка обратно.
Такое разделение видов обновлений поможет получить изменчивость мира, без потери легкости его постройки и поддержки.
Для работы с шаблонами должны быть написаны два отдельных редактора. Они требуют подключения к Нереалу, но не постоянного, а только на моменты запросов и отправки результатов. В функции этих редакторов входит следующее. (здесь под шаблоном одинаково понимаются и вещь и персонаж, но каждый из редакторов работает над своим видом шаблонов)
1. Запрос полного текущего списка шаблонов. Этот список может быть использован в редакторе зон.
2. Запрос полных данных о нужных шаблонах, просмотр, изменение, и добавление шаблонов. Изменять можно только те шаблоны, что ранее были добавлены тем же пользователем. Или любые, если пользователь имеет особые права доступа.
3. Отправка обратно в Нереал измененных и добавленных шаблонов и разрешение возможных конфликтных ситуаций. (например, если добавлен шаблон с уже существующим идентификатором)
Функция 2 предполагает знание о типах вещей и персонажей, и об их свойствах. Поэтому редакторы должны либо развиваться синхронно с Нереалом (и проверять версию при подключении), либо каким-то образом универсально поддерживать не только известные типы и свойства, но и будущие. Например, иметь функцию запроса сведений о типах и свойствах, или же полагаться во всем на пользователя, предоставляя лишь базовые возможности, и реализовав редактирование самого шаблона в виде обычного текста.
Такая система позволит распределить и облегчить работу над шаблонами, а так же обеспечит третий случай обновления зон.
Редактор зон должен предоставить возможность расстановки по локациям вещей и персонажей, основываясь на списках шаблонов, полученных от редакторов шаблонов. Непосредственно по этому наполнению создаются вещи и персонажи только при создании новой зоны или при кардинальном обновлении. В дальнейшем их изменение делается соответственно четвертому случаю обновления зон.