что такое сетевой код

Сетевой код для бедных

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

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

Как бы то ни было, я именно это и сделал, и ненавижу себя за это. На удивление, вышло замечательно. Никто из нас не знает всего.

Проблема №1: ресурсы

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

Сериализировать весь меш? Не стоит, у клиента он уже есть на диске.

Передавать имя файла? Не-а, малоэффективно и небезопасно.

Ну ладно, может быть, просто строковый идентификатор?

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

Если я переименую текстуру, то не хочу получать от игроков отчеты об ошибках с такими скриншотами:

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

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

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

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

Поэтому я могу ссылаться на меши следующим образом:

Если я переименую меш, то компилятор превратит это в мою проблему, а не в проблему какого-то несчастного игрока. И это хорошо!

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

Хорошие новости заключаются в том, что нас снова может спасти препроцессор.

Благодаря всему этому я смог запросто передавать ресурсы по сети.
Это просто числа! Я могу даже проверять их.

Проблема №2: ссылки на объекты

Следующим у меня возник такой вопрос: как мне вежливо попросить клиента, чтобы он переместил/удалил/обработал «тот объект, что и раньше, ты знаешь, какой».

С самого начала я знал, что мне потребуется куча списков различных видов объектов, примерно вот таких:

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

При этом появляется гора неочевидных проблем.

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

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

Ну ладно, хорошо. Буду использовать вместо указателя ID.

Вторая проблема: если я удалю этот Avatar из списка, то на его место будет перемещён другой Avatar, а я ничего об этом не узнаю.

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

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

Так, ладно. Вместо удаления аватара я буду приписывать ему номер версии:

Я не удаляю аватар полностью, а помечаю его как «мёртвый» и увеличиваю номер версии. Теперь всё, что попытается получить к нему доступ, будет получать null pointer exception. А сериализация ссылки по сети — это всего лишь вопрос передачи двух легко проверяемых чисел.

Проблема №3: дельта-компрессия

Если бы мне пришлось сократить свою статью до одной строчки, то это была бы просто ссылка на блог Гленна Фидлера.

Когда я решил реализовать собственную версию сетевого кода Гленна, я изучил эту статью,
в которой подробно рассматривается одна из самых серьёзных проблем многопользовательских игр. А именно следующая: если вы хотите передавать состояние всего мира по сети 60 раз в секунду, то забьёте 17 Мбит/с от ширины канала.

И это только на одного клиента.

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

Первая часть самая сложная: а знает ли вообще клиент, где находится объект? То, что я отправил позицию, не означает, что клиент её получил. Клиент может отправлять обратно подтверждения типа «я получил пакет 218, но это было 0,5 секунды назад и с тех пор ничего больше не принимал».

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

Кто-то задал на Reddit вопрос: «разве это не огромный объём памяти?»

Я храню в памяти 255 копий мира в едином огромном массиве. Но это ещё не всё —
в каждой из копий достаточно места для максимального количества объектов (2048) даже если активны только 2.

Если хранить состояние объекта как позицию и поворот, то нужно 7 чисел float: 3 на координаты XYZ и 4 на кватернион. Каждое число float занимает 4 байта. Игра поддерживает до 2048 объектов. 7 float * 4 байта * 2048 объектов * 255 копий =…

14 МБ. То есть примерно половина современной текстуры.

Могу представить, как писал бы эту систему пять лет назад на C#. Я бы сразу начал беспокоиться об используемой памяти, совсем как тот человек с Reddit, даже не задумавшись о действительном объёме задействованных данных. Я бы написал какую-нибудь ненужную, безумно изощрённую, переполненную багами систему компрессии. Когда вы уделяете секунду и задумываетесь над тем, какими будут настоящие данные, то это называется Data-Oriented Design. Когда я рассказываю людям о DOD, многие сразу начинают говорить: «Ого, это очень низкоуровневый подход. Похоже, ты хочешь выжать максимум производительности. У меня нет на это времени. Да и мой код работает нормально». Давайте разобьём эту фразу на утверждения.

Утверждение 1: «Это очень низкоуровневый подход».

Вы же видите — я всего лишь перемножил четыре числа, это не квантовая физика.

Утверждение 2: «Приходится жертвовать читаемостью и простотой ради скорости».

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

А вот характерное для C# решение. Всё случайным образом разбросано по динамической памяти. Элементы перераспределяются или перемещаются прямо посередине кадра, массив хаотичен, повсюду 64-битные указатели:

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

Но такова моя точка зрения. В моём решении я могу запросто сконструировать «достаточно хорошую» мысленную модель, чтобы понимать, что на самом деле происходит в машине. А в решении на C# я едва начал реализацию. Я понятия не имею, как оно поведёт себя в процессе выполнения.

Предположение 3: «Писать код таким образом стоит только ради производительности».

По моему мнению, скорость — это приятный побочный эффект Data Oriented Design. Главное преимущество — ясность мысли. Пять лет назад, если бы я приступил к решению задачи, то первым делом бы подумал не о самой задаче, а о том, как втиснуть её в классы и интерфейсы.

Недавно я собственными глазами наблюдал такой «паралич анализа» на геймджеме. Мой друг застопорился на создании сетки для игры в стиле 2048. Он не мог понять, должно ли каждое число быть объектом, или каждая ячейка сетки, или все они. Я сказал: «Сетка — это массив чисел. Каждая операция — это функция, изменяющая сетку». Внезапно ему всё стало кристально ясно.

Предположение 4: «Мой код работает нормально».

Повторюсь: скорость — не основная проблема, но она важна. Именно из-за неё весь мир переключился с Firefox на Chrome.

Попробуйте провести эксперимент: запустите calc.exe. Теперь скопируйте 100-мегабайтный файл из одной папки в другую.

Я не знаю, что делает calc.exe в течение этих бесконечных 300 мс, но вы можете сделать собственные выводы из двухминутного исследования: calc.exe запускает процесс Calculator.exe, и один из аргументов командной строки называется «-ServerName».

Скажите, calc.exe «работает нормально»? Упрощает ли всё добавление сервера, или только замедляет и усложняет?

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

Проблема №4: лаг

Теперь я вкратце расскажу о той части истории, в которой сетевой код хоть как-то работает.

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

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

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

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

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

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

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

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

Проблема №5: джиттер

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

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

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

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

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

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

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

Проблема №6: подключение к серверу посередине матча

Постойте, у меня уже есть способ сериализации всего игрового состояния. Так в чём же проблема?

Оказывается, для сериализации нового игрового состояния с нуля требуется не один, а несколько пакетов. А для передачи пакета клиенту может понадобиться несколько попыток. Чтобы получить полное состояние, может потребоваться несколько сотен миллисекунд, а как мы уже видели, это целая вечность. Если игра уже идёт, этого времени достаточно для передачи 20 пакетов с новыми сообщениями, которые клиент ещё не готов обработать, потому что он ещё не загрузился.

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

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

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

Проблема №7: вопросы разбиения

Эта часть будет самой противоречивой.

Помните житейскую мудрость разработчиков игр, упомянутую в начале статьи? «Никогда не добавляй сетевой многопользовательский режим в уже готовую игру».

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

Прежде чем распинать меня за это, подождите секунду. Что лучше: сгруппировать весь сетевой код в одном месте, или разбросать внутри каждого игрового объекта?

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

Но некоторые парадигмы проектирования (*кхм* ООП) не даёт мне принимать такие решения. Разумеется, нужно вставлять сетевой код внутрь объекта! Его данные приватны, поэтому для доступа к ним всё равно придётся писать интерфейс. Возможно, также придётся использовать всевозможные интеллектуальные преобразования.

Заключение

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

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

Благодарю за прочтение. Моя игра DECEIVER скоро появится в Kickstarter. Зарегистрируйтесь на сайте, чтобы скачать демо!

Источник

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

Было мучительно наблюдать за выпуском 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 уже много поколений повторяет эту историю, но другие разработчики файтингов (даже те, кто раньше противился изменениям), показывают, что так быть не должно.

Источник