Компьютерная физика

Ответ 1

То, что я в итоге закончил, просто пропустило предсказание alltogether и просто сделало это:

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

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

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

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

Ответ 2

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

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

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

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

• Сервер должен принять решение о надвигающемся столкновении. Алгоритм обнаружения столкновений не должен быть на 100% совершенным, он должен быть достаточно близко, чтобы избежать явных несоответствий.
• Как только сервер определит, что два транспортных средства столкнутся, он отправляет каждому из двух пользователей сообщение о том, что столкновение неизбежно.
• На клиенте А позиция транспортного средства В регулируется (реалистично), чтобы гарантировать, что произойдет столкновение.
• На клиенте B положение транспортного средства A регулируется (реалистично), чтобы гарантировать, что произойдет столкновение.
• Во время столкновения положение каждого транспортного средства может быть скорректировано по мере необходимости, чтобы конечный результат соответствовал остальной части игры. Эта часть - именно то, что MedicineMan предложил в его ответе.

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

Ответ 3

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

Ответ 6

Немногие мысли.

• Другим сверстникам лучше справляться с латентностью и высокими скоростями.

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

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

2. Если вы хотите пойти клиент/сервер, то это будет хуже p2p

Что нужно предпринять o) Экстраполируйте клиентов вперед, как в p2p, чтобы выполнить обнаружение столкновений. o) Отправить результаты столкновения обратно клиентам и экстраполировать вперед

Обратите внимание: это НИКОГДА не будет таким же хорошим, как p2p. В основном высокая скорость и латентность = ошибка, так что удаление латентности - лучшая стратегия. P2P делает это.

Ответ 7

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

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

Ответ 8

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