Это начало целого цикла статей про физику Kreedz. Сразу предупреждаю, что статьи не рассчитаны на новичков. Предполагается, что вы знакомы с техниками Kreedz и имеете базовые знания в программировании (переменные, функции, циклы, условные операторы) и линейной алгебре (сложение векторов, умножение матриц, скалярное и векторное произведения векторов).
Немного предыстории
Спустя некоторое время после того, как мы с
lxr создали сообщество
KZ-Rush в начале 2016 года, у меня появилась идея написать для сайта особую статью, которая рассказала бы о том, почему в CS вообще возможно делать стрейфы. В то время уже существовал учебник по Kreedz от
Xtreme-Jumps и его перевод от
Unique-KZ, который до сих ещё копируется с форума на форум. В нём были сделаны некоторые предположения о том, почему kz техники в CS работают именно таким образом. И вот в 2016 году обнаружились заметки
Arkshine с форума скриптеров
alliedmods, который, опираясь на код, нашёл существенные ошибки в учебнике.
Мы поступим аналогичным образом и будем отталкиваться непосредственно от кода, причём сначала нам хватит открытых файлов
HLSDK, а затем придётся перейти на код из
ReGameDLL и
ReHLDS. Как вы можете догадаться, это будет чтиво не для новичков, но это не значит, что мы о них забыли. Основам мы планируем посвятить отдельный цикл, причём в формате видео. Но прежде чем кого-то учить, нужно хорошенько разобраться в теме самому, не так ли?
Вышедшая тогда статья называлась "Физика стрейфов", и именно она лежит в основе того, о чём пойдёт речь дальше. За пару лет я несколько раз переделывал её структуру, и разные её версии успели попасть в виде копипасты в несколько мест, в том числе и сюда, в гайды. В комментариях на сайте
Lt.RAT выложил свои графики из MATLAB на ту же тему, и это побудило меня повторить его расчёты, так что теперь вы увидите обновлённую версию с 3D графиками. Весь остальной материал также будет чистым экслюзивом, так что пристегните ремни :)
Вступление
Задача данного цикла статей - дать достаточно глубокое понимание физики передвижения в Counter-Strike 1.6. Вся основа была заложена разработчиками ещё в Half-Life, созданном на движке GoldSrc, прародителем которого в свою очередь был движок Quake (полное дерево можно посмотреть
здесь). Во многих движках, порождённых Quake, имеется возможность ускорения за счёт использования кнопок стрейфа (от англ. strafe – «двигаться в сторону, боком»). В Half-Life это ускорение стало существенно зависеть от того, как игрок поворачивает во время стрейфа мышь.
Выложенные в открытый доступ SDK (средства разработки) Half-Life привели к появлению множества модов, в частности в 2000 году свет увидел мультиплеерный мод Counter-Strike 1.0. Затем вышло несколько обновлений, причём после версии CS 1.3 разработчики ввели ряд параметров, ограничивавших те огромные скорости, которых можно было достичь при помощи стрейфов во время так называемой «распрыжки» (серии сделанных подряд прыжков). В финальной версии CS 1.6 оказалось, что противодействовать введённым ограничениям возможно, но это требует определённых навыков. Следующие игры серии Counter-Strike (CS:Sourse и CS:GO) были созданы уже на основе движка Source (производного от GoldSrc), который ещё больше сковал движения игрока, сделав применение техник из CS 1.6 крайне неэффективным.
Таким образом, CS 1.6 стала той золотой серединой, где преодоление ограничений движка возможно, но достаточно сложно, чтобы вызвать интерес игроков.
Движок CS 1.6 и FPS
Игровой движок – понятие довольно широкое. Сюда входят физический движок, менеджер ресурсов, графический и сетевой интерфейсы и т. д.
Фрейм – это такт работы игрового движка. Знакомое всем понятие
FPS (frames per second) в CS 1.6 означает не просто «количество кадров в секунду», а именно «количество тактов движка в секунду». Нормальное значение FPS равно 100. Это означает, что 100 раз в секунду движок игры обрабатывает действия игрока и производит определённые вычисления, обновляя позицию, скорость и многие другие параметры. Плюс к этому, на каждом такте формируется кадр, который ожидает, пока монитор отобразит его. Если бы Вы играли на мониторе с частотой обновления 60 Hz (картинка меняется 60 раз в секунду), а игра выдавала бы 60 FPS, то задержка между формированием кадра движком и его отображением на экране могла бы составлять до 1/60 секунды. Если же FPS увеличить до 100, то:
- мы получаем более актуальную картинку, так как монитор отображает последний сформированный движком кадр;
- движок чаще воспринимает наши нажатия на клавиши и движение мыши, то есть растёт «отзывчивость» игры.
Продемонстрировать уменьшение задержек нам поможет следующая картинка:
Как видим, некоторые кадры движка просто теряются. Если же взять монитор с частотой 100 Hz, то мы увидели бы каждый сформированный кадр. При этом визуально картинка стала бы более плавной, хотя на механику игры это и не повлияло бы.
Кстати, а почему именно 100 FPS, может лучше ещё больше? Скорее всего, разработчики просто ориентировались на максимальную частоту, которую тогда поддерживали мониторы. Кроме того, ставить слишком большое значение было бы нечестно по отношению к игрокам со слабыми компьютерами, ведь в CS 1.6 от FPS зависят все действия.
При желании можно посмотреть, сколько FPS способен поддерживать ваш компьтер в CS 1.6. До обновления 2013 года для этого достаточно было зайти в режим разработчика (команда
developer 1) и поставить
fps_max побольше. Легальному значению в 100 FPS соответствовало
fps_max 101. Вы могли поставить больше, но при
developer 0 ничего бы не изменилось.
После обновления всё стало немного иначе. Теперь режим разработчика не поможет, вместо этого появилась отдельная команда
fps_override 1. Однако здесь есть важный момент - при
fps_override 0 маскимальное значение FPS стало не 100, а 100.5. При этом чтобы получить ровно 100, нужно использовать
fps_max 99.5. Смена легального значения в Kreedz привела к тому, что в течение всех этих лет находились те, кто записывал демки с
fps_max 101, и они оказывались нелегальными, так как давали 100.5 FPS. Так что внимательнее с этим, проверяйте своё FPS с помощью команды
net_graph 1.
CS 1.6 создана на движке GoldSrc, который изначально разрабатывался для Half-Life, поэтому графическая часть движка заточена под небольшие закрытые помещения. На открытых же пространствах создатели уровней Half-Life использовали различные ухищрения, создавая множество поворотов и перегородок, которые не давали игроку увидеть одновременно слишком много объектов. Со временем компьютеры стали мощнее, и создатели карт (мапперы) CS 1.6 стали позволять себе всё более открытые и детализированные пространства. Однако злоупотребление этим привело к тому, что на некоторых картах даже «средние» современные компьютеры не могут поддерживать стабильные 100 FPS. Мы стараемся избегать подобных карт и советуем всем мапперам учитывать эту важную особенность движка.