Оптимизация сетевого протокола Клиент-Сервер

Обзор

Проектирование многопользовательских игр для Интернет является сложным процессом. Наличие качественного on-line геймплея в вашем экшене, является неотъемлемой частью успеха и долголетия продукта. Кроме того, в компьютерном пространстве хорошо известна необходимость разработчиков в поддержке большого количества клиентских конфигураций. Зачастую пользователи используют не слишком современное оборудование, это-же справедливо и для сетевой конфигурации.

Хотя внедрение широкополосного Интернета стало панацеей от всех текущих проблем для многих on-line игр, оказалось не простым решением для разработчиков позволяющим игнорировать задержку и остальные сетевые факторы в играх. Пройдет много времени прежде чем широкополосный интернет будет принят в США и на много больше в остальном мире. Кроме того, есть множество "плохих" сетей, в которых пользователь порой имеет высокую пропускную способность, зачастую и нет, но наряду с этим значительную задержку и потерю пакетов в их соединении.

В ходе обсуждения будет дано некоторое представление о том как работает клиент-серверная архитектура во многих on-line играх. Кроме того, в ходе обсуждения будет показано, как прогнозирующее моделирование может быть использовано для маскировки эффекта задержки. А так-же специфику механизма лаг-компенсации за счёт качества соединения.

Базовая архитектура Клиент/сервер

Большинство современных игр в сети — это модифицированный клиент-сервер игровой движок. Игры такие как Half-Life включая её различные модификации Counter-Strike или Team Fortress Classic, работают по такой-же системе что и игры основанные на игровых движках Quake3 и Unreal Turnament. В этих играх существует один главный сервер который отвечает за работу основной логики игры. К нему подключаются один и более "немых" клиентов. Эти клиенты, изначально, представляют из себя не более чем путь соединяющий пользователя для отправки снимка ввода и направляет его для исполнения на сервере. Сервер исполняет полученные команды, передвигает объекты, просчитает движение и отправит обратно клиенту список этих объектов для рендеринга изображения. Конечно реальный мир состоит из большого количества объектов, но простейшее разложение полезно для понимания прогнозирования и лаг-компенсации.

Имея это ввиду типичная клиент/сервер архитектура выглядит примерно таким образом:

Далее показано всё что нужно что-бы начать обмен сообщениями и координацию между клиентом и сервером. Цикл снятия снимка клиента выглядит следующим образом:

1. Снимок таймера для нахождения времени старта
2. Снимок ввода (мыши, клавиатуры, джойстика)
3. Формирование пакета и посылает команду отправки используя симулированное время
4. Чтение пакета полученное от сервера из сети
5. Обработка пакета для визуализации объектов и их положения
6. Рендеринг сцены
7. Снимок таймера для нахождения конца
8. Время конца минус время старта — симулированное время для следующего кадра

Каждый раз как клиент проходит через этот цикл