ДЕВБЛОГ // Сетевой код VALORANT

Одна из важнейших целей при создании VALORANT — внимание к соревновательному духу игры. Соревновательный дух для нас означает, что исход каждого матча зависит только от игроков. Интернет-соединение, производительность клиента, серверы Riot и компьютеры пользователей не должны влиять на равенство игроков в каждом матче. Сегодня мы расскажем о том, как эти цели влияли на создание сетевого кода VALORANT!

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

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

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

Отметим, что в VALORANT используется модель авторитетного сервера, чтобы ограничить применение возможных читов. Поэтому наше клиент-серверное взаимодействие спроектировано на основе идеи «сервер не должен верить тому, что сообщает клиент».

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

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

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

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

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

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

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

Вызов: нужно обеспечить наивысшее качество игры для каждого игрока с учетом соединения и характеристик ПК. Это очень важно – мы хотим, чтобы проблемы с соединением или производительностью у одного игрока не влияли на результат игры остальных девяти игроков. Игра в VALORANT должна восприниматься так, как будто другие игроки находятся рядом с вами и играют на самых современных игровых ПК.

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

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

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

Давайте посмотрим на преимущество нападающего в действии (преувеличено для наглядности):

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

TTK (time-to-kill — время на убийство) в VALORANT очень маленькое. Большая часть видов оружия убивает с единственного попадания в голову, поэтому когда игрок выглядывает из-за угла, важна каждая миллисекунда!

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

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

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

1. Вводные данные о движении передаются от клиента нападающего на сервер игры...

2. Сервер игры их обрабатывает...

3. Сервер передаёт итоговое движение на компьютер обороняющегося...

4. Теперь клиент обороняющегося может применить данные о движении и отобразить нападающего в новом месте.

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

Перед тем, как перейти к математике, давайте поговорим об этих маленьких фиолетовых стрелках.

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

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

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

Для упрощения скажем, что «буферизация» включает всё время с момента, когда данные о движении получены из сети, до выполнения и отображения этого движения на экране для клиентов или трансляции клиентам для передачи на сервер. Длительность буферизации прямо зависит от тикрейта симуляции (и частоты отображения кадров на стороне клиента), поскольку:

• Кадры данных о движении сохраняются в буфер с частотой, равной частоте синхронизации.

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

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

Это означает, что серверы с высоким тикрейтом и оптимизация производительности клиента помогут уменьшить буферизацию и обеспечат более свежий взгляд на мир!

Давайте вернемся к диаграмме. В этот раз сосредоточимся на факторах, связанных с преимуществом нападающего.

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

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

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

Выразим его через время реакции обороняющегося:

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

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

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

Для этой упрощенной модели возьмем два кадра буферизации на сервере, которые включают следующее:

• 0,5 кадра – среднее время ожидания входящих данных до их помещения в очередь

• 0,5 кадра – целевое время для настоящей буферизации на сервере, то есть среднее время нахождения входящих данных в очереди до их применения (чтобы смягчить задержки передачи данных)

• 1 кадр – полный кадр, когда движение применяется и выводится (передаётся клиентам)

Для буферизации на стороне клиента возьмем три кадра буферизации. Они распределяются так же, как и буферизация на сервере, за исключением следующего:

• Целевое время клиента, используемое для буферизации, равно одному полному кадру, а не половине кадра.

• Клиенты должны вывести результат на экран, так что нужно учитывать задержку вывода данных видеокартой и задержку цепочки буферов. Это может составлять от 0 до 2 кадров в зависимости от многих факторов, но 0.5 кадра вполне разумное приближение.

Что ж, давайте подставим эти значения:

Получается, что у нападающих на ~141 мс больше времени, чтобы среагировать, чем у обороняющихся. Учитывая, что время реакции человека обычно не превышает 300 мс, это огромное преимущество!

Итак, что мы, разработчики, можем сделать, чтобы минимизировать преимущество нападающего?

Говоря кратко, вот что:

1. Мы разработали Riot Direct, собственную опорную сеть, чтобы свести к минимуму задержки маршрутизации и время обработки данных в интернете.

2. Мы размещаем серверы VALORANT по всему миру и ставим цель достигнуть пинга в 35 мс для 70% наших игроков.

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

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

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

6. Поддержка NVIDIA Reflex — пакета технологий, снижающих системную задержку в некоторых играх. Уже на GTX 1660 Super Reflex обеспечивает снижение задержки с 30 мс до 24 мс, а на 30-й серии можно обеспечить снижение задержки вплоть до 12 мс! Правда, на мониторах с частотой 360 Гц. Поэтому этот пункт учитывать не будем, так как на данный момент это крайне недоступные технологии.

Подставив в неравенство тикрейт серверов 128, задержку маршрутизации 35 мс, воспроизведение игры в режиме 60 кадров в секунду, получим:

Снижая задержку передачи данных игрокам и оптимизируя наши серверы, мы можем уменьшить наше базовое преимущество нападающего на ~40 мс (28%).

Оптимизируя производительность клиента, мы можем дополнительно уменьшить преимущество нападающего для обладателей мониторов с высокой частотой обновления. Те, кто играет с высокой частотой кадров, быстрее увидят обновление. Например, при игре с частотой 144 кадра в секунду преимущество нападающего противника снизится до 71 мс (уменьшение на 49%)!

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

Разница существенна, но как она влияет на исход боя?

На ранней стадии разработки VALORANT нужно было убедиться, что на устранение преимущества нападающего стоит тратить ресурсы. Окажет ли улучшение на 40 мс, ожидаемое от Riot Direct и серверов с тикрейтом 128, существенное влияние на игровой процесс?

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

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

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

Уменьшение преимущества во времени реакции нападающего очень важно для достижения нашей цели – преимущества обороняющегося. Riot выделяет много ресурсов на Riot Direct и глобальную инфраструктуру, чтобы уменьшить задержку передачи данных для наших игроков по всему миру. В то же время команда разработки VALORANT продолжает дальнейшую оптимизацию производительности клиентов и серверов, помимо внедрения изменений и новых особенностей в игру.

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

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

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

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

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

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

Давайте перейдем к другой интересной проблеме.

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

Наша цель – уменьшить частоту возникновения и критичность несогласованности симуляции, насколько это возможно, а также минимизировать ее воздействие на игровой процесс.

Сперва нужно убедиться, что различия в частоте кадров на стороне клиента и сервера не приводят к несогласованности симуляции. Два физических обновления по 5 мс, следующие друг за другом, дают иной результат, чем одно обновление на 10 мс. Это происходит из-за того, как данные численно интегрируются (собираются и применяются) при каждом обновлении.

Это означает, что клиент, выполняющий симуляцию физики с частотой 30 Гц, будет постепенно отклоняться от сервера, симулирующего физику с частотой 128 Гц, и потребуется частая коррекция клиента. Чтобы предотвратить такую ситуацию, мы отделяем наши обновления симуляции от тактов игры (частоты кадров воспроизведения вашей игры). Независимо от частоты воспроизведения игры, клиенты и серверы всегда обновляют движение, физику и другие данные с фиксированной частотой: ровно 128 раз в секунду.

Выше показано, как клиент, работающий при 60 кадрах в секунду, будет симулировать по несколько движений за кадр, в то время, как клиент с большей частотой кадров может выполнять одно обновление симуляции за несколько кадров. Наша симуляция происходит в недалеком будущем (например, движение #408), чтобы точно знать, где будет клиент на границе кадров. Затем мы линейно интерполируем состояние игры и обновление движения, чтобы отобразить все точно так, как должно быть при отрисовке кадра.

Теперь, с фиксированным шагом движения, клиент и сервер могут сопоставить результаты своих симуляций. Когда клиент сообщает серверу игры: «Я только что симулировал движение #408» – сервер игры точно знает, о каком движении сообщает клиент.

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

Когда сервер начинает принимать данные от клиента, он устанавливает расписание соответствия обновлений клиента и своих собственных (обновление #239 от клиента A соответствует обновлению сервера #400). Принимая каждое обновление от клиента, сервер помещает это обновление в соответствующее место в очереди.

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

Выполняя собственную симуляцию, сервер выполняет движения из очереди, поступившие от каждого клиента, и возвращает всем клиентам итоговое состояние симуляции. Однако, как показано выше при движении #401 для клиента B, иногда сервер не получает необходимое обновление от клиента вовремя. В таких случаях сервер предсказывает, что сделал бы клиент. Обычно мы предполагаем, что игрок продолжает удерживать клавиши, которые удерживались при последнем полученном обновлении несколько миллисекунд назад.

Но да, иногда предсказание неверно. Периодические несовпадения данных клиента и сервера неизбежны.

Что мы делаем при рассинхронизации сервера и клиента?

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

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

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

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

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

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

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

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

Мы уже говорили, что хотим избежать влияния низкого качества соединения или устаревшего оборудования одного игрока на других, но это не значит, что мы оставим этого игрока в беде!

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

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

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

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

VALORANT — командный тактический шутер от первого лица, выпущенный Riot Games. 4 августа в игре начался Акт 2, вместе с которым в игре вышла новый Агент Killjoy, добавился новый режим «Бой насмерть», а также свежий боевой пропуск. А если вам интересно узнать больше о разработке VALORANT, то можете ознакомиться с нашими статьями:

Кстати, сейчас мы проводим креативную коллаборацию с Покрасом Лампасом, в рамках которой художник создал наборный шрифт Г Ӆ Ѻ ƃ Å Л И Ʒ Å Џ И Я 1.0. Онлайн-активности в VK-сообществах игры и художника скоро подойдут к концу, успейте поучаствовать!

#valorant