- 'клиент-сервер' или 'peer to peer' или что-то среднее между ними: какой компьютер имеет полномочия над какими действиями в игре.
В пошаговых играх, как правило, очень просто сказать: «У сервера есть все полномочия, и мы закончили». В играх реального времени часто этот дизайн - отличное место для старта, но как только вы добавляете задержку, клиент / движение / действие перестает отвечать. Таким образом, вы добавляете какое-то «скрытие задержек», позволяющее вводить данные клиентов, чтобы немедленно воздействовать на их персонажа или юнитов, чтобы решить эту проблему, и теперь вам приходится иметь дело с урегулированием проблем, когда игровое состояние клиента и сервера начинает расходиться. 9 раз из 10, что просто отлично, вы выталкиваете или перетягиваете объекты, на которые клиент оказал влияние, на официальную позицию, но это 1 из 10 раз, когда объект является аватаром игрока или чем-то еще, такое решение неприемлемо, поэтому вы начинаете предоставить клиенту полномочия по некоторым действиям. Теперь вам нужно согласовать несколько игровых состояний на сервере и открыть себя для возможного «мошенничества» через вредоносного клиента, если вы заботитесь о подобных вещах. Это в основном то, где каждый телепорт / обман / любой баг / чит появляется.
Конечно, вы могли бы начать с модели, в которой «каждый клиент имеет полномочия над« своими »объектами» и игнорировать проблему мошенничества (в большинстве случаев это хорошо). Но теперь вы уязвимы для огромного влияния на симуляцию игры, если этот клиент выпадает, или даже «просто немного отстает в соответствии с симуляцией» - фактически каждая игра для игроков в конечном итоге будет / ощущать эффекты запаздывающий или иным образом неэффективный клиент, в виде ожидания ожидания отставания клиента или наличия синхронизированного состояния игры, которым он управляет.
- «синхронизированный» или «асинхронный»
Общая стратегия обеспечения того, чтобы все игроки работали в одном и том же игровом состоянии, заключается в том, чтобы просто согласовать список входов игроков (с помощью одной из моделей, описанных выше), а затем синхронно воспроизводить игровой процесс на всех машинах. Это означает, что логика симуляции должна точно совпадать, иначе игры будут не синхронизированы. Это на самом деле и проще, и тяжелее, чем кажется. Это проще, потому что игра - это просто код, и код в значительной степени выполняется точно так же, когда он дает одинаковые входные данные (даже генераторы случайных чисел). Это сложнее, потому что есть два случая, когда это не так: (1) когда вы случайно используете случайные вне игрового симулятора и (2) когда вы используете поплавки. Первое исправлено наличием строгих правил / утверждений в отношении того, какие ГСЧ используются в каких игровых системах. Последнее решается без использования поплавков. (У поплавков на самом деле есть 2 проблемы, одна из которых работает очень по-разному в зависимости от конфигурации оптимизации вашего проекта, но даже если это было решено, они работают непоследовательно на разных процессорных архитектурах, лол). Starcraft / Warcraft и любая игра, которая предлагает «повтор», скорее всего, используют эту модель. На самом деле, наличие системы воспроизведения - отличный способ проверить, синхронизируются ли ваши ГСЧ.
С помощью асинхронного решения органы управления игрой просто передают все это состояние всем другим клиентам с определенной частотой. Клиенты берут эти данные и помещают их в свое игровое состояние (и обычно делают некоторую упрощенную экстраполяцию, пока не получат следующее обновление). Вот где «udp» становится жизнеспособным вариантом, потому что вы рассылаете спам по всему игровому состоянию каждые ~ 1 с или около того, удаление некоторой части этих обновлений не имеет значения. Для игр с относительно небольшим игровым состоянием (Quake, World of Warcraft) это часто самое простое решение.