Pull to refresh

Не используйте Lockstep в стратегиях в RTS

Reading time 4 min
Views 12K

Привет, Хабр! Представляю вашему вниманию перевод статьи Don’t use Lockstep in RTS games.


Lockstep проиграл! Клиент-серверная модель победила и стала стандартом для большинства игр. Стратегии в реальном времени были последними, но в них Lockstep используется все реже и реже. Давайте узнаем почему, но сначала, что такое Lockstep?



В играх есть несколько игроков, играющих игру на клиенте. Но как же удостоверится, что они играют одну и ту же игру? Используя Lockstep все клиенты запускают один и тот же код, с одинаковыми параметрами и входными данными. Например, если один из игроков приказывает армии идти в указанную точку, эта команда передается всем клиентам и у всех эта армия двигается в указанную точку. Даже генератор случайных псевдо-случайных чисел должен быть одинаковым у всех, обычно это делается с помощью использования одинакового seed в начале игре и выполнения всего в одинаковом порядке. Это очень эффективно с точки зрения сети, потому, что передаются только команды. Такие вещи, как приказ или действие занимают очень мало места в сетевом пакете.


Lockstep — очень эффективная модель сетевого взаимодействия, но сложна в реализации из-за проблем рассинхронизации или различий компиляторов/разных платформ. Lockstep использовался в прошлом потому, что пропускная способность сети была очень низкой. Это отлично работало. Концептуально, его очень легко добавить в существующую игру. К примеру, DOOM, которая уже была написана и все работало. Чтобы добавить мультиплеер, John Carmack должен был запускать команды на каждом компьютере. Это очень легко в теории, до того, как задержки или отличия архитектур испортят все. На практике, это сложно сделать. Программист должен убедится, что все команды исполняются в одинаковом порядке на каждом клиенте. Что если кто-то не получил команду вовремя? Клиент должен ждать подтверждения получения команды от всех клиентов. Что случится, если кто-то переподключился? Первое, что приходит на ум — симулировать всю игру с самого начала, что может занять довольно много времени.



С использованием Lockstep'а, программист должен убедится, что компилятор не оптимизирует операции с числами с плавающей точкой, потому, что разные архитектуры процессоров могут иметь небольшие различия в результате одинакового вычисления. Это особенно заметно, если вы пробуете синхронизировать PC и iPad. Различия архитектур — кошмар для Lockstep. Если вы работаете с HTML5 -Javascript, JIT может оптимизировать вычисления по разному, делаю небольшие погрешности, которые могут повлечь за собой большие изменения. Программирование Lockstep — как удерживать большой вес на кончику ножа.


Если этого вам недостаточно, Lockstep использует p2p, наследуя все проблемы второго. Если вы используете TCP, вы не сможете соединить два любых компьютера через интернет из-за брандмауэров, NAT'ов, прокси, VPN… и т.д. С UDP есть шанс сделать hole punching. К счастью, браузеры поддерживают webRTC, который работает через UDP и имеет API для hole punching через STUN-сервер. Хотя-бы эта часть может быть сделана с помощью HTML5.


А что такое Клиент-Серверная модель? Это просто когда клиент присоединяется к серверу и сервер отправляет клиенту обновления. Готово! Сервер и клиент может использовать разный код, на разных языках и даже платформах. Сервер имеет полный контроль над игрой. Здесь нет ножа, на кончику которого нужно что-то держать. Основная проблема в том, что сервер должен отсылать больше обновлений. Это потому, что перемещение каждого юнита, выстрел пули, изменение здоровья должны быть синхронизированы. К счастью, сетевой канал пользователей расширяется и дешевле, чем время программиста.


Причиной, почему RTS использовали Lockstep была ширина канала. В FPS движение 32 людей не требует большого количества трафика. В RTS движение 1000 требует больше трафика, но ширина канала позволяет это.


Клиент-Серверная модель более устойчивая к читерам. Используя Lockstep, каждый клиент знает все обо всей игре. Например туман войны — клиентская часть, клиент в реальности знает, что за туманом, но не показывает его. Также каждый знает IP и открытый каждого из клиентов и может заспамить врагов — микро DDOS. В Клиент-Серверной модели сервер просто не отсылает обновления за туманом войны, а IP других клиентов знает только сервер. Конечно, клиент может сделать DDOS-атаку на сервер, но сервера легче могут противодействовать атаками и могут блокировать клиентов с подозрительной активностью.



Недостаток серверов — они стоят денег, в то время как для Lockstep не нужны сервера, все — p2p. Хорошо, что есть провайдеры, у которых можно арендовать сервера. Но если это все еще слишком дорого, вы можете запускать один сервер на одном из клиентов … это похоже на Lockstep … кроме того, что есть один полномочный клиент, и что на него больше нагрузка.


Примеры:


  1. StarCraft 1 использовал Lockstep, в то время как StarCraft 2 использует Клиент-Серверную модель.
  2. Supreme Commander 1 использует Lockstep когда более новые игры, например Planetary Annihilation, использует Клиент-Серверную модель.
  3. DotA запускалась на движке Warcraft 3 который использовал Lockstep, но Valve используют Клиент-Серверную модель для Dota 2.
  4. DOOM использовал Lockstep но Quake использует Клиент-Серверную модель, Lockstep вообще не пользовался популярностью в FPS.
  5. MMO никогда не использовали Lockstep потому, что он неприменим для такого большого количества игроков.

Развитие программирования, удешевление компьютеров, и современная скорость интернета делают Клиент-Серверную легче применимой, чем Lockstep. Lockstep будет использоваться все меньше и меньше.

Tags:
Hubs:
+21
Comments 24
Comments Comments 24

Articles