Устранение задержек в сетевых играх

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Подводя итог

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

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

О мошенничестве

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

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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