Еволюція тикрейту: Як частота оновлення сервера впливає на реєстрацію влучань та фізику
У лексиконі геймерів та адміністраторів ігрових серверів слово «тикрейт» (Tickrate) давно стало синонімом якості мережевого відгуку. Існує проста думка: чим вище це число, тим краще реєструються влучання, тим плавніші рухи персонажів і тим якісніший ігровий процес. Проте в реальності сліпа гонитва за високими значеннями Tickrate здатна перетворити сервер складної багатокористувацької гри на непрацездатне слайд-шоу.
Тикрейт — це не просто абстрактна мережева метрика, а фундаментальне обмеження, що визначає, як саме процесор хостигу ділить свої ресурси між обчисленням фізики, обробкою штучного інтелекту та мережевою синхронізацією. У цій статті ми розберемо анатомію серверного кадру і зрозуміємо, чому архітектурні вимоги змагальних шутерів та масштабних симуляторів виживання є кардинально протилежними.
Що таке Tickrate на рівні архітектури движка?
Будь-який ігровий сервер працює циклічно. Він не симулює світ безперервно; замість цього він дискретно розбиває час на мікроскопічні інтервали — тіки (Ticks) або серверні кадри. Число Tickrate (наприклад, 20, 30, 64 або 128) вказує, скільки таких циклів сервер встигає виконати рівно за одну секунду.
Протягом одного тіку сервер зобов'язаний виконати строго визначений набір завдань. Цей процес називається анатомією серверного кадру:
- Збір пакетів (Input Processing): Сервер зчитує з мережевого буфера вхідні пакети від усіх клієнтів (натискання клавіш, вектори руху, координати прицілу).
- Симуляція світу (World Update): Сервер прораховує логіку гри: переміщує персонажів, оновлює стан заводів, обробляє траєкторії падіння предметів.
- Фізика та Колізії (Physics & Collisions): Інтегратор фізичного рушія (наприклад, PhysX або вбудовані модулі Unreal/Unity) перевіряє, чи не врізалася машина в стіну і чи не перетнувся промінь кулі з хітбоксом гравця.
- Штучний інтелект (AI Update): Прораховуються шляхи переміщення ботів, зони їхньої видимості та тактичні рішення.
- Реплікація станів (State Broadcasting): Сервер упаковує світ, що змінився, в нові пакети і відправляє їх назад гравцям.
Якщо сервер працює на Tickrate 30, на виконання всієї цієї цепочки завдань у процесора є рівно 33.3 мілісекунди. Якщо сервер налаштовано на Tickrate 128, це часове вікно стискається до неймовірних 7.8 мілісекунд.
Дилема жанрів: Сесійні шутери проти Виживалок (Survival)
Розуміння часового бюджету серверного кадру пояснює, чому різні ігри вимагають абсолютно різного підходу до мережевої частоти.
CS2, Valorant, Apex Legends: Боротьба за мілісекунди
У змагальних тактичних шутерах світ статичний і передбачуваний. Карта не змінюється, на ній немає десятків тисяч кинутих предметів, фізика оточення зведена до мінімуму, а кількість динамічних сутностей обмежується десятьма гравцями та парою летячих гранат.
Оскільки фізичний та скриптовий прорахунок такого світу займає нікчемно малу частку від бюджету кадру (менше 1 мс), процесор майже весь час простоює. Розробники можуть безболісно підняти Tickrate до 64 або 128 Гц. Це необхідно для максимального скорочення затримки між пострілом на клієнті та підтвердженням влучання на сервері. У змагальному середовищі, де результат дуелі вирішують 10–20 мілісекунд, висока частота оновлення життєво необхідна.
Rust, DayZ, ARK, Palworld: Прокляття відкритого світу
У симуляторах виживання ситуація виглядає діаметрально протилежною. Тут світ повністю динамічний і величезний. На сервері Rust або DayZ одночасно можуть існувати:
- До 150 000 — 300 000 будівельних блоків, воріт та турелей, що вимагають прорахунку стабільності та гниття.
- Тисячі одиниць луту, диких тварин та зомбі зі своїм штучним інтелектом.
- Складна фізика балістики куль з урахуванням гравітації та опору повітря, а також модульний транспорт.
У таких умовах тільки обчислення фізики та колізій величезного світу може займати у процесора 15–20 мілісекунд за кадр. Якщо адміністратор survival-сервера спробує виставити Tickrate 64 або 100, сервер моментально вийде за рамки бюджету кадру. Настане стан Server Tick Rate Drop (просадка тикрейту). Процесор фізично не встигатиме обробляти симуляцію за відведений час, пакети почнуть накопичуватися в черзі, а гравці зіткнуться з жорстоким rubberbanding (гумовими поверненнями) та телепортацією об'єктів.
Що відбувається при нестачі серверного часу?
Коли математичний прорахунок світу починає тривати довше, ніж ліміт часу, заданий тикрейтом, ігровий рушій включає внутрішні механізми компромісу:
- Пропуск тіків (Tick Skipping): Сервер починає штучно розтягувати ігровий кадр. Замість положених 33 мс кадр триває 50 або 100 мс. Для гравця це виглядає так, ніби його пінг раптово зріс, хоча мережевий маршрут до хостингу залишився ідеальним. Насправді це «внутрішній пінг» самого сервера, який не встигає відповідати.
- Деградація реєстрації влучань: Якщо фізичний рушій не встигає оновити положення хітбоксів (сіток реєстрації урону) слідом за мережевими координатами гравця, виникає розсинхронізація. Ви стріляєте точно в голову біжучого супротивника, клієнт відмальовує кров, але сервер у цей тік ще не пересунув хітбокс слідом за візуальною моделлю. Постріл не зараховується.
- Аварійний сон ШІ: Щоб врятувати мережевий код, сервер починає урізати частоту оновлення ШІ. Боти починають реагувати на гравця із затримкою в кілька секунд, застигають на місці або переміщуються ривками.
- Змагальні шутери (CS2, Valorant)
| Жанр / Тип гри | Оптимальний Tickrate | Куди йдуть ресурси процесора в кадрі? |
|---|---|---|
| 64 — 128 Гц | 90% — Мережева синхронізація та моментальна звірка траєкторій куль (Hitreg). Фізика мінімальна. | |
| Класичні MMO / Виживалки (Rust, DayZ) | 20 — 30 Гц | 70% — Симуляція сутностей, колізії будівель, ШІ монстрів/ботів. 30% — Мережевий обмін. |
| Інженерні симулятори (Satisfactory, Factorio) | 10 — 20 Гц | 95% — Математичні графи конвеєрів, логістика, виробництво фабрик. Мережевий код вторинний. |
Висновок
Tickrate — це не чарівний тумблер плавності, а суворий математичний баланс. Збільшення цього параметра виправдано тільки тоді, коли ігровий світ простий, а серверний процесор має величезний запас нереалізованого часу всередині кадру.
Для масштабних світів і виживалок справжня майстерність оптимізації полягає не в завищенні тикрейту, а в утриманні стабільної, монолітної частоти (наприклад, залізні 30.0 UPS) без мікросекундних відхилень. Плавність гри визначає не абстрактна цифра в конфігу, а здатність сервера укладати всі розрахунки вашої мегабази в відведений йому часовий ліміт кадру.