Лучшая одноранговая игровая архитектура

10

Рассмотрим настройку, где игровые клиенты:

  1. иметь достаточно небольшие вычислительные ресурсы (мобильные устройства, смартфоны)
  2. все подключены к общему маршрутизатору (LAN, точка доступа и т. д.)

Пользователи хотят играть в многопользовательскую игру без внешнего сервера.

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

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

Каков наилучший подход к проектированию такой архитектуры? Есть ли известные примеры такого однорангового протокола на уровне локальной сети?

Ноты:

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

Безопасность

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

Редактировать:

Я забыл упомянуть: это будет довольно динамичная игра (стрелялка).

Кроме того, я уже читал о сетевых архитектурах в Gaffer на играх .

Dawid
источник

Ответы:

10

Взгляните на эту статью о сетевой архитектуре Age of Empires II.

Им удалось создать многопользовательскую игру, которая отлично работала на Pentium 90 с 16 МБ ОЗУ и модемным соединением 28,8 КБ / с. Они сделали это, заставив каждого игрока запустить свою собственную симуляцию, но синхронизировать свои команды.

У них есть некоторые хитрые трюки, я очень рекомендую это.

knight666
источник
5

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

Из-за пункта 2 система не должна быть сложной в отношении оптимизации

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

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

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

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

Каждый клиент может быть авторитетным источником данных о себе и своем непосредственном окружении (например, пули).

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

На самом деле это удивительно сложные переговоры между игроками, когда игра «a» предлагает игру «b»: «Я думаю, что этот объект ближе к вам. Вы должны взять его под контроль». И тогда игра «b» может либо принять, либо может отказаться, исходя из собственного взгляда на ситуацию. Различия в воспринимаемом игровом состоянии между «a» и «b», а также изменение во времени между отправкой и получением запроса и ответа делают это особенно неприятным небольшим согласованием для обеспечения надежности, и оно может легко выродиться в игру «горячая картошка», с владением объектом, постоянно подпрыгивающим между несколькими игроками. И даже если это работает должным образом, если смотреть с точки зрения игры «с», там «

Моя интуиция заключается в том, что такого рода подход «владения объектами», вероятно, будет слишком громоздким для небольших, недолговечных объектов, таких как пули. Мы использовали его для дорожных машин и для гонщиков ИИ, которые, как правило, жили в симуляции относительно долгое время. Кажется, что более эффективный подход, если вы готовы доверять клиентам, состоял бы в том, чтобы у каждого игрока была своя позиция и свои снаряды, и объявляли, когда этот игрок был поражен чужим снарядом. (Так же как и «игра A», я отвечаю за то, где находится игрок A и снаряжение игрока A, но игрок B отвечает за то, что я ударил игрока B). С некоторыми хорошими расчетами вы должны быть в состоянии получить довольно разумное поведение из системы, подобной этой.

Тревор Пауэлл
источник
1

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

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

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

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

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

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

kochol
источник
1
Этот ответ, кажется, о цикле игры. Я думаю, что ОП спрашивает о системе распределения нагрузки; в частности, кто имитирует, что и как общаются клиенты. Не могли бы вы рассказать подробнее? Я также заинтересован в этой проблеме.
Wackidev
@Wackidev с этим типом сети вы можете быть уверены, что все ваши клиенты синхронизированы, чтобы вы могли протестировать лучший способ, который соответствует вашим потребностям. Первый способ - отправлять входные данные только другим, и каждый клиент имитирует работу, стрельбу, обнаружение столкновений и т. Д. Второй способ - каждый клиент отправляет информацию о своем персонаже другим, например, положение, поворот, состояние, кадр анимации и т. Д., Чтобы другие клиенты только рассчитывает их материал и отправляет их по сети, но первый способ более безопасен.
Кочол
Поэтому, пожалуйста, укажите это в своем ответе. Прямо сейчас я не думаю, что это отвечает на вопрос. Также, пожалуйста, удалите первый дублирующий комментарий. Спасибо. Что касается самой идеи, разве первый вариант, который вы перечислили, не требует, чтобы моделирование было детерминированным?
Wackidev