Подтвердить что ты не робот

Мультиплеерная синхронизация игр

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

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

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

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

4b9b3361

Ответ 1

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

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


Также описание того, как это обрабатывается в исходном движке (механизм Valve для первой игры Half Life), можно найти здесь, принцип в основном тот же - пока сервер не скажет вам, что в противном случае используется алгоритм прогнозирования для перемещения объекта по ожидаемому пути, но эта статья обрабатывает эффект, который это имеет при попытке сделать что-то более подробно.

Ответ 3

Никогда не будет возможности гарантировать идеальную синхронизацию в разных точках зрения в реальном времени - законы физики делают невозможным. Если солнце взорвалось сейчас, как бы вы могли гарантировать, что наблюдатели на Альфе Центавра видят сверхнову одновременно с Землей? Информация требует времени для поездок.

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

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

Ответ 4

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

Ответ 5

Если клиент видит события, происходящие со скоростью, которую его кормит сервер, это нормальный способ сделать это (я работал с протоколами Ultima Online, KalOnline и немного World of Warcraft), то это мгновенное Задержка в 5 секунд просто заставит его получить это 5 секунд событий сразу и увидеть, что те события проходят очень быстро или мгновенно, так как другие игроки будут видеть его "ходьбой" очень быстро на короткое расстояние, если его выходы также задерживаются. После этого все снова нормально. На самом деле, кроме нормализации графики и физики, я не вижу особых особых проблем, чтобы заставить его правильно синхронизировать, он просто синхронизируется.

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

В конце концов, игроки с задержкой должны принять свое условие или закрыть свой проклятый eMule.