Освещаем работу серверов: сила красоты

Капсулёры!

Пришло время продолжить разговор о Quasar — экосистеме, на базе которой сейчас ведётся разработка EVE Online. С момента анонса на «Фанфесте-2022» эта платформа послужила основой для ряда крупных улучшений, включая:

Эти улучшения, реализованные в рамках проекта «Эволюция EVE», заставили вспомнить теорию множеств, теорию графов и даже… теорию цвета. Как бы там ни было, сегодня речь пойдёт о технологии, поддерживающей создание авторских окрасок для кораблей, ведь это не просто занятный редактор или магия шейдеров! На деле этот инструмент — главный залог повышения производительности серверов в будущем. Однако наберитесь терпения: чтобы оценить все тонкости того, над чем работала наша команда, понадобится пройти парочку ускоренных технических курсов.

Сетевой код и частота обновления сервера

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

В разных движках используется разный подход. Например, Unreal Engine фильтрует информацию по релевантности и отправляет каждому клиенту только самые важные обновления, а в Source Engine имеется функция прогнозирования ввода, которая обеспечивает плавность игрового процесса путём сокращения количества исправлений.

Каким бы ни был подход, частота обновлений сервера остаётся базовым фактором сетевой производительности. Большинство игр работают на частоте от 20 до 120 Гц — в зависимости от количества активных игроков. Это значит, что каждый клиент получает обновления от 20 до 120 раз в секунду. К примеру, при частоте 60 Гц сервер должен обрабатывать и передавать обновления раз в 16,6 мс, чтобы обеспечить 60 обновлений в секунду для одного игрока и оставить место для других игроков, которые должны получить ту же информацию в тот же промежуток времени. Представим, что интернет магическим образом работает без задержек и информация о состоянии игры передаётся клиентам непосредственно при подключении (притворимся, что так бывает). В таком случае сервер с частотой 60 Гц будет обрабатывать обновления состояния игры следующим образом:

Два обновления на сервере с частотой 60 Гц

Прогнозирование ввода и интерполяция движения могут создать иллюзию взаимодействия в реальном времени даже при условии, что у нас нет волшебного интернета с нулевой задержкой. Однако с падением частоты обновления сервера задержки становятся всё более заметными. Звучит паршиво, не правда ли? Кому захочется так играть?

Что ж. EVE Online появилась ещё в эпоху модемов со скоростью 56 кбит/с. Стремясь обеспечить низкие требования для масштабных космических битв, мы сделали так, чтобы частота обновления сервера составляла всего 1 раз в секунду.

Точнее говоря, частота обновления сервера при физическом моделировании равна 1 Гц. Это существенно уменьшает нагрузку, связанную с отправкой обновлений клиентам ПК.

Другие взаимодействия с элементами, не имеющие к физике отношения, обрабатываются с той скоростью, на которую способен Python. Это означает, что, если ввод передаётся непосредственно перед обновлением сервера, отклик не заставит себя ждать. Если же ввод передаётся сразу после обновления, вы увидите эффект через секунду или даже больше с учётом задержки в реальном мире (привет, Австралия!). Технически вы, конечно, можете настроиться на частоту сервера, нажимая клавишу ровно раз в секунду, но для психического здоровья бывает очень полезно щёлкнуть по команде гиперпрыжка тридцать раз подряд.

Если провести общий анализ статистики Tranquility за последний год, станет ясно, что количество операций в секунду соотносится с числом активных игроков во вселенной. Средняя скорость обработки операций за один сеанс составляет 0,7/с. Это демонстрирует, насколько эффективно EVE Online справляется с передачей только необходимых данных.

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

Так при чём тут окраски?

Почти все косметические изменения в EVE Online передаются в соответствии с частотой кадров моделирования: это такой вариант частоты обновления сервера, специфичный для нашей игры. До внедрения инструмента «Окраска-С» обновления передавались со следующим кадром моделирования, который отправлялся всем задействованным в событии клиентам. Даже в отсутствие ограничений по частоте отправки данных интерфейса или сетевых запросов не имело значения, как часто вы меняете окраски: никто не мог видеть больше одного изменения в секунду, поскольку таким был лимит частоты передачи кадров моделирования.

Существует и другая проблема — разветвление (это последний курс, обещаем).

Когда вы меняете окраску корабля, эти данные нужно отправить нескольким адресатам, что и называется разветвлением. Но кто именно должен получить такую информацию? Что происходит, если рядом с вами — сотня кораблей? Что вообще значит «рядом» и какая сотня кораблей следующая на очереди?

Кадры моделирования решали обе эти проблемы, обрабатывая обновления только для кораблей, находящихся в одном «пузыре», или сетке (не путать с пузырями варп-подавления). У такого подхода есть свои недостатки: чем больше данных отправляется с кадром моделирования, тем длиннее последовательности и шире разветвления на сервере, моделирующем конкретную звёздную систему. Ранее Quasar лишь отслеживал, в какой системе находится корабль, однако для того, чтобы «Окраска-С» работала в реальном времени, необходимо было отслеживать ещё и передвижения корабля между «пузырями».

Это была сложная задача. Требовалось существенно изменить ключевой механизм моделирования EVE Online, чтобы он совершенно иначе предоставлял Quasar доступ к своим данным. Результат оказался ошеломляющим! В сравнении с простым переходом между звёздными системами скорость обработки данных увеличилась в 27 раз.

Ниже мы приводим сравнение событий в секунду при перемещении между звёздными системами и перемещении между «пузырями». Имейте в виду, что во время варп-прыжка корабль преодолевает сразу несколько «пузырей», а не просто попадает из «пузыря» А в «пузырь» Б.

И это только внутренний трафик, без учёта разветвления!

Решение проблемы разветвления

Вернёмся к сценарию «один корабль меняет окраску рядом с сотней других кораблей». Теперь, когда платформа Quasar отслеживает все корабли во всех «пузырях», она уже понимает, что значит «рядом» и какие клиенты должны получить обновление. Не дожидаясь следующего кадра моделирования, Quasar немедленно передаёт изменения окраски всем, кто находится в соответствующем «пузыре».

Всё это стало возможным благодаря брокеру сообщений NATS, который каждую секунду эффективно обрабатывает более 10 000 сообщений, отправляемых клиентам EVE. Теперь такие сервисы, как те, что отвечают за косметические изменения, не связаны ограничением частоты моделирования в 1 Гц. Они могут перевести в последовательность и отправить одно-единственное обновление окраски, которое затем посредством разветвления пересылается всем ближайшим кораблям.

Процесс запечатлён в этом коротком ролике, сделанном в ходе тестирования «Окраски-С»:

Возникает вопрос: почему так важно, чтобы Quasar отслеживал местоположение кораблей и отправлял косметические изменения независимо? Потому что такая технология разгружает основной механизм моделирования EVE Online.

Кроме того, перенос затрагивает все остальные косметические эффекты, которые нужно переводить в последовательность и пересылать клиентам посредством разветвления. Если же оставить косметику в покое, сразу появляется мысль: а какие ещё функции можно передать Quasar?

Раздвигаем границы

Во время массового тестирования «Окраски-С» мы решили проверить систему на прочность и убрали ограничение интерфейса на переключение окрасок, чтобы посмотреть, что произойдёт. Признаться, результат нас удивил:

Самое интересное случилось во время стресс-теста, когда 500 игроков из одного пузыря постоянно меняли окраски в одно и то же время на слабом тестовом сервере. В результате при пиковой нагрузке система обрабатывала 45 000 сообщений в секунду!

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

Но вернёмся к примеру выше. Что он нам демонстрирует?

Как мы уже говорили, сервер Tranquility в целом обрабатывает примерно 30 000 сообщений в секунду, что в среднем равняется одной операции в секунду, или 1 Гц. Во время тестирования «Окраски-С» пиковый показатель на сервере всего с 500 игроками достиг 45 000 сообщений в секунду. Это означает, что Quasar эффективно передавал обновления с частотой 90 Гц.

Если Quasar может обеспечить трафик в 90 Гц на небольшом тестовом сервере всего с тремя узлами и 500 игроками, то на что он способен на сервере Tranquility с 230 узлами, где одновременно присутствует 30 000 активных пользователей?

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

Что случится, если интервал в целую секунду между отправкой кадров моделирования останется в прошлом?

Как это повлияет на эффект замедления времени и на игровые стратегии в ходе настоящих масштабных битв?

Если мы сумели ускорить сеть в 90 раз, какой новый опыт мы сможем предоставить пилотам Нового Эдема?

Эти вопросы определят дальнейшее развитие EVE Online. На некоторые из них мы попытаемся ответить 20 февраля, на трансляции CCP TV, которая начнётся в 15:00. Присоединяйтесь!

o7