Начнем как обычно с вопроса из комментариев к предыдущей трансляции.
Есть ли планы добавить умения, требующие усилия нескольких игроков? Например, 10 призывателей, создающих огромного голема?
Да, планы на такую синергию между умениями и классами есть, но это еще не разрабатывалось. Идея в том, чтобы игрок имел возможность присоединиться к умению другого игрока или использовать свое отдельно. Т.е., чтобы в рейде танк мог решить – поставить собственную стену или присоединиться к уже установленной другим игроком, сделав её больше и прочнее. Но пока это находится на стадии обсуждения хотя у текущей системы умений такая возможность уже предусмотрена. Разработчики хотят добавить эту возможность, но позже.
И сразу к самому интересному
Серверная сторона Ashes of Creation
На видео, помимо Маргарет и Стивена, комментарии давали Зак (технический директор, возглавляющий команды движка и сетевого окружения), Хантер (сетевой инженер игровых систем) и Антон (Старший сетевой инженер).
Разработчики постарались максимально подробно объяснить процесс создания такой сложной серверной системы и начали с базовых объяснений.
Итак, что такое Networking в принципе? Это передача информации от сервера к клиенту и обратно. И, конечно же, для любой MMO игры важно, чтобы это происходило как можно быстрее и поддерживало максимально возможное количество игроков. Учитывая, сколько игроков одновременно планируется поддерживать в Ashes of Creation, это одна из самых важных частей разработки, которой было уделено максимальное внимание.
Сейчас многие игры идут путем создания различных инстансов, чтобы решить вопрос с сетевой пропускной способностью, другие не создают событий, где одновременно участвуют сотни игроков. Но разработчики Ashes of Creation наоборот, ставят перед собой цель создать бесшовный мир практически без инстансов, а некоторые события будут вовлекать огромное количество жителей Верры.
Система, которую разработали для игры практически полностью создана самими разработчиками. Задача была достаточно сложной, так как игроки должны иметь возможность идти туда, куда они хотят, при этом в игре практически не должно быть инстансов или зеркалирования. Все это дополнялось тем, что в Ashes много PvP и крупных событий и, конечно же, важным моментом было сделать так, чтобы задержка была минимальной.
Также нужно было учитывать проблемы движения. Многие игры не в полной мере используют валидацию движения на стороне сервера, что приводит к появлению читеров, использующих, например, воллхаки.
В процессе разработки стало понятно, что у Unreal Engine масса сильных сторон, но есть и свои слабости. При увеличении количества игроков, очень быстро возрастала «стоимость» обработки и симулирования физики, коллизий, ИИ и тому подобного. Одиночный сервер не справлялся с такой нагрузкой. Также перегружалась система репликации, так как тысячи игроков, присоединяющихся к игре, конечно должны были видеть все вокруг, что требовало обработки и отправки миллионов обновлений одновременно буквально в каждом тике сервера.
Стандартные системы UE не могли обрабатывать такие массивы информации. В итоге разработчики создали свою сетевую систему, для решения этих вопросов. В неё вошли и система Server Meshing и система внутрисерверных репликаций и микросервисы и много других технологий.
Чтобы более или менее разобраться во всех этих технических подробностях, нужно понимать терминологию.
Actor – в UE это, по сути, любой физически присутствующий в мире предмет или существо (объект). Бочка, телега, маунт, NPC, игрок – всё это акторы.
Replication — репликация, это процесс синхронизации состояния акторов сервером между игровыми клиентами. Как пример: все акторы должны получать информацию о движении других акторов. Ну и любых других действий. Некоторые действия и анимации могут обрабатываться и на стороне клиента — например, движение листьев на дереве. Но если это дерево срублено, то эта информация передается через репликацию всем акторам поблизости.
При этом, сервер не должен «верить» клиенту и должен перепроверять информацию, чтобы предотвратить хакинг.
Чтобы снизить нагрузки, постоянно приходится думать о том, как упросить систему. Например, клиентам можно передавать только информацию о силе и направлении ветра — всё остальное рассчитает клиент и проиграет соответствующую анимацию для деревьев. Тогда не нужно будет делать репликацию для каждого дерева по отдельности. Т.е. задача инженеров состоит в том числе в том, чтобы сделать эту систему максимально эффективной.
Server Meshing — процесс распределения различных географических областей мира по разным серверам. Т.е. мир игры располагается не на одном сервере, а на нескольких. Благодаря этому не нужно беспокоиться о репликации и обновлении на единственном сервере.
Чтобы было понятнее — на скриншоте ниже вы видите территорию Riverlands. И каждая ячейка сетки — это отдельный сервер. И все эти серверы создают единый бесшовный мир.
Для создания этой системы пришлось переделывать и дополнять системы и сетевую архитектуру Unreal Engine.
Однако, здесь возникает вопрос — будет ли игрок, находящийся на одном сервере, видеть игроков, находящихся на другом? Эту задачу решили «репрезентацией» игрока, находящегося на другом сервере. Своего рода — прокси, копия персонажа, обновляющаяся в реальном времени. Эта копия полностью повторяет действия основного персонажа, но только уже на соседнем сервере. Полупрозрачная стена на скриншоте (и видео) — это граница между серверами, отображаемая в дебаг инструментарии.
Но тут возникает второй вопрос — как в таком случае будет происходить бой между игроками, находящимися на границе? Прямой урон прокси-персонажу наноситься не может. Чтобы учесть это, добавлена система кросс-серверных событий. Эта система передает данные между серверами, включая данные о других игроках, состоянии прокси-персонажей и т.п., позволяя игрокам взаимодействовать сквозь границы серверов. Эти события обрабатываются множество раз за тик сервера, что позволяет получить мизерную, практически полностью незаметную задержку при обработке взаимодействий и сражений. Вы скорее всего и не узнаете, что бой велся на границе серверов.
В процессе боя вы можете пересекать границу несколько раз и это будет происходить также незаметно — это была отдельная задача, которую необходимо было выполнить. Переход должен быть незаметен как для вас, так и для окружающих игроков. Но это достаточно сложная задача, так как нужно передать состояние персонажа полностью, не потеряв никаких данных. И здесь на помощь также приходит прокси-персонаж, который уже частично обновлен на сервере, куда вы перемещаетесь. В итоге, переходя на соседний сервер, ваш прокси-персонаж по сути становится полноценным персонажем, а тот, что был на предыдущем сервере, становится прокси. В результате, переход происходит мгновенно, так как данных, которые надо дослать в прокси-персонажа, совсем немного.
Стоит заметить, что, разрабатывая эту систему, разработчики старались по максимуму исключить работу клиентской части в таких моментах. Вся обработка ведется на сервере, что значительно снижет нагрузку на клиента, уменьшает возможные проблемы с производительностью, а также в определенной мере защищает от хакинга и читов.
В итоге получается, что все серверы, благодаря системам, описанным выше, объединены друг с другом и постоянно обмениваются информацией. Каждый сервер напрямую соединен с серверами соседних игровых регионов. В отличие от обычной системы Server Meshing, которую используют другие проекты, в Ashes of Creation нет сервера централизованной репликации объектов, что дает несколько преимуществ. Среди них можно отметить то, что благодаря такой системе нет центрального ядра, отказ которого приведет к недоступности всей игры. В случае какой-то поломки, проблемы затронут только один регион. Также, благодаря такому подходу, убирается так называемое «бутылочное горлышко», которое могло бы ограничить количество игроков. Помимо этого, такая система позволяет устанавливать патчи и хотфиксы незаметно для игроков, не отключая игру.
Отказ от центрального сервера репликации привел к появлению определенных сложностей, которые инженерам пришлось решать. Так как не было центрального места получения игровой информации, возникла ситуация, когда отдельный сервер не получал достаточно данных для поддержания всего игрового функционала. Например, два игрока находятся в группе, но в разных концах игрового мира. Когда один из них открывает карту, он должен видеть, где находится его товарищ, но сервер должен эти данные откуда-то получить. Для решения этих проблем была создана система микро-сервисов. По сути — дополнительного уровня серверов или активных баз данных, которые отслеживают состояние различных систем игры: узлов, гильдий, крафта, почты и т.д., и т.п. И необходимые данные, которые сервер не может получить напрямую от соседей, передаются через эти микро-сервисы.
На основе микро-сервисов был создан инструмент под звучным названием Shol’s Eye (Око Схола), который отслеживает положение, названия, типы и другие данные всех объектов в мире — игроков, NPC, ресурсов и так далее. Око буквально позволяет в реальном времени видеть как перемещаются игроки, где происходят события, где погибают NPC, появляются ресурсы… И этот инструментарий позволяет добиться корректной работы всех игровых систем, распределенных по серверной сети. (Большой Брат следит за нами!)
При этом здесь также действует система распределения. Если какой-то из микро-сервисов выйдет из строя, то недоступным в игре станет только та система, за которую он отвечал. Всё остальное продолжит работать. Конечно же, разработчики предусмотрели и системы оповещения о неполадках, что позволит исправлять их максимально быстро.
Но самая, пожалуй, важная и интересная часть технологии Server Meshing, это её масштабируемость в реальном времени. Dynamic Gridding. Если в какой-то момент в одной локации в игре окажется слишком много игроков, эта система запустит новые серверы и разобьёт этот квадрат на несколько более мелких до того, как сервер, поддерживающий эту локацию, окажется перегружен. Это происходит на лету. Самая сложная часть задачи здесь состоит в том, что игроков надо совершенно незаметно переместить на новый сервер — без лагов, подтормаживаний, потерь. Игрок не должен заметить этого вообще. Но усилия того стоят, так как позволяют предоставить игрокам наилучший игровой опыт. Эта система на данный момент находится в процессе доработки (остальные уже работают) — её добавление планируется к старту второго альфа-теста (или немного позже). Вполне вероятно, что Ashes of Creation станет первой игрой, использующей подобную систему.
Но даже с учетом Dynamic Gridding, ситуация, когда на одном единственном сервере собралось огромное количество игроков всё равно может случиться. Ведь нельзя разделить мир на квадраты по 10 метров, например. Что же планируют разработчики на такой, самый сложный случай? А на такой случай подготовлена система масштабирования производительности конкретного сервера, а также оптимизация отображаемых предметов. На скриншоте ниже можно увидеть пример загруженности CPU сервера во время теста с большим количеством ботов. Как видно, каждый тик сервера занимал примерно 150 миллисекунд. А чтобы поддерживать стабильную высокую производительность это число должно быть в районе 16-30мс. на тик. Соответственно, в такой ситуации нужно как-то оптимизировать работу сервера.
В Unreal Engine, каждый актор в мире имеет собственные настройки отображения — на какой дистанции при различных условиях его будет видно, и он будет реплицироваться. По умолчанию, проверки на репликацию и отображения в движке проводятся каждый тик сервра, что может потребовать огромного количества ресурсов, если акторов много (а их в Ashes of Creation действительно много!). На предыдущем скриншоте более одной трети нагрузки приходилось именно на эту задачу. Появилась цель снизить количество таких проверок таким образом, чтобы это не повлияло существенным образом на игроков.
Так как в текущей системе не используется центральный сервер репликации, эта нагрузка распределяется по отдельным серверам, что уже снижает влияние этой системы на производительность, но этого недостаточно в определенных случаях. Для этого в UE существует дополнительная система Replication Graph, позволяющая разработчикам создавать собственные системы для сбора и установки приоритетов различных акторов. Это уже позволило настроить то, как часто и каким образом производятся проверки релевантности и серьезно уменьшить их влияние на нагрузку. Но хотелось большего. В итоге, разработали систему Spatial Grid Bucket. По сути, все акторы теперь распределены по ячейкам и система сначала проверяет, насколько далеко ячейка находится от игрока. И если расстояние велико, то акторы в этой ячейке не опрашиваются вообще, что позволило сэкономить огромное количество ресурсов. Время репликации снизилось на около 35%, что уже хорошо, но… опять недостаточно!
До этого момента мы обсуждали «живые» объекты – NPC, животных, игроков… Но игра продолжает учитывать деревья, дроп лута, точки сбора ресурсов, разрушаемые здания в соседних ячейках. Но они находятся на одном и том же месте – зачем их опрашивать постоянно? Если они не изменяются, то их можно убрать из списка на постоянное опрашивание. Если кто-то, например, начинает рубить дерево, то мы переносим его в отслеживаемые объекты. Но только его, а не все несколько сотен деревьев в округе. И такой подход дал огромный прирост производительности. Время на репликацию снизилось практически в пять раз. А учитывая все изменения, описанные выше, производительность улучшилась в семь раз.
Но и это было недостаточно быстро для самого сложного сценария — когда масса игроков собирается в одной маленькой области. Это может быть какое-то событие, захват точки во время осады и т.п. А самое сложное — это интенсивное PvP сражение, в котором участвуют сотни игроков. Представьте, что в локации идет сражение, в котором участвуют 200 игроков. Каждый игрок должен видеть и получать данные о себе и 199 других акторов. Т.е. это 200 обновлений на каждого игрока. Т.е. это 40 000 обновлений в целом за один тик. Система репликации Unreal не была рассчитана на подобное.
Дело в том, что система Replication Graph в UE изначально работает в один поток, нагружая всего одно ядро сервера и разработчикам предстояло каким-то образом решить эту проблему, что они с успехом и сделали… При работе в несколько потоков, скорость репликаций увеличилась в 2,5 раза! Решение именно этого вопроса оказалось самым важным для производительности в самом сложном сценарии.
Впереди еще немало вещей, которые предстоит улучшить, но именно снижение времени репликации на 96% стало важнейшим успехом для Ashes of Creation.
Эта система уже практически полностью готова и будет полноценно использоваться во время второго альфа-теста. И так как она позволит гарантировать качественный опыт всем игрокам, разработчики решили в будущем открыть продажу ключей доступа к альфа-тесту, когда эта система будет полностью готова и протестирована. Скорее всего, это произойдет с началом тестирования или уже в процессе, когда понадобится больше игроков, чтобы создать более значительную нагрузку. Это будут не наборы с косметикой, как раньше, а просто ключи с доступом к тестированию.
Также планируется расширить спот-тестирование перед запуском второго альфа-теста. Сейчас доступ к мини-тестам есть только у членов Phoenix Initiative, но скоро он будет расширен на игроков, принимавших участие в первом альфа-тесте. Первыми получат доступ 500 человек, показавших самую большую вовлеченность в первом тестировании и 500 человек, выбранных случайным образом. В августе спот-тесты могут быть расширены до всех участников первого альфа-теста.
Вопросы по видео
Как вы планируете решить проблему с очередями в первые месяцы после запуска, а также со стандартным оттоком игроков после?
С этой проблемой сталкивается запуск любой MMORPG — никто не хочет запускать слишком много серверов в начале, чтобы решить проблему с очередями, а потом заниматься объединением серверов где игроков стало меньше. Такая же проблема может возникнуть и на втором альфа-тесте, но здесь мы хотя бы понимаем, сколько игроков у нас будет на старте и можем масштабировать систему (и будем делать это). Конечно, очереди будут, и мы понимаем, что игроки не очень любят ждать в очереди, но альтернатива этому – полупустые сервера, что также не особо весело. Мы постараемся сохранить баланс.
Были ли проблемы во время тестирования этой системы? Особенно на границах? Например, дублирование предметов или что-то подобное?
Конечно, такие проблемы были, это вполне нормально для разработки. Последние 9-10 месяцев мы как раз занимались поиском багов и их исправлением в этой системе. Возможно, вы сможете найти новые и мы их поправим.
У вас есть план, как реализовать динамическое изменение серверов и сетки или пока что это просто «мы хотим, но пока не знаем как»?
Эта система уже работает. Сейчас мы ее оптимизируем, работаем над производительностью. И текущая цель — запустить эту систему вместе со стартом второго альфа-теста.
Насколько финансово выгодно держать такое количество серверов?
Это вопрос отношений между нами и провайдером клауд серверов. Это может настраиваться на лету. Конечно же, мы рассчитываем стоимость поддержки игры на пользователя. Что касается теста — это всегда дорого, но это необходимо.
Обновлении о студии
- Планы по старту второго альфа-теста пока не изменились. А дату начала тестирования планируют рассказать уже во время следующего стрима!
- Разработчики завершили очередной этап подготовки (9 майлстоун). Цели выполнены на 89% процентов, что очень хороший результат.
- Следующий этап – полировка графики, анимаций и систем к старту тестирования.
- За последний квартал количество сотрудников в компании выросло на 15%. За время с начала этого года, к команде уже присоединилось больше людей, чем за весь прошлый год.
- Следующий стрим будет посвящен архетипу Бард.
Обновление от художников
Ответы на вопросы
Игроки, не являющиеся гражданами города, могут выполнять задания мэра. Значит ли это, что они могут выполнять и задания, необходимые для начала войны?
Это пока что обсуждается. Скорее всего определенные задания будут рассчитаны только на граждан узла. С точки зрения инструментария мы можем поставить это ограничение на любое задание в любой момент и будем тестировать это во время Alpha 2
Что будет давать мобам больше угрозы — лечение, атака или танкование? Или будет одинаково?
Сейчас в формуле набора аггро есть модификаторы, которые мы можем менять при необходимости. И мы будем балансировать эту систему в процессе тестирования. Формула очень гибкая.
Будут ли в морях точки интереса вроде данжей, которые не будут попадать под влияние PvP (на море PvP всегда активно)?
На данный момент PvP зона в море действует везде. В событиях, где на море мы не хотим PvP, там скорее всего будут инстансы.
Какие инструменты будут доступны для изменения UI?
Максимально возможное количество.
Будут ли мобы появляться чаще, если в округе много игроков?
Такое возможно. Есть разные системы появления монстров: по времени, в зависимости от количества монстров (если их стало меньше определенного количества, появятся новые) и прочие варианты. Все зависит от квеста, области, монстров и настроек, которые сделают гейм-дизайнеры.
Можно ли будет при создании персонажа загрузить фото и сделать рендер по этой фотографии?
Не на Альфа 2, но это то, что мы хотим обсудить и попробовать. Но точно не в начале теста.
Когда мы получим доступ к инструменту по созданию персонажа?
Скоро 🙂
Будет ли система сервер-меша влиять на появление монстров, боссов и т.п.?
Нет, влиять на их появление не будет, но позволит большому количеству игроков принимать участие в событиях.
Будет ли подводный контент в подземной части игры?
Да, там будет вода и там могут быть области, где вы сможете нырять, плавать и получать контент 🙂
Сможем ли мы получать рецепты не своей основной профессии, чтобы продавать их?
Да, конечно. В игре открытая экономика и было бы странно запрещать подобное. Мы хотим, чтобы вы торговали.
Будут ли отдельные модификаторы снаряжения, влияющие на выносливость?
Да, конечно, на нее влияют и характеристики персонажа и снаряжения и наборов снаряжения.
На этом всё! Ждём следующего стрима про Барда и дату альфа-теста!
Спасибо!
Сенк
Благодарю