У меня есть опыт создания многопользовательских игр пошаговой с использованием сокетов, но я никогда не пытался играть в реальном времени. С какими дополнительными проблемами я должен справиться? Нужно ли мне вести историю действий игрока в случае, если игроки с отставанием делают что-то в прошлом? Действительно ли мне нужно использовать UDP-пакеты или TCP достаточно? Что еще?
Я действительно не решил, что делать, но для этого вопроса вы можете рассмотреть 10-игровую 2D-игру с движением X Y.
С пошаговыми играми, как правило, очень просто сказать, что "сервер обладает высшими полномочиями, и мы закончили". В играх реального времени часто этот дизайн - отличное место для начала, но как только вы добавляете латентность, клиентское движение/действия чувствуют себя невосприимчивыми. Таким образом, вы добавляете какое-то "скрытие скрытия", позволяющее входным данным клиентов сразу же влиять на их характер или единицы, чтобы решить эту проблему, и теперь вам приходится иметь дело с согласованием проблем, когда клиент и серверные игры начинают расходиться. 9 раз outta 10, что просто отлично, вы поп или lerp объекты, которые клиент повлиял на авторитетную позицию, но что 1 из 10 раз, когда объект является аватаром игрока или что-то еще, это решение неприемлемо, поэтому вы начинаете предоставить клиенту полномочия над некоторыми действиями. Теперь вам нужно согласовать множество игр на сервере и открыть себя для потенциального "обмана" через вредоносного клиента, если вам это нравится. Это в основном там, где каждый телепорт/обман/любой ошибка/чит приходит вверх.
Конечно, вы можете начать с модели, в которой "каждый клиент имеет полномочия над своими" объектами и игнорирует проблему обмана (в некоторых случаях это довольно хорошо). Но теперь вы уязвимы для массового влияния на имитацию игры, если этот клиент выпадает, или даже "просто немного отстает в поддержании имитации" - эффективно каждая игра игроков будет в конечном итоге ощущаться или ощущаться отстающим или иным образом неэффективным клиентом, в виде ожидания ожидания отстающего клиента или контроля игры, которую они контролируют из-за синхронизации.
Общая стратегия обеспечения того, чтобы все игроки работали на одном и том же игровом компьютере, состоит в том, чтобы просто согласовать список входов проигрывателя (через одну из описанных выше моделей), а затем имитировать симуляцию игрового процесса синхронно на всех машинах. Это означает, что логика моделирования должна соответствовать точно, или игры будут выходить из строя. На самом деле это проще и труднее, чем кажется. Это проще, потому что игра - это всего лишь код, а код в значительной степени выполняется точно так же, когда он дает один и тот же ввод (даже генераторы случайных чисел). Это сложнее, потому что есть два случая, когда это не так: (1) когда вы случайно используете случайные вне игрового моделирования и (2) при использовании поплавков. Первое исправляется путем установления строгих правил/утверждений о том, какие RNG используются в каких игровых системах. Последний решается, не используя поплавки. (у поплавков фактически есть 2 проблемы, одна из них работает по-разному на основе оптимизации конфигурации вашего проекта, но даже если это было разработано, они работают непоследовательно по разным архитектурам процессоров atm, lol). Starcraft/Warcraft и любая игра, предлагающая "повтор", скорее всего, используют эту модель. Фактически, наличие системы воспроизведения - отличный способ проверить, синхронизируются ли ваши RNG.
С помощью решения асинхронного управления государственные органы власти просто передают это состояние всем другим клиентам с некоторой частотой. Клиенты берут эти данные и хлопают их в свою игру (и обычно делают некоторую упрощенную экстраполяцию, пока не получат следующее обновление). Здесь, где "udp" становится жизнеспособным вариантом, поскольку вы спамаете всю игру gamestate каждые ~ 1 сек или около того, снижение некоторой части этих обновлений не имеет значения. Для игр с относительно небольшим игровым состоянием (землетрясение, мир warcraft) это часто является самым простым решением.
Есть несколько факторов, связанных с настройкой многопользовательской игры
В протоколе важно решить, хотите ли вы использовать TCP или UDP. UDP имеет меньше накладных расходов, но не гарантируется доставка. Наоборот, TCP более заслуживает доверия. У каждой игры будет свой предпочтительный протокол. UDP, например, будет работать для шутера от первого лица, но может не подходить для RTS, где информация должна быть последовательной.
Брандмауэр/Connection. Убедитесь, что ваша многопользовательская игра не должна составлять 2000 исходящих подключений и использует стандартный порт, поэтому перенос портов легко. Взаимодействие с брандмауэром Windows, вероятно, будет дополнительным бонусом.
Bandwidth. Это важно, сколько данных вы собираетесь использовать через сетевое соединение? Я предполагаю, что это снизится, чтобы играть тестирование и запись пропускной способности. Если вам требуется более 200 кб/с для каждого клиента, вы можете пересмотреть несколько вещей.
Загрузка сервера. Это также важно, сколько требуется серверу для нормальной игры? Вам нужен супер-8-серверный сервер с 16-гигабайтной ОЗУ для его запуска? Существуют ли способы его сокращения?
Я думаю, что есть кучи больше, но на самом деле вам нужна игра, которая удобна для игры по сети и по множеству подключений.
Планирование - ваш лучший друг. Выясните, каковы ваши потребности.
Загрузка данных: каждый компьютер будет иметь одни и те же модели и графику, а просто имена и местоположения перемещаются по сети. Если каждый игрок может настроить свой персонаж или другие предметы, вам придется перемещать эти данные.
Обман: вам нужно беспокоиться об этом? Можете ли вы доверять тому, что говорит каждый клиент. Если нет, то логика на стороне сервера будет выглядеть иначе, чем логика на стороне клиента. Представьте себе этот простой случай, каждый из ваших 10 игроков может иметь другую скорость передвижения из-за бонусов. Чтобы свести к минимуму мошенничество, вы должны рассчитать, как далеко каждый игрок может перемещаться между обновлениями связи с сервера, в противном случае игрок мог бы взломать там скорость, и ничто не остановило бы их. Если игрок последовательно немного быстрее, чем ожидалось, или имеет однократный переход, сервер будет просто перемещать их в ближайшем месте, которое было бы возможно, потому что это, скорее всего, перекос или однократное прерывание связи. Однако, если игрок постоянно перемещается вдвое дольше, возможно, разумно выгнать их из игры. Чем больше математика, тем больше частей игры вы можете дважды проверить на сервере, тем более последовательной будет игра, кстати, это сделает обман более сложным.
Как может быть сверстник: даже если игра будет сверстницей, вы, вероятно, захотите, чтобы один игрок начал игру и использовал их в качестве сервера, это намного проще, чем пытаться управлять некоторыми из более облачные подходы. Если нет сервера, тогда вам нужно будет работать протокол для разрешения споров между двумя машинами с несогласованными состояниями игры.
Снова планирование - ваш лучший друг, план, план, план. Если вы думаете о проблеме достаточно, вы можете продумать свой путь через большинство проблем. Тогда вы можете начать думать о тех, которые еще не решили.
Насколько важно избегать обмана? [Вы можете доверять любой информации, поступающей от клиента, или им можно доверять и проверять подлинность?]
Объектная модель Как объекты передаются с одной машины на другую? Как выполняются действия над объектом?
Делаете ли вы клиент/сервер или одноранговый узел?
Случайные числа Если вы делаете одноранговый узел, вам необходимо сохранить блокировку и синхронизировать случайные числа.
Если вы делаете клиент/сервер, как вы справляетесь с задержкой? [мертвый расчет?]
В сетевом кодировании много нетривиальных проблем.
Откажитесь от RakNet и бесплатно скачать код, и его группы обсуждения.
TCP прекрасен, если ваш запуск в локальной сети. Но если вы хотите играть в онлайн, вы должны использовать UDP и реализовать свой собственный TCP-подобный уровень: необходимо передать броузеры NAT-маршрутизаторам.
Вам нужно выбрать между одноранговой или клиент-серверной связью. В модели "Клиент-сервер" синхронизация и состояние мира проще реализовать, но у вас может быть отсутствие реактивности в Интернете. В Pee-to-peer это сложнее, но быстрее для игрока.
Не храните историю действий игрока в целях игры (сделайте это, но только для функции воспроизведения). Если вы достигнете точки, где это необходимо, предпочитайте, чтобы каждый игрок ждал.