мірялка у тебе так і не виросла за стільки років.
проте нічо, я допоможу, але почну з деталей, щоб було зрозуміло, як працює гра.
Весь обмін між клієнтом і сервером іде через WebSocket поверх одного TCP-з'єднання. Ти щось клікаєш — клієнт шле пакет з дією на сервер, сервер її обробляє і розсилає результат гравцям поруч. Інші гравці (і їхній софт) дізнаються про твою дію тільки тоді, коли до них доходить цей пакет від сервера.
Домовимося про терміни, щоб ніхто не заплутався:
Плече — час, за який пакет долітає в одну сторону: від клієнта до сервера або від сервера до клієнта.
Пінг — те число, що показує будь-яка програма («ping 30 ms»). Пакет доходить до сервера, сервер одразу відповідає «отримав», нічого не обробляючи, і відповідь повертається назад. Пінг = два плеча (туди й назад).
Прохід — від моменту, коли клієнт відправив дію, до моменту, коли сервер її обробив (виконав дію), розіслав результат і пакет дійшов назад до клієнта. Прохід = плече + обробка на сервері + плече.
Наприклад, пінг 30 мс — це два плеча по 15 мс. Якщо сервер обробляє дію 20 мс, прохід = 15 + 20 + 15 = 50 мс.
Ти кажеш, що через пінг софт фізично не встиг би, і тому це збіг. Давай не гадати, а заміряти.
Відео. Воно в 60 fps, на шкалі секунди й номер кадру: поділки йдуть 0.00, 0.12 … 0.48, а далі одразу 1.00. Гном натискає зняття FD на 0.43, tay починає каст на 0.51. Це 8 кадрів, тобто 133 мс (±17 мс).
Що мало б статись за ці 133 мс:
прохід гном → сервер → tay: софт tay отримує пакет «гном встав»;
софт одразу шле каст, бо програмі нічого не треба «помічати», тож ~0 мс (реально долі мілісекунди);
прохід tay → сервер → гном: гном бачить початок касту.
Тобто два проходи. Питання лише в тому, скільки триває один прохід.
Замір у неідеальних умовах. Я навмисно взяв не найкращий варіант: інстанс на Oracle Cloud у Лондоні. Ігровий сервер Європа-1 стоїть у Google Cloud у Фінляндії. Прямого оптичного кабелю між Британією і Фінляндією немає, тож пакети йдуть транзитом через інші країни й чужі мережі. До того ж це різні хмари, тобто жодних внутрішніх оптимізованих маршрутів, лише звичайний публічний інтернет.
Міряв прохід: від відправки пакета дії (сісти/встати — FD теж закінчується тим, що персонаж встає) до отримання від сервера пакета про цю дію, на вже відкритому з'єднанні.
Результат за 16 спроб: прохід мін 60,3 мс, медіана 60,7 мс, макс 73,4 мс. Пінг з Лондона до сервера ~40 мс, тобто плече ~20 мс. Розкладаємо:
Лондон -> сервер 20 мс (плече)
сервер обробляє дію 20 мс
сервер -> Лондон 20 мс (плече)
------------------------------------
прохід 60 мс (заміряно: 60,7)
Обробка на сервері дуже стабільна: 15 з 16 замірів лягли між 60,3 і 61,2 мс, розкид менше мілісекунди. Тобто сервер нічого не притримує і не збирає в пачки, а просто обробляє дію за ~20 мс і одразу розсилає.
Рахуємо софт з Лондона (обидва гравці там):
гном -> сервер 20 мс
сервер знімає FD 20 мс
сервер -> tay 20 мс = прохід 1: 60 мс
софт tay шле каст ~0 мс
tay -> сервер 20 мс
сервер приймає каст 20 мс
сервер -> гном 20 мс = прохід 2: 60 мс
------------------------------------
разом ~120 мс < 133 мс на відео
Навіть з Лондона, транзитом через кілька країн, софт встигає.
Те саме для гравців з України (пінг ~30 мс, тобто плече ~15 мс):
гном -> сервер 15 мс
сервер знімає FD 20 мс
сервер -> tay 15 мс = прохід 1: 50 мс
софт tay шле каст ~0 мс
tay -> сервер 15 мс
сервер приймає каст 20 мс
сервер -> гном 15 мс = прохід 2: 50 мс
------------------------------------
разом ~100 мс < 133 мс на відео
З Польщі пінг ~25 мс, з Латвії й Литви 15–20 мс, з Естонії ~10 мс, тож софту треба ще менше: 60–90 мс із тих 133.
Твої «100 мс пінгу» — це не пінг. Коли міряєш кліком на біг і рахуєш кадри до початку бігу, ти міряєш прохід плюс те, як клієнт малює і запускає анімацію. Справжній пінг до Європа-1 з Європи — 10–40 мс.
А тепер про збіг. Ти пишеш, що каст tay спрацював ще до того, як гном встав. Тоді сервер прийняв би каст раніше, ніж зняв FD, і гном побачив би його не пізніше ніж через один свій прохід після натискання: 35–60 мс, тобто 2–4 кадри. На відео ж 8 кадрів, тобто каст tay дійшов до сервера вже після того, як гном встав.
Тож «фізично неможливо через пінг» не підтверджується: заміри показують, що навіть у поганих умовах софт укладається в ці 8 кадрів.
Додаю лог пакетів заміру:
Oracle London -> Europe-1 (35.228.144.6), 2026-10-06
час, мс напрям пакет на дроті (зашифровано)
0.0 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
60.7 сервер -> клієнт ChangeWaitType (сів) bce221f5aa6699cca01ebd5f31cf88c62b0a871ef3
прохід: 60.7 мс
3000.6 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
3061.0 сервер -> клієнт ChangeWaitType (встав) bce221f5aa66d9cca01ebd5f31cf88c62b0a871ef3
прохід: 60.4 мс
6001.1 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
6061.9 сервер -> клієнт ChangeWaitType (сів) bce221f5aa6699cca01ebd5f31cf88c62b0a871ef3
прохід: 60.8 мс
9003.7 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
9064.4 сервер -> клієнт ChangeWaitType (встав) bce221f5aa66d9cca01ebd5f31cf88c62b0a871ef3
прохід: 60.7 мс
12004.5 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
12065.3 сервер -> клієнт ChangeWaitType (сів) bce221f5aa6699cca01ebd5f31cf88c62b0a871ef3
прохід: 60.8 мс
15006.2 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
15066.8 сервер -> клієнт ChangeWaitType (встав) bce221f5aa66d9cca01ebd5f31cf88c62b0a871ef3
прохід: 60.6 мс
18007.4 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
18068.1 сервер -> клієнт ChangeWaitType (сів) bce221f5aa6699cca01ebd5f31cf88c62b0a871ef3
прохід: 60.7 мс
21009.3 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
21069.7 сервер -> клієнт ChangeWaitType (встав) bce221f5aa66d9cca01ebd5f31cf88c62b0a871ef3
прохід: 60.4 мс
24011.2 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
24084.6 сервер -> клієнт ChangeWaitType (сів) bce221f5aa6699cca01ebd5f31cf88c62b0a871ef3
прохід: 73.4 мс
27013.3 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
27073.8 сервер -> клієнт ChangeWaitType (встав) bce221f5aa66d9cca01ebd5f31cf88c62b0a871ef3
прохід: 60.5 мс
30014.3 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
30075.3 сервер -> клієнт ChangeWaitType (сів) bce221f5aa6699cca01ebd5f31cf88c62b0a871ef3
прохід: 61.0 мс
33015.4 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
33076.1 сервер -> клієнт ChangeWaitType (встав) bce221f5aa66d9cca01ebd5f31cf88c62b0a871ef3
прохід: 60.7 мс
36017.2 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
36078.0 сервер -> клієнт ChangeWaitType (сів) bce221f5aa6699cca01ebd5f31cf88c62b0a871ef3
прохід: 60.8 мс
39018.6 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
39079.0 сервер -> клієнт ChangeWaitType (встав) bce221f5aa66d9cca01ebd5f31cf88c62b0a871ef3
прохід: 60.4 мс
42019.5 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
42080.7 сервер -> клієнт ChangeWaitType (сів) bce221f5aa6699cca01ebd5f31cf88c62b0a871ef3
прохід: 61.2 мс
45020.8 клієнт -> сервер RequestActionUse (0) 8a0071c52e6699cca018
45081.1 сервер -> клієнт ChangeWaitType (встав) bce221f5aa66d9cca01ebd5f31cf88c62b0a871ef3
прохід: 60.3 мс
Розшифровані пакети не покажу
