Мережевий код «із передбаченням» (Client-side Prediction): Чому ми бачимо те, чого ще немає на сервері

Технічний розбір роботи мережевої синхронізації в іграх. Принцип роботи передбачення на стороні клієнта, інтерполяція, екстраполяція та компенсація лагів.

01.06.2026 Українська

Мережевий код «із передбаченням» (Client-side Prediction): Чому ми бачимо те, чого ще немає на сервері

Кожен раз, коли ви натискаєте клавішу руху в сучасному онлайн-шутері або симуляторі, ваш персонаж робить крок негайно. Для вас гра здається миттєвою та чуйною. Проте з точки зору законів фізики та мережевої архітектури це відчуття — не більше ніж ілюзія, створена складними математичними алгоритмами.

Якби ваш клієнт (комп'ютер) чекав, поки пакет даних долетить до сервера хостингу, обробиться ним і повернеться назад, то при стандартному пінгу в 50–60 мілісекунд ви б відчували желеподібну затримку при кожній дії. Щоб гра приносила задоволення, сучасні движки (Source, Unreal Engine, Unity) використовують мережеву архітектуру з передбаченням на стороні клієнта (Client-side Prediction) та компенсацією лагів. У цій статті ми заглянемо під капот мережевого коду і розберемо, як ігри обманюють час і чому цей обман іноді призводить до розсинхронізації.

1. Клієнтське передбачення (Client-side Prediction) — життя в майбутньому

В авторитетній мережевій архітектурі (Server Authority) сервер є єдиним джерелом правди. Тільки он знає, де насправді перебуває ваш персонаж. Щоб приховати пінг, рушії змушують ваш клієнт «бігти попереду потяга».

Коли ви натискаєте клавішу W (йти вперед):

  1. Клієнт миттєво переміщує вашу локальну модельку персонажа на екрані вперед. Для вас рух розпочався.
  2. Одночасно з цим клієнт відправляє серверу пакет: «Я натиснув W в момент часу (тік) №100».
  3. Через 30 мілісекунд сервер отримує цей пакет, перевіряє, чи не заважає персонажу стіна, і підтверджує: «Так, у тік №100 ти дійсно просунувся вперед».

Весь цей час ви бачили плавний рух, тому що ваш ПК передбачив схвалення сервера. Якби сервер відповів відмовою (наприклад, вас приголомшили або перед вами закрилися двері), стався б неприємний візуальний баг — Rubberbanding (гумове повернення), коли сервер примусово відкидає ваш клієнт назад, до своєї «версії правди».


2. Як ми бачимо інших гравців: Інтерполяція та Екстраполяція

Якщо свої рухи ваш комп'ютер може передбачити, то передбачити дії інших 50 гравців на карті він не здатний. Сервер надсилає координати ворогів дискретно — наприклад, 30 разів на секунду (при Tickrate 30). Без спеціальної магії їхні моделі переміщалися б ривками, як у ляльковому театрі. Щоб цього уникнути, застосовуються два методи:

Інтерполяція (Interpolation) — погляд у минуле

Щоб вороги бігли плавно, ваш клієнт свідомо відображає їх із невеликою затримкою (зазвичай на 100 мілісекунд назад). Клієнт чекає, поки від сервера прийде пакет №1 та пакет №2 з координатами ворога. Маючи дві точки в просторі, комп'ютер плавно згладжує (інтерполює) рух модельки між ними.

Парадокс мережі: Коли ви дивитеся на ворога, що біжить у CS2 або Apex Legends, ви дивитеся на його минуле. Його реальне становище на сервері вже перебуває трохи далі за траєкторією руху.

Екстраполяція (Extrapolation) — небезпечне ворожіння

Якщо ваш інтернет нестабільний, і пакет №2 від сервера затримується (Packet Loss), интерполяция ламається — у клієнта більше немає кінцевої точки для згладжування. У цей момент вмикається екстраполяція. Комп'ютер каже: «Останній раз ворог біг на північ зі швидкістю 5 м/с. Пакет загубився, але я припущу, що він продовжує бігти туди ж», і домальовує рух самостійно.

Щойно втрачений пакет нарешті долітає, з'ясовується, що ворог насправді вже натиснув кнопку «назад» і зупинився. Екстраполяція вимикається, і моделька ворога неприродно телепортується на свою законную позицію. Це і є класична розсинхронізація.


3. Компенсація затримки (Lag Compensation): Машина часу для реєстрації влучань

Найскладніший математичний вузол мережевого коду — це реєстрація влучань (Hitreg). Уявіть дуель: ворог біжить зі швидкістю 10 м/с. Через інтерполяцію на вашому екрані ви бачите його позицію із затримкою в 100 мс. Ви цілитеся точно в його голову на своєму екрані і стріляєте. Пакет про постріл летить на сервер ще 30 мс.

До моменту, коли сервер отримує інформацію про ваш постріл, на самому сервері цей ворог уже втік уперед на цілий метр! Без компенсації лагів ви б ніколи не влучили по цілі, що рухається.

Обйти цю проблему допоможе Лаг-компенсація (Lag Compensation) — серверну машину часу:

  1. Сервер безперервно зберігає в оперативній пам'яті історію координат усіх хітбоксів гравців за останні 1000 мілісекунд.
  2. Коли від вас приходить пакет пострілу, сервер дивиться на ваш пінг та інтерполяцію і буквально відмотує час назад для всієї карти саме на ту мілісекунду, коли ви натиснули на курок на своєму моніторі.
  3. Сервер звіряє: «Де знаходився хітбокс голови ворога Х у цей момент минулого? Ага, точно туди, куди вистрілив гравець Y». Влучання зараховується.

4. Математичні похибки та ціна обману

За ідеальну плавність та чуйність мережевого коду доводиться платити математичними компромісами, які гравці часто називають багами:

  • Смерть за стіною (Dying behind cover): Найчастіший симптом роботи машини часу сервера. Ви встигли забігти за бетонну стіну на своєму екрані, но для ворога з високим пінгом ви ще перебуваєте в проході. Він стріляє у ваше «минуле», сервер відмотує час назад, фіксує влучання та надсилає вам пакет про смерть, коли ви вже секунду стоите в безпеці за укриттям.
  • Розрив хітбоксу (Hitbox Desync): Виникає на серверах із високим навантаженням (низький серверний TPS). Якщо сервер оновлює фізичні сітки рідше, ніж мережевий шар реплікує координати, хітбокс гравця може візуально «відшаруватися» від його графічної модельки. У цей момент кулі починають проходити крізь текстуру персонажа без шкоди.
Ігрова механіка Що бачить гравець на клієнті Що реально відбувається на сервері
Рух локального гравця Миттєвий відгук персонажа без затримки. Віртуальний прорахунок «гіпотетичного» майбутнього. Сервер підтвердить його лише через час пінгу.
Рух ворогів Плавний біг суперників по карті. Відображення глибокого минулого (на 50–100 мс назад) заради згладжування анімацій через інтерполяцію.
Постріл по ворогу Прицелювання точно в модельку суперника. Примусовий відкат часу назад для звірки старих координат хітбоксів.

Підсумок

Мережевий код сучасних багатокористувацьких ігор — це не просто трансляція координат по дротах. Це складна математична надбудова, яка постійно балансує на межі передбачення майбутнього та аналізу минулого. Ідеальний баланс цієї системи неможливий без стабільної роботи серверного процесора на хостингу: якщо залізо пропускає кадри, вся ця тендітна математична модель рушиться, перетворюючи високі технології на хаотичний розсинхрон.

Схожі статті

Віртуалізація та Обмеження ресурсів: Що відбувається, коли ваш сервер виходить за рамки лімітів хостингу

Технічний огляд роботи контейнеризації та підсистеми cgroups в Linux. Розбір процесорного троттлінгу (CFS) та ефекту «галасливих сусідів» на ігрових серверах.

Читати далі

Синхронність проти Асинхронності: Як бази даних визначають стабільність ігрового TPS

Технічний архітектурний посібник, що демонструє вплив синхронних запитів до БД на виникнення I/O Bottleneck та падіння TPS ігрових серверів.

Читати далі

Витоки пам'яті під мікроскопом: Що відбувається в RAM, коли сервер працює занадто довго

Технічний посібник із дослідження оперативної пам'яті ігрових серверів. Розбір роботи Stack та Heap, лімітів збирача сміття та причин крашів Out Of Memory (OOM).

Читати далі