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

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

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

// ОГЛАВЛЕНИЕ

// НЕМНОГО О ЦЕЛЯХ РАЗРАБОТКИ

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

Игра должна быть честной.

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

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

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

Передвижение должно быть плавным и очень отзывчивым.

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

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

Положительная обратная связь от стрельбы.

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

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

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

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

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

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

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

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

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

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

// УМЕНЬШЕНИЕ ПРЕИМУЩЕСТВА НАПАДАЮЩЕГО

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

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

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

ЧЕСТНОСТЬ ИГРЫ: НЕТКОД ЗА ПРЕИМУЩЕСТВОМ НАПАДАЮЩЕГО

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

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

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

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

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

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

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

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

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

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

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

ПЛАВНОЕ ДВИЖЕНИЕ: БУФЕРИЗАЦИЯ ВХОДЯЩИХ ДАННЫХ

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

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

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

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

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

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

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

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

ПРЕИМУЩЕСТВО ОБОРОНЯЮЩЕГОСЯ: ИЗМЕРЕНИЕ ЧЕСТНОЙ ИГРЫ ЧЕРЕЗ ВРЕМЯ РЕАКЦИИ

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

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

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

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

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

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

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

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

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

ПОДСТАВЛЯЕМ ЧИСЛА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Гц. Поэтому этот пункт учитывать не будем, так как на данный момент это крайне недоступные технологии.

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

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

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

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

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

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

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

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

ВЛИЯНИЕ НА ИСХОД БОЯ

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

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

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

  • На профессиональном уровне соревновательной игры разница между временем реакции игроков становится очень мала. Разница между победой и поражением в поединке в наших экспериментах часто уменьшалась до 20 – 50 мс.
  • Даже в слепых тестах (игрокам не сообщались параметры, при которых проводится матч) опытные игроки могли точно определить небольшие изменения (~10 мс) в преимуществе нападающего. Различие в 20 мс для этих игроков было очень значительным.
  • Для игроков с одинаковым уровнем мастерства изменение преимущества нападающего на 10 мс приводило к изменению частоты побед от 90% для игрока, удерживающего угол и вооружённого Operator, до 90% для наступающего противника, вооружённого винтовкой.

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

СТРЕМЯСЬ К НУЛЮ

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

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

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

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

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

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

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

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

// МИНИМИЗАЦИЯ РАСХОЖДЕНИЙ СИМУЛЯЦИИ

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

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

ПЛАВНОЕ ДВИЖЕНИЕ: ФИКСИРОВАННАЯ ЧАСТОТА ОБНОВЛЕНИЯ

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

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

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

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

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

ОЧЕРЕДЬ И РАСПИСАНИЕ ДВИЖЕНИЙ

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

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

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

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

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

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

ПОДДЕРЖКА ИГРЫ ПРИ РАЗЛИЧНЫХ НАСТРОЙКАХ: КАК СПРАВИТЬСЯ С НЕСОВПАДЕНИЕМ ДАННЫХ

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

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

// ОПРЕДЕЛЕНИЕ РЕЗУЛЬТАТА БОЯ НА СЕРВЕРЕ

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

ПООЩРЯЮЩИЙ ГАНПЛЕЙ: ПОДТВЕРЖДЕНИЕ ПОПАДАНИЯ

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

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

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

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

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

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

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

// РЕШЕНИЕ ПРОБЛЕМ НА СТОРОНЕ КЛИЕНТА

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

ПОДДЕРЖКА РАЗЛИЧНЫХ НАСТРОЕК: МОНИТОРИНГ ПРОИЗВОДИТЕЛЬНОСТИ

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

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

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

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

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

// ЧТО ГОТОВИТ БУДУЩЕЕ?

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

Мэтт деВет
Руководитель отдела обеспечения игрового процесса
Дэвид Стрейли
Руководитель технического отдела

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

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

5757
95 комментариев

Комментарий недоступен

4
Ответить

Уже обсуждали в другой ветке комментариев https://dtf.ru/gameindustry/210823-ya-blagodaren-za-vtoroy-shans-v-zhizni-borec-s-chiterami-gamerdoc-soobshchil-chto-poluchil-rabotu-v-riot-games

По-моему, у вас немножко предвзятое отношение.

4
Ответить

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

Ответить

Спасибо за статью!

5
Ответить

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

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

3
Ответить

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

3
Ответить

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

Ответить