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

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

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

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

Стабильный отклик

Как следует из рассмотренного алгоритма, обе стороны, клиент и сервер, полагаются на своевременное получение определенной информации. И если отклик нестабилен, может возникать джиттер. То есть стабильный 100-миллисекундный отклик иногда лучше, чем «усредненные» 50 мс, если фактический разброс времени отклика составляет 10–110 мс. Конечно, игра знает точное время пакета, но визуально поведение при джиттере может быть будет более дерганным.

Приемлемый коэффициент потери пакетов

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

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

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

Отсутствует взаимодействие с другими игроками

Разумеется, в игре такого быть не может. Однако большую часть времени (99,9%) никаких взаимодействий не происходит, а 99% всех взаимодействий составляет стрельба. Стрельба — отличный тип взаимодействия (с точки зрения сетевого кода и погружения в игру), поскольку большую часть времени она либо ни к чему не приводит (промахи и рикошеты), либо наносит реальные повреждения. Поэтому некоторая рассинхронизация выглядит приемлемо и не сказывается на погружении (например, в случае небольшой телепортации, если позиция смещалась еще в течение 100 мс после того, как уже 200 мс назад на траектории игрока было нанесено повреждение).

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

Насколько мне известно, подобный сетевой код был изобретен именно в War Thunder. Отраслевым стандартом для шутеров является отображение каждого клиента с интерполяцией в прошедшем времени (Battlefield, CS), что ставит игроков с высоким откликом в более выгодное положение (а также не работает достаточно эффективно для физических столкновений по очевидным причинам — все движения уже были совершены в прошлом), либо вообще без (дополнительной) интерполяции (Q3), где нужно угадывать время задержки и целиться в противника с упреждением (что также неэффективно в отношении столкновений и ставит игроков с высоким откликом в крайне невыгодное положение).

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

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

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

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

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

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

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

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

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

Генеральный директор и ведущий разработчик Gaijin Entertainment Антон Юдинцев