Почему «не регает»: чем саб-тик отличается от тикрейта и решила ли Valve проблемы в CS?

С выходом Counter-Strike 2 Valve отказалась от привычного тикрейта в пользу архитектуры саб-тика. Тема спорная и по сей день, а со стороны сообщества порой доносятся возгласы недовольства новой системой. На фоне этого возникает вопрос: стоила ли игра свеч, и на самом ли деле CS:GO была лучше в плане передачи данных? В этой статье разбираемся во внутренних механиках игры, рассинхронизации анимаций, пресловутой регистрации выстрелов и том, почему картинка, что отображается на вашем экране, может быть обманчивой.

Многим знакома ситуация, когда выстрел сделан, казалось бы, в идеальный момент: прицел на голове, левая кнопка мышки нажата раньше соперника. Но CS2 будто игнорирует этот факт, и попадание не регистрируется. В подобных моментах пользователь сталкивается с особенностями системы тикрейта — частотой обновления сервером информации обо всех действиях в игре.

Этот показатель измеряется в герцах (Гц). Ранее, ещё во времена CS:GO, сервера делились на два лагеря: с низким тикрейтом в 64 Гц, который был присущ официальному игровому подбору, и с высоким в 128 Гц, на основе которого функционировали, к примеру, сервера FACEIT, и игрались турниры. Проще говоря, количество герц обозначает, сколько раз в секунду происходит обновление.

Выходит, что на 64 тикрейте интервал между тиками составляет примерно 15,6 миллисекунд, а на 128 — вдвое меньше. Чем чаще сервер получает и обрабатывает информацию, тем точнее он фиксирует и отражает происходящее во время игры. Так, если действие совершено в момент между тиками, то оно либо зарегистрируется с задержкой, либо вообще останется проигнорированным. По этой причине сервера с частотой обновления в 128 Гц воспринимались как «золотой стандарт» в рамках соревновательной реальности, а их «младший брат» с 64 Гц — как компромисс ради доступности массового подбора.

Культ 128 тикрейта предельно понятен: чем чаще обновляется сервер — тем больше точек фиксации, что резко уменьшает количество вариантов для возникновения ошибок. Но в чём именно можно наиболее наглядно увидеть разницу каждой частоты?

В CS:GO она отражалась в бросках дымовых гранат в верхней точке прыжка. Один и тот же дым, который безотказно работал на серверах с 128 тикрейтом, необязательно приземлится в ту же точку в официальном соревновательном матче с частотой обновления в 64 тика.

Это объясняется тем, что движение игрока в воздухе обновляется вдвое реже, чем на 128 Гц, и это создаёт ситуацию, когда сервер хуже «ловит» пиковую скорость в прыжке. Низкий тикрейт всегда зарегистрирует меньшее значение ускорения модельки игрока при тех же условиях на большей частоте обновления. Причина этого в том, что если действие происходит между двумя тиками, то сервер фиксирует только показатели скорости до достижения пикового значения и сразу после него. На 128 тикрейте же есть дополнительный тик, благодаря которому показатель окажется ближе к наивысшему, что и влияет на окончательную траекторию полёта и точку приземления дымовой гранаты.

Также разница чувствовалась и в ситуациях, где преимущество «пикающего» могло быть заметно выше из-за скорости обновления сервера.

Когда CS:GO ушла «на покой», вместе с новым движком в обновлённой версии игры появилась архитектура саб-тик, которая заменила привычный тикрейт. Новый принцип не отменил систему тиков, а несколько её модернизировал. Если раньше серверу было необходимо дождаться новой точки для фиксирования действия, то теперь произошедшее привязывается ко времени его совершения.

То есть в рамках новой архитектуры обработка действий теперь должна происходить точнее, а основной фокус компании Valve смещается с частоты обновления на чёткость регистрации конкретного события внутри игры. Фактически, это должно делать CS2 более отзывчивой и предсказуемой.

В сравнении с тикрейтом, система саб-тик имеет ряд преимуществ. На её основе выстрелы должны фиксироваться лучше, так как теперь действие имеет собственную временную метку, а не привязывается к следующему тику сервера. То же касается и бросков гранат: проблема неверной траектории полёта, что была замечена ранее, должна быть решена, ведь новая архитектура сможет точнее запечатлеть момент нажатия кнопки игроком.

Саб-тик должен был сделать игру отзывчивее, но игроки всё равно оказались недовольны, а в комьюнити всё чаще стала звучать фраза о том, что выстрелы «не регает». Так в чём причина?

Вместе с новой архитектурой возникли новые проблемы:

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

Если анализировать каждую систему, то можно выделить как очевидные преимущества, так и недостатки.

В CS:GO тикрейт 64 был стандартом, выделялся удобством для массового использования на серверах для соревновательного подбора игр и не требовал конкретных особенностей «железа». Но одновременно с этим его воспринимали менее надёжным и не таким точным, как 128, ведь он отличался явно меньшей частотой обновления.

Выбранный для киберспортивной сцены и сторонних серверов, вроде FACEIT, тикрейт 128 считался более комфортным для игры из-за скорости смены тиков. Но он требовательнее в плане ресурсов для обработки, что делает его не таким универсальным для массовой аудитории.

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

Подводя итоги, нельзя назвать саб-тик однозначным провалом, но и панацеей эта система не стала. Это, определённо, эволюция старой архитектуры тикрейта, где теперь всё привязано не к тикам, а к временной точке совершения действия. Но возникли новые проблемы, на решение которых потребуется ещё немало времени и обновлений, если разработчик не решит оставить всё, как есть. Фактически, Valve не упростила старую проблему, а заменила её на более сложную, где точность сервера всё ещё не всегда совпадает с тем, что игрок видит у себя на экране.