Российский ведущий Quake-девелопер Дмитрий "Qrealka" Логинов разразился очередной статьей на тему внутреннего устройства современных модов. На этот раз разговор пошел о механике работы Lighning gun в моде cpma, режим vq3.

Итак VQ3-шафт это оружие, которое раньше было сложно использовать при большом пинге даже если использовать алгоритмы компенсации лагов. Почему?

1. самая главная причина: шафт это instanthit випон с большой скорострельностью. instanthit это значит патроны никакие по воздуху не летят, а выстрел происходит моментально. А т.к. хиттест и прочие прилагаемые к этому данные обесчитываются на сервере, то чем больше задержка между нажатием кнопки на компьютере игрока, тем больше шансов у тебя промазать.

2. Но почему зависимость от величины лага и погрешности при стрельбе из VQ3-шафта в обычном Ку3 нелинейна? И почему даже при небольших значениях пинга это погрешность сильно ощутима? На то есть несколько причин:

* Когда вы попадаете в кого-то из шафта или когда вы «мажете», всякий раз создается временный объект(Entity) с флагом EV_MISSILE_HIT или EV_MISSILE_MISS соответсвенно. И затем он в версии BASE-Q3, да и в ОСП тоже, отправлялся ВСЕМ подсоединившимся клиентам. Объект этот небольшой, насколько я помню что-то в районе 16 байт для BASEQ3(OSP), правда следует это умножить на скорострельность шафта. Ну, а под словом «отправлялся» я имел ввиду, что ядро сервака должно было решить кому это событие пойдет, а кому нет. Зачем это делается? Это делается, чтобы уже на клиенте код мода решал, что и как делать с этим событием (например, пораждать несколько других). Событие отправляется всем клиентам, потому что это классический пример решения задачи в лоб. Сама задача же - как сделать так, чтобы стрельба из шафта одного игрока по другому игроку корректно отображалась для третьего наблюдателя. Цена решения – сильно увеличивается траффик в сторону от сервера к клиенту, особенно для тимплейных игр. Плюс, увеличивается время задержки отправки этого события.

Дело в том, что ID использует в своих играх прогрессивную для своего времени (Quake 1) реализацию PVS – набор потенциально видимых объектов. Только они передаются клиенту. Это усложняет компенсацию лагов, но зато уменьшает трафик и, как РАНЬШЕ считалось, делает сетевой код более безопасным, в отличии от версии, когда серверная часть работает и на клиенте. Самым тонким местом этого решения является, собственно, сам алгоритм формирования PVS. В том плане, как сервер будет решать – видим этот объект кому-то или нет. На примере работе Doom3/Quake4 мы можем видеть, что неверное работающий алгоритм PVS может сильно испортить мультиплеерную игру.

Так вот, алгоритм формирования этого множества, PVS, напрямую связан с тем, как хранятся данные о карте, то есть с форматом BSP. Ядро сервера трассирует эти данные по определенному алгоритму, решая тем самым задачи «видимости» того или иного объекта. Не стоит и говорить, что неверное построенная карта (с неправильно соединенными поверхностями или расположенными порталами видимости) может сильно деорганизовать дерево BSP и усложнить работу алгоритма работы PVS, что, в свою очередь, сказывается на фпс. Пример такой багнутой карты – pro-q3tourney4 и ее предшественник. Неправильно расположенные или отсутсвующие «порталы видимости» заставляли рендерить объекты внутри башни, даже если вы находились снаружи. С этими багами связаны ОТЧАСТИ современные баги «слышу всех игроков» при включении mvd или mv в cpma 1.40.

Возвращаясь к пункту об отправке события попадания или непопадания из шафта ВСЕМ клиентам сервера, мы получаем более полную анатомию того, что приходится делать серверу в этой ситуации. Во многих ситуациях для сервера это превращается в достаточную большую задержку, из-за чего объект улетает к клиенту не сразу, а через некоторую задержку. Многие игроки ошибочно думали, что это напрямую связано ТОЛЬКО с пингом. Но общая задержка – это сумма задержки на сервере и задержки по сети(пинга). Не учитывать задержки на серваке – это ошибаться порой на величину равнуюю величине серверного фрейма (1000/sv_fps). Именно с такой частотой отправляются данные с сервера до клиентов.

Id пробовало решить это проблему заплатой trueLightning. Опять же исправление в лоб. Заплата на заплате, это бесконечный процесс, если не найти главную причину и не устранить ее. А главная причина была именно в отправке объекта всем клиентам. В CPMA событие о том, что вы попали или промазали отправляется только вам.

* Еще одна причина это опять же округление данных на клиенте. При показе луча, прицела и прочего, клиент вызывает функцию округления для углов, координат и прочих параметров поверхностей и объектов. Когда сам луч короткий, или, проще говоря, когда длина объекта мала, то действительно этой ошибкой можно пренебречь. Длина луча же шафта может достигать 768 единиц. Это значит минимальная ошибка округления будет шесть с половиной единиц для каждой из осей. Если же просуммировать ошибку округления для всех осей (45 градусов от координатных осей карты), то получится ошибка в районе 11 единиц. А это больше трети хитбокса! Причем как видим это ошибка не постоянна, она зависит от: а) длины луча, то есть удаленности врага; б) от взаимной позиции стреляющего и его врага; в) от фпс стреляющего. Стоит учесть, что эта ошибка никак не зависит от ошибок связанных с задержкой на сервере. То есть она проявляется и на LAN.

Сложите все это вместе и вы получите то, что вы имеете в BASEQ3 – оружие которое ведет себя порой не так как ожидает этого игрок, и наличиствует ошибка наведения, которую с определнным допущением можно назвать случайной. То есть это как случайный «шум в прицеле» при стрельбе в КС. Оружие в мультиплеере, которое ориентируется на aim-skill игрока, не должно обладать такими недостатками.

3. Что же мы получаем в итоге в CPMA? Мы исключаем округление на клиенте, чтобы игрок стрелял именно туда, куда показывает прицел, а не плюс минус треть корпуса. Мы исключаем задержку события на серваке, уменьшая траффик и загрузку, увеличивая тем самым время реакции системы. И instant weapon начинает действовать достаточно близко к тому как должны действовать instant weapon. А не с приблизительной задержкой. То есть мы получаем шафт, который работает в точности с заданными параметрами стрельбы. Никаких предварительных вычислений и оптимизаций на клиенте тут НЕТ. Никакого увеличенного дамаджа НЕТ. Никакой увеличенной сокрострельности НЕТ. Никаких более толстых хитбоксов НЕТ. Просто оружие работает так, как оно должно работать.

По материалам promode.ru