Server Meshing и Persistent Streaming: ответы разработчиков

Когда мы увидим Persistent Streaming и Server Meshing в PU?

 

Наша текущая цель - выпустить Persistent Streaming и первую версию слоя репликации, в идеале, между 1 и 2 кварталом следующего года. Затем, если не возникнет каких-либо непредвиденных технических сложностей, мы выпустим первую версию статической серверной сетки в третьем-четвертом кварталах следующего года.

 

Каково текущее состояние технологии Server Meshing и каковы наиболее серьезные проблемы, сдерживающие ее развитие?

 

Большинство людей, говоря о технологии Server Meshing, обычно имеют в виду последний этап, на котором мы "объединяем серверы". На самом деле перед этим шагом необходимо выполнить очень длинную цепочку предварительных требований и внести фундаментальные технологические изменения в наш игровой движок. Учитывая это, я постараюсь ответить на этот вопрос в контексте полной картины.

 

Короткий ответ: состояние на самом деле очень продвинутое.

 

Теперь длинная версия. Путь к Server Meshing начался еще в 2017/2018 году:

 

 

Потоковая передача объектных контейнеров

 

Для работы Server Meshing нам сначала потребовалась технология, позволяющая динамически связывать/развязывать сущности через систему потоков, поскольку на момент запуска движок этого не поддерживал. Поэтому, когда в 2018 году мы выпустили "потоковую передачу объектов-контейнеров на стороне клиента" (OCS), мы также сделали первый шаг к серверной сетке!

 

Как только этот первый шаг был сделан, технологию, позволяющую динамически связывать/развязывать сущности на клиенте, необходимо было включить и на сервере (поскольку в конечном итоге серверные узлы сетки должны будут динамически передавать сущности). Эта технология получила название "потоковая передача контейнеров объектов на стороне сервера" (S-OCS), и первая версия S-OCS была выпущена в конце 2019 года. Это стало следующим большим шагом на пути к Server Meshing.

 

Полномочия сущностей и передача полномочий

 

Хотя у нас была технология, позволяющая динамически перемещать сущности на сервере, по-прежнему существует только один единственный сервер, который "владеет" всеми моделируемыми сущностями. В сетке, где несколько серверных узлов разделяют моделирование, нам понадобилась концепция "полномочий сущности". Это означает, что любая конкретная сущность больше не принадлежит одному выделенному игровому серверу, вместо этого в сетке имеется несколько серверных узлов. То есть один серверный узел, который управляет сущностью, и несколько других серверных узлов, которые имеют клиентское представление об этой сущности. Этот орган также должен иметь возможность передачи между серверными узлами. В первой половине 2020 года концепции "полномочий сущности" и "передачи полномочий" было посвящено значительное количество времени. Это был первый случай, когда всей компании пришлось работать над Server Meshing, так как для работы с новой концепцией "сущность-авторитет" пришлось изменить большое количество игрового кода. К концу 2020 года большая часть кода (игрового) была изменена для поддержки этой концепции, так что был сделан еще один большой шаг, но реальной сетки пока не видно.

 

Слой репликации и постоянный поток

 

Следующим шагом стало перемещение репликации сущностей в центральное место, где мы можем управлять потоковой передачей и логикой сетевой привязки. Это позволит нам реплицировать состояние сети на несколько серверных узлов. Для этого нам пришлось перенести логику потоковой передачи и репликации из выделенного сервера в слой "Репликация", на котором теперь располагается код сетевой репликации и потоковой передачи сущностей.

 

В то же время мы реализовали функцию Persistent Streaming, которая позволяет слою Replication сохранять состояние сущностей в графовой базе данных, где хранится состояние каждой отдельной реплицируемой в сеть сущности. 2021 год был посвящен работе над слоем репликации и графом сущностей (EntityGraph), который позволяет управлять потоковой передачей и репликацией сущностей из отдельного процесса (отдельно от традиционного выделенного игрового сервера). Эта работа практически завершена и находится на финальной стадии.

 

Статические и динамические серверные сетки

 

Если я создам базу на луне, будет ли моя база отражаться на других осколках, на которых меня нет?

 

Команда Planet Tech планирует реализовать строительство баз на серверных осколках. Если вы претендуете на землю для своей базы, то эта земля будет заявлена на всех шардах, и мы планируем реплицировать вашу базу на все шарды.

 

Однако только один шард будет иметь "активную" версию базы, а на других шардах будет создаваться "ограниченная/только для чтения" версия той же базы. Например, база будет давать полный доступ и возможность расширяться на том осколке, на котором ее владелец играет в данный момент, а на всех остальных осколках эта база может появляться с запертыми дверями в неизменном состоянии. Полный дизайн пока не определен на 100% и может измениться.

 

Является ли истинной конечной целью единый шард для всех игроков?

 

Мы стремимся к этому, однако дать однозначный ответ на данный момент не представляется возможным.

 

Мы начнем с множества небольших шардов на регион и будем постепенно сокращать их количество. Первой крупной целью будет сокращение числа осколков до одного на регион. Чтобы достичь этой цели, мы планируем постепенно увеличивать количество игроков на каждом осколке и постоянно совершенствовать бэкэнд и клиентские технологии, чтобы поддерживать все большее количество игроков.

 

Для достижения этой цели необходимы не только технологические изменения, но и новый игровой дизайн и игровые механики. Без механики, предотвращающей попадание каждого игрока в одно и то же место, создать большой мегаосколок будет очень сложно, особенно на клиенте. Например, можно предусмотреть механику временного закрытия точек перехода в переполненные локации или создать новые уровни для определенных локаций.

 

В то время как бэкэнд рассчитан на горизонтальное масштабирование, клиент игры работает на одной машине и ограничен определенным количеством ядер CPU/GPU, а также памяти.

 

Только преодолев эти препятствия и создав по одному мега-шарду на регион, мы сможем сразиться с последним боссом: Объединение региональных шардов в один глобальный мега-шард.

 

Это сопряжено с рядом проблем, поскольку локальность играет большую роль для игроков. Например, задержки между сервисами в одном центре обработки данных гораздо ниже, чем задержки между сервисами, размещенными в двух разнесенных по регионам центрах обработки данных. И хотя мы спроектировали бэкэнд для поддержки одного глобального шарда, развернуть его таким образом, чтобы не создавать преимуществ для одной группы игроков перед другой, является сложной операционной задачей.

 

Будет ли экономика вселенной независимой на каждом осколке или объединенной?

 

Экономика будет глобальной и отражаться на каждом осколке. 

 

Например, рассмотрим магазины. В то время как каждый магазин имеет локальный инвентарь (предметы, которые выставлены в данный момент), магазины пополняются из глобального инвентаря, общего для всех осколков. Если многие игроки начнут покупать определенное оружие в оружейном магазине Порт-Олисара, цена на него будет расти на всех шардах. В конце концов, запасы этого оружия будут исчерпаны, и магазины на всех шардах больше не смогут пополнять запасы этого оружия.

 

 

Что помешает большим группам "синих" и большим группам "красных" оказаться на осколках с эхо-камерой? Социальная динамика предполагает большую концентрацию людей, которые будут иметь друзей и состоять в организациях с одинаковыми интересами. Будет ли найдено решение, которое обеспечит правильное смешение хороших, плохих и промежуточных вариантов?

 

Игроки не будут постоянно прикреплены к шардам, так как система подбора игроков при каждом входе в игру назначает новый шард для выбранного региона. На ранних этапах это приведет к естественному распределению, поскольку мы начнем с множества небольших шардов параллельно.

 

По мере масштабирования шардов (и, соответственно, уменьшения количества параллельных шардов) этот вопрос будет становиться все более актуальным. Мы планируем решить его с помощью новой системы подбора игроков.

 

Новая система подбора игроков, разрабатываемая в настоящее время вместе с системой Server Meshing, позволяет подбирать игроков к шардам на основе множества входных параметров. Эти параметры используются для того, чтобы сопоставить игроков с их друзьями или с тем местом, где они оставили большинство своих предметов в открытом мире. Однако оно также позволяет нам использовать более сложные параметры, такие как репутация и другие скрытые статистические данные игроков, которые мы отслеживаем.

 

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

 

Насколько новый контент теперь зависит от Server Meshing?

 

Объединение серверов позволит нам увеличить количество игроков, которые могут играть вместе в Star Citizen, но также позволит нам начать добавлять новый контент. В данный момент мы сосредоточены на добавлении новых звездных систем. Server Meshing - это одна из ключевых технологий, позволяющих реализовать в игре работу точек перехода, благодаря которой звездные системы могут плавно перемещаться в память и из нее без необходимости использования экранов загрузки. Впервые игроки увидят это в следующем году, когда первая итерация Server Meshing начнет работать с внедрением системы Pyro.

 

По мере совершенствования технологии и перехода от статического моделирования серверов к динамическому, дизайнеры смогут использовать эту технологию для создания более крупных и интересных областей (например, больших поселений или интерьеров крупных кораблей) с более плотным расположением персонажей ИИ и игроков. Server Meshing может открыть двери для игрового процесса, о котором наши дизайнеры еще даже не задумывались!

 

На какой прирост производительности мы можем рассчитывать?

 

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

 

На клиентский FPS серверная сетка оказывает очень незначительное влияние. Клиент и так передает только те объекты, которые находятся в зоне видимости. Возможно, будут некоторые незначительные улучшения, поскольку мы можем быть более агрессивными с очисткой радиуса действия на клиенте, так как сейчас некоторые объекты имеют большой радиус потоковой передачи для корректной работы таких функций, как радар или ракеты. С помощью Server Meshing мы сможем разделить радиус потоковой передачи на клиенте и сервере. Однако на клиенте эти улучшения будут минимальными. Тем не менее, более высокий FPS на сервере улучшит общее впечатление от игры, так как значительно уменьшится сетевая задержка.

 

Я знаю, что ответа на этот вопрос, возможно, еще нет, но при первоначальном выпуске Server Meshing, какое количество шардов, по вашим прогнозам, потребуется? 10, 100, 1000, больше? Мы знаем, что переход от DGS означает увеличение количества игроков на одну игровую зону, просто не уверены, сколько игроков вы ожидаете.

Короткий ответ заключается в том, что мы не можем назвать конкретную цифру.

 

Концепция шарда - это "податливая" часть архитектуры сетки, и мы сможем сказать, сколько шардов потребуется, только когда все компоненты будут на месте, и мы планируем итеративно к этому прийти.

 

При первом запуске Persistent Streaming (не meshing) мы хотим начать с имитации текущего поведения, которое вы видите в Интернете: один шард на серверный экземпляр и один репликант (так называемый гибрид). Единственное отличие заключается в том, что все сущности в этих шардах будут постоянными. Это позволит нам справиться с наихудшим сценарием, имея очень большое количество постоянных осколков и очень больших репликантов для тестирования механики создания/посева, симуляции с активными игроками, а также спуска для переработки или уничтожения. Мы хотим, чтобы создание и уничтожение осколков на этом первом этапе было оптимальным, быстрым и не требовало больших затрат.

 

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

 

Например (неполный список!):

 

Хотя у нас есть соответствующие оценки и внутренние измерения для них, ничто не заменит реальных игроков, создающих репрезентативную нагрузку на систему.

 

 

По мере внедрения других компонентов сетки, в первую очередь статической, мы планируем постепенно уменьшать количество шардов, объединяя игроков во все большие и большие шарды, пока мы не почувствуем себя комфортно с производительностью репликантов, DGS и графа сущностей. Конечно, статическая сетка будет страдать от проблем скопления игроков, и мы сможем вернуться к использованию более крупных шардов только после того, как будет создана динамическая сетка.

 

В конечном счете, с помощью динамической сетки мы стремимся поддерживать очень большие шарды. 

 

Я живу в Восточной Европе. Смогу ли я после запуска Server Meshing играть с друзьями из США?

 

Мы не планируем ограничивать выбор осколков и регионов. 

 

Игрок сможет выбрать любой регион для игры, а в пределах этого региона мы разрешим ограниченный выбор шардов. Например, шард с друзьями или шард, на котором вы играли в последний раз. 

 

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

 

Гибель слоя репликации: Что будут испытывать игроки, если уровень репликации отключится или "умрет"? Мы знаем, что граф сущностей будет собирать посеянную информацию и передавать ее в новый слой репликации, но вернемся ли мы в главное меню, если слой репликации умрет, по сравнению с тем, если умрет узел сервера, или у нас будет что-то вроде экрана загрузки, который автоматически подгонит нас к новому слою?

 

Для того чтобы ответить на этот вопрос, мне сначала нужно более подробно рассказать о том, как будет выглядеть наша окончательная архитектура. В конечном счете, слой репликации не будет представлять собой один серверный узел. Вместо этого он будет состоять из нескольких экземпляров набора микросервисов с такими названиями, как Replicant, Atlas и Scribe. Одним из преимуществ такого подхода является возможность масштабирования самого уровня репликации. Другое преимущество, более относящееся к данному вопросу, заключается в том, что, хотя отдельный узел/экземпляр уровня репликации может выйти из строя, очень маловероятно, что весь уровень репликации выйдет из строя сразу. С точки зрения клиента узлы-репликанты наиболее важны, поскольку именно они будут выполнять сетевое парение сущностей и репликацию состояния между клиентами и игрой. Репликант спроектирован таким образом, чтобы не выполнять никакой игровой логики, и, по сути, он будет выполнять очень мало кода вообще: ни анимации, ни физики, только сетевой код. Создание на основе такой небольшой кодовой базы должно означать меньшее количество ошибок. Поэтому, после некоторых неизбежных проблем, мы ожидаем, что Replicants будет достаточно стабильной. Важно также знать, что в каждый момент времени один клиент может обслуживаться несколькими репликантами (но эти репликанты будут одновременно обслуживать и других клиентов). Последняя часть головоломки - уровень шлюза: Клиенты будут подключаться не непосредственно к репликантам, а к шлюзовому узлу на уровне шлюза. Служба Gateway служит для передачи пакетов между клиентами и различными репликантами, с которыми они общаются. Служба шлюза использует еще меньшую кодовую базу, чем репликатор, поэтому вероятность сбоя должна быть еще меньше.

 

Что же будет испытывать клиент, если один из обслуживающих его репликантов внезапно выйдет из строя?

 

Клиент останется подключенным к шарду, но часть или вся его симуляция временно зависнет. Уровень репликации запустит новый узел-репликант взамен отказавшего и восстановит потерянное состояние сущности из сохранения через EntityGraph. Клиентские шлюзы и узлы DGS, которые были подключены к старому репликанту, восстановят связь с новым. После восстановления связи игра будет разморожена для затронутых клиентов. В этот момент клиент может испытывать некоторые замирания/телепортацию сущностей. Мы надеемся, что весь процесс займет меньше минуты.

 

Что будет испытывать клиент, если обслуживающий его шлюз внезапно выйдет из строя?

 

Служба шлюза не хранит никакого игрового состояния и будет иметь свою собственную форму восстановления после сбоя. Поскольку это гораздо более простая служба, чем репликант, время восстановления должно быть гораздо быстрее, скорее, в районе нескольких секунд. Во время восстановления клиент будет испытывать временное зависание с последующим переключением на телепорт.