Сетевой код что это в играх

Игры изнутри : сетевой код

Более 15 лет назад у игроков наконец появилась возможность играть вместе, и не в какие-то автоматы с примитивными играми, а в полноценные технически сложные творения.

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

Базовый набор

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

Допустим шутер, что играет 16 игроков, нужно ли каждый тик серверу отправлять каждому из них местоположение остальных 15? Скорее всего.
А вот ММОРПГ, на сервере которой пару тысяч игроков? Нет.

А когда персонаж попадет в дистанцию рендера, сервер пошлет еще информации :

Как не надо

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

Дабы пристально наблюдать за гриндящими кабанчиков одноклассниками, в центре королевства Вася воткнул замок и трон, но, увы, в «Wow killer starter pack» не нашлось анимации задумчивого восседания, пришлось делать самому.

Отныне каждый игрок сервера знал, когда Вася садится на трон, ибо каждый тик от сервера передавались положения и повороты каждой из косточек и вместо «Praise the Vasya» слышалась лишь отборная брань игроков с четырехзначным пингом.

Источник

СОДЕРЖАНИЕ

Типы сетевых кодов

В отличие от локальной игры, в которой входные данные всех игроков выполняются мгновенно в одном и том же моделировании или экземпляре игры, в онлайн-игре существует несколько параллельных имитаций (по одному для каждого игрока), в которых входные данные от соответствующих игроков принимаются мгновенно, в то время как входные данные для того же кадра от других игроков поступают с определенной задержкой (большей или меньшей в зависимости от физического расстояния между игроками, качества и скорости сетевых подключений игроков и т. д.). Во время онлайн-матча игры должны получать и обрабатывать ввод игроков в течение определенного времени для каждого кадра (например, 16 мс при 60 кадрах в секунду ), и если удаленный игрок вводит конкретный кадр (например, кадр номер 10), когда другой уже запущен (например, в кадре номер 20, 160 мс позже), происходит десинхронизация между симуляциями игроков. Есть два основных решения для разрешения этого конфликта и обеспечения бесперебойной работы игры:

На основе задержки

Откат

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

Возможные причины проблем с кодом сети

Задержка

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

Тикрейт

Из-за ограничений в доступной пропускной способности и времени ЦП, затрачиваемом на сетевое взаимодействие, некоторые игры отдают приоритет определенным жизненно важным коммуникациям, ограничивая при этом частоту и приоритет менее важной информации. Как и в случае с тактовой частотой, это эффективно увеличивает задержку синхронизации. Игровые движки могут ограничивать количество раз, когда обновления (симуляции) отправляются конкретному клиенту и / или конкретным объектам в мире игры, в дополнение к снижению точности некоторых значений, отправляемых по сети, чтобы помочь с использованием полосы пропускания. В некоторых случаях такая неточность может быть заметной.

Программные ошибки

Различные ошибки синхронизации симуляции между машинами также могут подпадать под действие «проблем сетевого кода». Они могут включать в себя ошибки, из-за которых моделирование на одной машине происходит иначе, чем на другой, или из-за которых некоторые вещи не сообщаются, когда пользователь понимает, что они должны быть. Традиционно в стратегических играх в реальном времени (таких как Age of Empires ) использовались одноранговые сетевые модели с блокировкой шага, в которых предполагается, что симуляция будет выполняться одинаково на всех клиентах; если, однако, один клиент по какой-либо причине выходит из строя, десинхронизация может усугубиться и ее невозможно будет восстановить.

Протокол транспортного уровня и код связи: TCP и UDP

Выбор в игре протокола транспортного уровня (а также его управление и кодирование) также может влиять на воспринимаемые сетевые проблемы.

Источник

СОДЕРЖАНИЕ

Типы сетевых кодов

В отличие от локальной игры, в которой входные данные всех игроков выполняются мгновенно в одном и том же моделировании или экземпляре игры, в онлайн-игре существует несколько параллельных имитаций (по одному для каждого игрока), в которых входные данные от соответствующих игроков принимаются мгновенно, в то время как входные данные для того же кадра от других игроков поступают с определенной задержкой (большей или меньшей в зависимости от физического расстояния между игроками, качества и скорости сетевых подключений игроков и т. д.). Во время онлайн-матча игры должны получать и обрабатывать ввод игроков в течение определенного времени для каждого кадра (например, 16 мс при 60 кадрах в секунду ), и если удаленный игрок вводит конкретный кадр (например, кадр номер 10), когда другой уже запущен (например, в кадре номер 20, 160 мс позже), происходит десинхронизация между симуляциями игроков. Есть два основных решения для разрешения этого конфликта и обеспечения бесперебойной работы игры:

На основе задержки

Откат

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

Возможные причины проблем с кодом сети

Задержка

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

Тикрейт

Из-за ограничений в доступной пропускной способности и времени ЦП, затрачиваемом на сетевое взаимодействие, некоторые игры отдают приоритет определенным жизненно важным коммуникациям, ограничивая при этом частоту и приоритет менее важной информации. Как и в случае с тактовой частотой, это эффективно увеличивает задержку синхронизации. Игровые движки могут ограничивать количество раз, когда обновления (симуляции) отправляются конкретному клиенту и / или конкретным объектам в мире игры, в дополнение к снижению точности некоторых значений, отправляемых по сети, чтобы помочь с использованием полосы пропускания. В некоторых случаях такая неточность может быть заметной.

Программные ошибки

Различные ошибки синхронизации симуляции между машинами также могут подпадать под действие «проблем сетевого кода». Они могут включать в себя ошибки, из-за которых моделирование на одной машине происходит иначе, чем на другой, или из-за которых некоторые вещи не сообщаются, когда пользователь понимает, что они должны быть. Традиционно в стратегических играх в реальном времени (таких как Age of Empires ) использовались одноранговые сетевые модели с блокировкой шага, в которых предполагается, что симуляция будет выполняться одинаково на всех клиентах; если, однако, один клиент по какой-либо причине выходит из строя, десинхронизация может усугубиться и ее невозможно будет восстановить.

Протокол транспортного уровня и код связи: TCP и UDP

Выбор в игре протокола транспортного уровня (а также его управление и кодирование) также может влиять на воспринимаемые сетевые проблемы.

Источник

Как мы писали сетевой код мобильного PvP шутера: синхронизация игрока на клиенте

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

В целом подходы к созданию быстрых мультиплеерных игр за последние 20 лет не особо изменились. Можно выделить несколько методов в архитектуре сетевого кода:

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

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

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

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

Механизм предсказания действий локального игрока (prediction)

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

Пример списков систем выполняемых на клиенте и сервере:

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

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

Общая схема работы сетевого кода в проекте

Клиент и сервер синхронизируют время по номерам тиков. Из-за того, что передача данных по сети требует некоторого времени, клиент всегда находится впереди сервера на величину половины RTT + размер буфера ввода на сервере. На диаграмме выше показано, что клиент отправляет инпут для тика 20 (a). В этот же момент на сервере обрабатывается тик 15 (b). К моменту, когда инпут клиента дойдет до сервера, на сервере будет обрабатываться тик 20.

Весь процесс состоит из следующих шагов: клиент отсылает инпут игрока на сервер (a) → этот инпут обработается на сервере через время HRTT + input buffer size (b) → сервер шлет результирующее состояние мира на клиент (с) → клиент применит подтвержденное состояние мира с сервера через время RTT+input buffer size + game state interpolation buffer size (d).

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

Процесс согласования состоит из двух частей:

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

Операторы сравнения конкретных компонентов у нас генерируются вместе со всей структурой EC, специально написанным генератором кода. Для примера приведу сгенерированный код оператора сравнения Transform компонента:

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

Сложность механизма согласования в том, что в случае рассинхронизации состояния клиента и сервера (misprediction) необходимо повторно выполнить симуляцию всех предсказанных состояний клиента, о которых еще нет подтверждения с сервера, вплоть до текущего тика за один кадр. В зависимости от пинга игрока это может быть от 5 до 20 тиков симуляции. Нам пришлось существенно оптимизировать код симуляции, чтобы вложиться во временные рамки: 30 фпс.

Для выполнения процесса согласования на клиенте необходимо хранить два типа данных:

Уменьшение времени лага

На схеме выше показано, что в игре существует два буфера в схеме передачи данных:

На старте игры клиент начинает синхронизацию с сервером только после того, как получит от сервера несколько состояний мира и буфер геймстейтов заполнится. Обычно размер этого буфера равен 3-м тикам (100 ms).

В то же время, когда клиент синхронизируется с сервером, он «забегает» вперед от времени сервера на величину буфера инпута на сервера. Т.е. клиент сам контролирует насколько впереди сервера ему находиться. Стартовый размер буфера инпутов у нас также равен 3-м тикам (100 ms).

Первоначально мы реализовали размер этих буферов как константы. Т.е. в не зависимости от того, существовал ли реально jitter в сети или нет, существовала фиксированная задержка в 200 ms (input buffer size + game state buffer size) на обновление данных. Если добавить к этому средний предполагаемый пинг на мобильных устройствах где-то в 200 ms, то реальная задержка между применением инпута на клиенте и подтверждением применения со стороны сервера выходила 400 ms!

Нас это не устраивало.

Дело в том, что некоторые системы выполняются только на сервере — такие как, например, расчет HP игрока. При такой задержке игрок делает выстрел и только через 400 ms видит, как убивает соперника. Если это происходило в движении, то обычно игрок успевал забежать за стену или в укрытие и уже там умирал. Плейтесты внутри команды показали, что такая задержка полностью ломает весь геймплей.

Компенсация лага на сервере

Из-за того, что клиент получает обновления мира с сервера с задержкой (лагом), игрок видит мир немного не таким, как он существует на сервере. Игрок видит себя в настоящем, а весь остальной мир — в прошлом. На сервере же весь мир существует в одном времени.

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

Для компенсации лага мы используем перемотку времени на сервере. Алгоритм работы примерно такой:

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

Некоторые проблемы, с которыми мы столкнулись

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

Симуляция всего мира в системе предсказания и копирование

Изначально все системы в нашей ECS имели только один метод: void Execute (GameState gs). В таком методе обычно обрабатывались компоненты относящиеся ко всем игрокам.

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

Процесс предсказания происходил следующим образом:

Проблем в данной реализации было две:

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

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

Создание и удаление сущностей в системе предсказания

В нашей системе сопоставление сущностей на сервере и клиенте происходит по целочисленному идентификатору (id). Для всех сущностей у нас используется сквозная нумерация идентификаторов, каждая новая сущность имеет значение >
Такой подход очень удобен в реализации, однако у него есть один существенный недостаток: очередность создания новых сущностей на клиенте и сервере может быть разная и вследствие этого идентификаторы у сущностей будут отличаться.

Выстрелы на сервере создавались в другой очередности:

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

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

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

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

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

Источник

Плохой сетевой код убивает ваши любимые файтинги

Было мучительно наблюдать за выпуском DLC второго сезона Samurai Shodown. Игра продолжает расти и развиваться, не стремясь решить свою самую большую проблему: ужасный онлайн-режим. Есть ли вообще смысл развивать соревновательную игру, как бы ни была она красиво и хорошо сделана, если большинство игроков едва может играть друг против друга?

Сама игра потрясающа. Когда мы собираемся с друзьями, я часто запускаю Samurai Shodown; она великолепна и дружелюбна к новым игрокам, а мощные удары заставляют затаить дыхание всех в комнате. Всем очень нравится в неё играть, вне зависимости от уровня навыков.

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

Онлайн-файтинги заслуживают много большего. NetherRealm Studios (Mortal Kombat) и Capcom (Street Fighter) со временем создали превосходный сетевой код, и даже мелкие инди-игры, в том числе такие шуточные, как файтинг мемов Fight of Animals, благодаря улучшенным технологиям добились отличных результатов.

Но лидеры жанра, такие как SNK и Arc System Works, вместе с другими разработчиками, в основном из Японии, на протяжении долгих лет не меняли своего подхода к онлайн-боям, даже выпуская новые восхитительные игры. Хотя Granblue Fantasy Versus находится на острие прогресса 3D-анимации, уровень её сетевого кода остался в далёком прошлом.

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

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

Устаревший статус-кво: сетевой код на основе задержек

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

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

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

В Under Night In-Birth и других играх в верхней части экрана показывается задержка, измеряемая в кадрах.

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

Из показанного выше клипа можно понять, как выглядят пики задержек в Guilty Gear Xrd Rev 2.

Заметьте, что число в правом верхнем углу экрана сменяется с двух кадров (а это говорит нам, что соединение гораздо быстрее среднего!) до семи, 11 и даже 13 кадров задержки. Это выглядит плохо для наблюдателя, но ещё хуже ощущается для игрока. Мне удалось проделать комбо, только намеренно нажимая каждую кнопку за четверть секунды до нужного момента.

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

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

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

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

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

Последствия привязки к задержкам

Популярность и актуальность игр жанра «файтинг» всегда зависели от сообществ простых фанатов, ещё задолго до того, как появилась сама возможность онлайн-матчей. Не всякая игра достаточно мейнстримна, чтобы обеспечивать постоянный поток игроков, как в Tekken или Street Fighter, а игры, неспособные найти своё сообщество соревнующихся поклонников, обречены увянуть на корню.

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

Заполненное игроками открытое лобби Нью-Йорка игры Granblue Fantasy Versus. Ещё до официального выпуска в США количество одновременно играющих пользователей по вечерам доходило до ста, и этого более чем достаточно.

Если игра новая, например, как недавно выпущенная Granblue Fantasy Versus, которой пользователи, купившие её за рубежом, могли насладиться за месяц до выпуска в США, то всё в порядке, даже когда сетевой код основан на задержках. При хорошем соединении нет никаких проблем найти себе соперника, потому что игра популярна в сообществе и её все хотят попробовать. Чем больше игроков, тем лучше соединение между соперниками, ведь они находятся ближе, поэтому когда игра только выпущена, игрокам редко приходится волноваться о плохом сетевом коде. И в самом деле, для игр наподобие Samurai Shodown это может быть единственным моментом, когда игроки способны найти хорошие матчи.

Открытое лобби в Guilty Gear Xrd Rev 2, пустующее уже не менее двух лет.

Но что если перенестись на полгода вперёд, когда уже перестали появляться дополнительные персонажи? Всё становится очень мрачным. Что произойдёт, когда позже в этом году выйдет Guilty Gear Strive и фанаты «аниме-файтингов» перейдут на новую, интересную игру? Внезапно в вашем регионе может оказаться не так много активных игроков, а иногда, в зависимости от вашего местоположения и качества связи, их может не найтись вообще.

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

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

Rollback — более совершенный способ работы сетевого кода

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

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

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

В 2007 году я использовал первый rollback-клиент GGPO (Good Game, Peace Out) для игры с друзьями по сети в эмулируемую Street Fighter Alpha 2, и результат оказался безупречным — мне казалось, что я сижу на одном диване с моим противником. Это стало настоящим откровением. Я решил, что у такой системы должно быть будущее. Capcom и другие разработчики из мира игр-файтингов обязательно используют подобные идеи, например, в грядущей Street Fighter 4. Ведь правда?

(Спойлер: они так её и не использовали.)

Несмотря на то, что прошло 13 лет, за это время мало что изменилось. Западные файтинги со временем пришли к rollback (в качестве примеров можно назвать Mortal Kombat, Skullgirls и Power Rangers: Battle for the Grid), но крупнейшие японские разработчики в основном продолжили использовать собственные системы на основе задержек. В некоторых играх сетевая игра на основе задержек была реализована лучше, чем в других, но в целом они просто не могли обеспечить плавных, стабильных результатов и более широкого сообщества игроков, обеспечиваемых архитектурой rollback.

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

Rollback — это не безупречный волшебный ключ, и для его реализации требуется серьёзная работа — на самом деле, у команды разработчиков Mortal Kombat на это ушло два года — но его преимущества с лихвой окупают усилия. На самом деле они жизненно важны для длительного выживания файтингов на переполненном нишевом рынке. Можете убедиться сами: в Killer Instinct можно бесплатно сыграть на Xbox One и Windows PC. В старых играх SNK, например, в Mark of the Wolves и Samurai Shodown 5 Special используется rollback в портах на PC и PS4. Даже вышеупомянутая Fight of Animals, которая, как мы помним, стоит всего шесть долларов, может похвастаться более качественной онлайн-игрой, чем многие современные файтинги.

Японские разработчики: последний рубеж сопротивления

Западные разработчики файтингов освоили rollback, но сам жанр родился и вырос в Японии. Такие компании, как Capcom, Arc System Works и SNK, продолжают оставаться в нём продуктивными. Из них только Capcom выпустила крупную игру с сетевым кодом на основе rollback, и его реализация в Street Fighter 5, по словам одного участника Capcom Cup, оставляет желать лучшего.

— 竹内ジョン(JohnTakeuchi)｜Team Liquid (@john_takeuchi) August 17, 2019

Частично это может быть вызвано тем, что сетевая игра на основе задержек в Японии может вызывать меньше проблем благодаря малым географическим размерам, высокой плотности населения и высококачественному широкополосному доступу к Интернету. Так зачем что-то менять? При игре в онлайн-файтинги в залах аркадных автоматов в Токио соединение всегда было плавным, даже когда я играл в игры, печально известные плохим качеством сетевого кода, например, в Million Arthur Arcana Blood. Вероятно, вся проблема заключается в этом: зачем утруждать себя тем, что потребует больше работы, если дома достаточно хорошо работает готовое решение?

Но в японские файтинги играют не только люди в Японии. Существует Tekken World Tour, в котором участвуют находящиеся в десятке лучших игроки из Кореи, Пакистана, Франции и США. Уровень конкуренции и киберспорта повышается, и разработчикам давно уже пора было признать, что это сообщество всемирное, и что нужно служить этому сообществу по мере возможностей и используя самые лучшие инструменты.

К счастью, похоже, изменения начинаются. Capcom, например, наконец-то решила начать работу над исправлением халтурного rollback-кода Street Fighter 5. И после многих лет равнодушной реакции на требования улучшения сетевого кода — фанаты месяцами спамили «GGPO!» на всех стримах компании — Arc System Works сообщила, что собирается встроить rollback-код в грядущую крупнейшую игру компании Guilty Gear Strive.

Хотя Arc не является издателем масштаба Bandai Namco или Capcom — Dragon Ball FighterZ только недавно превратила эту компанию в мейнстримную, это один из японских специалистов в жанре. Куда пойдёт он, туда начнёт двигаться и остальная часть нишевого рынка. Если улучшение онлайн-боёв будет означать повышение объёмов продаж, то Strive может стать игрой, заставившей остальную часть японских компаний взглянуть на rollback серьёзно.

Остаётся только SNK. Если не обращать внимания на старые игры компании, то можно подумать, что SNK никогда не слышала о rollback, и её сетевой код на основе задержек всегда был одним из самых худших среди всех файтингов. В прошлом году на Evo разработчик объявил, что он работает над The King of Fighters 15, новой частью своей крупнейшей франшизы. The King of Fighters 14 была превосходной игрой, но ей так и не удалось собрать значимое сообщество в США, и в большой степени это было вызвано ужасными онлайн-поединками.

Вообще-то, такое было и с The King of Fighters 13. SNK уже много поколений повторяет эту историю, но другие разработчики файтингов (даже те, кто раньше противился изменениям), показывают, что так быть не должно.

Источник