Совпадение с ванилью

Просто “совпадает с ванилью” слишком расплывчато, чтобы это можно было протестировать. Поэтому в mcrs каждая подсистема объявляет одну из трех политик, а политика говорит, что обязано совпадать и что может отличаться. Утверждению на странице или в README можно верить ровно настолько, насколько сильны его политика и его тест.

Каждая подсистема объявляет один из трех уровней

Уровень	Что значит	Примеры в mcrs
exact (точный)	наблюдаемое поведение совпадает очень близко	сетевой протокол, байты NBT и Anvil, генерация мира для seed, арифметика движения игрока
semantic (семантический)	совпадает игровой результат, порядок работы внутри тика может не совпадать	освещение, жидкости, редстоун, обновления соседей, случайное поведение (распределения, а не ванильная последовательность случайных чисел)
intentional deviation (намеренное отклонение)	поведение ванили случайное или патологическое, поэтому mcrs отличается намеренно и записывает это	у каждого отклонения есть запись в спецификации с правилом, эталонным поведением, тем, что видит клиент, и тем, что делает дифференциальный тест

Уровней детерминизма в проекте три, потому что ни одна из крайностей не работает.¹ Совпадать с эталоном везде значило бы копировать порядок, в котором Java обходит хеш-таблицы, а если не совпадать нигде, совпадение с ванилью нельзя будет проверить. Полная таблица по подсистемам есть в разделе 2 заметки о шардировании.

Сейчас семантика, позже точность

Редстоун, жидкости и обновления блоков пока семантические. Их очереди хранят поля, по которым упорядочивает ваниль, то есть тик срабатывания, приоритет и порядковый номер вставки, а сам порядок - одна заменяемая политика на область. Чтобы перейти к ванильному порядку тик в тик, достаточно сменить эту политику, и проверяется такая смена по записанным фикстурам.² Самого редстоуна пока нет.³

У каждого правила в спецификации есть вид

Спецификация в docs/spec/ описывает поведение правилами. У каждого правила есть вид, и виды определены в docs/spec/README.md.

Вид	Что утверждает правило
Wire	Байты, id и кодеки, которые декодирует ванильный клиент. Здесь совпадение точное.
Согласование с клиентом	Сервер должен вычислить то же, что вычисляет клиент, например разбор командной строки.
Семантика	Смысл. Порядок внутренних операций остается свободным.
Layout	Позиция, размер или цвет элемента GUI клиента. Проверяется скриншотом в известном масштабе.
Отклонение	Дефект эталона, для которого указано правильное поведение.
Не определено	Реализация выбирает сама. Parity-тест не должен это сравнивать.

Как проверяется утверждение

Возьмем генерацию мира, единственное место, где проект сегодня говорит “совпадает с ванилью в parity-тестах”. Это утверждение значит, что результаты плотности, поверхности, биомов и структур равны oracle на тех seed и чанках, которые попали в дампы. Оно не значит “бит в бит на любом seed”. Для всего остального на странице Статус формулировки свои. За таким утверждением стоят три вещи.

Первая - дампы oracle. tools/vanilla-oracle - отдельный Gradle-проект, который не запускает ни сервер, ни клиент. Он загружает реестры самой игры, сэмплирует ее генерацию мира и пишет бинарные дампы, а Rust-тесты сравнивают их поэлементно. Повторный запуск дает побайтово одинаковые файлы. В дампы попадают seed 1, 2 и 42 и несколько позиций чанков, так что это проверка на эталонных seed, а не на всех.

Вторая - фикстуры. tools/fixtures.json перечисляет 49 снятых фикстур. Около 14 из них покрывают генерацию мира, остальные относятся к другим областям, например к командам, протоколу и физике. Фикстуру снимают с игры и коммитят. После обновления снапшота recapture создает фикстуры заново, об этом рассказывает страница Одна версия игры за раз.

Третья - метки происхождения. У каждого правила есть метка, которая говорит, откуда оно взято, и по ней видно, насколько правилу можно доверять. Например, source_suggested значит, что автор прочитал эталон, а правило описывает только поведение. Когда эксперимент на игре подтверждает правило, метка меняется на подтвержденную. Подробности есть в реестре папки спецификаций.

Совпадение никогда не получают чтением кода игры

Авторы спецификаций могут читать код игры, исполнители не могут, и один человек не совмещает обе роли для одного поведения. Правило целиком описано на странице Clean-room на практике. Артефакты, которые создает игра, считаются допустимыми свидетельствами: это датапак, отчеты, дампы oracle и снятые пакеты. Как добавить правило или parity-тест, показано на странице Спецификации и parity-тесты.

Footnotes

1. Работает#367 Решение, которое вводит три уровня детерминизма. ↩

2. В работе#272 Отслеживает запись ванильных результатов в виде фикстур. ↩

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