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

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

В итоге

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

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

Обман

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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

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

Answer 5

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

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