В многопользовательском уровне 100+ реплицируемых актёров — игроки, снаряды, подбираемые предметы и статичные декорации — и десятки подключённых игроков. Выделенный сервер упирается в CPU на сетевом цикле: каждый тик он пересчитывает релевантность по соединениям и сравнивает реплицируемые свойства каждого актёра, а трафик к каждому клиенту насыщен. Большинство актёров меняются редко, и многие далеки от любого конкретного игрока. Опишите, как вы снизите стоимость сетевого цикла за тик. Требования: далёкие и нерелевантные актёры перестают тратить работу отправки для данного клиента; редко меняющиеся актёры не рассматриваются каждый тик; клиенту шлются только нужные ему свойства; а подход продолжает масштабироваться с ростом числа актёров и игроков.
Снижайте работу за тик: настройте NetUpdateFrequency и NetCullDistanceSquared, применяйте дормантность для статичных актёров, ограничивайте свойства через DOREPLIFETIME_CONDITION и внедрите Replication Graph для пространственного отсечения при масштабе.
- ✗Помечать всё
bAlwaysRelevant, что сводит на нет отсечение по релевантности - ✗Оставлять высокий
NetUpdateFrequencyу редко меняющихся актёров - ✗Никогда не применять дормантность для статичных или простаивающих актёров, из-за чего сервер обрабатывает их каждый тик
- →Как профилировать, чтобы подтвердить, что узкое место именно репликация?
- →Какой компромисс вносит снижение
NetUpdateFrequencyдля быстро движущихся актёров?
Постановка задачи
Уровень со 100+ реплицируемыми актёрами и десятками игроков. Сервер тратит слишком много CPU на сетевой цикл: каждый тик он для каждого соединения вычисляет релевантность и сравнивает свойства каждого актёра.
Компоненты решения
1. Релевантность и отсечение по расстоянию
пределами радиуса. Базовая защита от рассылки всего всем.
NetCullDistanceSquared— актёр перестаёт реплицироваться клиентам за- Не злоупотребляйте
bAlwaysRelevant— он отключает отсечение.
2. Частота обновлений
Статичной декорации хватит 1–2 Гц; пешке игрока нужно 30–60 Гц.
обновления, когда актёр не меняется.
NetUpdateFrequencyзадаёт, как часто актёр рассматривается для репликации.MinNetUpdateFrequencyвместе с adaptive net update частотой снижает
3. Дормантность
Сервер пропускает их в сетевом цикле, пока не вызван FlushNetDormancy.
- Статичные или простаивающие актёры переводятся в
DORM_DormantAll.
4. Условная репликация свойств
для приватных данных, COND_SkipOwner для предсказанного владельцем состояния. Меньше свойств — меньше работы при сравнении.
DOREPLIFETIME_CONDITIONограничивает свойство — напримерCOND_OwnerOnly
5. Replication Graph
раскладываются по пространственным узлам (grid spatialization), и списки для соединений собираются из узлов вместо полного перебора.
- При большом масштабе заменяет поактёрный цикл релевантности. Актёры
Поток данных
Сервер: изменение состояния
→ актёр в узле Replication Graph (или поактёрный цикл)
→ отсечение по релевантности/расстоянию/дормантности
→ сравнение свойств с фильтром DOREPLIFETIME_CONDITION
→ пакет соединению
Клиент: применение свойств → колбэк OnRepКомпромиссы
рассинхрону.
узлов и сложнее в отладке.
- Низкий
NetUpdateFrequencyэкономит CPU, но добавляет рывки быстрым актёрам. - Дормантность бесплатна для статики, но забытый
FlushNetDormancyведёт к - Replication Graph даёт лучшее масштабирование, но требует кода настройки
