Синхронизация многопользовательских игр

Question

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

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

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

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

Answer 1

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

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

---

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

Answer 2

Лучшие ресурсы, которые я нашел в этой области, - это две статьи от Valve Software:

• Методы компенсации задержки в разработке и оптимизации внутриигрового протокола клиент / сервер
• Источник Многопользовательская сеть

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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