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

Итак, сначала я бы проверил, что форма использует

Если вы используете Laravel Forge, убедитесь, что лимит файлов установлен на приемлемое значение, это можно изменить в разделе «Сведения о сервере -> PHP». "

enter image description here

Вы также можете проверить, используя dd по запросу и проверяя, что вы получаете на стороне сервера

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

7 ответов

В конце концов я просто пропустил предсказание и просто сделал следующее:

  1. Клиент очень много говорит о своей позиции,
  2. Сервер (почти) говорит что-нибудь только о положение клиента-владельца, когда произошло "высокоэнергетическое" столкновение с другим динамическим объектом (т. е. не статической средой).
  3. Клиент принимает meshoffset = meshpos-Physpos при получении позиционного обновления от сервера, а затем устанавливает meshpos = Physpos + meshoffset для каждого кадра и постепенно уменьшает meshoffset .

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

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

Редактировать: В конце концов я добавил функцию «владения», которую Глен Фидлер (блоггер, упомянутый в вопросе) реализовал для Mercenaries 2: каждый клиент получает право собственности на (динамические) объекты, с которыми они сталкиваются из-за какое-то время. Это было необходимо, поскольку в противном случае проникновение становится глубоким в ситуациях с высокой задержкой и высокой скоростью. Это решение работает так же здорово, как вы думаете, когда видите видео-презентацию GDC, можете определенно рекомендовать его!

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

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

Клиент 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
поделиться

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

Например, я реализовал некоторые важные части сетевой физики для Mercenaries 2 под руководством Гленна (упомянутый вами плакат в блоге). Невозможно было передать все необходимое физическое состояние по проводу даже для одного твердого тела. Физика Havok постепенно генерирует точки контакта в каждом кадре, поэтому текущее «контактное многообразие» является необходимой частью физического состояния для сохранения детерминированности моделирования. К тому же это слишком много данных. Вместо этого мы отправили желаемое преобразование и скорости и использовали силы и моменты, чтобы мягко подтолкнуть тела на место. Ошибки неизбежны, поэтому вам нужна хорошая схема исправления ошибок.

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

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