Это перевод статьи с официального сайта. Вот тут Вы можете прочитать оригинал.
Добрый день!
Работа над версией 0.12 идет полным ходом в соответствии с планом, изложенным в предыдущих пятничных фактах. Так что сегодня у нас есть отличная возможность поговорить об одном из предстоящих улучшений для мультиплеера, а именно - что же мы планируем делать с задержкой?
Давайте начнем с определения проблемы. Допустим, Вы хотите поиграть в мультиплеер c другом (это еще пока не проблема). Если Вы живете далеко друг от друга (в разных странах), либо у Вас проблемы с интернет соединением, то пакеты с компьютера на компьютер будут путешествовать не мгновенно. Эту штуку мы и называем задержкой. В зависимости от расстояния и качества сети задержка может быть довольно значительной. Также, поскольку соединение может быть ненадежным, мы по сути имеем дело с удвоенной задержкой (сигнал путешествует туда и обратно).
При запуске многопользовательской игры Вы увидите ползунок, который выставляет ожидаемую задержку. В настоящий момент это значение вводится вручную и оно одинаково для всех игроков. Это число определяет задержку между каким-либо действием пользователя и применением результатов этого действия. К примеру, Вы кликните по машине, чтобы открыть ее содержимое. В одиночной игре результат будет мгновенным. В мультиплеере это произойдет только по истечении определенного времени (в среднем равному задержке). Причиной этого является необходимость соблюдать последовательность действий. Все игроки производят какие-то действия в определенном порядке. Поэтому игра может применить Ваше действие только тогда, когда она применит все предыдущие действия (на данный момент времени) всех других игроков. Вот и получается, что Вы делаете что-то, потом ждете, ждете, ждеееетееее.... и только потом получаете результат.
Проблема не особо серьезна для клиент-серверных моделей (Quake, Doom и т.п.). Это возможно потому что текущее состояние компонентов игры не велико по размеру. Насколько я знаю, клиент в таких играх обновляет состояние, а затем спрашивает у сервера, является ли его новое состояние корректным. Если нет, то клиент загружает с сервера корректное состояние. Увы, но как уже упоминалось, такой путь не подходит для factorio, потому что тут текущее состояние игры весит слишком много, чтобы запросто передавать его по сети (к тому же оно меняется очень часто и быстро - подумайте, например, обо всех объектах, перемещающихся на конвейере).
Ну ладно, лаги раздражают. Реально бесят. Одна из вещей, над которой мы постоянно работаем для версии 0.12 - это механизм, обеспечивающий устранение задержки. Короче говоря, этот механизм будет выглядеть так, как будто некоторые действия пользователя исполняются моментально. Пока что у нас не стоит цель сделать этот механизм применимым для любых действий. Мы просто стараемся сделать игровой процесс настолько быстрым, насколько это возможно в данных условиях. На данный момент самое трудное уже сделано и уже работают следующие действия:
Спасибо за внимание!
Если Вам понравилась статья, поделитесь ей с друзьями! Чтобы следить на новыми статьями, подписывайтесь на наш блог или вступайте в сообщества: ВКонтакте, google+, twitter.
Добрый день!
Работа над версией 0.12 идет полным ходом в соответствии с планом, изложенным в предыдущих пятничных фактах. Так что сегодня у нас есть отличная возможность поговорить об одном из предстоящих улучшений для мультиплеера, а именно - что же мы планируем делать с задержкой?
Проблема задержки.
Давайте начнем с определения проблемы. Допустим, Вы хотите поиграть в мультиплеер c другом (это еще пока не проблема). Если Вы живете далеко друг от друга (в разных странах), либо у Вас проблемы с интернет соединением, то пакеты с компьютера на компьютер будут путешествовать не мгновенно. Эту штуку мы и называем задержкой. В зависимости от расстояния и качества сети задержка может быть довольно значительной. Также, поскольку соединение может быть ненадежным, мы по сути имеем дело с удвоенной задержкой (сигнал путешествует туда и обратно).
При запуске многопользовательской игры Вы увидите ползунок, который выставляет ожидаемую задержку. В настоящий момент это значение вводится вручную и оно одинаково для всех игроков. Это число определяет задержку между каким-либо действием пользователя и применением результатов этого действия. К примеру, Вы кликните по машине, чтобы открыть ее содержимое. В одиночной игре результат будет мгновенным. В мультиплеере это произойдет только по истечении определенного времени (в среднем равному задержке). Причиной этого является необходимость соблюдать последовательность действий. Все игроки производят какие-то действия в определенном порядке. Поэтому игра может применить Ваше действие только тогда, когда она применит все предыдущие действия (на данный момент времени) всех других игроков. Вот и получается, что Вы делаете что-то, потом ждете, ждете, ждеееетееее.... и только потом получаете результат.
Устранение задержки.
Проблема не особо серьезна для клиент-серверных моделей (Quake, Doom и т.п.). Это возможно потому что текущее состояние компонентов игры не велико по размеру. Насколько я знаю, клиент в таких играх обновляет состояние, а затем спрашивает у сервера, является ли его новое состояние корректным. Если нет, то клиент загружает с сервера корректное состояние. Увы, но как уже упоминалось, такой путь не подходит для factorio, потому что тут текущее состояние игры весит слишком много, чтобы запросто передавать его по сети (к тому же оно меняется очень часто и быстро - подумайте, например, обо всех объектах, перемещающихся на конвейере).
Ну ладно, лаги раздражают. Реально бесят. Одна из вещей, над которой мы постоянно работаем для версии 0.12 - это механизм, обеспечивающий устранение задержки. Короче говоря, этот механизм будет выглядеть так, как будто некоторые действия пользователя исполняются моментально. Пока что у нас не стоит цель сделать этот механизм применимым для любых действий. Мы просто стараемся сделать игровой процесс настолько быстрым, насколько это возможно в данных условиях. На данный момент самое трудное уже сделано и уже работают следующие действия:
- передвижения игрока.
- выбор объектов / построек.
- открытие / закрытие окна управления постройками.
- возведение и быстрая замена построек.
- добыча ресурсов.
- сбор вещей из курсора.
Мы могли бы добавлять к этому какие-то детали. Возможно даже сделать таким образом движение автомобиля, но это сложнее, так как нужно учитывать возможность столкновения.
Состояние задержки.
Технически, устранение задержки происходит с помощью специального слоя (назовем его слой состояния задержки), который дублирует соответствующую часть состояния игры. Все буферные локальные действия игрока, еще не примененные к текущему состоянию игры, применяются к этому слою. Вернувшись к примеру с машиной, мы увидим, что ее интерфейс по прежнему закрыт в текущем статусе игры, но на слое задержки он открывается. Слой задержки далее применяется для прорисовки окна игры и для дальнейших действий пользователя (например игрок может взять что-нибудь из машины, хотя, фактически в статусе игры она все еще закрыта).
Хорошая штука в этом подходе - само-исправление ситуации. То есть слой задержки сбрасывается каждый тик игры и синхронизируется с ее текущим статусом. Что же произойдет, если когда происходит конфликт действий пользователей? Например игрок начал движение (на слое задержки), а другой игрок в этот момент построил на его пути какое-нибудь здание. Из-за использования слоя задержки игрок начнет двигаться сразу. Но потом, во время обработки игрового тика, в который другой игрок построил здание, наш бегун будет как бы "телепортирован" назад и обнаружит себя бегущим лбом в здание. Таким образом не происходит корректировки состояния игры. Просто корректируются результаты отложенных действий игрока (в данном случае - бег) после получения информации о новом здании.
Планы на будущее.
В целом описанная система скрытия задержки довольно трудно применима для многих действий игрока. Поэтому мы не планируем как то применять ее при взаимодействиях со зданиями (ну кроме основных, таких как открытие, вращение и т.п.) и боях. Стрельба может приводить к целому каскаду изменений в состоянии игры, которые нужно будет учитывать на слое задержки. Мы считаем, что это слишком сложно, чтобы заниматься этим в данное время.
Сейчас мы планируем потратить какое-то время на игру с большими задержками, чтобы потом внести в игру новые дополнения и улучшения, основанные на этом опыте. Естественно, чем больше игроков, тем больше суммарная задержка (максимальное время ожидания между всеми парами игроков). Это еще одна из слабостей нашей P2P модели. В ближайшем будущем мы попытаемся устранить эту проблему. Есть два пути:
- Уменьшить размер передаваемых пакетов. Существенная часть пакетов не содержит важной информации, зато там много заголовков, серийных номеров и прочих структур данных. Этот момент будет учтен в версии 0.12.
- Разрешить ретрансляцию пакетов через сервер. Даже лучше, если это будет выделенный сервер (мы поработаем над этим). Это означает, что игроки будут общаться только с сервером, а не друг с другом. Меньше трафика, меньше медленных соединений. Вероятно, таких новшеств не будет в версии 0.12, но этот способ имеет высокий приоритет в нашем списке дел.
Сегодня вместо картинки мы представляем короткое видео, на котором показано скрытие задержки в игре:
Обсуждение этого всего на официальном форуме: http://www.factorioforums.com/forum/viewtopic.php?t=10116
Спасибо за внимание!
Если Вам понравилась статья, поделитесь ей с друзьями! Чтобы следить на новыми статьями, подписывайтесь на наш блог или вступайте в сообщества: ВКонтакте, google+, twitter.
Комментариев нет:
Отправить комментарий