Многопользовательская игровая синхронизация
Взгляните на PDFSharp
, Это - открытый исходный код, и это записано в.NET, я использую его сам для некоторого поколения счета PDF.
5 ответов
Основной подход к этому - это так называемый Dead Reckoning , и здесь можно найти довольно интересную статью об этом. По сути, это алгоритм прогнозирования того, где позиции сущностей будут угадываться в промежутках между обновлениями сервера.
Существуют более продвинутые методологии, основанные на этой концепции, но это хорошая отправная точка.
Также описание того, как это обрабатывается в исходном движке (движке Valve для первой игры Half Life), можно найти здесь , принцип в основном тот же - пока сервер не скажет вам иначе, используйте алгоритм прогнозирования для перемещения объекта по ожидаемому пути - но в этой статье рассматривается эффект, который это оказывает при попытке выстрелить в что-либо более глубоко.
Ваш лучший вариант - отправить изменения обратно клиенту из будущего, тем самым доставив клиенту в тот же момент времени, что и для других клиентов, у которых нет проблем с задержкой.
Лучшие ресурсы, которые я нашел в этой области это две статьи от Valve Software:
Если клиент видит, что события происходят с той скоростью, с которой сервер его кормит, это нормальный способ сделать это (я работал с протоколами Ultima Online, KalOnline и немного World of Warcraft), то эта мгновенная 5-секундная задержка просто заставит его получить эти 5 секунд событий сразу и увидеть, как эти события проходят очень быстро или почти мгновенно, так как другие игроки увидят, что он очень быстро "идет" на короткое расстояние, если его выходы задерживают тоже. После этого все снова течет нормально. На самом деле, за исключением нормализации графики и физики, я не вижу каких-либо особых требований для правильной синхронизации, она просто синхронизируется сама.
Если вы когда-нибудь играли в игры Valve на двух близких компьютерах, вы бы заметили, что им все равно. о мелких деталях вроде "
Никогда не будет способа гарантировать идеальную синхронизацию между несколькими точками обзора в реальном времени - законы физики делают это невозможным. Если бы Солнце взорвалось сейчас, как можно было гарантировать, что наблюдатели на Альфе Центавра увидят сверхновую в то же время, что и мы на Земле? Информация требует времени для перемещения.
Таким образом, вы можете либо точно смоделировать все с задержкой, которая может отличаться от зрителя к зрителю (что у вас есть в настоящее время), либо смоделировать их неточно без задержки и в целом синхронизировать между зрителями (что здесь на помощь приходят предсказания / точный расчет / экстраполяция). Более медленные игры, такие как стратегия в реальном времени, обычно идут первым путем, более быстрые игры - вторым.
В частности, никогда не следует думать, что время, необходимое для поездки, будет постоянным. Это означает, что простой отправки сообщений о запуске и останове для перемещения объектов никогда не будет достаточно ни в одной из моделей. Вам необходимо отправлять периодические обновления фактического состояния (обычно несколько раз в секунду для более быстрых игр), чтобы получатель мог исправить ошибки в своих прогнозах и интерполяциях.