Игровая коллизия физики сети

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

Пример

Скажите, что клиент A - 20 мс перед сервером, клиент B 300 мс перед сервером (считающий и задержку и максимальное дрожание). Это означает, что, когда эти два механизма сталкиваются, оба клиента будут рассматривать другой как 320 мс позади - в противоположном направлении скорости другого механизма. Лицом к лицу на шведской магистрали означает различие дворов на 16 метров/17.5!

Что не попробовать

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

50
задан Vaillancourt 17 October 2019 в 10:31
поделиться

5 ответов

Простите, что отвечаю «Что не пробовать», но я никогда не слышал о решении, которое не предполагает прогнозирования результата на стороне клиента. Рассмотрим упрощенный пример:

Клиент A неподвижен и наблюдает, как автомобиль клиента B приближается к обрыву. Транспортное средство клиента B способно мгновенно снизить скорость до 0, и делает это в последний возможный момент перед тем, как переехать обрыв.

Если клиент A пытается показать состояние клиента B в реальном времени, у клиента A нет другого выбора, кроме как предсказать, что Клиент Б упал со скалы. Вы часто видите это в MMORPG, разработанных таким образом, что персонаж игрока способен немедленно останавливаться при беге на полной скорости. В противном случае, Клиент A может просто отображать состояние клиента B по мере поступления обновлений состояния, но это не жизнеспособно, поскольку клиент A должен иметь возможность взаимодействовать с клиентом B в реальном времени в вашем сценарии (я предполагаю).

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

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

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

2
ответ дан 7 November 2019 в 11:09
поделиться

Возможно, лучшее, что вы можете сделать, - это не показывать фактическое столкновение в реальном времени, а создать иллюзию, что все происходит в реальном времени.

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

6
ответ дан 7 November 2019 в 11:09
поделиться

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

-1
ответ дан 7 November 2019 в 11:09
поделиться

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

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

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

Вот основная идея:

  1. сервер должен принять решение о надвигающейся коллизии. Алгоритм обнаружения столкновений не обязательно должен быть идеальным на 100%, он просто должен быть достаточно близким, чтобы избежать очевидных несоответствий.

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

      1. Сервер должен принять решение о надвигающейся коллизии. Алгоритм обнаружения столкновений не обязательно должен быть идеальным на 100%, он просто должен быть достаточно близким, чтобы избежать очевидных несоответствий.
      2. После того, как сервер определил, что столкновение двух транспортных средств произойдет, он отправляет каждому из двух пользователей сообщение, указывающее, что столкновение неизбежно.
      3. На клиенте A положение транспортного средства B регулируется (реально), чтобы гарантировать, что столкновение произойдет.
      4. На клиенте B положение транспортного средства A регулируется (реально), чтобы гарантировать, что столкновение произойдет.
      5. После столкновения положение каждого транспортного средства можно при необходимости отрегулировать, чтобы конечный результат соответствовал остальной части игры. Именно эта часть была предложена MedicineMan в его ответе .

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

13
ответ дан 7 November 2019 в 11:09
поделиться

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

Конечно, это добавляет дополнительный уровень сложности к вашей программе, поскольку вы должны учитывать, какие данные отправлять своим клиентам и как они должны на это реагировать. Например, вы можете отправить все «будущее» буфер для клиентов и позволяет им видеть, какие возможные коллизии на самом деле произойдут, а какие нет.

0
ответ дан 7 November 2019 в 11:09
поделиться
Другие вопросы по тегам:

Похожие вопросы: