Почему некоторые сетевые игры используют интерполяцию, а некоторые используют поиск пути для удаленного перемещения?

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

Для быстрого примера обоих:

Модель интерполяции

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

Найти путь

В этой модели, думайте, что пользователь отправляет пункт назначения, и все находят пути к нему.

Какие типы игр подходят для каждого и когда каждый должен использовать каждый?

Я работал над сетевым кодом для двух сетевых игр AAA в режиме реального времени, одной для смартфонов и одной для портативной консоли.

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

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

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

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

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

• Сложные с меж / экстраполяционными обновлениями аналогичны очень сложным обновлениям, но для постоянно меняющихся данных, для которых практически невозможно надежно отправлять данные каждый раз, когда они изменяются. Подумайте об отправке позиции и вектора скорости; Вы должны иметь возможность интерполировать данные между двумя точками и экстраполировать их после них. У вас должен быть план действий в чрезвычайных ситуациях, если поступающие данные не соответствуют вашим экстраполяциям. Я бы сказал, что большинство игр, которые требуют обновления позиции, используют этот метод.

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

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

• Мягкие обновления состоят из отправки плановых данных и запуска плана на всех хостах. Это то, что вы называете «поиск пути». Количество данных, необходимых для синхронизации данных, намного ниже; Вы можете использовать эти типы обновлений, когда вы можете избежать определенных несоответствий в том, как данные представляются пользователю, например, при синхронизации сотен врагов.

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

• Очень мягкие обновления используются, когда результат действия может быть надежно рассчитан задолго до того, как это произойдет. Вы просто отправляете результат, а другой клиент просто воспроизводит его. Например, некоторые игры для браузеров и смартфонов позволяют сражаться с другими людьми, но настоящая битва решается часами (например, игры в стиле Травиана). Вполне возможно, что эти игры рассчитывают результат в тот самый момент, когда начинается сражение, и вы просто видите результаты этого сражения.

  Другим примером, не связанным с сетью, может быть цивилизация 4 с включенной анимацией битвы. Когда вы нападаете на кого-то, результат битвы сразу подсчитывается, но вы видите анимацию его воспроизведения. Уверяю вас, битва не рассчитывается, а оживляется.

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

Я не имею представления о процессе разработки Valve, так что это чисто мое мнение, но:

Интерполяция : я бы сказал, что было бы лучше для игр с быстрым темпом, таких как FPS, например, где важно иметь постоянную позицию для врага по времени между игроками. Интерполяция означает, что даже если некоторые пакеты отброшены (AFAIK, большинство многопользовательских FPS используют UDP вместо TCP / IP, что не гарантирует ни целостности, ни порядка, в котором поступают пакеты), вы будете иметь плавное движение на экране.

поиск пути : если время не является решающим элементом вашего игрового процесса, и ваш алгоритм находит повторный путь при повторном запуске, поиск пути может быть интересным, поскольку он не требует частой отправки и, следовательно, тяжелых обновлений с указанием позиции каждого юридическое лицо. Я бы сказал, что это подходит для пошаговой системы, например, где вы можете ограничить количество сетевых запросов (один в начале хода, один - когда поворот закончен, чтобы убедиться, что все клиенты находятся в «нормальном» состоянии. " государство.

Еще раз, я никогда не работал над сетевой игрой или для большой игровой студии, но из того, что я читал иногда, я так и поступил бы :)

Panda Pajama ответ довольно хороший.

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

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

Однако он не упомянул один метод. Принудительные результаты.

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

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