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

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

Гленн в своей статье и комментариях приводит очень веские аргументы в пользу использования UDP поверх TCP, но SC2, очевидно, использует TCP. Чтобы высказать Глин,

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

Поэтому из его заявления я предполагаю, что его подход заключается в отправке полного игрового состояния каждого юнита в каждом кадре. Если сервер не получает данные игрока о текущем кадре, то это просто удача для этого игрока. Для God of War: Acension, в которой он является ведущим сетевым разработчиком, это должно работать довольно хорошо, я думаю.

Для SC2, благодаря его способности к воспроизведению, мое интуитивное чувство говорит мне, что базовый механизм - это детерминированный фиксированный временной интервал «машина воспроизведения пользовательского ввода», где единственными данными, которыми обмениваются, являются входы игрока . Следовательно, утверждение Гленна может быть совершенно неуместно для SC2. Ввод игрока важен, а последовательность ввода еще важнее. Я не думаю, что это возможно для SC2, отправляющего игровое состояние 200 единиц и более при 30 - 60 FPS.

Вопрос: я могу ошибаться, но я попытался определить 2 возможных типа данных. Каковы другие методы? Будет хорошо процитировать игру, если вы будете.

РЕДАКТИРОВАТЬ: нашел эту ссылку о сетевой модели Starcraft

Гленн в своей статье и комментариях приводит очень веские аргументы в пользу использования UDP поверх TCP, но SC2, очевидно, использует TCP.

Гленн в основном говорит о физически управляемых играх, т.е. шутеры от первого лица и гоночные игры. Они предъявляют различные требования к стратегиям в реальном времени, где важны точные позиции юнитов на каждом логическом этапе. Так что коммуникационные стратегии обязательно разные.

«В реальном времени» означает разные вещи в разных контекстах. Игры не являются «тяжелыми» в реальном времени, потому что, если сообщение опаздывает, все ломается. (По крайней мере, нет веской причины, по которой игра должна быть настолько требовательной, поскольку только программная система должна быть способна восстанавливаться после задержек обработки, в отличие, например, от атомной электростанции или какого-либо медицинского оборудования.) Игры действительно «мягкий» или «твердый» в режиме реального времени. ( Определения в Википедии как обычно .) Тип игры влияет на то, как быстро вам понадобится информация, можете ли вы потерять информацию и уйти с ней и т. Д. Достаточно сказать, что TCP достаточно хорош для многих игр, но для других игр предпочтительнее использовать UDP.

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

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

1. Вам не нужно отправлять информацию о том, что не изменилось.
2. Вам не нужно отправлять полное состояние, если вы можете отправить получателю достаточно информации, чтобы построить новое состояние из старого состояния. (Например, просто отправьте дельта-значение относительно старого состояния. Или просто отправьте части состояния, которые изменились, а не остальные.)
3. Если в двух играх используется один и тот же алгоритм и одни и те же данные, вы можете просто отправить входные данные, и получатель повторно изменит эффекты локально, чтобы получить новое состояние.

Большинство игр не соответствуют критериям 3, поэтому вместо них используются 1 и 2. Однако во многих играх RTS можно и нужно использовать 3.

Кроме того, это не обязательно должен быть «каждый кадр». Концепция рамы также туманна. Это кадр рендеринга? Это партия логики? Это фрейм отправляемых сетевых данных? Эти три всегда выравнивают один к одному, или вы получаете переменную графическую скорость с фиксированными логическими скоростями? Некоторые игры, особенно стратегии в реальном времени, такие как Starcraft 2 или игры с возможностью воспроизведения (как вы касаетесь), любят держать все в идеальном состоянии, регулярно обновляя сеть (которая может совпадать или не совпадать с «кадрами» в других смыслах), но это не требование для всех игр. Многие игры просто отправляют обновления на полурегулярной основе, в зависимости от того, насколько далеко они готовы позволить клиентам работать.

Ввод игрока важен, а последовательность ввода еще важнее. Я не думаю, что это возможно для SC2, отправляющего игровое состояние 200 единиц и более при 30 - 60 FPS.

Многие игры не обязательно рассматривают кадр рендеринга как логический кадр. Они могут иметь 60FPS в графике, но иметь только 10 обновлений логики в секунду и посылать по 1 сетевому обновлению для каждого. Но даже 30 сетевых обновлений в секунду - это разумно, если вы используете метод «отправки ввода», конечно.

Я попытался определить 2 возможных типа данных. Каковы другие методы? Будет хорошо процитировать игру, если вы будете.

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

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

Основная техника, о которой вам нужно знать, - это техника «1500 лучников». Он был классно использован Age of Empires, но также используется в других играх, таких как OpenTTD (с открытым исходным кодом) (на основе Transport Tycoon Deluxe).

Для ясности: используя эту технику, вам не нужно отправлять ЛЮБОЕ состояние игры во время игры. Все состояние игры отправляется при первом запуске, подключении и повторной синхронизации. Единственное, что вам нужно регулярно отправлять, это сигналы времени и проверки синхронизации. Только команды игрока обычно отправляются с клиента на сервер и наоборот. Если игрок не выполняет никаких команд (как в большинстве случаев), данные отправлять не нужно.

Смотрите эту ссылку.

http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php

Обновление: Kylotan называет это "техникой 3" в ответе.