Как синхронизировать действия, такие как прыжок в мультиплеере?

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

Предположим, что клиент А двигался, он был на 100 м в 10,2 раза со скоростью 100 м / с и отправил эту информацию. Клиент Б получит эту информацию несколько позже, пусть это будет 10.4. Поэтому на клиенте B я могу использовать прогнозирование и разместить клиента A на расстоянии 120 метров. Но что, если клиент сделал прыжок на 110 м в 10.3. Я не могу предсказать это, и так как я использовал предсказание, я не могу показать, как клиент А прыгал в прошлое.

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

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

— Суяш Мохан
источник

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

— Кристиан

@ Кристиан, эй! Спасибо за ответ. Я знаю об этом подходе, но это может сделать игровой процесс прерывистым, если задержка высока, и, кроме того, я использую систему реального времени BaaS AppWarp, поэтому вся моя логика лежит только на стороне клиента.

— Суяш Мохан

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

— MichaelHouse

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

— Крис Уэлш

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

— ggambett
источник

Я использовал этот подход, когда писал свою первую сетевую многопользовательскую игру. На самом деле я использовал @ ggambett в качестве ссылки. Это хорошо сработало для меня.

— NoobsArePeople2

Существует довольно подробное описание исходного движка. Казалось бы, часть соответствующего исходного кода также доступна как часть Source SDK.

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

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

— Будет
источник