Пост на RSI от 10.11.2021 года.
Server Meshing и Persistent Streaming — Q&A
На CitizenCon 2951 мы вместе с Полом Ренделлом (технический директор по онлайн-технологиям) и Бенуа Босежур (технический директор компании Turbulent) погрузились в обзор технологий Server Meshing (Сетка серверов) и Persistent Streaming (Поток постоянства). После выхода этого раздела мы увидели, что у многих людей остались дополнительные вопросы, и мы хотим дать ответы на них. Ниже представлены ваши вопросы и ответы Пола, Бенуа и Роджера Годфри (ведущий продюсер) и Клайва Джонсона (ведущий сетевой программист).
Когда мы увидим Persistent Streaming и Server Meshing в Постоянной вселенной (PU)?
Наша текущая цель — выпустить Persistent Streaming и первую версию Replication layer (уровень Репликации) между первым и вторым кварталом следующего года. Затем мы разработаем первую версию статичной Server Meshing, исключающую любые непредвиденные технические сложности, в период с 3 по 4 квартал следующего года.
Каково текущее состояние технологии объединения серверов и какие самые большие проблемы сдерживают ее?
Большинство людей, когда говорят о Server Meshing, обычно думают о самом последнем шаге этой технологии — объединении серверов в одно единое пространство. Дело в том, что перед этим заключительным этапом в наш игровой движок необходимо внести очень длинную цепочку предварительных изменений и фундаментальных технологических модификаций. Я постараюсь ответить на этот вопрос в контексте полной картины.
Короткий ответ: технология очень сложная.
Теперь длинная версия ответа. Путь к Server Meshing начался еще в 2017/2018 году:
— Object Container Streaming (Потоковая передача контейнеров объектов)
Для работы Server Meshing нам сначала потребовалась технология, которая позволяла нам динамически связывать / отменять привязку сущностей (объектов) через систему потоковой передачи, поскольку это движок не поддерживал, когда мы только начинали работу. Поэтому, когда в 2018 году мы выпустили «Client Side Object Container Streaming» (OCS), мы сделали первый шаг к созданию серверной сетки!
После того, как мы сделали первый шаг, технология, которая позволяет нам динамически связывать / отменять привязку объектов на клиенте, должна быть включена и на сервере (поскольку в конечном итоге серверные узлы (server nodes) в сетке должны будут динамически передавать объекты в / из). Эта технология называется «Server Side Object Container Streaming» (S-OCS), и первая версия S-OCS была выпущена в конце 2019 года. Это был следующий большой шаг на пути к созданию серверной сетки.
— Полномочия объекта и Передача полномочий
Несмотря на то, что у нас была технология, которая позволяла нам динамически передавать объекты на сервер, по-прежнему существует только один сервер, который «владеет» всеми смоделированными объектами. В сетке, где несколько серверных узлов совместно выполняют симуляцию, нам нужна была концепция «полномочий объекта». Это означает, что любой данный объект больше не принадлежит одному выделенному игровому серверу, а вместо этого в сетке серверов используются серверные узлы. Итак, мы имеем один серверный узел, который контролирует объект, и несколько других серверных узлов, которые имеют клиентское представление об этом объекте. Эти полномочия также нуждаются в возможности передачи между серверными узлами. В первой половине 2020 года значительная часть времени разработки была посвящена концепциям «полномочий объекта» и «передачи полномочий». Это был первый раз, когда всей компании пришлось работать над Server Meshing, так как много игрового кода пришлось изменить для работы с новой концепцией сущности-полномочия. К концу 2020 года большая часть игрового кода была изменена для поддержки этой концепции, поэтому был сделан еще один большой шаг вперед, но реальная сетка серверов еще не готова.
— Уровень репликации и Поток постоянства
Следующим шагом было переместить репликацию объектов в центральное место, где мы сможем контролировать логику потоковой передачи и привязку к сетке. Это позволяет нам реплицировать состояние на несколько серверных узлов. Для этого нам пришлось переместить логику потоковой передачи и репликации с выделенного сервера на уровень «Репликации», на котором теперь размещается сетевой код репликации и потоковой передачи объектов.
Также мы реализовали Persistent Streaming, что позволяет уровню репликации сохранять состояние объекта в базе данных графа, в которой хранится состояние каждой отдельной сетевой реплицированной сущности. 2021 год был посвящен работе над уровнем репликации и EntityGraph, что позволяет нам управлять потоковой передачей и репликацией объектов в отдельном процессе (отдельно от традиционного выделенного игрового сервера). Эта работа практически завершена и находится на завершающей стадии.
— Статическая и динамическая Server Meshing (Серверные сетка)
Однако это все еще не требуемая сетка. Работа над реальной сеткой началась, завершиться работа лишь в следующем году, и все предварительные задачи, которые я изложил выше, были необходимы для того, чтобы дойти до этого момента. Первой версией этой технологии будет статическая серверная сетка, и она станет следующей большой ступенькой разработки. Однако и она будет не последней! Со статической сеткой у нас будет первая версия настоящей сетки, но, как указывает название «статическая», возможность масштабирования этой сетки очень ограничена.
Прежде чем мы действительно сможем назвать эту работу завершенной, нам нужно будет сделать еще один большой шаг, который мы называем «динамической сеткой». Этот шаг позволит нам динамически связывать серверные узлы вместе, а затем динамически масштабировать сетку в зависимости от потребности. Большая часть работы над этой частью выполняется параллельно. Например, Fleet Manager, который динамически контролирует необходимость в использовании сетки, уже находится в разработке, как и требования к синхронизации, которые идут вместе с использованием «шардов» (shard / осколок или instance / экземпляр, по нашему просто «инстанс» — название того, что будет разделять игровые области в игровой вселенной для всех одновременно играющих игроков).
Между тем, многие команды разработчиков игрового кода также должны работать над адаптацией существующего игрового кода для полной работы с будущей серверной сеткой (и, что более важно, определить все возможные случаи, которые могут возникнуть, когда у нас будет настоящая сетка). Хоть работа с полномочиями объекта и была завершена в 2020 году, в настоящее время полномочия объекта передаются только между клиентом и одним сервером, поэтому код может потребовать дополнительных корректировок.
Как вы планируете управлять большим кораблем, скажем, Javelin? Будет ли для него выделен собственный ресурс с кораблями вокруг него?
При использовании динамического объединения серверов вполне возможно, что большие корабли, такие как Javelin, будут иметь свой собственный выделенный сервер, назначенный для запуска моделирования поведения этого корабля и всего, что внутри него. Однако мы стараемся избегать негибких правил о том, как для определенного объекта назначаются ресурсы. Все сводится к эффективности как с точки зрения скорости обработки, так и с точки зрения затрат мощностей сервера. Если бы у нас было жесткое правило, согласно которому каждый Javelin и все, что в нем находится, получает свой собственный сервер, тогда это было бы не очень рентабельно (и с финансовой точки зрения тоже), т.к. на Javelin работает всего несколько игроков. То же правило также не было бы эффективным с точки зрения скорости обработки сервера, если бы сотни игроков работали на Javelin, поскольку это правило не позволяло бы нам распределять нагрузку между несколькими серверами.
Динамическая сетка серверов будет немного отличаться в том смысле, что она будет постоянно пересматриваться, как лучше всего и быстрее обрабатывать симуляцию мира, стремясь найти золотую середину, чтобы ни один сервер не был перегружен или недоиспользован. Распределение ресурсов обработки будет меняться по мере того, как игроки перемещаются по вселенной. Чтобы учесть эти изменения, нам понадобится возможность передавать полномочия над объектами с одного сервера на другой, а также переводить новые серверы в «боевой» режим или «отключать» не используемые. Это позволит нам перенести нагрузку с сервера, подверженного риску перегрузки, на сервер, который в настоящее время простаивает. Если ни один из существующих серверов не имеет достаточно свободных мощностей для обработки увеличенной нагрузки, мы можем просто арендовать дополнительные серверы у нашего поставщика облачной платформы. А когда серверы будут простаивать, мы сможем отключать их.
Сколько игроков смогут видеть друг друга в одной области пространства? Какой максимум игроков вы планируете установить?
На этот вопрос сложно ответить, и лучший ответ, который мы можем дать на данный момент — всё зависит от обстоятельств.
Если предположить, что вопрос заключается в ограничении количества игроков, которые смогут видеть друг друга с точки зрения клиента, это в основном продиктовано клиентом игры. Это связано с параметрами на стороне клиента, например физикой и кодом игры, а также с возможностью рендеринга.
Кроме того, это также сильно зависит от сценария. 100 игроков в режиме FPS проще моделировать и визуализировать на клиенте, чем 100 игроков, сражающихся на одноместных космических кораблях, стреляя друг в друга ракетами и лазерами.
Команда по графике активно работает над Vulkan, что позволит нам увеличить скорость отрисовки, это должно улучшить то, сколько игроков / кораблей мы сможем визуализировать одновременно, в то время как команда по движку сильно сосредоточена на оптимизации игрового кода, чтобы увеличить количество игровых объектов, которые мы можем отображать одновременно.
Мы стремимся увеличить количество игроков и надеемся, что будем поддерживать сценарии, в которых 100 игроков смогут видеть друг друга с разумной частотой кадров. Однако по мере того, как мы начинаем масштабировать наши шарды для поддержки большего количества игроков, вероятность того, что каждый отдельный игрок в шарде сможет перейти в одно и то же физическое место и увидеть друг друга без проблем для производительности, уменьшается на текущий момент.
Здесь нам нужно будет начать реализацию игровой механики, которая предотвратит слишком частое повторение кодовых сценариев с задержками.
Абсолютный предел игроков трудно предсказать, пока не появятся новые технологии, и мы не начнем оценивать производительность.
Если я сделаю базу на какой-либо луне, будет ли моя база видна в других шардах в той области, в которой я её создал?
Команда по планетарным технологиям планирует реализовать создание базы с учетом серверных шардов. Приобретение территории для вашей базы будет одинаковым для всех шардов, и мы планируем реплицировать вашу базу на все шарды.
Однако только один шард будет иметь «активную» версию базы, а другие шарды будут порождать копию этой же базы с «ограниченным доступом / только для чтения». Например, будет полный доступ к базе и возможность её расширения в шарде, на котором в настоящее время играет её владелец, в то время как на всех других шардах эта база бедт появляться с запертыми дверями в неизменном однотипном состоянии. Полный дизайн процесса еще не согласован на 100% и может измениться.
Является ли конечной целью создание одного общего шарда для всех игроков?
Это наша цель, однако точно ответить, будет ли всё так, на данный момент нельзя.
Мы начнем реализацию с множества маленьких шардов на регион и постепенно будем уменьшать количество шардов. Первой важной целью будет сведение к минимуму необходимость в одном шарде на регион. Для этого мы планируем постепенно увеличивать количество игроков на шард и постоянно улучшать серверную часть и клиентские технологии, чтобы поддерживать все больше и больше игроков.
Для достижения этой цели необходимы не только технологические изменения, но и новый игровой дизайн и игровая механика. Без механики, не позволяющей каждому игроку попасть в одно и то же место, будет очень сложно получить большой мега-шард, особенно на клиентской стороне. Например, может быть механика для временного закрытия прыжковых точек в перенаселенные места или создание новых пространственных уровней для определенных мест.
Серверная часть приспособлена для горизонтального масштабирования, но игровой клиент работает на одном компьютере и ограничен количеством ядер CPU / GPU, а также памятью.
Только после того, как мы преодолеем эти препятствия и создадим один мега-шард для каждого региона, мы сможем, так сказать, «сразиться с последним боссом»: объединением региональных шардов в один глобальный мега-шард.
Это связано с особым набором проблем. Географическое местоположение серверов играет большую роль в настройке игры. Например, задержка между службами в одном локальном центре обработки данных намного ниже, чем задержка между службами, размещенными в двух региональных центрах обработки данных. И хотя мы разработали серверную часть для поддержки одного глобального шарда, имеется проблема развертывания серверной части таким образом, чтобы одна группа игроков в одном регионе благоприятно перетекала в другой регион с игроками. Это сложная задача.
Будет ли экономика Вселенной независима в каждом шарде или будет одна экономика на всех?
Экономика будет глобальной и одинаковой для каждого шарда.
Например, давайте посмотрим на магазины. В каждом магазине есть местный инвентарь (предметы, которые в настоящее время доступны к покупке). Магазины пополняются из глобального инвентаря игры, общего для всех шардов. Если множество игроков начнут покупать одно конкретное оружие в оружейном магазине в Port Olisar, цена на это оружие вырастет в этом магазине на всех шардах. Запас этого оружия будет исчерпан, поэтому магазины во всех шардах больше не смогут пополнять свои запасы такого оружия.
Что предотвратит ребаланст попадания больших групп игроков, например, «синей стороны» и другой «красной стороны» в конкретные шарды? Социальная динамика предполагает большую концентрацию людей, которые будут иметь друзей и работать в крупных организациях с одинаковыми интересами. Будет ли решение, которое обеспечит правильное сочетание «хорошего», «плохого» и «промежуточного» в игре?
Игроки не будут постоянно закреплены за одним шардом, поскольку система подбора игроков назначает новый шард для выбранного региона при каждом входе в систему. На раннем этапе это приведет к естественному распределению, так как мы начнем использовать параллельно множество мелких сегментов пространства.
Когда мы начнем масштабировать наши шарды (и уменьшать количество параллельных шардов), этот вопрос станет более актуальным. Мы планируем решить эту проблему с помощью нашей новой системы подбора игроков.
Новая система подбора игроков, которая в настоящее время разрабатывается вместе с технологией Server Meshing, позволяет нам сопоставлять игроков с шардами на основе нескольких входных параметров. Эти параметры используются для сопоставления игроков по шардам со своими друзьями или оставленным предметам в открытом мире. Это также позволяет нам использовать более сложные параметры, такие как репутация и другие скрытые статистические данные игроков, которые мы отслеживаем.
Это позволит нам сделать так, чтобы в каждом шарде была разнообразная «коллекция» индивидуумов. Например, это поможет нам убедиться, что мы случайно не загрузили шард только с законопослушными игроками, что может быть не очень весело для тех, кто хочет охотиться на преступников.
Всегда ли наш персонаж и корабль будут сохраняться в пространстве игры при выходе из игры. То есть, если я разлогинюсь с кровати корабля на планете, будет ли мой корабль оставаться на том же месте всё время? То есть люди смогут попытаться взломать или уничтожить мой корабль?
Когда объект «незакреплен» в шарде (т.е. физически существует в пространстве шарда), он постоянно существует / отображается в этом шарде, пока игрок не «сложит / сохранит» объект (оружие, корабль и т.д.) в так называемый инвентарь шарда. Это можно сделать, взяв ружье и поместив его в рюкзак, или посадив корабль на посадочную площадку, которая поместит его в специальный инвентарь посадочной площадки. Как только объект попадает в инвентарь, он сохраняется в глобальной базе данных и может быть перенесен в любой шард.
Мы также планируем использовать механику под названием «сохранение / выгрузка предметов героя». В этом случае любые предметы героя, принадлежащие игроку, будут принудительно помещены в особый инвентарь шарда для перехода между шардами. Автоматическое сохранение объектов будет происходить, когда поблизости нет других игроков и объект ни у кого не отображается. Предметы в этом особом переходном между шардами инвентаре будут автоматически следовать за игроком, поэтому, когда игрок будет входит в другой шард, система будет брать объекты и расставлять их обратно в новом шарде в тех местах, где их оставил игрок ранее.
Когда вы приземляете свой корабль на луну и выходите из игры, корабль автоматически сохраняется в особом инвентаре шарда, если в этот момент поблизости нет других игроков. Теперь, когда вы зайдете в другой шард, ваш корабль будет выгружен в новом шарде. Если по какой-то причине корабль остался в старом шарде и был уничтожен, пока вы были не в сети, вы проснетесь в больнице.
Насколько сейчас новый контент зависит от Server Meshing?
Объединение серверов позволит нам увеличивать количество игроков, которые могут играть вместе в Star Citizen, но также позволит нам добавлять новый контент. Прямо сейчас мы сосредоточены на использовании этой технологии для добавления новых звездных систем. Server Meshing — одна из ключевых технологий, позволяющих звездным системам плавно загружаться в память и выгружаться из нее без необходимости использования экранов загрузки. Игроки впервые увидят это в следующем году, когда выйдет первая итерация Server Meshing с введением системы Pyro.
По мере того, как мы совершенствуем технологию и переходим от статической серверной сетки к динамической серверной сетке, дизайнеры смогут использовать эту технологию для создания более крупных и интересных областей (например, больших поселений или интерьеров больших кораблей) с более плотным количеством ИИ и игроков. Server Meshing может открыть двери для игрового процесса, о котором наши дизайнеры еще даже не думали!
Какого улучшения производительности мы можем ожидать с выходом технологии?
Самый большой прирост будет в производительности сервера. Прямо сейчас производительность нашего сервера довольно ограничена из-за огромного количества объектов, которые мы должны моделировать на одном сервере. Это приводит к очень низкой частоте кадров и деградации сервера, в результате чего клиент испытывает большой пинг / низкий fps и другие проблемы с рассинхронизацией сети. Когда у нас будет хотя бы статическая сетка, мы думаем, что частота кадров сервера будет значительно выше.
На клиентской стороне в части fps сетка серверов на самом деле очень мало что изменит. Клиент передает потоки только тех объектов, которые находятся в видимом диапазоне. Могут быть некоторые небольшие улучшения, так как мы можем регулировать диапазон отображения пространства на клиенте, например, сейчас некоторые объекты имеют увеличенный радиус потоковой передачи для правильной работы таких функций, как радар или ракеты. С помощью Server Meshing мы сможем разделить радиус потоковой передачи клиента и сервера. Однако для клиента эти улучшения будут минимальными. Тем не менее, более быстрая работа серверов с высоким fps улучшит общее впечатление от игры, поскольку сетевая задержка будет значительно уменьшена.
Я думаю, что ответа на мой вопрос еще нет, но после первого запуска Server Meshing, сколько может понадобиться шардов? 10, 100, 1000 или еще больше? Мы знаем, что отход от DGS означает большее количество игроков в игровом пространстве, но мы не знаем, на сколько много.
Короткий ответ: мы не можем предположить это число.
Концепция шардов — это «зависимая» часть архитектуры создания сетки, и мы сможем указать количество требуемых шардов только после того, как все компоненты будут на своих местах. Мы планируем добиваться результата поэтапно.
При первом вводе Persistent Streaming (без создания сетки) мы хотим начать с имитации текущего состояния игры, которое вы видите сейчас в сети, имея по одному сегменту для каждого экземпляра сервера и одному репликанту (назовем этот вариант гибридным). Единственное отличие состоит в том, что все объекты в этих шардах по-прежнему будут постоянными. Это позволит нам справиться с наихудшим сценарием, имея действительно большое количество постоянных шардов и очень большого количества репликаций для тестирования механики создания / заполнения, а также для опытов с активными игроками и серверной частью. Мы хотим, чтобы создание и уничтожение элементов симуляции игры на этом первом этапе были оптимальными, быстрыми и экономичными.
У этого подхода есть несколько преимуществ. Мы можем раньше протестировать устойчивость сегментов и, что более важно, измерить активные метрики для множества сегментов.
— Пример метрик (неполный!):
— Количество оставленных объектов в постоянном сегменте игры с течением времени (скорость роста объема сегмента);
— Размер глобального графа (глобальные темпы роста всех элементов);
— Сколько игроков может обрабатывать одна база данных шарда (активность игроков);
— Влияние нескольких игровых механик на обновление объектов в базе данных шарда (эффекты игрового процесса);
— Профиль производительности очереди записи / сохранения, среднее время запросов кластера базы данных шарда (метрики базы данных шарда);
— Профиль производительности очереди записи / сохранения, среднее время запроса глобального кластера базы данных (глобальные метрики базы данных);
— Эффективность сегментирования базы данных (это еще один уровень сегментирования!) графа.
Хоть у нас и есть статистика и внутренние метрики, ничто не заменит реальных игроков, создающих реальную нагрузку на систему.
По мере того, как мы вводим в игру компоненты создания сетки, в основном статической сетки, мы планируем постепенно уменьшать количество сегментов, группируя игроков во все большие и большие сегменты, пока мы не почувствуем себя комфортно с нужной производительностью репликаций, DGS и графа сущностей. Конечно, статическая сетка будет страдать от проблем с переполнением, а мы сможем возобновить переход к гораздо большим шардам только после того, как динамическая сетка будет реализована.
В итоге, с динамической сеткой мы планируем иметь огромные пространства.
Может ли такой маленький объект, как пуля, перемещаться по серверным шардам?
Краткий ответ: нет.
Вы можете рассматривать шарды как полностью изолированный экземпляр моделируемой вселенной, что очень похоже на текущие изолированные пространства для каждого выделенного сервера. Чтобы предметы передавались между такими пространствами, эти предметы должны быть сохранены в инвентаре для перемещения в другой шард. Например, когда игрок поднимает пистолет в одном шарде и кладет его в свой рюкзак. Теперь, когда игрок подключится к другому шарду, он сможет достать пистолет из своего рюкзака в новом шарде.
А вот, например, в шарде такой объект, как ракета, сможет перемещаться через несколько серверных узлов, если эти серверные узлы имеют ракету в области потоковой передачи информации. Один серверный узел будет контролировать (обладать полномочиями) эту ракету, в то время как другие серверные узлы будут видеть отображение клиентской версии ракеты (данные о ней).
Пули же порождаются только на стороне клиента. Уникальная версия пули создается только на клиенте и конкретном серверном узле, поэтому в примере выше я использовал только реплицируемый в сети объект, такой как ракета.
С учетом регионов нашего мира, планируете ли вы разместить четыре разделенные основные серверные фермы в США, ЕС, Китае, Австралии? Или вы планируете создать «Единую глобальную вселенную» для всего мира? Если будете создавать одну вселенную, как вы будете справляться с балансом игроков при экстремальных значениях пинга?
Мы по-прежнему планируем сохранить региональное распределение сетевых сервисов. При первоначальном развертывании Persistent Streaming глобальная база данных будет по-настоящему глобальной. Сами шарды будут распределены по регионам, поэтому игровой клиент, подключающийся к региону ЕС, предпочтительно будет согласован с шардом ЕС. По мере увеличения размера шардов (как для игроков, так и для организаций) мы планируем пересмотреть эту модель, а также внедрить сервисы регионального уровня для обслуживания данных ближе к местности обитания игрока.
Я живу в Восточной Европе. Смогу ли я играть с друзьями из США после запуска Server Meshing?
Мы не планируем ограничивать выбор шарда и региона.
Игрок сможет выбрать любой регион для игры, и в этом регионе мы разрешим ограниченный выбор шардов. Например, шард с вашими друзьями или шард, на котором вы в последний раз играли.
Поскольку все данные игроков хранятся в глобальной базе данных, игроки смогут переключаться между шардами так же, как они могут переключаться между серверами сегодня. Сложенные в инвентарь предметы будут переходить вместе с переходом игрока и будут всегда доступны независимо от выбранного шарда.
Что будет с игроками, если используемый ими уровень репликации отключится? Мы знаем, что граф сущностей будет собирать информацию и передавать ее на другой уровень репликации, но выкинет ли нас в главное меню, если уровень репликации отключится вместе с серверным узлом, или у нас появится какой-то загрузочный экран, который автоматически перекинет нас на новый уровень?
Чтобы правильно ответить на этот вопрос, мне сначала нужно подробнее рассказать о том, как будет выглядеть наша окончательная архитектура. Уровень репликации не будет зависим напрямую от одного серверного узла. Вместо этого он будет состоять из нескольких экземпляров микросервисов с такими названиями, как Replicant, Atlas и Scribe. Одним из преимуществ этого является то, что сам уровень репликации сможет масштабироваться. Другое преимущество, более актуальное для этого вопроса, заключается в том, что если один серверный узел на уровне репликации может выйти из строя, то очень маловероятно, что весь пул уровней репликации выйдет из строя одновременно. С точки зрения клиента, репликантные (Replicant) узлы являются наиболее важными, так как именно они будут обрабатывать передачу сетевых объектов и репликацию состояний между клиентами и игрой. Репликант спроектирован так, чтобы не запускать какую-либо игровую логику, он будет запускать очень малое количество кода: без анимации, без физики, только сетевой код. Такое построение из небольшой кодовой базы должно означать меньшее количество ошибок в целом. Итак, после решения некоторых задач мы ожидаем, что репликанты будут довольно стабильными элементами. Также важно знать, что один клиент может обслуживаться несколькими репликантами, а эти репликанты также будут обслуживать несколько клиентов одновременно. Последняя часть головоломки — это уровень шлюза (Gateway): клиенты будут подключаться не напрямую к репликантам, а сначала к узлу шлюза на уровне шлюза. Служба шлюза предназначена только для направления пакетов между клиентами и различными репликантами, с которыми они обмениваются данными. Служба шлюза будет использовать еще меньшую кодовую базу, чем репликант, поэтому вероятность сбоя еще ниже.
— Так что же будет с клиентом, если один из обслуживающих его Репликантов внезапно выйдет из строя?
Клиент останется подключенным к шарду, но его симуляция частично или полностью приостановится. Уровень репликации запустит новый репликантный узел, чтобы заменить тот, который отключился, и восстановит потерянное состояние объекта из постоянства через EntityGraph. Клиентские шлюзы и узлы DGS, которые были подключены к старому репликанту, восстановят соединение с новым. Как только все будет восстановлено, игра разморозится для затронутых клиентов. На этом этапе клиент может наблюдать некоторые фризы объектов и лаги. Мы надеемся, что весь процесс будет занимать меньше минуты.
— Что будет с клиентом, если обслуживающий его шлюз внезапно выйдет из строя?
Служба шлюза не хранит состояние игры и будет иметь собственную форму восстановления после сбоя. Поскольку это гораздо более простой сервис, чем репликант, время восстановления должно исчисляться секундами. Пока идет восстановление, клиент будет испытывать временное зависание, за которым последует возможные лаги.
— А что насчет гибридного сервиса?
Во время презентации на CitizenCon, посвященной Persistent Streaming и Server Meshing, Пол и Бенуа рассказали об уровне репликации с точки зрения гибридного сервиса. Гибридный сервис, как следует из названия, представляет собой гибрид сервисов Replicant, Atlas, Scribe и Gateway, о которых я упоминал выше (но не EntityGraph), а также нескольких других сервисов, которые еще не обсуждались. Мы решили сначала разработать этот гибридный сервис, а затем разделить на составляющие сервисы, поскольку это уменьшает количество элементов, с которыми мы пытаемся справиться одновременно. Это также позволяет нам сосредоточиться на доказательстве всех основных концепций, а не на шаблонном принципе правильного взаимодействия всех этих отдельных сервисов. В этой начальной реализации уровень репликации будет одним гибридным серверным узлом. Если этот гибридный узел выйдет из строя, то ситуация будет аналогична той, что сейчас испытывают клиенты при выходе из строя выделенного игрового сервера. Все клиенты будут возвращены в меню внешнего интерфейса с печально известной ошибкой 30k. После повторного запуска гибридного сервиса клиенты смогут снова присоединиться к сегменту игры и продолжить с того места, где они остановились. Надеюсь, мы сможем реализовать это так, чтобы клиенты получали на экране уведомление о том, что сегмент снова доступен, и одно нажатие клавиши вернет их обратно в игру в то же место (аналогично тому, как это работает при краше клиента).
Мы видели много разговоров на CitizenCon о том, какие узлы имеют право записи в базах данных шардов, но как насчет прав записи между отдельными шардами? Поддерживаются ли отдельные базы данных постоянства для отдельных шардов, или состояние элементов мира в конечном итоге будут синхронизированы между шардами, даже если они были оставлены в разных состояниях (например, дверь останется открытой на одном шарде, но закрытой на другом — будет ли один шард в конечном итоге записывать его состояние в базу данных, обновляя состояние двери на другом шарде)?
Каждый шард представляет собой свою собственную уникальную копию вселенной, и любой элемент внутри шарда не будет иметь состояние другого шарда, поскольку каждый шард имеет свою собственную базу данных. С другой стороны, у нас будет глобальная база данных с информацией об инвентаре игроков. Эта база данных используется для хранения любого предмета в инвентаре игрока, и предметы могут передаваться между шардами, если они сохранены в инвентаре игрока или шарда.
Некоторые элементы, такие как аванпосты игроков или добываемые ресурсы, используют специальный код, который будет реплицировать глобальное состояние на все шарды, поэтому форпост может существовать в нескольких шардах параллельно и медленно (относительно скорости игры в реальном времени) реплицировать его состояние между всеми шардами, т.е. это не мгновенная репликация, как открытие или закрытие двери (такое не будет воспроизведено), однако постоянное состояние, такое как запирание или отпирание двери, может быть реплицировано между шардами.
То же самое и для добываемых ресурсов. Каждый шард имеет уникальную версию добываемого ресурса, общее количество будет реплицировано между шардами, поэтому, когда игроки начнут добывать ресурс в определенной области, глобальная карта ресурсов для этой области будет изменена, а число добываемых ресурсов в этой локации будет изменено для всех шардов.
Во время квантового или любого другого группового путешествия от одного объекта к другому, если инстанс будет заполнен, будет ли при статической сетке на уровне T0 создаваться другой инстанс заранее? Или как это будет реализовано для комфортной игры?
При Static Server Meshing всё фиксируется заранее, включая количество серверных узлов на сегмент и то, какой игровой сервер отвечает за моделирование мест. Это означает, что если все игроки в шарде решат отправиться в одно и то же место, все они в конечном итоге будут обрабатываться одним и тем же серверным узлом.
Худший сценарий — это когда все игроки решат распределиться по всеми локациям, контролируемым одним серверным узлом. Таким образом, сервер будет пытаться обработать не только всех игроков, но также должен будет обрабатывать все локации. Выход в такой ситуации — подключить большее количество серверов на шард, чтобы у каждого серверного узла было меньшее количество обрабатываемых локаций для потоковой передачи. Однако, поскольку это статическая сетка, и все заранее настроено, наличие большего количества серверных узлов на шард также увеличивает эксплуатационные (и финансовые) расходы. В итоге нам нужно начать с малого, поэтому план для первой версии Static Server Meshing состоит в том, чтобы начать с как можно меньшего количества серверных узлов на сегмент, пока мы все тестируем и пытаемся убедиться, что технология действительно работает. Всем ясно, что это будет проблемой, если мы позволим шардам иметь намного больше игроков, чем те 50, которые есть сейчас в наших односерверных «шардах».
Так что не ждите, что количество игроков сильно увеличится с первой версией сетки. Это позволит избежать проблемы с заполнением одного узла сервера до того, как туда попадут игроки, поскольку мы ограничим максимальное количество игроков на сегмент в зависимости от худшего сценария. Как только всё заработает, мы посмотрим, как будет работать производительность, и посмотрим, как далеко мы сможем расширить границы. Но для того, чтобы дальнейшее расширение было экономически выгодным, нам нужно как можно скорее сделать Server Meshing более динамичным.
При огромных объемах данных, перемещающихся между клиентами и серверными узлами, и необходимости в низкой задержке, можете ли вы описать то, как вы справляетесь с этими задачами, или какие технологии вы используете, чтобы ускорить или улучшить эти процессы?
Самыми большими факторами, влияющими в настоящее время на задержку, являются тактовая частота сервера, пинг клиента, время загрузки объектов и задержка постоянно действующих служб.
Наибольшее влияние на всё это оказывает тиковая скорость сервера, которая связана с количеством локаций, моделируемых игровым сервером. Объединение серверов должно помочь в этом за счет уменьшения количества локаций, которые каждый игровой сервер должен транслировать и моделировать. Меньшее количество локаций будет означать гораздо меньшее среднее количество объектов на сервере, а экономия вычислительной мощности может быть использована для увеличения количества игроков на сервере.
Пинг клиента зависит от расстояния до сервера. Мы видим, что многие игроки предпочитают играть в регионах на совершенно разных континентах. Часть нашего игрового кода по-прежнему ориентируется на клиента, а это означает, что игроки с высоким пингом могут отрицательно повлиять на игровой процесс для всех остальных игроков. В краткосрочной перспективе мы мало что можем с этим поделать, но мы хотим улучшить это после того, как заработает Server Meshing.
Медленная загрузка объектов может быть вызвана задержкой загрузки объекта на клиенты. Это может вызывать нежелательные эффекты, например, когда после квантового путешествия не появляются локации в течение нескольких минут, или происходит падение через этажи после возрождения в локации, или задерживается появление кораблей у терминалов ASOP, или изменяется положение игроков и т.д. Во-первых, объекты не реплицируются на клиенты, пока не будут полностью созданы на сервере. Во-вторых, у сервера есть одна очередь появления, которую он должен обрабатывать по конкретному порядку. В-третьих, чем больше локаций требуется серверу обработать для потоковой передачи, тем больше он должен обрабатывать информации. Чтобы улучшить ситуацию, мы изменили код создания для сервера, чтобы использовать параллельные очереди появления объектов. Объединение серверов также поможет в решении данной проблемы не только за счет уменьшения нагрузки на очередь появления за счет уменьшения количества локаций, которые сервер должен обрабатывать и передавать клиентам, но также потому, что репликация объектов на клиенты и серверы будет происходить одновременно, позволяя объектам появляться параллельно.
Мы все еще используем устаревшие сервисы постоянства, которые, как мы знаем, имеют проблемы с производительностью и масштабируемостью в соответствии с нашими требованиями. Это может привести к задержке при выборке данных из сервисов постоянства, например, создание корабля из терминала ASOP, проверка инвентаря, изменение обвеса игрока и т.д. Нам нужно решать задачи при резком увеличении объема данных, который нам необходимо сохранять в постоянстве. Вот почему Бенуа и его команда в Turbulent заново изобрели способ сохранения данных в форме EntityGraph, которая представляет собой высокомасштабируемую службу, построенную на основе высокомасштабируемой базе данных, оптимизированной именно для тех операций с данными, которые мы используем. Кроме того, мы также разрабатываем уровень репликации, который действует как масштабируемый кеш в памяти текущего состояния всех объектов в сегменте, устраняя необходимость в большом количестве запросов, которые мы отправляем в унаследованные постоянные службы. Это будут высокомасштабируемые сервисы на всех этапах!
Чтобы уменьшить / устранить любую дополнительную задержку, которую может вызвать уровень репликации, мы делаем его управляемым по событиям, а не в связи с тактовой частотой, как традиционный игровой сервер. Это означает, что по мере поступления пакетов он немедленно обрабатывает их и отправляет ответ и / или пересылает информацию соответствующим клиентам и игровым серверам. После завершения работы над начальной версией уровня репликации (гибридной службой) мы проведем этап оптимизации, чтобы убедиться, что она максимально адаптивна. В конечном итоге это решение для DevOps, мы развернем их в тех же центрах обработки данных, что и сами игровые серверы, поэтому задержка в сети из-за дополнительного перехода между уровнем репликации и игровым сервером должна быть меньше, чем миллисекунда. О, и я уже упоминал, что уровень репликации будет хорошо масштабируемым? Это означает, что если мы обнаружим, что уровень репликации вызывает задержку в определенных областях вселенной, мы сможем перенастроить его, чтобы устранить проблему.
Отказ от ответственности
Ответы точно отражают намерения разработчиков на момент написания, но компания и команда разработчиков оставляют за собой право адаптировать, улучшать или изменять функции и проекты в ответ на отзывы, тестирование, изменения дизайна или другие соображения для улучшения баланса или качества игры в целом.
Оригинальный пост на сайте RSI можно найти здесь
