WorldRegenerator 2.0
- 16817
- 12
- 57
1 февраля прошла первая регенерация карты в этом году. К этому небольшому событию мы подготовились, обновив наш регенератор. Обновлённая версия регенератора выполняет тот же объём работы всего за 5 мин., вместо прежних 7 часов. Рассказываем вам, как всё это работает.
Трущобы со множеством столбов сменились чистой равниной с одиноко стоящими постройками. Однозначно стало лучше :p_up:
Так появился оффлайн-режим. Для того, чтобы полноценно поработать с файлами карты, сервер должен быть выключен - иначе результат может быть перезаписан из памяти сервера; либо повредить чанк, если сервер и регенератор начнут записывать один и тот же файл одновременно.
Метод удаления чанков по сути переводит чанки в "несгенерированное" состояние, будто вы только что создали мир. От старой карты остаются только чанки с постройками, так что заново они генерироваться не будут. Данный метод позволяет ещё получить качественную генерацию, ведь происходит обычная генерация мира. API сервера конечно позволяет регенерировать чанки в игре, но работает это, мягко говоря, не очень - чанки каждый раз генерируются по-разному (в особенности деревья), на стыках чанков это выглядит некрасиво. Потому в основном мире мы никогда не использовали регенерацию, всегда восстанавливали чанки из резервной копии (это первый секрет успеха нашего плагина).
Успешно протестировав удаление чанков, стало ясно, что данный метод можно применить в основном мире. Только вместо удаления чанка, он будет заменяться версией из резервной копии. Это в тысячи раз быстрее, чем пересобирать чанк по каждому блоку в игре - много драгоценного времени тратилось на всякие обновления блоков и медленный API (для работы игры его скорости вполне достаточно). Ещё одно достоинство метода - полный перенос чанка со всей информацией (биомы, мобы и т.п).
Карта состоит из файлов регионов (*.mca), которые хранят в себе сетку 32x32 из чанков. Формат файла региона напоминает диск, на котором каждый чанк хранится в отдельном из 1024 разделов: каждый чанк расположен в файле по фиксированному адресу, зависящему от его координат. Такой подход обеспечивает быструю загрузку чанков - сразу известно, с какой позиции нужно читать файл. А главное - это ещё обеспечивает высокую надёжность. Потому в случае недозаписи чанка, это не приводит к смещению байт во всём файле (повреждение всех чанков в файле).
Зная как примерно устроен файл региона, мы пошли ещё на одну хитрость ради ускорения региона. Список чанков, которые нужно сохранить, разбивается по файлам региона, чтобы можно было быстро проверять, какие чанки в каждом файле региона нужно сохранить. Если в регионе нет чанков для сохранения, то регенератор даже не будет парсить файл региона - он отдаст файловой системе команду на удаление, либо копирование файла региона из снимка целиком. Так что теперь скорость оффлайновой регенерации целиком зависит от скорости диска. У нас в среднем регенерация основного и нижнего миров заняла 2,5 мин. (SSD) и 35 сек. (NVMe).
Новый метод конечно не обошёлся без недостатков. Как уже говорилось, чанки полностью со всеми свойствами возвращаются в первоначальное состояние, а значит в первые 2-3 дня после регена, снова придётся терпеть лаги связанные с просчётом освещения ¯\_(ツ)_/¯
Немного ностальгии
Регенератор у нас появился в конце 2015 года. Тогда шёл разговор о его возможностях и зачем это нужно. Но до сих пор мы не подвели итоги, как регенератор изменил карту...Трущобы со множеством столбов сменились чистой равниной с одиноко стоящими постройками. Однозначно стало лучше :p_up:
Проблемы регенератора
На пути сделать карту лучше, нас поджидали подводные камни. Серьёзных проблем у регенератора никогда не было - потому что мы всегда делаем надёжно. Были проблемы с производительностью. Наш регенератор очень мощный, что во время его работы играть на сервере почти что невозможно. За счёт этого он успевал обработать основной мир и нижний всего за 7 часов (вместо 15, как у аналогов). Естественно, нам пришлось сталкиваться с различными проблемами вроде нехватки памяти и отката чанков. С этими проблемами мы сталкивались во время применения различных методов ускорения регенерации.Offline Mode
Идея реализовать данный режим назрела давно, да вот, как всегда, руки не доходили. Подтолкнули к его реализации проблемы регенерации нижнего мира - низкая производительность генерации чанков и качество. Тогда было решено применить новый метод - удаление чанков. Но сделать это прямо из игры нельзя - нужно редактировать сами файлы карты.Так появился оффлайн-режим. Для того, чтобы полноценно поработать с файлами карты, сервер должен быть выключен - иначе результат может быть перезаписан из памяти сервера; либо повредить чанк, если сервер и регенератор начнут записывать один и тот же файл одновременно.
Метод удаления чанков по сути переводит чанки в "несгенерированное" состояние, будто вы только что создали мир. От старой карты остаются только чанки с постройками, так что заново они генерироваться не будут. Данный метод позволяет ещё получить качественную генерацию, ведь происходит обычная генерация мира. API сервера конечно позволяет регенерировать чанки в игре, но работает это, мягко говоря, не очень - чанки каждый раз генерируются по-разному (в особенности деревья), на стыках чанков это выглядит некрасиво. Потому в основном мире мы никогда не использовали регенерацию, всегда восстанавливали чанки из резервной копии (это первый секрет успеха нашего плагина).
Успешно протестировав удаление чанков, стало ясно, что данный метод можно применить в основном мире. Только вместо удаления чанка, он будет заменяться версией из резервной копии. Это в тысячи раз быстрее, чем пересобирать чанк по каждому блоку в игре - много драгоценного времени тратилось на всякие обновления блоков и медленный API (для работы игры его скорости вполне достаточно). Ещё одно достоинство метода - полный перенос чанка со всей информацией (биомы, мобы и т.п).
Карта состоит из файлов регионов (*.mca), которые хранят в себе сетку 32x32 из чанков. Формат файла региона напоминает диск, на котором каждый чанк хранится в отдельном из 1024 разделов: каждый чанк расположен в файле по фиксированному адресу, зависящему от его координат. Такой подход обеспечивает быструю загрузку чанков - сразу известно, с какой позиции нужно читать файл. А главное - это ещё обеспечивает высокую надёжность. Потому в случае недозаписи чанка, это не приводит к смещению байт во всём файле (повреждение всех чанков в файле).
Зная как примерно устроен файл региона, мы пошли ещё на одну хитрость ради ускорения региона. Список чанков, которые нужно сохранить, разбивается по файлам региона, чтобы можно было быстро проверять, какие чанки в каждом файле региона нужно сохранить. Если в регионе нет чанков для сохранения, то регенератор даже не будет парсить файл региона - он отдаст файловой системе команду на удаление, либо копирование файла региона из снимка целиком. Так что теперь скорость оффлайновой регенерации целиком зависит от скорости диска. У нас в среднем регенерация основного и нижнего миров заняла 2,5 мин. (SSD) и 35 сек. (NVMe).
Новый метод конечно не обошёлся без недостатков. Как уже говорилось, чанки полностью со всеми свойствами возвращаются в первоначальное состояние, а значит в первые 2-3 дня после регена, снова придётся терпеть лаги связанные с просчётом освещения ¯\_(ツ)_/¯
Вы сами разрабатываете ядро или используете какое-то существующее? Если собственное ядро, то в чём проблема модификации ядра для обнуления чанков на ходу? Более того, на мой взгляд регенератор должен быть частью ядра, проводя обнуление чанков параллельно с работой сервера. Так, например, изначально формировать список всех чанков которые нужно обнулить. После этого на ограниченной скорости обрабатывать список. Если чанк выгружен и без привата => Обнуление, удаление из списка. Если чанк в привате - просто удаление из списка. Если чанк загружен => пропуск чанка, обработка остальной части списка. Итерации происходят по определённому интервалу, обрабатывая список. На конец итерации список либо пуст, либо содержит загруженные чанки вне привата, которые должны будут быть удалены в течении следующей итерации.
А смысл в ядро пихать? Большой необходимости в интеграции нет, оффлайновый реген реализуется намного проще и работает очень быстро. Вот границу мира и anti-xray действительно есть смысл туда "пихать".
Ты удивишься, но есть как минимум две больших беседы по программированию майна на пе и ПК. Про остальное вообще молчу