Гленн в своей статье и комментариях приводит очень веские аргументы в пользу использования UDP поверх TCP, но SC2, очевидно, использует TCP.
Гленн в основном говорит о физически управляемых играх, т.е. шутеры от первого лица и гоночные игры. Они предъявляют различные требования к стратегиям в реальном времени, где важны точные позиции юнитов на каждом логическом этапе. Так что коммуникационные стратегии обязательно разные.
«В реальном времени» означает разные вещи в разных контекстах. Игры не являются «тяжелыми» в реальном времени, потому что, если сообщение опаздывает, все ломается. (По крайней мере, нет веской причины, по которой игра должна быть настолько требовательной, поскольку только программная система должна быть способна восстанавливаться после задержек обработки, в отличие, например, от атомной электростанции или какого-либо медицинского оборудования.) Игры действительно «мягкий» или «твердый» в режиме реального времени. ( Определения в Википедии как обычно .) Тип игры влияет на то, как быстро вам понадобится информация, можете ли вы потерять информацию и уйти с ней и т. Д. Достаточно сказать, что TCP достаточно хорош для многих игр, но для других игр предпочтительнее использовать UDP.
Я предполагаю, что его подход заключается в отправке полного состояния игры каждого юнита в каждом кадре.
Он послал бы достаточно информации, чтобы восстановить соответствующее игровое состояние любого юнита, который изменился.
- Вам не нужно отправлять информацию о том, что не изменилось.
- Вам не нужно отправлять полное состояние, если вы можете отправить получателю достаточно информации, чтобы построить новое состояние из старого состояния. (Например, просто отправьте дельта-значение относительно старого состояния. Или просто отправьте части состояния, которые изменились, а не остальные.)
- Если в двух играх используется один и тот же алгоритм и одни и те же данные, вы можете просто отправить входные данные, и получатель повторно изменит эффекты локально, чтобы получить новое состояние.
Большинство игр не соответствуют критериям 3, поэтому вместо них используются 1 и 2. Однако во многих играх RTS можно и нужно использовать 3.
Кроме того, это не обязательно должен быть «каждый кадр». Концепция рамы также туманна. Это кадр рендеринга? Это партия логики? Это фрейм отправляемых сетевых данных? Эти три всегда выравнивают один к одному, или вы получаете переменную графическую скорость с фиксированными логическими скоростями? Некоторые игры, особенно стратегии в реальном времени, такие как Starcraft 2 или игры с возможностью воспроизведения (как вы касаетесь), любят держать все в идеальном состоянии, регулярно обновляя сеть (которая может совпадать или не совпадать с «кадрами» в других смыслах), но это не требование для всех игр. Многие игры просто отправляют обновления на полурегулярной основе, в зависимости от того, насколько далеко они готовы позволить клиентам работать.
Ввод игрока важен, а последовательность ввода еще важнее. Я не думаю, что это возможно для SC2, отправляющего игровое состояние 200 единиц и более при 30 - 60 FPS.
Многие игры не обязательно рассматривают кадр рендеринга как логический кадр. Они могут иметь 60FPS в графике, но иметь только 10 обновлений логики в секунду и посылать по 1 сетевому обновлению для каждого. Но даже 30 сетевых обновлений в секунду - это разумно, если вы используете метод «отправки ввода», конечно.
Я попытался определить 2 возможных типа данных. Каковы другие методы? Будет хорошо процитировать игру, если вы будете.
Дело не только в том, что существуют разные методы, но в системе есть несколько различных ограничений, и важность каждого ограничения будет варьироваться от игры к игре. Так что вам просто нужно выбрать систему, которая работает для вас.
- Немногие устройства, быстро и беспорядочно перемещающиеся с помощью пользовательского ввода, задержка чувствительна, точная синхронизация между системами не важна - широковещательные позиции по ненадежному протоколу (например, UDP) для получения максимальной скорости, а пропущенные сообщения не будут иметь значения, так как новые будут приезжай скорее. Моделируйте физику локально, чтобы улучшить качество рендеринга, но исправьте позиции, когда поступит новая информация. Хорошо для стрелков и гоночных игр.
- Многие устройства, но большинство из них не имеют значения, и они перемещаются медленно - отправляют обновления только для устройств рядом с получателем, отправляют их как изменения, а не как полные состояния, отправляют их относительно редко и отправляют по надежному протоколу (например, TCP), чтобы избежать беспокоиться о том, как обрабатывать пропущенные обновления. Хорошо для ММО.
- Многие юниты, перемещаемые ИИ на основе предшествующего пользовательского ввода, очень важны точной синхронизации между системами - отправляйте пользовательские данные с меткой времени по надежному протоколу и локально изменяйте размеры, чтобы игровые алгоритмы сохраняли синхронизацию состояния. Хорошо для RTS и пошаговых игр.