В последнее время Riot Esports Tech Team работала над решением серии технических проблем, связанных с инструментом, который мы используем для выравнивания значений пинга между локальными и удалёнными соперниками в турнире Mid-Season Invitational 2022 (MSI).

Первая проблема — это баг, найденный нами в ПО под названием Latency Service, которое должно было подстраивать задержку (пинг) на 35 мс для всех участвующих в турнире игроков. Баг проявлялся как избыточный пинг у игроков из Пусана (Южная Корея): их реальный пинг был выше, чем отображаемые на экране 35 мс. По сути, когда игроки из Китая играли с пингом 35 мс, пинг у игроков из Пусана был выше. К сожалению, проблема была выявлена лишь после начала турнира. Мы не нашли её раньше потому, что причиной проблемы был баг в коде, неверно рассчитывающий задержку, то есть значения в наших логах тоже были ошибочными. Поэтому онлайн-мониторинг и тестирование перед турниром показывали, что всё работает правильно, хотя на самом деле это было не так.

Чтобы устранить баг, нам удалось 13 мая внести изменения в конфигурацию Latency Service. Учитывая то, что сетевое окружение ставило игроков из Пусана в невыгодное положение, добавляя избыточную задержку, мы приняли сложное, но необходимое решение переиграть ве три игры в Группе B, в которых уровни пинга были неодинаковы.

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

В этом посте мы расскажем об этих проблемах с технической точки зрения.

События до турнира

Когда мы приступили к планированию последней мили нашей технологической системы для турнира MSI этого года, мы испытали сложности, связанные с продолжающейся эпидемией COVID-19. Состоящая в LPL команда Royal Never Give Up (RNG) не смогла прилететь из Шанхая в Пусан, поэтому участвовала в турнире удалённо.

Казалось бы, можно было использовать простое решение — удалённая команда подключается к шарду MSI, а локальные команды играют в LAN. Однако из-за множества проблем этот вариант был нежелательным.

Одна из проблем заключается в том, что расстояние между Пусаном и Шанхаем составляет примерно 850 км (и их разделяет Жёлтое море). Из-за этого сетевой трафик должен быть перемещаться из Шанхая на серверы турнира MSI в Корее, а затем обратно в Шанхай.

Это время полного прохождения сигнала туда и обратно называется «пингом» (или задержкой). Пинг из местонахождения RNG до серверов турнира MSI составлял примерно 35 миллисекунд (мс). Десять из одиннадцати команд располагались в Пусане и их пинг был ниже, порядка 15 мс. Стоит заметить, что эти значения пингов приблизительны, потому что естественным образом колеблются в интервале ± 5 мс.

Для обычного игрока в League of Legends разница между пингами в 35 мс и 15 мс может быть незаметной, однако для профессиональных игроков это изменение в ходе игры вносит небольшую, но заметную разницу. Так как одним из наших базовых принципов является равенство всех сторон, нам нужно было сделать так, чтобы все команды соревновались на одинаковом уровне.

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

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

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

У нас было два вопроса:

• Находится ли пинг в 35 мс между Шанхаем и Пусаном в рамках допустимого для демонстрации навыков противников на высочайшем уровне?
• Можем ли мы обеспечить равенство условий, чтобы у всех игроков была одинаковая задержка?

Ответ на первый вопрос оказался положительным. Для киберспортивной League of Legends мы установили потолок в 40 мс, ниже которого игра считается играбельной на максимальном уровне соперничества при допустимых колебаниях в ± 5 мс. Этот показатель был принят в середине 2020 года после глубоких обсуждений и анализа внутренних и внешних партнёров, а также нашей внутренней группы анализа и дизайна игры. 40 мс — переломный момент, в котором большинство опрошенных игроков начинает замечать пинг и он начинает влиять на такие вещи, как draft pick, реализацию skillshot и способность быстро реагировать на игру противника.

Чтобы ответить на второй вопрос, мы рассмотрели следующие варианты:

Вариант 1: каждая команда играет со своей естественной сетевой задержкой

В этом варианте удалённые команды подключаются к серверам турнира MSI по самому быстрому подключению из имеющихся. Это будет означать, что команды на площадке MSI смогут играть с очень низким пингом (около 15 мс), а удалённая команда (в данном случае RNG) — со своей естественной задержкой (около 35 мс в Китае).

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

Вариант 2: разместить серверы посередине между Китаем и Южной Кореей

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

Вариант 3: добавить искусственную задержку

Если проблема в том, что команды в Корее имеют очень низкий пинг, а команды в Китае — пинг повыше, то почему бы не добавить немного задержки в Корее, чтобы их уравновесить? Это сработает? Как это можно реализовать?

На самом деле, у команды разработчиков League уже имелся способ добавления искусственной задержки, называемый Latency Service. Ещё его называют «фальшивым пингом». Это клиент-серверная функция, созданная для выравнивания уровней между удалёнными соперниками в условиях невозможности перемещения из-за COVID-19. Latency Service позволяет задать целевое значение (допустим, пинг 35 мс), после чего он встраивает задержку в клиент и сервер для каждого игрока, чтобы выровнять для всех показатель задержки.

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

Наш выбор

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

Исследование искусственной задержки: как она работает

Latency Service встроен в нативный сетевой стек клиент-сервера ПО League of Legends. Он непрерывно замеряет задержку сети между каждым игроком и сервером, внося необходимые задержки с целью обеспечения целевого значения задержки. Это клиент-серверное решение, поэтому оно стремится добавлять эту задержку с равномерно с обеих сторон сети.


На схеме выше показаны компоненты системы. В верхней части схемы видны компоненты игрового сервера, а внизу — клиент (компьютер игрока). В этом примере Latency Service настроен на уравновешивание на 35 мс. Красными стрелками показана истинная сетевая задержка. Как вы видите, у Игрока 1 и Игрока 2 в Пусане «истинный» пинг равен 15 мс, а у Игрока 10 в Шанхае он равен 35 мс. В жёлтых полях показана величина искусственно добавляемой задержки на сторонах клиента и сервера. В данном случае у Игроков 1 и 2 на стороне клиента и сервера добавляются по 10 мс, что даёт в сумме целевое значение в 35 мс. У Игрока 10 уже и так есть реальная задержка, равная целевой задержке в 35 мс, и поэтому задержка не добавляется (0 мс).

Один или два уровня?

Чтобы ещё больше углубиться, нам нужно поговорить о решении, которое мы приняли в отношении удалённого окружения и окружения на площадке.

Наша киберспортивная технологическая группа (Esports Tech Group) всегда стремится к минимизации рисков турниров, проходящих в прямом эфире. События 2012 Season 2 Worlds в Лос-Анджелесе, когда нам пришлось отменить турнир посредине дня из-за проблем с Интернетом, врезались в память каждого сотрудника Riot, работающего в киберспортивной сфере.

При выборе сетевой топологии для турнира MSI 2022 мы осознали, что нужно выбирать из двух возможных стратегий:

Стратегия 1: одна топология для всех ситуаций

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

Учитывая принцип надёжности, мы знали, что если нам придётся использовать игровой сервер в Интернете, нужно выбрать размещение, в котором мы уверены больше всего. Очевидным решением для этого стало использование южнокорейских киберспортивных серверов. Это окружение только для профи, расположенное в том же дата-центре, что и корейские публичные серверы, и регулярно используемое для корейской лиги LCK. Это означало, что высокое качество связи и надёжность инфраструктуры протестированы бесчисленным количеством наигранных пользователями часов. С точки зрения надёжности очевидно, что когда хотя бы одной команде нужно играть удалённо, использование этого шарда крайне логично. Однако возникает вопрос: нужно ли использовать его для всех игр или только для тех игр, где участвует удалённая команда? Это привело нас к стратегии 2: минимизации сетевого риска.

Стратегия 2: минимизация сетевого риска, использование удалённого режима только при необходимости

Так как некоторые игры необходимо проводить через Интернет, возникает вопрос: почему просто не провести их все в этом окружении? На него есть очень простой ответ: надёжность Интернета. Возможно, Интернет будет вести себя идеально, но может быть и нет. Если все игры MSI будут проводиться через Интернет, то любые проблемы с Интернет-подключением могут вызвать проблемы в игре. Если проводить через Интернет только игры с участием удалённых команд, то мы ограничим риск только этими играми. Хотя мы уверены в своей возможности преодоления проблем с Интернетом благодаря множеству планов действий в непредвиденных ситуациях, в идеале нужно стремиться к максимальному снижению риска. Учитывая нашу способность выравнивания условий пинга при помощи искусственной задержки, это вопрос баланса между сложностью и надёжностью. Мы повышаем сложность (используем две топологии), чтобы снизить риск (минимизировать потенциальные проблемы с Интернетом).

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

Ниже показана схема выбранной нами топологии. Она демонстрирует различные сценарии сетевых подключений.

Даже самые лучшие планы…

Взвесив все перечисленные выше факторы, мы приняли решение о поддержке двух разных топологий с соблюдением принципа равенства противников при помощи Latency Service, обеспечивающего одинаковый уровень задержки во всех играх. Игры между командами, физически находящимися в Корее, должны играться на игровых серверах площадки MSI, а игры, в которых участвует удалённая команда, должны играться на киберспортивных серверах в корейском дата-центре. Мы настроили систему и выполнили тестирование инфраструктуры, чтобы убедиться, что всё работает правильно: провели замеры и мониторинг пинга, джиттера сети и наличия потери пакетов. Также несколько команд провели тренировочные игры на киберспортивных серверах, а потом вышли на арену, чтобы провести технические проверки на сцене.

После первого дня соревнований игроки сказали нам, что с играми что-то не то. Некоторые игроки говорили, что несмотря на экранный показатель пинга в 35 мс, игра им казалась медленнее. Все наши логи и инструменты мониторинга инфраструктуры показывали, что всё было правильно, но мы продолжили изучение, чтобы выявить причину проблемы.

Охота за призраками?

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

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


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

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

В процессе анализа логов и кода мы начали получать от профессиональных команд дополнительную информацию. Поступали новые жалобы об окружении на площадке MSI. Нам это казалось парадоксальным, ведь игры в окружении площадки игрались на оборудовании, которое находилось в одном здании с игроками. Как игры в полностью контролируемом сетевом окружении могут ощущаться хуже игр, играемых через Интернет?

Это привело нас к ещё одной гипотезе… Если логи демонстрируют хорошие показатели задержек, но ощущения им не соответствуют, возможно, что-то не так с логами? Возможно, существует проблема с тем, как мы измеряем задержку?

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


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

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

Первым делом мы хотели получить базовые показатели с отключенным Latency Service. Так как у нас имелись данные о бесчисленном количестве часов игры на публичных серверах, мы сделали их «контрольным» тестом, позволяющим нам убедиться в отсутствии багов на сервере. Этот первый эксперимент, который был точкой отсчёта, симулирует окружение, которое бы получилось, если бы команды в Корее и команда в Китае были подключены к серверу в Интернете.

Эксперимент 1: Latency Service отключен, сравниваем сети Кореи и Китая

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

Если пойти по оси X (Game Time, время игры), то можно увидеть, что изначально (в левой части графика) значения задержки низки. Спустя несколько минут (середина графика слева направо) мы начали симулировать сеть с повышенным пингом (например, из Шанхая). Как видите, замеры задержки по вертикальной оси сместились вверх. Именно этого и следовало ожидать. В сети с низким пингом задержка низка, а в сети с высоким пингом она выше.

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

В следующем эксперименте мы хотели провести те же тесты, симулирующие те же условия сети, но на этот раз запустить их со включенным Latency Service.

Эксперимент 2: Latency Service включен, сравниваем сети Кореи и Китая

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

Из этого отчёта мы выяснили три аспекта:

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

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

Это объясняло множество наблюдаемых нами проблем. Наши логи не отображали проблему, потому что вычисления были ошибочными. Это объясняло, почему задержка была хуже на площадке, чем на Интернет-серверах: баг проявлялся активнее в окружениях с низким пингом. Это также объясняло, почему игрокам в Пусане казалось, что пинг хуже, чем 35 мс: он на самом деле был хуже значения 35 мс, отображаемого на их экранах.

Теперь, когда мы обнаружили проблему, нужно было её как можно быстрее решить.

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

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

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

Эксперимент 3: Latency Service включен, параметры конфигурации скорректированы

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

Кажется, проблема решена?

Хотя изменение конфигурации корректировала параметры с учётом бага вычисления пинга в игре, побочным эффектом стало то, что после вывода изменений на экран (ctl-v) отображающий FPS и пинг оверлей демонстрировал игрокам в Пусане неправильное число, оно было примерно на 13 мс ниже реальной задержки. Так получилось потому, что внесённое в Latency Service изменение конфигурации, по сути, добавляло смещение в целевое значение, чтобы компенсировать баг вычислений. Это имело каскадный эффект — смещение применялось к записываемым в лог и отображаемым на экран значениям пинга в клиенте (подробнее об этом ниже). В результате этого отображаемые числа были ниже реального пинга на 13 мс. Разумеется, это неприятно, но мы решили, что лучше добавлять в игру правильную задержку для выравнивания условий, даже если на экране будет отображаться ошибочное значение.

Дальнейшая работа и неприятное открытие

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

В процессе более глубокого изучения проблемы мы пришли к очень неприятному открытию.

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

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

Разбираемся со значениями пинга на оверлеях

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

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

Вскоре после повторного проведения турнира фанаты игры начали сообщать нам о кажущемся несправедливом преимуществе команд в Пусане. Мы видели, как фанаты начали постить скриншоты с трансляции с пингом 22 мс.


Очевидно, что нам нужно было прояснить этот момент.

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

• Значения пинга, отображавшиеся игрокам в Шанхае, были верными
• Значения пинга, отображавшиеся игрокам в Пусане, были неверными; на самом деле, реальная игровая задержка была приблизительно на 13 мс выше отображемой

Повторно объясним причины этого: в Шанхае значения пинга были правильными, потому что они уже были равны целевому значению в 35 мс, поэтому компенсация не добавлялась. Значения в Пусане были неверными, потому что смещение конфигурации задержек корректировало ошибочное вычисление пинга в движке, поэтому реальный пинг выравнивался на значении приблизительно 35 мс, однако это смещало значения пинга в логах и на экранах примерно на 13 мс.

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


В показанном выше графике отображены игры только с RNG. По оси Y отложено сообщаемое значение пинга. В отличие от графиков из предыдущего раздела, в которых отображаются данные за промежуток времени, в данном случае ось X обозначает дискретные наборы данных, по одному для каждой игры. То есть каждый из зелёных квадратов- это гистограмма сообщаемых значений пингов по клиентским логам для машины одного игрока в одной игре. Как видите, в значениях присутствует минимальная флуктуация, а все значения находятся в интервале от 33 мс и 39 мс. Это соответствует естественному значению пинга RNG (35 мс ± 5 мс).

Далее мы исследовали данные из клиентских логов игроков в Пусане, до и после изменения конфигурации.


На показанном выше графике мы отфильтровали данные так, чтобы в них отображались только игры, сыгранные на площадке в Пусане. Игры слева от двусторонней стрелки сыграны до изменения конфигурации. Как видите, передаваемые значения находятся в интервале от 33 мс до 39 мс, то есть в диапазоне 35 мс ± 5 мс. Также мы знаем, что эти значения неверны.

В правой части мы видим, что после внесения изменений в конфигурацию исправился реальный пинг, а передаваемые значения пинга снизились, показывая значения от 19 мс до 25 мс (в общем случае в диапазоне 22 мс ± 5 мс). Вычтя одно значение из другого, мы можем увидеть, что погрешность смещения в передаваемом значении пинга постоянна и приблизительно равна 13 мс (35 мс — 22 мс = 13 мс). То есть после изменения конфигурации отображаемый на экране игрока в Пусане пинг в 22 мс на самом деле означает 35 мс.

Это объясняет, почему на скриншоте игры T1 vs. SGB на экране Zeus отображается 22 мс, хотя мы выровняли для всех реальный пинг до 35 мс. Если прибавить корректирующее значение смещения в 13 мс, которое мы вычислили по эмпирическим данным из клиентских логов, то получим верное значение пинга в 35 мс.

Заключение

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

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

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

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