Работа с задержкой в сетевых играх

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

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

В этой статье GamaSutra есть решение, которое экономит полосу пропускания и делает локальный ввод гладким, имитируя на клиенте, но, похоже, чит-контроль в окне. Кроме того, я не уверен, что делать, когда игроки начинают манипулировать окружающей средой, толкать камни и тому подобное. Эти ранее нейтральные объекты временно становятся объектами, которые клиент должен отправлять PDU, или, возможно, сразу несколько игроков. Чей PDU выиграют? Когда объекты перестанут дважды отслеживаться каждым игроком (для сравнения с мертвой считающейся версией)? Небеса запрещают двум игрокам участвовать в сумо-матче (например, начать толкать друг друга).

Этот бит gamedev.net показывает, что решение gamasutra является неадекватным, но описывает другой метод, который на самом деле не исправляет мою совместную болтовню пример. Большинство других вещей, которые я нашел, специфичны для стрелков. Мне бы хотелось увидеть что-то более ориентированное на игры, которые играют как SNES Zelda, но с немного большей физикой/импульсом.

Примечание. Я не спрашиваю о физическом моделировании здесь - в других библиотеках это покрыто. Как раз стратегии для того, чтобы сделать игры гладкими и реактивными, несмотря на латентность сети.

Ответ 1

Посмотрите, как Valve делает это в исходном движке: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Если это для шутера от первого лица, вам, вероятно, придется углубиться в некоторые из тем, которые они упомянули, например: предсказание, компенсация и интерполяция.

Ответ 2

Я нахожу этот пост в блоге по физике сети Гленна Фидлера, и даже более того, ответ/обсуждение под ним, потрясающе. Это довольно долго, но стоит.

В итоге

Сервер не может поспевать за повторяющимся моделированием всякий раз, когда клиент получает входные данные в современном игровом симуляторе физики (то есть в динамике транспортных средств или твердого тела). Поэтому сервер упорядочивает задержку всех клиентов + дрожание (время) перед сервером, чтобы все входящие пакеты приходили в JIT до того, как сервер будет нуждаться в них.

Он также дает общее представление о том, как обращаться с типом собственности, который вы запрашиваете. Слайды, которые он показал на GDC, потрясающие!

Об обмане

Сам г-н Фидлер (и другие) заявляет, что этот алгоритм страдает от недостатка мошенничества. Это неправда. Этот алгоритм не менее прост или труден в использовании, чем традиционное предсказание клиент/сервер (см. статью о традиционном предсказании клиент/сервер в @CD Sanchez 'answer).

Чтобы быть абсолютно ясным: сервер не так легко обмануть просто потому, что он получает физическое позиционирование сети как раз вовремя (а не на x миллисекунд позже, чем в традиционном прогнозировании). На клиентов это никак не влияет, поскольку все они получают информацию о позициях своих оппонентов с той же задержкой, что и при традиционном прогнозировании.

Независимо от того, какой алгоритм вы выберете, вы можете захотеть добавить чит-защиту, если выпускаете крупный заголовок. Если да, я предлагаю добавить шифрование против богов-мошенников (например, потокового шифра XOR, где "поток ключей генерируется генератором псевдослучайных чисел") и простых проверок работоспособности против трещины. Некоторые разработчики также реализуют алгоритмы для проверки целостности двоичных файлов (для уменьшения риска взлома) или для того, чтобы убедиться, что пользователь не запускает отладчик (для снижения риска разработки взлома), но они являются более спорными.

Если вы просто делаете небольшую инди-игру, в которую могут играть только несколько тысяч игроков, не беспокойтесь о реализации каких-либо античит-алгоритмов, пока 1) они вам не понадобятся; или 2) база пользователей растет.

Ответ 3

мы внедрили многопользовательскую змеиную игру на основе обязательного сервера и удаленных игроков, которые делают прогнозы. Каждые 150 мс (в большинстве случаев) сервер отправляет обратно сообщение, содержащее все консолидированные движения, отправленные каждым удаленным игроком. Если удаленные клиентские движения задерживаются на сервере, он отбрасывает их. Клиент будет воспроизводить последнее движение.

Ответ 4

Ознакомьтесь с темами сетевого обучения на веб-сайте Клуба разработчиков XNA. Он охватывает такие темы, как сетевая архитектура (одноранговая сеть или клиент/сервер), сетевое прогнозирование и некоторые другие вещи (в контексте, конечно, XNA). Это может помочь вам найти ответы, которые вы ищете.

http://creators.xna.com/education/catalog/?contenttype=0&devarea=19&sort=1

Ответ 5

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

Я, конечно, не предлагаю, чтобы вы наложили 500 мс на всех, но люди с 50 мс могут быть в порядке с 150 (добавлено дополнительно 100 мс), чтобы игровой процесс выглядел более плавным.

В двух словах; если у вас 3 игрока:

Джон: 30 мс
Пол: 150 мс
Эми: 80 мс

После расчетов вместо отправки данных обратно клиентам все одновременно, вы учитываете их задержку и, например, отправляете Павлу и Эми до Джона.

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