Приветствую чемпионы Battlerite!
Меня зовут Даниэль “Prog” Фахлстрём и я один из программистов (примечание редактора: “Один из ведущих разработчиков”) здесь, в Stunlock Studios. Я работаю тут с января 2013. Кто-то из вас может знать меня со времён Bloodline Champions, так как я был активным участником сообщества и модератором. За время разработки Battlerite, я успел поработать в разных областях: бэк-энд геймплея, интерфейс и локализация.
В этих дневниках я коротко расскажу как работает система перемещения чемпионов в Battlerite (не сильно вдаваясь в технические подробности), что от нас требовалось и с какими вызовами мы столкнулись, избрав решение, которым пользуемся.
Задачи и сложности
Отзывчивость
Любое перемещение в Battlerite должно быть отзывчивым, будто вы напрямую управляете персонажа. Стоит избегать задержки между нажатием клавиш и происходящим на экране для полного погружения и сохранения плавности игрового процесса. Как нам кажется, это удалось нам при помощи нынешнего решения. Перемещение в Battlerite ощущается очень отзывчиво и будет таким, какими бы ни были задержки.
Защита от читов
Поскольку Battlerite это состязательная игра, мы вкладываем много усилий в то, чтобы игроки не смогли жульничать. В связи с этим, все действия игроков “происходят” на сервере, это значит, что любое действие (движение, использование способности, попадание снарядов и т.д.) полностью контролируются сервером.
Такое решение требует, чтобы сервер подтверждал все действия, которые ему присылают из локального клиента (имеется в виду игра Battlerite, которая запущена у вас на компьютере). После этого сервер убеждается, что все действия правильные, и только потом отправляет эти правильные позиции всем другим клиентам.
Задержка
Вызов, которого не избежать, создавая онлайн игру, — это задержки. Всеобщий повод для ярости во всех многопользовательских играх, и особенно в тех, где делается упор на скорость реакции и быстроту действий.
Из-за них все действия, происходящие в локальном клиенте, случаются позднее во всех других клиентах, если только оно не было спрогнозировано или симулировано. Поскольку задержек нельзя избежать, мы пользуемся принципом “Не убирая задержку, нужно просто решить, где её спрятать”.
В идеальном мире все игроки бы имели пинг не более 50мс на наших серверах, но, так как это не наш случай, одним из требований было, чтобы наша система работала и при задержках в 150 мс.
Вот пример того, как отзывчивость игры бы выглядела с и без большого пинга. Зелёная линия показывает направление движение, какие клавиши нажимаются в клиенте. Очевидно, что визуальное отображение делает игру намного более вялой для пользователя.
Вдохновение
Так как перемещение в Battlerite использует WASD, также как это работает во многих шутерах от первого лица, мы вдохновлялись примером надежно работающих решений, которые использовались в Quake и любой из игр Valve на движке Source. Мы адаптировали их подход, чтобы он лучше работал в Battlerite, но его суть осталась неизменной.
Существует большая разница между шутерами, перечисленными выши и Battlerite. Заключается она в том, что скорость снарядов в нашей игре достаточно медленная, по сравнению с моментальными выстрелами в тех играх. Это означает, что, когда в связи задержкой неправильно происходит попадание способностью (в вас попадают, хотя выглядело будто по вам промахнулись), это намного заметнее. Тот факт, что Battlerite это игра с видом сверху, только усугубляет это.
Если вам интересно, вы можете подробнее познакомиться с упомянутыми выше решениями, которыми мы вдохновлялись. Я подготовил список в конце этой статьи.
Так как же это работает?
Самым легким способом объяснить, как работает система передвижений – это подумать о ней примерно так: клиент визуализирует движения и отправляет команды имитированного движения на сервер. Это означает, что клиент постоянно показывает вашу исходную позицию, являющуюся позицией персонажа в игре. Поскольку клиент и сервер выполняют одни и те же вычисления, несоответствия возникают очень редко. Если это происходит, то клиент изменит визуализацию движения так, чтобы она соответствовала ожидаемой позиции на сервере.
Вот наглядный пример того, как ответная реакция будет выглядеть с нашим решением и без него, с высокой задержкой отклика сервера. Зелёная линия показывает направление движения в клиенте в момент нажатия на кнопку. Очевидно, что задержка визуальной обратной связи делает игру неповоротливой и медленной для игрока.
Зелёный кружок всегда идёт с опережением, когда мы симулируем команды движения через клиент, моментально отвечая на нажатие клавиш. Тогда как серверная позиция идёт с опозданием в связи с задержкой.
Проблемы
На данный момент эти принятые изменения (или любые другие) не являются полностью идеальными, поскольку задержка будет всегда решающим фактором. Так же, как упоминалось ранее, противоречивые ошибки будет гораздо легче обнаружить, глядя на снаряды при виде сверху.
Вот пример визуальной ошибки с очень высокой задержкой. Красным кружком, показанным на видео, является позиция Shifu, когда столкновение было обнаружено. Хоть в клиенте это выглядит неправильно, но это правильный результат на сервере.
Как мы знаем, игроки иногда называют это неправильными хитбоксами, но на самом деле это связано с задержкой на сервере.
Подводя итог, подобные ошибки неизбежны. Мы хотим позволить клиенту симулировать движения, но при этом позволить серверу владеть полномочиями выше клиента. Мы знаем – это то, что разочаровывает игроков Battlerite и мы постоянно ищем разные способы решения этих проблем, и стремимся к тому, чтобы игроки наслаждались игрой.
Спасибо за прочтение!
Технические статьи
Вот некоторые из статей, которые мы использовали в качестве вдохновения для сетевой модели, которую мы используем в разных областях игры Battlerite.
http://fabiensanglard.net/quake3/network.php
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization