Работа с задержкой в сетевых играх
Я думаю о создании сетевой игры. Я немного новичок в этом и уже столкнулся с множеством проблем, пытаясь составить хороший план для точного расчета и задержки в сети, поэтому я хотел бы увидеть хорошую литературу по этой теме. Я опишу методы, которые я рассмотрел.
Первоначально я просто отправлял данные игрока на сервер, моделировал их и передавал изменения в состоянии игры всем игрокам. Это усложняло мошенничество, но в условиях высокой задержки было немного сложно контролировать, так как вы не сразу видите результаты своих действий.
В этой статье о GamaSutra есть решение, которое экономит пропускную способность и делает локальный ввод гладким за счет симуляции на клиенте, но, кажется, выбрасывает защиту от мошенничества в окно. Кроме того, я не уверен, что делать, когда игроки начинают манипулировать окружением, толкать камни и тому подобное. Эти ранее нейтральные объекты временно стали бы объектами, о которых клиент должен отправлять PDU, или, возможно, несколько игроков одновременно. Чьи PDU выиграют? Когда объекты перестанут быть вдвойне отслеживаемыми каждым игроком (по сравнению с мертвой версией)? Небеса запрещают двум игрокам участвовать в матче сумо (например, начинать толкать друг друга).
Этот фрагмент gamedev.net показывает решение gamasutra как неадекватное, но описывает другой метод, который на самом деле не исправляет мой пример совместной игры в боулдеринг. Большинство других вещей, которые я нашел, относятся к стрелкам. Я хотел бы видеть что-то более ориентированное на игры, которые играют как SNES Zelda, но с немного большей физикой / импульсом.
- Примечание: я не спрашиваю об симуляции физики здесь - это обсуждается в других библиотеках. Просто стратегии, позволяющие сделать игры плавными и реактивными, несмотря на сетевую задержку.
5 ответов
Узнайте, как Valve делает это в движке исходного кода: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Если это шутер от первого лица, вам, вероятно, придется углубиться в некоторые темы, которые они упоминают, такие как прогнозирование, компенсация и интерполяция.
Я нахожу этот пост в блоге по физике сети Гленна Фидлера, и тем более отклик / обсуждение под ним, потрясающе. Это довольно долго, но стоит.
В итоге
Сервер не может поспевать за повторяющимся моделированием всякий раз, когда клиент получает информацию, полученную в современном игровом симуляторе физики (например, динамики транспортных средств или твердого тела). Поэтому сервер упорядочивает задержку всех клиентов + дрожание (время) перед сервером, чтобы все входящие пакеты приходили в JIT до того, как сервер будет нуждаться в них.
Он также дает общее представление о том, как обращаться с типом собственности, который вы запрашиваете. Слайды, которые он показал на GDC, потрясающие!
Об обмане
Сам г-н Фидлер (и другие) заявляет, что этот алгоритм страдает от недостатка защиты от мошенничества. Это неправда. Этот алгоритм не менее прост или труден в использовании, чем традиционное предсказание клиент / сервер (см. Статью о традиционном предсказании клиент / сервер в ответе @CD Sanchez).
Чтобы быть абсолютно ясным: сервер не так легко обмануть просто потому, что он получает физическое позиционирование сети как раз вовремя (а не на x миллисекунд позже, чем в традиционном прогнозировании). На клиентов это никак не влияет, так как все они получают информацию о позициях своих оппонентов с той же задержкой, что и при традиционном прогнозировании.
Независимо от того, какой алгоритм вы выберете, вы можете захотеть добавить чит-защиту, если выпускаете основной заголовок. Если да, я предлагаю добавить шифрование против ботов-мошенников (например, потокового шифра XOR, где "поток ключей генерируется генератором псевдослучайных чисел") и простых проверок работоспособности на наличие взломов. Некоторые разработчики также реализуют алгоритмы для проверки целостности двоичных файлов (для уменьшения риска взлома) или для гарантии того, что пользователь не запускает отладчик (чтобы уменьшить риск развития взлома), но они являются более спорными.
Если вы просто делаете небольшую инди-игру, в которую могут играть только несколько тысяч игроков, не беспокойтесь о реализации каких-либо античит-алгоритмов, пока 1) они вам не понадобятся; или 2) база пользователей растет.
Мы реализовали многопользовательскую игру змея, основанную на обязательном сервере и удаленных игроках, которые делают прогнозы. Каждые 150 мс (в большинстве случаев) сервер отправляет обратно сообщение, содержащее все консолидированные движения, отправленные каждым удаленным игроком. Если удаленные клиентские перемещения приходят на сервер поздно, он отбрасывает их. Клиент будет воспроизводить последнее движение.
Вы можете попытаться установить задержку для всех ваших клиентов, в зависимости от средней задержки в регионе. Таким образом, клиент может попытаться обойти проблемы с задержкой, и это будет выглядеть одинаково для большинства игроков.
Я, конечно, не предполагаю, что вы заставляете всех задерживать по 500 мс, но люди с 50 мс могут подойти с 150 (дополнительно 100 мс), чтобы игровой процесс выглядел более плавным.
В двух словах; если у вас есть 3 игрока:
- Джон: 30 мс
- Пол: 150мс
- Эми: 80мс
После вычислений, вместо того, чтобы отправлять данные обратно клиентам одновременно, вы учитываете их задержку и начинаете отправку, например, Полу и Эми до Джона.
Но этот подход нежизнеспособен в ситуациях с чрезвычайной задержкой, когда коммутируемые соединения или беспроводные пользователи могут действительно испортить это для всех. Но это идея.
Ознакомьтесь с темами сетевого образования на веб-сайте клуба создателей XNA. Он углубляется в такие темы, как сетевая архитектура (одноранговая или клиент-серверная), сетевое прогнозирование и некоторые другие вещи (конечно, в контексте XNA). Это может помочь вам найти ответы, которые вы ищете.
http://creators.xna.com/education/catalog/?contenttype=0&devarea=19&sort=1