Главная » Пятничные факты » [Пятничные факты] Обзор мультиплеера #147

[Пятничные факты] Обзор мультиплеера #147

Просмотров: 84
Опубликовано:

Мультиплеер — новое поле для меня

После того, как мы запустили сервер соревований, мне, наконец, пришлось столкнуться с реальностью мультиплеера через интернет с людьми по всему миру. Мы поняли, что существует много проблем, возникающих на поверхности, и что нужно работать дальше. Я оставил всю многопользовательскую логику на cube и Tomas до сих пор, и у меня была только очень упрощенная  идея, как она работает. С Tomas’ом на праздниках и cube занят с другими задачами, я понял, насколько большая проблема — это то, что никто не имеет ни малейшего понятия, как она работает под капотом, поэтому я воспользовался этой возможностью, чтобы погрузиться в него лично. После недели чтения, дискуссии с cube и частичных обзоров, я могу представить вам мои выводы и дорожную карту происходящих изменений.
От модели равноправных узлов ЛВС в модели клиент-сервер, который до сих пор своего рода клиент-клиент.

От модели клиент-клиент к модели сервер-клиент это до сих пор клиент-клиент

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

  • Каждый должен быть на самом деле посылать пакеты всем остальным, что не так просто в современном мире, где IPv6 не везде, и общественный адрес IPv4 становится роскошью. Это может быть решена с помощью nat, но он также не 100% надежен.
  • Логика событий, как присоединение, выход, отсоединение, является очень сложным, так как он всегда должен быть обсужден коллегами, прежде чем что-либо может быть сделано. И, как у нас есть замок-шаг моделирования, он всегда должна быть обеспечена, что эти действия выполняются в совершенном синхронности. Сложность означает ошибки, и в этом случае, некоторые из них трудно исправить. Кроме того, даже если бы это было написано прекрасно, это бы не работало так прекрасно.
  • Каждый должен иметь такую же задержку.
  • Нет защиты от лагов отдельных игроков.
  • Один пакет для каждого игрока считается за тик отправленных и полученных каждым, поэтому количество отправленных пакетов является O (N ^ 2)

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

Оригинальная клиент-клиент модель:

fff-147-peer-to-peer-sending

Новая модель сервера:

fff-147-peer-to-peer-with-resending

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

Реальный клиент-сервер архитектура версии 1.0 (будет сделано)

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

Клиенты получают объединенный пакет раз за тик.

Одним из наиболее очевидных изменений, что вместо того, чтобы повторно отправлять все пакеты, сервер распаковывает и сливает их. Сначала он ждет, чтобы получить действия всех игроков в определенном тике, а затем отправляет его всем клиентам в качестве отдельного сообщения. Это не только снижает количество отправленных пакетов (от O (N ^ 2) O (N)), но он также держит клиентов от необходимости иметь дело с синхронизацией и дерьмом. Они просто принимает пакет,  и применяет его. Если он что-то упустил из-за потери пакетов, клиент просто запрашивает у сервера весь пакет, другими словами, клиенты больше не общаются друг с другом.

zbz

Клиенты не знают о других клиентах.

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

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

Удаление странных фризов из сетевых событий.

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

Упрощение внутреннего кода

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

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

Задержка в настоящее время является глобальным параметром многопользовательской игры, и это задержка между созданием пользовательского действия (Input действия), и это исполнение, тем больше задержка, тем больше времени, чтобы доставить действий между игроками, так что игра может быть менее лага. Большая задержка плохо для игры, небольшая задержка плохо для удаленных игроков. Но с правильной архитектурой клиент-сервер и сервер является органом действия только ввод, каждый может иметь различное время ожидания. Парень на той же улице, что и сервер должен только 30мс послать пакет на сервер, чтобы быть включены в следующий пакет объединенном и последующих 30мс, чтобы получить его действие назад, чтобы увидеть его на экране. Но кто-то из другой части мира, в той же самой игре, возможно, потребуется 500мс, чтобы отправить сообщение, поэтому его действия будут просто быть упакованы в объединенном пакет с большей задержкой.
Задержка отдельных игроков должна быть изменена автоматически во время игры на сервере, чтобы  он мог убедиться, что он настолько мал, насколько это возможно для безупречной игры.
Последствием этого было бы, что сервер будет иметь 0 задержки, это было бы несправедливо в конкурентной игре, но в Factorio, нет никаких причин, чтобы перетащить все вниз только, чтобы сделать его справедливым.
Не ждите загрузки.

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

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

 


comments powered by HyperComments

рек 728х90 single.php
Звёзд: 1Звёзд: 2Звёзд: 3Звёзд: 4Звёзд: 5 (Пока оценок нет)
Понравилось? Поделись в соц сетях!