Как работает движок Half-Life. Клиент и сервер.

Как работает движок Half-Life. Клиент и сервер.

Это краткое описание как между собой взаимодействуют серверы и клиенты, что такое частота кадров (FPS), какие факторы влияют на пинг (ping), и как это все работает вместе.

Движок

Многопользовательский движок игры Half-Life состоит из сервера и одного или более клиентов из 32 максимально возможных (хотя на самом деле движок может обрабатывать до 255), которые соединены через сеть (интернет) интерактивно, в режиме полу-реального времени.
Коммуникация между сервером и клиентами использует UDP протокол который очень подходит для такого вида соединения.
Более детально о специфике TCP/UDP сетей смотрите в соответствующей литературе.

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

Обычно, сервер выполняется с установленными по умолчанию 100FPS (Frames Per Second - фреймами в секунду) или со скоростью 10 милисекунд за фрейм. При помощи всевозможных доступных мировых инновацияй, сервер может выполнятся намного быстрее, до 1000FPS.
Ограничивающий фактором для FPS являются ограничения аппаратного и програмного обеспечения на той платформе где они рассматриваются.

Выполнение сервера со скоростью 500FPS или 1000FPS не имеет непосредственного влияния на FPS определенного клиента, так как каждый клиент рендерит фреймы независимо от сервера.
FPS - частота фреймов на сервере устанавливается при помощи консольной переменной(CVAR) sys_ticrate со значениями от 0 до 1000.

Если компьютер на котором выполняется сервер обладает избыточной мощьностью, установка высокого значения FPS (до 1000) дает выигрышное преимущество.
Рассмотрим подробнее что здесь происходит и почему это происходит.

Сервер выполняющий карту на которой происходит игра, кэширует ресурсы, рендерит фреймы, принимает обновления статусов от клиентов и отправляет обратные обновления клиентам.

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

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

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

Итак мы видим, что в движке имеется две разные независимые и связанные друг с другом системы рендеринга которые соединены одна с другой через сеть.

Преположим, сервер рендерит фреймы с частотой 500FPS.
Это означает что снимок всего происходящего из всего доступного отправляется клиенту каждые 2 милисекунды (если будет 1000FPS - каждую милисекунду).
Клиент взаимодействует с сервером в два раных способа.
Клиента отправляет обновления состояния игрока (позиция, действия) 30 раз в секунду (по умолчанию это установлено в консольной переменной cl_cmdrate) а также оправляет зарос дял полного обновления от сервера 20 раз в секунду (устанавливается в переменной cl_updaterate).
Далее мы пропустим рассмотрение переменной cl_cmdrate так как она не указывает что клиенту требуется ответные данных от сервера.

Итак, cl_updaterate 20 означает что каждые 50мс или около того клиент совершает запрос и обновление от сервера.
Далее, добавим время путешествия (1/2 пинга) от клиента к серверу а также задержку около 2 мс на то что на сервере отрендериться обновление (при 500FPS) и будет отправлено обратно клиенту с примерно той же задеркой 1/2 пинга.

При 100FPS, максимальная задержка составит 10мс для рендера.

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

Частота с которой эти обновления оправляются туда и обратно котроллируется CVAR-переменной rate на стороне клиента (значения от 0 до 20000), а на стороне сервера: sv_minrate и sv_maxrate.

Настройки на стороне сервера перекрывают все что установлено на стороне клиента. Скорость измеряется в байтах в секунду.
В среднем, игрок с скоростью 7500 отправляет серверу и получает от него максимум до 7.5Кбайт в секунду.

Сервер выполняющийся с 100FPS в таком случае с 10мс периодом для этих запросов аккумулирует их во время рендеринга а затем отправляет обратно обновления всем запросам коиентов в данном периоде.
Если сервер способен отрендерить текущий фрейм перед завершением интервала sys_ticrate он простаивает оставшееся количество времени.

Это означает что при большом количестве клиентов, сервер вынужден отпрвлять большие объемы данных каждые 10 мс что может повлиять на пропускной канал сервера (требуется расширять канал).

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

Данная эффективность делает три вещи, уменьшает потребность в расширении канала (благодаря более ровной загрузке), слегка уменьшает относительное увеличение значение пинга которое видят пользователи клиентов (для 10ms около 1 или 2 мс) и менее важное, это сохраняет клиента максимально обновленным насколько это возможно, что в лучшую влияет на появление "лагов".

Замечание.

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

Подведем итоги.

1. Сервер рендерит фреймы с частотой 100FPS , 500FPS или 1000FPS, обновляясь каждые 10, 2 или 1 мс соответствено.

2. Клиенты рендерят фреймы по умолчанию с частотой 100FPS и отображают фреймы обычно с частойто от 30 до 100 FPS в зависимости от того какой процессор и графическая система в их системе и смотря что происходит в игре на карте.

3. Клиенты отправляют обновляющую информацию (cl_updaterate) серверу 30 раз в секунду (по умолчанию).

4. Клиенты запрашивают обновления из сервера (cl_cmdrate) и (по умолчанию) 20 раз в секунду (тоесть каждые 50мс между обновлениями).
Сервер отправляет обновленную информацию клиенту.
На протяжении интервала 50ms (и время доставки данных), клиент рендерит видимые фреймы, предиктует события и взаимодействует с игроком пока принимается обновление.

5. Клиенты отправляют данные серверу и сервер отправляет данные клиенту со скоростью установленной CVAR-значением rate на стороне клиента и перекрываемым CVAR-значением sv_maxrate сервера.

6. Серверы выполнющиеся с большей FPS способны отправлять обновляющую информацию клиентам чаще и немного снизить требования к ширине пропускной способности канала сервера.

7. Клиенты отправляют серверу и принимают от сервера одинаковые объемы данных в не зависимости от FPS сервера. В связи с этим есть резон ограничивать sv_maxupdaterate.

8. Серверные CVAR-переменные sv_maxrate и sv_maxupdaterate имеют эффективность, если видимые визуальные задержки перед тем как были произведены изменеия (если видимы только визуальные эффекты).