Почему mcrs: новое устройство, а не переписывание

Допустим, вы переписали классы Java-сервера в Rust-структуры. Общие объекты оказываются за Arc<Mutex<...>>, а тик игры идет в одном потоке, вокруг которого крутятся async-задачи. Получается тот же объектный граф с borrow checker, только еще и с блокировками.

Новый язык этого не исправит, как и промпт “rewrite Minecraft in Rust, make no mistakes”. Самое трудное здесь - решить, как должна быть устроена игра, когда Java больше нет, и на это уходит большая часть работы в репозитории. mcrs начинает с движка.

ECS и есть движок

ECS расшифровывается как entity component system. Состояние мира хранится в компонентах и ресурсах, а поведение задают системы. Система - это одно преобразование над всеми сущностями, у которых есть нужные ей данные. Если системы обращаются к разным данным, планировщик Bevy запускает их параллельно, а одна система может еще и разделить свои сущности между потоками. Блокировки для этого никто не пишет.

Цель - код mcrs без Arc, без Mutex и без trait object на горячем пути. Эта работа еще идет.¹ Сама модель объяснена на странице От объектов к данным.

Параллельно работает то, что не пересекается по данным

Обычно, чтобы занять больше ядер, с главного потока выносят отдельные задачи, например поиск пути или отслеживание сущностей. mcrs смотрит на то, что каждая часть работы читает и что пишет.

Возьмем мобоферму и редстоун, который ей управляет. Они стоят в одних и тех же чанках, но ИИ мобов и редстоун работают параллельно, как и две фермы на разных концах базы. То, что действительно влияет друг на друга, остается вместе и выполняется по порядку, а результат одинаков при любом числе потоков.

Сам редстоун пока не реализован, поэтому пример с фермой показывает целевой дизайн.² Подробности есть на странице Как тик идет параллельно.

Работа пропорциональна изменениям

Цель в том, чтобы сущность в покое и нетронутая секция не добавляли работы в тик.³ Стоимость простоя и время кадра измерены в PERF.md, и каждое исключение из этих правил ссылается на число оттуда. Память на секцию пока не измерена.⁴ См. Производительность и как мы меряем.

Сначала спецификация, потом код

Каждую область пишут по спецификации из docs/spec/ и по правилам clean-room. Ваниль - эталон для данных и наблюдаемого поведения, а устройство кода у нас свое. См. Clean-room на практике.

Совпадение с ванилью объявлено и проверяется

Каждая подсистема относится к одной из трех групп. В группе exact протокол, сохранения, движение игрока и генерация мира. В группе semantic редстоун, жидкости и обновления блоков. Третья группа - намеренные отклонения, и каждое из них записано.

Точные части сравниваются с выводом игры, а генерация мира уже совпадает с ванилью в parity-тестах. См. Совпадение с ванилью.

Крейты можно брать по одному

Большинство крейтов для Minecraft делают одно дело, например читают NBT, открывают region-файлы, разбирают схематики или рисуют карту. Одних NBT-крейтов много, и у каждого свои типы, поэтому, чтобы подружить два таких крейта, приходится конвертировать типы друг в друга.

Крейты mcrs тоже можно брать по одному, но типы у них общие. Состояние блока, прочитанное из сохранения, - то же самое значение, из которого рендерер строит меш и которое ставит генератор мира. Слоям ниже движка Bevy не нужен, а tokio нужен только сетевому слою. Слои описаны на странице Слои и крейты, а крейты перечислены в Карте крейтов.

Содержимое игры читается из данных во время работы

Реестры, биомы, измерения, генерация мира и атрибуты окружения читаются из ванильного датапака. Датапак, который добавляет биом или измерение, подхватывается без пересборки. Serde-типы читают JSON датапака, пишут NBT сохранения и передаются по сети, то есть делают то же, что в ванили делает кодек. См. Миры и сохранения.

mcrs идет за новейшим снапшотом

mcrs работает с одной версией игры за раз, сейчас это 26.4-snapshot-7. Данные и отчеты заново генерируются из jar игры одной командой, поэтому переход на следующий снапшот в основном сводится к обновлению данных. См. Одна версия игры за раз.

Footnotes

1. В работе#566 Направление: код библиотеки без разделяемого владения, блокировок, трейт-объектов и аллокаций на горячем пути. ↩

2. В работе#190 Отслеживает редстоун-схемы, которые ведут себя как в ванили. ↩

3. Частично#365 Решение о том, что работа пропорциональна изменениям, а не числу объектов. ↩

4. В работе#324 Отслеживает фиксацию размера компонентов и подсчет памяти секций. ↩