Принцип принят при старте проекта; запись извлечена из замороженного
10-reference/tech-stack.
Решили: детерминизм боя — несущая стена архитектуры, а не страховка под мультиплеер. Один механизм (детерминированная симуляция + лог команд + сид) даёт сразу три вещи: реплеи, сравнение AI-профилей между собой и воспроизводимость забега по сиду.
Почему: если считать детерминизм страховкой под сеть, он выглядит платой за фичу, которой ещё нет —
и первым же идёт под нож при любом упрощении. А он оплачен трижды и работает уже в одиночке: без него
нельзя ни повторить баг по сиду, ни честно сравнить два AI-профиля на одном бою, ни записать реплей.
Именно поэтому запреты вокруг него жёсткие и не обсуждаются по одному: UnityEngine.Random только через
IRngService, никакой физики Unity и Time.deltaTime в симуляции, никакого обхода Dictionary/HashSet
без сортировки.
Это же объясняет, почему выбор host-authoritative не отменил детерминизм: сеть перестала быть его заказчиком, а остальные два потребителя никуда не делись. См. Journal - Host-Authoritative, Not Lockstep.
Грабли: «детерминизм ради сети» — самая частая неверная формулировка, и из неё следуют неверные выводы («сеть отложена, значит можно») . Правильная: детерминизм ради воспроизводимости, а сеть была лишь одним из трёх потребителей — и как раз тем, который от него отказался.
Владелец правды: Reference - Code Standards §4 (инварианты
детерминизма) и тесты тик-ордера; IRngService в Assets/_Project/Scripts/Core/.