Gamedev
Kilyari Azure
6112

Неткод

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

В закладки
Аудио

Предисловие от автора перевода.

Что-то не смотря на то, что у нас тут вроде крупный информационный ресурс про видеоигры, DTF освещает только то, что им интересно/за что им платят, поэтому такой жанр как файтинги, например, всё время оказывается за бортом, либо отдаётся на откуп псевдо-спонсорских материалов по мобильным играм, файтингами называющимися чисто номинально. Даже не смотря на интересные новости вроде того, что недавно один из фанатов за пару дней просто взял и создал патч для Street Fighter V, который решает одну из главных проблем с онлайном в этой игре, существовавшую четыре года. Применимо это не для всех, конечно, а только для пользователей ПК, из-за чего между игроками на этой платформе и консолями появился ещё более крупный культурный раскол, но это уже детали, о которых здесь я говорить не буду.

Поэтому сегодня я хотел бы перевести для вас замечательную статью Рики «Infil» Пуша (Пуска?) (Ricky Pusch) о видах неткода, которую тот создал для своего сайта под названием The Complete Killer Instinct Guide.

Прежде чем у вас возникнут претензии по переводу, я рекомендую вам прочитать сноску, которую я оставлю в самом конце материала.

Добро пожаловать на Fightin' Words. Прошло довольно много времени с тех пор как мы обсуждали самые известные баги в файтингах и то, какое влияние они оказали на сообщества этих игр. Сегодняшняя тема будет немного более техническая, но она является не менее важным фактором для того, как мы играем в игры — мы глубоко занырнём в обсуждение неткода.

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

Онлайновый режим в играх это не какое-то новшество, но у файтингов есть свой набор уникальных препятствий для его успешной реализации. Чаще всего файтинги включают в себя прямое подключение к другим игрокам, в отличие от многих других жанров, а также низкую и постоянную задержку, которая является крайне важной из-за требований к мышечной памяти и скорости реакции, лежащих в самом ядре геймплея этого жанра. В попытках найти решение для данных препятствий в сетевой игре появилось два характерных подхода: использование неткода, основанного на задержке (delay‑based netcode) либо же неткода, основанного на откате (rollback netcode).

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

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

Но прежде чем мы начнём, давайте сперва кое-что для себя уясним.

Почему меня это должно заботить?

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

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

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

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

А как же те люди, которые никогда не играют по сети потому что предпочитают играть оффлайн с друзьями? Здоровая экосистема, создаваемая хорошим неткодом вокруг игры, будет полезна всем. Благодаря ей появится больше активных игроков, больше возможностей для них потреблять контент по своей любимой игре — от технических видео с демонстрациями комбо до просмотров соревнований и гайдов о менее популярных персонажах — и больше интереса к этой игре в FGC (fighting game community). Не смотря на родословную Killer Instinct как отличного файтинга, несомненно именно откат-неткод сыграл огромную роль в постоянном росте сообщества этой игры.

Хороший неткод важен, это даже не обсуждается. Поэтому давайте поговорим о нём подробнее.

Основы

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

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

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

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

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

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

Всё это меняется в том случае, когда два игрока подключены по интернету.

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

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

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

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

Теперь, после всей этой подготовки, мы можем перейти к сути проблемы. Если у нас есть детерминированный файтинг, который использует lockstep-модель сети, единственное что нам необходимо для успешного сетевого матча это только инпуты от обоих игроков. Давайте поговорим о тех «умных решениях», которые файтинги используют для обработки этих инпутов, всё время приходящих позже обычного.

Неткод, основанный на системе задержки

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

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

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

Давайте рассмотрим это на примере видео. Здесь у нас есть два игрока в матче UNIST — файтинге, который использует неткод с задержкой, и играют они по сети с пингом в 90мс. Это значит что в среднем потребуется где-то 45мс (или примерно 3 игровых фрейма по 16 мс) чтобы инпут оппонента дошёл до тебя. Локальный игрок нажимает кнопку на 3-ем фрейме, и если бы это был оффлайн-матч, то мы бы сразу увидели начало его анимации, но вместо этого игра удерживает инпут на 3 фрейма и начинает выполнять приём на 6-ом.

В случае, когда локальный игрок нажимает кнопку, неткод, основанный на задержке, искусственно задерживает его нажатия (в данном случае на 3 фрейма, как показано выше)

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

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

К сожалению, реальность нашего интернета несколько иная.

Проблемы с неткодом, основанным на задержке

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

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

При воспроизведении на 30% -й скорости, можно увидеть как игра замирает во время проблем с соединением. По-фреймовый разбор показывает потерю инпута от удаленного игрока на протяжении 6 фреймов, и у игры не остается выхода кроме как встать и подождать.

Учитывая, что даже небольшая пауза может нарушить опыт игрока, большинство игр с таким неткодом стараются избегать подобного результата всеми доступными способами. Внимательно следя за состоянием соединения, они могут динамически менять задержку в зависимости от качества сети. Но из-за проблем с возможностью предугадать следующий скачок, поправки часто происходят слишком поздно, а новые, увеличенные настройки для этой задержки будет действовать дольше, чем надо. К примеру, перед переходом к откат-системе, Mortal Kombat X использовал неткод с задержкой, которая колебалась в пределах от 5 до 20 фреймов, и любые колебания в соединении увеличивали её на долгое время, даже если первоначальный скачок длился всего пару фреймов. Это может привести к случаям, в которых игроки будут считать что игра лагает намного больше, чем она сама показывает.

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

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

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

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

Но что если бы у нас было хорошее соединение?

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

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

Почему неткодом с задержкой всё ещё пользуются?

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

К сожалению, чаще всего подобным неткодом пользуются японские студии, ибо практически все игры сделанные в США отказались от системы задержки в пользу отката. Такие игры включают в себя крупные тайтлы от известных издателей, вроде Killer Instinct и Mortal Kombat 11, а также небольшие инди-проекты на манер Skullgirls, Punch Planet, Pocket Rumble и Them’s Fightin' Herds. Возможно что именно большая географическая протяженность Америки и Европы стимулировала этих разработчиков сделать неткод одной из своих приоритетных задач, но нельзя сказать что игроки в Японии защищены от плохих соединений и расстройств, с ними связанных, даже не смотря на то что живут они намного теснее и в более развитой онлайн-инфраструктуре.

Из-за настойчивых просьб со стороны фанатов и трендов в индустрии, сложно поверить что японские разработчики просто не знают о существовании отката как альтернативы онлайна для своих игр. Capcom, одни из ведущих японских разработчиков файтингов, даже попробовали добавить откат-неткод в три своих своих игры (Street Fighter x Tekken, Street Fighter V, Marvel vs. Capcom Infinite), правда с переменным успехом. Дайске Ишиватари, главный творческий директор Arc System Works, признался что фанаты доканывали его с просьбой ввести откат, но они всё равно остановились на решении с задержкой для своего Blazblue: Cross Tag Battle. Некоторые фанаты (и даже разработчики) предполагают что это может быть связано с желанием компании решать подобные вещи по-своему — проблема, которая особенно распространена в японских студиях. Но из-за того что подавляющее количество наиболее популярных файтингов в сообществе сделано японскими разработчиками, неткод, основанный на задержке продолжает преобладать. Прошло десять лет с тех пор, как откат-неткод дебютировал в файтинг-сообществе, но только 2 из 9 игр на EVO 2019 использовали его для своего онлайн-мультиплеера, и только одна из них была обласкана фанатами за качество этого самого неткода.

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

Неткод, основанный на откате

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

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

Но давайте начнём с того, что рассмотрим чем же этот «откат» является.

Действуй сейчас, извиняйся после

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

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

В первую очередь состояние игры перезагружается до того, каким оно было до фрейма номер 1 — т.е оно буквально «откатывается» до того фрейма, в котором необходимо было применить инпут, на несколько фреймов в прошлое. Затем, когда инпут от удаленного игрока (точно также как и все те, которые локальный игрок прожал за последние несколько фреймов) применяется, игра ре-симулируется на несколько фреймов вперед, чтобы догнать настоящее.

Удаленный Джаго прожимает MP на 1-ом фрейме. Когда его инпут до нас доходит, мы уже на 4-ом фрейме, поэтому нам необходимо отмотать до фрейма 1, когда Джаго нажал МР и очень быстро ре-симулировать обратно до фрейма номер 4. Оранжевый фильтр и "призрачная" версия Джаго демонстрируют фоновые подсчёты, который игрок никогда не видит. На скорости в 30%, локальный игрок просто видит как МР Джаго появляется спустя пару фреймов начала анимации.

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

Джаго атакует, используя свой оверхэд. Видео демонстрирует приём с учётом разницы в 0, 1, 2 и 3 фреймов отката соответственно, что срезает несколько фреймов с начала анимации. Даже на скорости в 30%, разницу трудно заметить.

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

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

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

Это и есть ядро отката. Но мы можем сделать его даже лучше.

Основы предугадывания

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

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

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

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

Когда фактические, правильные инпуты доходят несколько фреймов спустя, игра должна решить что с ними делать. Если они были неверными, то мы производим откат по системе, которую уже описали раньше — игра отматывается до предыдущего состояния и использует новые инпуты, чтобы симулировать (и пере-предсказать) наперед. Но если инпуты были идентичны предсказанным (например, если игрок действительно продолжал держать назад-вниз), то никакого отката не требуется; показанное игроку во время предсказания оказалось истиной! Игра вместо этого просто обновляется до последнего корректного инпута от удаленного игрока и локальный игрок даже не замечает, что что-то пошло не так. Когда игра верно предугадывает нажатия, откат обеспечивает идеальное ощущение от игры, даже если возникли какие-то проблемы со связью.

Инпуты удаленного игрока на Фулгоре снова потеряны после 3-го фрейма. Затем они все одновременно доставляются по сети после 8-го фрейма, и Фулгор действительно двигался вперёд, как игра и предсказывала. Игра быстро подтверждает это и продолжает без отката.

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

Почему предугадывание так хорошо работает

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

Как оказалось, данное предположение вполне закономерно, если мы посмотрим на то как часто игроки в файтингах действительно меняют свои инпуты. Рассмотрим матч в игре похожей на Street Fighter, в котором игроки передвигаются вперёд и назад; предположим что игрок меняет своё направление около пяти раз в секунду, довольно неплохая примерная цифра даже по меркам особенно активных игроков. Это означает что нам всего лишь нужны инпуты от удаленного игрока на пяти из 60 фреймов в любой момент времени (что составляет поразительно низкие 8% от всего времени). Инпуты игрока для остальных пятидесяти пяти фреймов могут быть предсказаны с высокой долей точности, исходя исключительно из предыдущих.

И всё это в особенно активный момент матча. Если же вы сбили противника с ног и пытаетесь прессовать его, стандартной стратегией для оппонента будет просто удерживать вниз-назад в течении 30, 60 или 120 последующих фреймов. Если ваш оппонент прыгает, то в воздухе он проведёт около 45 фреймов и скорее всего за это время нажмёт только одну кнопку. Зачем нам ждать ответа от сети об этом, если по-фреймовое предсказание о том, что ваш противник будет держать вниз-назад, или же продолжит не нажимать на кнопки, верно в 95% случаев?

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

Откат заботится об игровом процессе

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

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

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

Джаго прожимает HP, но после этого мы ненадолго теряем его инпуты. Откат всё равно продолжает симуляцию. Когда инпуты появляются, оказывается что Джаго мэшил; Это не совпадает с предсказанием, поэтому мы ре-симулируем. Но результат всё равно идентичен.

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

Как и в прошлом сегменте, подумайте о том, как часто инпуты вашего оппонента не могут поменять состояние игры. Это варьируется от одной игры к другой, но обычно включает в себя ситуации, когда противник сбит с ног, находится в вашем комбо, в блокстане, когда начинается любой из их приемов, или анимация его восстановления/промаха, а также много других. Количество фреймов, которые эти действия занимают, тоже не самое короткое; сбитый с ног сильной атакой противник в Street Fighter может потратить вплоть до 60 фреймов, чтобы подняться, промахи тяжелыми атаками занимают от 30 фреймов и больше, а комбо могут длиться в течении 10 и более секунд! Если игра правильно зафиксировала начало всех этих действий противника, то вы получаете абсолютный иммунитет к лагу, (до тех пор пока у врага не появится возможность снова повлиять на состояние игры своими действиями) даже если в этом временном промежутке игра с безумной скоростью проводит один откат за другим.

Сложив эти факты и нашу модель предугадывания вместе, вы сможете увидеть насколько часто лаг «съедается» в ходе матча. Проблемы с соединением не пропали, конечно, но решение их с помощью отката предлагает способ их просто игнорировать, и может превратить даже самую плохую связь в крайне играбельную. В случае с Killer Instinct, он даже позволяет отыгрывать сеты игрокам из Сингапура и восточного побережья США по соединению с 200мс пинга, которое было бы просто невозможным в игре с неткодом, построенным на задержке.

А можно ли сделать 50/50?

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

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

Сама ответственность за эту задержку ложится на плечи разработчика. Некоторые игры, вроде 3rd Strike Online Edition, Darkstalkers Resurrection, Skullgirls и Samurai Shodown V Special позволяют игроку самостоятельно настраивать свою задержку, обычно между 0 и 8 фреймами. Другие игры, такие как Killer Instinct или Injustice 2, выбирают универсальный параметр, применяющийся ко всем игрокам (в случае этих игр это 3 фрейма) и не предоставляют возможности его поменять.

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

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

Суммирование преимуществ системы, использующей откат

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

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

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

Техническая сторона неткода, основанного на откатах

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

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

Here's a list of things you have to deal with uniquely when supporting rollbacks versus delay based netcode.

-separate gameplay from
presentation layer
- serializable game state
- particle simulation
- object lifetime
- sound fx
- animation system
- UI
- desync detection
Вот список уникальных проблем, с которым вам придется столкнуться, если вы выберете систему откатов вместо задержки: -Разделение слоев геймплея и видимого слоя игры -Сериализация состояния игры -Симуляция частиц -Длительность жизни объектов -Звуковые эффекты -Система анимации -UI -Детектирование рассинхронизации

Как игра должна создаваться

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

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

Процесс конвертирования объектов из памяти компьютера в формат, который может быть сохранен или загружен игрой по желанию называется сериализацией, и состояние игры на каждом отдельно взятом фрейме должно быть сериализовано для того, чтобы мы могли бы на него «откатиться» в будущем. Это означает что сериализация состояния игры в вашем продукте (довольно трудоёмкая задача сама по себе, в зависимости от количества данных) должна быть молниеносной и хорошо оптимизированной. В зависимости от того как вы спроектировали свою игру, вам быть даже потребуется пересмотреть методы сохранения данных и то, как ваша игра с ними взаимодействует, лишь для того чтобы получить необходимый уровень производительности. Если вы изначально будете проектировать свою игру с оглядкой на откаты, то это конечно снизит потенциальную нагрузку, но вот добавление данной системы к уже существующему проекту может потребовать кардинальных изменений самого ядра вашей игры. Майкл Сталлоне, инженер в NetherRealm Studios, подсчитал что им потребовалось около 2х лет в человеко часах для того, чтобы создать и оптимизировать систему сериализации в Mortal Kombat X, как раз после того как они решили добавить неткод с откатами в одном из патчей.

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

И так как всё это должно происходить за один игровой фрейм, то вдобавок к стандартным операциям внутри цикла на передний план разработки выходит качественная оптимизация. Возможно все те затратные циклы GPU, симулирующие эффекты частиц и физику ткани внезапно начинают сильно напрягать ваш бюджет производительности. Или, допустим, вы поторопились с оценкой мощности вашей консоли, поскольку на тот момент, когда вы только начинали создавать игру, таких потребностей у вас ещё не было. В своей презентации Сталлоне говорит что при использовании старого неткода с задержкой MKX требовалось всего 10мс из возможных 16-ти на то, чтобы прогнать полную симуляцию одного фрейма, и всё это благодаря тем самым дополнительным мощностям, предоставленным на PS4 и Xbox One. После перехода на неоптимальное, наивное решение использовать откат, стоимость обработки одного фрейма, по его словам, подскочила в три раза, до 32мс, что вынудило команду с нуля проанализировать все игровые системы в надежде на то чтобы выискать новые источники, из которых можно было бы выжать нужный уровень производительности.

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

Заметим, что любая игра с детерминированным алгоритмом может использовать неткод с откатами, при условии что обладает возможностью достаточно быстро производить сохранение/загрузку состояния игры и просчёт нескольких фреймов логики, при этом умещаясь в один-единственный игровой цикл. Чтобы развеять миф о возможностях отката, надо уточнить что он не ограничивается только определенными поджанрами файтингов. Откат применяется как для 2D, так и 3D игр, в число которых входит Street Fighter III 3rd Strike: Online Edition, Killer Instinct, Brawlhalla и For Honor. Он также может использоваться и за пределами файтингов; студия Iron Galaxy использовала этот тип неткода в Dungeons & Dragons: Chronicles of Mystara, рассчитанной на 4-х игроков. Даже игры на подобие Rocket League добавляют в свой неткод систему откатов, чтобы создать ощущение отзывчивости и отсутствия задержки в онлайне.

Поддерживание мира в синхронном режиме

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

Последствия этого могут быть просто катастрофичными, если данные проблемы вовремя не скорректировать. Предположим ситуацию, в которой игрок А в своём матче видит 20-й фрейм, но игрок Б видит 23-й фрейм, и это всё при учёте дополнительной задержки в 3 фрейма от игры по сети. Игрок Б отсылает свои инпуты с 23-го фрейма игроку А. Так как тот находится на 20-ом фрейме, то это означает что он получит этот инпут как полагалось, с 3-фреймовой задержкой на 23-ем фрейме и никакого отката не потребуется. В то же время если игрок А отошлёт свой инпут с 20-го фрейма игроку Б, то из-за начальной разницы в 3 фрейма, сложенной с дополнительными тремя из-за онлайн-задержки, игрок Б получит инпут только на 26-фрейме, из-за чего постоянно будет испытывать очень неприятные откаты на 6 фреймов.

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

Заметим, что в данном случае откат полностью односторонний; только тот игрок, который опережает другого по фреймам будет испытывать последствия плохого интернет-соединения. Тони Кэннон, во многих смыслах основатель современной системы откатов (благодаря созданию middleware под названием GGPO), выдвигает теорию о том, что это один из главных изъянов в неткоде Street Fighter V, и более качественная синхронизация часов могла бы исправить проблемы с онлайном в игре. Некоторые фанаты даже протестировали эту идею самостоятельно и пришли к похожим выводам. Чтобы ещё более наглядно продемонстрировать свою точку зрения, Zinac показывает действие односторонних откатов на примере, который был изначально создан для демонстрации преимуществ самой системы.

Пример от Zinac, в котором P1 управляет красным прямоугольником, а P2 синим; Он сделал так, что игра у P2 опережает игру P1 на пару фреймов, без возможности синхронизироваться. Когда синий прямоугольник двигается, то P1, отстающий по синхрону, видит как тот передвигается плавно. Но когда двигается красный, то P2, опережающий P1, испытывает на себе кучу откатов (источник)

Решить эту проблему можно довольно прямолинейно. Большинство неткодов с откатом ненадолго приостановят игру, опережающую систему на 1 или 2 фрейма, чтобы отстающая смогла её догнать. Если игра будет держать это в приоритете и не позволит обоим версиям сильно отстать друг от друга, то данный процесс будет происходить быстро и безболезненно. Заострим внимание на том, что эти паузы происходят не из-за отсутствующих инпутов или других проблем с сетью; они направлены на устранение проблем, возникающих в тех случаях, когда программа запущена на двух разных компьютерах с разными мощностями, что в итоге может вызывать непредсказуемую разницу в том, как игра функционирует для обоих игроков. В данном случае потеря одного фрейма в течении каждых 10 секунд, необходимая для поддержания синхронизации на нужном уровне, будет малозаметной даже для самых внимательных игроков.

Что же такое GGPO?

Если вы общаетесь в кругах фанатов файтингов, то рано или поздно обязательно услышите про GGPO, библиотеке, созданной специально для неткода с откатами (код которой теперь находится в совершенно свободном доступе, а сама программа абсолютно бесплатна!), написанной Тони Кэнноном, одним из со-основателей EVO. И вы возможно заметите, что термины «откат» и «GGPO» используются так, будто они взаимозаменяемы. Первоначальный релиз GGPO состоялся в 2006-ом и был нацелен на тестирование системы откатов в популярных старых файтингах, запускавшихся с эмуляторов, а спустя некоторое время Кэннон выпустил версию библиотеки, которую можно было лицензировать и встроить в любую современную игру.

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

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

Опасайтесь граничных случаев

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

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

Звук также является одной из главных причин головной боли при использовании данного неткода. Звуки, проигранные в предсказанной версии игры часто обрезаются из-за отката, а аудио-эффекты, которых у локального игрока не было в принципе, теперь должны были прозвучать на несколько миллисекунд в прошлом, когда игра начнёт ре-симуляцию до актуального состояния. Особенно сложным это оказывается из-за того, что вы при этом должны всегда помнить о разделении игровой логики и всех остальных аспектов цикла. В играх, использовавших раннюю версию отката, игнорирование этих проблем приводило к вещам вроде жутких багов со звуком в Street Fighter x Tekken, когда в игре внезапно пропадал звук вовсе, или эффекты начинали внезапно проигрываться в неподходящий момент. Тони Кэннон перечислил свои советы по тому, как справляться с аудио-проблемами при использовании движка с откатом в статье из Game Developer Magazine, в разделе «Отделение игрового прогресса от рендеринга»

So at this point your game is rolling back properly and it is playable, woo!

Except now you've got visual and audio errors, everywhere.

A sound was rolled back over and should never have been played, but it's still playing. What do?
Итак, у вас наконец-то заработал откат и вы можете нормально играть, ура! Но теперь повсюду сплошь визуальные и звуковые ошибки. Звуковой эффект откатился и никогда не должен был прозвучать, но всё равно проигрывается. Что с этим делать?
Unlike a traditional game, you now have to keep full track of not just every sound you play, but the status of every sound that has been played, and whether or not it has been 'canceled out' by things that occured in the rollback.

That's not easy to do!
В отличие от традиционной игры, вам нужно следить не только за всеми проигрываемыми звуками, но и за статусом звуков которые уже прозвучали, а также «отменились» ли они после отката. И это не самая лёгкая задача!

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

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

Игрок за Коди использует EX Zonk Knuckle, для применения которого надо зажать несколько кнопок, а потом отпустить, но затем игра внезапно производит откат, отменяя это действие. Я могу лишь предположить что это произошло потому, что алгоритм SFV некорректно запомнил во время своего предсказания, какие именно кнопки Коди зажимал, из-за чего заставил его выполнить именно этот приём.

Стоит ли откат всех этих усилий?

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

Всё зависит от того, когда именно вы решите добавить откаты в свою игру. Если вам необходимо ввести их уже после того, как вы создали каркас основных игровых механик и систем то да, это очень затруднительно. Когда NetherRealm Studios решили сделать это в патче для Mortal Kombat X, игре которая уже вышла, им потребовалось порядка 8 лет в человеко часах, поделенные на команду программистов, занимавшихся этим на протяжении 10 месяцев. Создатели Rivals of Aether потратили большую часть своего времени разбираясь в том, как им превратить свой основанный на задержке неткод в такой же, но с откатами, и в конце концов просто отказались от этого перехода, когда поняли что это им дорого обойдется. С другой стороны у нас есть Майк Займонт (более известный как MikeZ), главный программист Skullgirls, добавивший GGPO в свою игру за две недели в раннем цикле разработки, используя для этого собственный движок, который был специально заточен под откаты. Таким образом мы делаем вывод, что определение типа неткода на ранних стадиях разработки сильно снижает потребность в его последующей отладке и изменениях.

Добавление откатов также даст вам дополнительные преимущества и в других аспектах игры. К примеру если вы обладаете возможностью без лишних затрат сохранять и загружать игровое состояние, то можете использовать её для улучшения режима тренировки. И один раз добавив откаты в ваш неткод, вы сможете воспользоваться этим опытом для всех ваших последующих проектов. После всех вложенных в MKX сил, NetherRealm Studios и их фанаты могут довольствоваться приятной, стабильной игрой по сети во всех будущих играх компании, которые будут созданы на том же движке, включая Injustice 2 и Mortal Kombat 11.

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

Послесловие от переводчика.

Я слегка поленился и не до конца перевёл эту статью. Последние два листа в ней заняты интервью с разработчиками Iron Galaxy Studios, которые приложили руку к созданию второго и третьего сезонов Killer Instinct, а также интервью с Стивеном «Sajam» Льоном, комментатором соревнований по файтингам, в котором автор по сути рассматривает мнение касательно неткода с откатами со стороны разработчиков и игроков. Но так как я маленькая инди-студия…то есть человек с 40-часовой рабочей неделей, то я может быть переведу это уже у себя в блоге. Потом.

Касательно самого перевода — я испытывал небольшие проблемы с переводом "game state", и остановился на "игровом процессе" (UPD. - уже подправленный обратно на "игровое состояние, чтобы не вызывать неразбериху), а также "edge case", который больше знаком программистам, но не мне, равно как и вещи вроде "game loop". Также я решил оставить термины вроде "фрейм" и "инпут" нетронутыми, потому что если вы спросите любого фаната файтингов, то ему эти вещи намного ближе чем "кадр" и "ввод".

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

Всё, я кончил.

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Kilyari Azure", "author_type": "self", "tags": ["\u043b\u043e\u043d\u0433","long"], "comments": 92, "likes": 230, "favorites": 453, "is_advertisement": false, "subsite_label": "gamedev", "id": 96175, "is_wide": false, "is_ugc": true, "date": "Thu, 23 Jan 2020 20:05:14 +0300", "is_special": false }
0
92 комментария
Популярные
По порядку
Написать комментарий...
12

DTF освещает только то, что им интересно/за что им платят

Безотносительно к теме статьи: смешно читать такие высказывания на сайте, размещать информацию на котором может любой желающий.

Ответить
14

Разместят.

 Но вот только любой пук про Mortal Kombat выведут в твиттер и ВК, остальное же, менее популярное в СНГ такой участи не удостоится.

В конце марта-начале апреля будут проводиться отборы на Intel World Open 2020 на который будет отбираться российская команда по Street Fighter V - как думаешь, выведут этот пост в соц.сети? Нет, ибо не МОБА и не шутаны и переходов и рекламы не даст нужной. Это реалии и ред.коллегии надо тратить усилия на "хлебные" статьи, чтобы ресурс был на плаву.

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

Ответить
10

И тебе привет) давай сразу к делу:
1) Редакция всегда старается постить те темы, которые могут вызвать максимальный интерес у читателей. Да, про файтинги мы пишем мало, потому что у них достаточно маленькая аудитория. Естественно, мы стараемся цеплять какие-то хайповые темы вроде новых героев в известных тайтлах или больших анонсов новых игр. Тут логика очень простая: если тема не интересна читателям (а просмотры на постах о файтингах подтверждают этот факт), то никто из редакции не будет тратить рабочее время на заметку, которая даст мало выхлопа и будет не интересна основному ядру аудитории.
2) Как я уже сказал выше, мы пишем про то, что "залетает". Файтинги, увы, в этот пункт не попадают. Это, в первую очередь, бизнес. Ты правильно говоришь, что мы работаем за просмотры, как и любой другой сайт, на который ты заходишь каждый день — потому что жрать хочется всем.
3) Из агрументов выше ты поймёшь, почему мы пишем про "MOBA и шутаны" — потому что они интереснее основному ядру читателей. Да и то, претензия странная: из всех моба мы пишем только про League of legends, про доту и тд вообще не пишем, ну а про шутаны так говорить просто глупо — все любят шутаны, особенно в преддверии Дум Этернал.
4) Я понимаю твою боль, поверь. Мне самому нравится этот жанр и я бы хотел, чтобы он по популярности сравнился с теми же шутанами. Но я, увы, уже взрослый мальчик и понимаю, что некоторые вещи не зависят от моих хотелок.
5) Конкретно про меня и про мои "ошибки". Может, я уже забыл, но я вроде бы ни разу не писал заметки о механиках или чем-то таком, что могло вызвать у тебя негодование. Я всегда стараюсь объяснять понятным и доступным языком — такова моя работа. Какой смысл мне писать заметку так, чтобы ее поняло три человека, а не 300?

Надеюсь, объяснил доступно.

Ответить
5

Единственные пользовательские материалы по файтингам, которые я видел за последние полгода, были анонсы по Guilty Gear Strive, и 90% из них были просто коротким описанием с тизером, за исключением вещей вроде https://dtf.ru/games/79549-novaya-informaciya-o-guilty-gear-2020

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

Ответить
3

Этот пост, кажется самый длинный длиннопост который я видел. Моё почтение

Ответить
6

Имхо,  game state, равно как и edge case, хорошо звучат дословно: "состояние игры" и "граничный случай" - это распространенные общепринятые термины, которые, к тому же, сами себя прекрасно описывают. Для game loop "игровой цикл" - тоже неплохой вариант, но тут уже нужно примечание, что он из себя представляет.

Ответить
2

состояние игры

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

По-моему ведь это немного не то, нет? Edge Case конечно обладает словом "edge", но здесь скорее отсылка к "fringe", когда у тебя есть какое-то постоянство, из которого что-то выбивается. 

Ответить
2

Есть еще конкретный пример. Есть поля ввода ника при регистрации на сайте. В 99% случаев пользователь введет нормальный ник, типа "Arugin". Это так называем "Main Success" сценарий. И в 1% кто-нибудь вобьет "sf@'``dasس‎ ش‎ ص‎ ض‎ ط‎ ظ‎ f31_4", не вобьет ничего, попытается вставить в поле картинку и так далее. Это все "едж кейсы", и не смотря на такой малый процент, их все нужно обрабатывать. И на это уходит солидный кусок времени разработки.  Аналогично в играх игрок может пойти не туда, куда запланировано, выполнять действия в обратном порядке или пытаться вообще подменить файлы игры или влезть в память с помощью Артмани. Короче всё, что редко, но ожидаемо может пойти не так, как запланировано.

Ответить
1

В любом случае, проделана отличная работа!

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

Ответить
2

Ну, я это учту на будущее, потому что поиск в ру-сегменте не помог, перенаправляя меня на "крайний случай"

Ответить
4

я испытывал небольшие проблемы с переводом "game state", и остановился на "игровом процессе"

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

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

Ответить
2

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

Я постараюсь что-то с этим сделать, но очень надеюсь что использование термина "сериализация" будет достаточно ясным намёком для того, чтобы люди не перепутали процесс и состояние.
UPD.
А вообще не, вылез из кровати, поправил как надо, где смог. 

Ответить
1

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

Ответить
0

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

Я бы предложил что-нибудь вроде:
кадр/момент/состояние игрового процесса

Ответить
4

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

Ответить
0

Не любишь МК?

Ответить
0

Неа. Файтинги от незеров неуважаю.

Ответить
2

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

Ответить
1

Игра предсказывает как поведёт себя твой противник. Приходит от него пакет с нажатыми кнопками и сравнивается с предсказанием. Совпало? Отлично. Не совпало? А вот теперь игра прогоняется с момента, когда не угадала, до текущего кадра. Т.е. за один кадр игре надо умудриться промотать несколько кадров, т.е. время вперёд. Ладно, хоть рендерить их не надо.

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

Ответить
1

Отличная идея объяснять на примере Кинг Кримсон, учитывая что "он просто работает"

Ответить
1

Этот мем уже лет пять как не актуален.

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

Ответить
0

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

Ответить
0

А тут стирают время оба игрока другу-другу :D

В итоге - битва телепортеров.

Ответить
1

Орешь ЗА ВАРУДО и метаешь ножи

Ответить
0

Потом забываешь, что делал это.

Ответить
0

Ведь это делал твой враг

Ответить
0

Для меня это все еще магия, даже с полным пониманием

Ответить
2

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

Ответить
0

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

Ответить
4

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

Ответить
1

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

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

Ответить
3

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

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

Ответить
1

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

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

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

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

Ответить
0

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

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

Ответить
1

Спасибо за перевод! Game state я бы скорее перевел как "состояние игры", то есть внутреннее состояние мира, со всеми переменными и данными.

Еще на ArsTechnica недавно была очень подробная статья с иллюстрациями про неткод файтингов

Ответить
0

Это вообще-то она и была, потому что они просто взяли текст из блога/с сайта Infil'а. 

Ответить
1

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

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

Ответить
0

Во время выполнения увидишь, что увернулся - и всё, не прервать и не уклониться?

Ответить
0

Играл же в Черепашки на Денди?

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

Или пускает ложную атаку, ты прыгаешь, а атаки не было. И вот ты попался...

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

Комбо вообще не должна была начаться - вот в чём прикол.

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

Ответить
0

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

Ответить
0

Если так уверен, значит личный опыт есть? Потому что чот нет жалоб на такое.

Ответить
0

При чём тут личный опыт. Это просто вытекает из того, как оно работает.

Ответить
0

Тогда откуда максимальная уверенность? Тыж знаешь все это только по статье.

Ответить
0

Ты прочёл статью? Ты понял как именно работает традиционный код с синхронной задержкой и как работает роллбак?

Ответить
0

Да понял, но я все еще считаю что игрок просто не заметит этого. Слишком маленькое окно для подобного.

Ответить
0

А знаешь, что такое хитконфирм? Знаешь за сколько фреймов человек физически способен осмысленно среагировать на движения противников в файтингах?

Ответить
0

менее 0.1с. Это на 60 фпс вообще не заметно если не сидеть с лупой

Ответить

Тактический файл

0

откат-неткод

Я канешн придираюсь, но может стоило оставить оба англицизма дав пояснение вида:
Роллбэк-неткод [сетевой код с откатом] ну или что-то подобное.

Ответить
0

В попытках найти решение для данных препятствий в сетевой игре появилось два характерных подхода: использование неткода, основанного на задержке (delay‑based netcode) либо же неткода, основанного на откате (rollback netcode).

Или тебе нужна была прямо русская транслитерация слова "rollback"?

Ответить

Тактический файл

Kilyari
0

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

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

Ответить
3

Я долго над всем этим думал, на самом деле. Если использовать "роллбэк", то опять-таки будет очень много режущих слух/глаз словосочетаний. Если использовать и то, и другое, то возникнет винегрет из терминов.

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

Ответить

Тактический файл

Kilyari
0

Спасибо за статью, бтв. Муторно и много.

Ответить
1

Оригинальный источник просто хороший, человек выбрал самые нужные вещи и ссылки. Там одна презентация Сталлоне с GDC золотая, потому что он максимально подробно и сжато объясняет все проблемы с роллбэком и то, как же они задницу в NetherRealm рвали, чтобы задним числом вилкой прикрутить совершенно новый тип онлайна в ПАТЧЕ! ПАТЧЕ, КАРЛ! Я хоть их игры и не люблю, но целеустремленность небольшой команды программистов там легендарная была.

Ответить

Минувший месяц

0

Спасибо! С меня дошик.

Ответить
0

Ооочень подробно

Ответить
0

Хотела бы узнать, как называются типы сети, когда ты управляешь объектом (Dota 2, Wreckfest, iRacing...) и когда ты сам являешься объектом (CS: GO, GTS...)? Мб какие-то другие есть?

Ответить
0

Разницы непонятна. GTS - это Gran Turismo Sport же? Wreckfest тоже с прямым управлением, не мышкой...

Ответить
0

Gran Turismo Sport же

Не поняла про мышку, к чему она? 

Ответить
0

Попробуй объяснить по другому чем перечисленные игры отличаются в управлении.

Ответить
0

Не в управлении, а в сетевом взаимодействии. 

Ответить
0

Какое различие между iRacing и GTS, из-за чего у них должна быть разная сетевая часть?

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

Ответить
0

В iRacing авто находится на сервере и ты ее управляешь (что для постороннего наблюдателя авто твое будет ехать плавно внезависимости от интернета, при этом у тебя лагать), в GTS ты и есть авто, и если у тебя плохой интернет, то твоя машина будет телепортироваться и лагать для стороннего наблюдателя, а у тебя авто будет ехать плавно. 

Ответить
0

Это сокрытие лага, интерполяция и экстраполяция: http://www.ant-karlov.ru/PlayerIO-interpolyatsiya-ili-udivitelniy-mir-obmana.html

Ответить
0

Спасибо за статью. Немножко не то, но интересно было прочесть. 

Ответить
0

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

Да в общем-то никак. Проблемы те же, методы борьбы те же. Но на самом деле в большинстве игр используется авторитетный сервер, который получает все инпуты, у себя высчитывает единое состояние и отсылает его всем клиентам. Lockstep для игр с >2 игроками это тот ещё ад. В файтингах его использовать удобнее потому что большие требования к задержке (фреймы считают) и всего два игрока.

А от первого лица игра или от третьего - роли не играет никакой.

Ответить
0

Статья супер, спасибо!

Ответить
0

Большое спасибо за интересную статью.

Ответить
0

Отличный труд, спасибо.

Ответить
0

Спасибо, очень интересная статья =)

Ответить
0

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

Ответить
0

Под конец жизни Mortal Kombat XL неткод в игре был уже вполне сносным. Даже с пингом выше 100 мс можно было играть без особых проблем. С одиннадцатой частью, на мой взгляд, все не так радужно. Иногда затыки какие-то совершенно непонятные случаются.

Ответить
0

Ну чо, давай теперь статью про баги в файтингах.

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

Ответить
0

Почему бы просто не увеличивать окно без этой системы?

Ответить
0

Ну, да наверное нет никаких причин почему бы и нет.

Ответить
0

Шикарная статья, спасибо за перевод.

Ответить
0

Отлично зашла статья, узнал много нового. За перевод отдельное спасибо.

Ответить
0

Хоть и много воды, но работа монументальная. И разрабы МК просто красавчики - то неткод, то фотореалистичные лица на уровне Капкома.

Ответить
0

Хоть и много воды

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

Ответить
0

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

Ответить
0

Да вообще нет, не пропал, рывки есть в любой игре. Или тебе прямо актуален бег как в раннем МК? Я думаю он пропал скорее из-за того что игры решили выбрать немного другую модель для своего геймплея. Если хочешь такой же динамики, то есть всякие GG и BB, где ты можешь делать эйрдаши до посинения через весь экран так, будто перепил кофе с кокаином. 

Ответить
0

А там можно так же резко приблизиться по земле и свободно атаковать?

Ответить
0

А почему нет? 

Ответить
0

Где там резкое сокращение дистанции по земле?

Ответить
0

В первых же секундах ролика. 

Ответить
0

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

Ответить
0

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

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

Ответить
0

я из за гг разломал psp в детстве, очень уж специфичное удовольствие эти файтинги

Ответить
0

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

Ответить

Прямой эфир

{ "jsPath": "/static/build/dtf.ru/specials/DeliveryCheats/js/all.min.js?v=05.02.2020", "cssPath": "/static/build/dtf.ru/specials/DeliveryCheats/styles/all.min.css?v=05.02.2020", "fontsPath": "https://fonts.googleapis.com/css?family=Roboto+Mono:400,700,700i&subset=cyrillic" }