Оптимизация сетевого протокола Клиент-Сервер: различия между версиями
DoBeRMaN (обсуждение | вклад) |
DoBeRMaN (обсуждение | вклад) |
||
Строка 13: | Строка 13: | ||
[[Файл:Lagcomp1.png |center]] | [[Файл:Lagcomp1.png |center]] | ||
+ | |||
+ | Далее показано всё что нужно что-бы начать обмен сообщениями и координацию между клиентом и сервером. Цикл снятия снимка клиента выглядит следующим образом: | ||
+ | |||
+ | #Снимок таймера для нахождения времени старта | ||
+ | #Снимок ввода (мыши, клавиатуры, джойстика) | ||
+ | #Формирование пакета и посылает команду отправки используя симулированное время | ||
+ | #Чтение пакета полученное от сервера из сети | ||
+ | #Обработка пакета для визуализации объектов и их положения | ||
+ | #Рендеринг сцены | ||
+ | #Снимок таймера для нахождения конца | ||
+ | #Время конца минус время старта — симулированное время для следующего кадра | ||
+ | |||
+ | Каждый раз как клиент проходит через этот цикл |
Версия 00:42, 15 января 2010
Обзор
Проектирование многопользовательских игр для Интернет является сложным процессом. Наличие качественного on-line геймплея в вашем экшене, является неотъемлемой частью успеха и долголетия продукта. Кроме того, в компьютерном пространстве хорошо известна необходимость разработчиков в поддержке большого количества клиентских конфигураций. Зачастую пользователи используют не слишком современное оборудование, это-же справедливо и для сетевой конфигурации.
Хотя внедрение широкополосного Интернета стало панацеей от всех текущих проблем для многих on-line игр, оказалось не простым решением для разработчиков позволяющим игнорировать задержку и остальные сетевые факторы в играх. Пройдет много времени прежде чем широкополосный интернет будет принят в США и на много больше в остальном мире. Кроме того, есть множество "плохих" сетей, в которых пользователь порой имеет высокую пропускную способность, зачастую и нет, но наряду с этим значительную задержку и потерю пакетов в их соединении.
В ходе обсуждения будет дано некоторое представление о том как работает клиент-серверная архитектура во многих on-line играх. Кроме того, в ходе обсуждения будет показано, как прогнозирующее моделирование может быть использовано для маскировки эффекта задержки. А так-же специфику механизма лаг-компенсации за счёт качества соединения.
Базовая архитектура Клиент/сервер
Большинство современных игр в сети — это модифицированный клиент-сервер игровой движок. Игры такие как Half-Life включая её различные модификации Counter-Strike или Team Fortress Classic, работают по такой-же системе что и игры основанные на игровых движках Quake3 и Unreal Turnament. В этих играх существует один главный сервер который отвечает за работу основной логики игры. К нему подключаются один и более "немых" клиентов. Эти клиенты, изначально, представляют из себя не более чем путь соединяющий пользователя для отправки снимка ввода и направляет его для исполнения на сервере. Сервер исполняет полученные команды, передвигает объекты, просчитает движение и отправит обратно клиенту список этих объектов для рендеринга изображения. Конечно реальный мир состоит из большого количества объектов, но простейшее разложение полезно для понимания прогнозирования и лаг-компенсации.
Имея это ввиду типичная клиент/сервер архитектура выглядит примерно таким образом:
Далее показано всё что нужно что-бы начать обмен сообщениями и координацию между клиентом и сервером. Цикл снятия снимка клиента выглядит следующим образом:
- Снимок таймера для нахождения времени старта
- Снимок ввода (мыши, клавиатуры, джойстика)
- Формирование пакета и посылает команду отправки используя симулированное время
- Чтение пакета полученное от сервера из сети
- Обработка пакета для визуализации объектов и их положения
- Рендеринг сцены
- Снимок таймера для нахождения конца
- Время конца минус время старта — симулированное время для следующего кадра
Каждый раз как клиент проходит через этот цикл