Компенсація відставання за допомогою мережевих 2D ігор


31

Я хочу зробити 2D гру, яка в основному є фізикою, що керується пісочницею / дією. Є щось, чого я насправді не розумію. Згідно з дослідженнями, схоже, що оновлення з сервера мають бути приблизно кожні 100 мс. Я бачу, як це працює для гравця, оскільки вони можуть одночасно імітувати фізику і робити компенсацію відставання за допомогою інтерполяції.

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

В основному, як це працює для зйомки та подібних матеріалів?

Спасибі

Відповіді:


58

Підсумок для тих, хто не любить довгих відповідей ...

Це можна зробити, але неможливо виконати ідеальну багатокористувацьку фізику, якщо є затримки. Чому затримка впливає на фізику, пояснюється, а потім пропонуються поради щодо зменшення впливу затримок на ваше фізичне моделювання.


Створення багатокористувацької фізичної гри може бути загрожує небезпекою. Неможливо створити "ідеальний" онлайн-досвід багатокористувацької фізики. Ви можете зробити це для того, щоб покращити його, але немає можливості зробити ідеальну фізику з урахуванням затримок.

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

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

Приклад, щоб показати, як все може зіпсуватись

Уявіть гру, де до гравця підключені два гравці (клієнти). Потрібно 100 мілісекунд (1/10 секунди), щоб повідомлення пройшло через Інтернет від клієнта до сервера. Коли гравець щось робить, на сервер надсилається повідомлення про те, що вони зробили. Потім сервер передає повідомлення іншим гравцям, щоб вони всі знали, що робив актор.

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

Давайте розглянемо різні способи впоратися з цим і які були б результати ...

Що робити, якщо фізика обчислюється саме на сервері?

Припустимо, у нас фізика розраховується лише на сервері. Гравець A відправляє на сервер повідомлення "Я вдарив ящик таким чином", через 10/10 секунду сервер отримує повідомлення. Гравець B надсилає повідомлення "Я потрапив у ящик таким чином". Сервер обчислює зміну фізики в поєднанні двох дій і надсилає повідомлення обом гравцям, кажучи: "Добре, що рухається так". Ідеальна фізика виконується на основі дій обох гравців у поєднанні.

Але проблема полягає в тому, що це пройде 2/10 секунди, перш ніж кожен із гравців побачить, як реагує ящик. Повідомлення обох гравців займають 1/10 секунди, щоб дістатися до сервера, потім ще 1/10 секунди, щоб результати обчислення серверів були відправлені обом гравцям.

Підсумок, млявий геймплей.

Що робити, якщо фізика просто розрахована на клієнта?

Припустимо, у нас фізика розрахована лише на клієнта. Давайте розглянемо це з точки зору гравця А. Гравець A б'є в ящик, і він негайно починає рухатись у своєму напрямку. На сервер також надсилається повідомлення про те, що зробив Player A.

У той же час, B зробив свій удар і побачив, що ящик рухається в їхньому напрямку та надіслав повідомлення серверу про те, що вони зробили.

2/10 секунди пізніше від сервера до клієнтів надходить повідомлення. A кажуть, що зробив B, а B - те, що зробив A. Проблема полягає в тому, що обидва клієнта кажуть: "Ну гравець X, можливо, зробив цей удар на цьому місці, але в цьому місці вже немає ящика, тому їхній удар не зробив нічого".

Підсумок - це дві синхронізовані ігри та гравці, які не мають спільного досвіду. Який сенс багатокористувацького, якщо вони обоє бачать різні речі?

Що робити, якщо фізика розрахована як на клієнті, так і на сервері?

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

Обидва гравці потрапляють у ящик у відповідних напрямках, і кожен бачить рух ящика лише на основі свого удару. Але потім 2/10-ої секунди пізніше сервер повертається і каже: "Ну насправді ви обоє помиляєтеся. Ящик пішов цим шляхом". Раптом обидва гравці бачать, що ящик різко міняє напрямки та глюкає на нове місце.

Підсумок - це гнучка гра.

Висновок

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

Що ви можете зробити, щоб багатокористувацька гра працювала добре

Використовуйте прості томи зіткнення. Не переймайтеся моделюванням кожної деталі фігури з фізики, коли це зробить проста форма кубика. Куля з колосками не повинна моделюватися як кулька колоска для фізики. Натомість просто моделюйте його як сферу.

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

Об'єкти фізики роблять лише тоді, коли вони повинні бути об'єктами фізики, щоб число активних об'єктів фізики було низьким.

Запускайте гру в повільному режимі, виконуючи багатокористувацьку фізику. Подумайте, можливо, "час кулі". Ігри з повільним рухом компенсують затримку і дозволяють декільком гравцям взаємодіяти з фізикою разом.

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

Окремі гравці-фізики, щоб вони не могли заважати один одному. Це було б чудово для такої гри, як боулінг або більярд, де лише один гравець одночасно має контроль, або кожен гравець має власну «пісочницю» (як боулінг).

Якщо ви не можете перемогти їх, приєднайтесь до них і зробіть відставання фізики частиною вашої гри. Уявіть історію про те, що ви перебуваєте у глянцевому Всесвіті з порушеними законами фізики чи що-небудь :)

Додаток: Як з ними впораються ігри з стріляниною

Ігри з стріляниною займаються цим, не займаючись надмірно складною фізикою. Вони використовують побічні ефекти клієнта, тому гравці швидко бачать речі, але потім сервер робить остаточний дзвінок про те, що сталося.

Уявіть собі сценарій, коли гравець A стріляє гравця B. Ваша типова гра-шутер зробить щось подібне ...

  1. Локальний підрахунок, якщо вони потрапили в B, і якщо він схожий на те, що є удар, він відіграє ефект "удару", як кров'яна затяжка. Це робиться на стороні клієнта, щоб гравець відразу побачив реакцію на їх дію. Якщо цього не зробити, гра відчуває себе млявою.
  2. А також надсилає повідомлення на сервер із записом: "Я стріляв по цьому вектору"
  3. Коли сервер отримує повідомлення, він переглядає, де ІТ вважає гравців, і вирішує, чи потрапив вектор вистріленого A у B.
  4. Якщо сервер вирішує удар B, він вирішує B потрапив і надсилає повідомлення клієнтам BOTH із повідомленням про те, що сталося.
  5. Якщо сервер вирішив, що A НЕ вдарив B, B нормально, а "промахнеться". Це може здатися A, як вони потрапляють ("Я бачив кров!"), Але сервери дзвонять, що вони пропустили.

То як міг A пропустити B, коли це виглядало так, ніби вони їх вдарили? Оскільки B, можливо, перемістився, але A ще цього не бачив, оскільки сервер ще не надіслав клієнту повідомлення "B переїхав сюди".

У Valve на цьому сайті є хороший запис. Дивіться сторінку http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking


2
Це вірно на сервері з хорошим з'єднанням. Є багато випадків, коли фізика в іграх для багатьох гравців не вдається, і я впевнений, що в модних іграх Гаррі багато поганого досвіду фізики. Однак якщо буде затримка, то окреслені нами питання існуватимуть. Ви не можете обійти той факт, що фізика повинна бути обчислена дуже швидко, щоб бути рівною. І якщо у вас затримка, відбудеться затримка. Затримка означає відставання.
Тім Холт

1
Можливо, ви захочете повернутися і перечитати мій пост. Мінус, який є впевненим в передній частині з мого боку, я описую саме те, що відбувається у фізичному моделюванні з кількома гравцями - включаючи ваші сесії гри Гаррі. Ви не можете обійти факти.
Тім Холт

2
Гаразд, я змінив свій нижчий рахунок на оновлений. Але ви малюєте дійсно негативну картину для багатокористувацьких ігор з фізикою, коли це було зроблено раніше і порівняно безкоштовно.
AttackingHobo

7
@AttackingHobo: "Без збоїв" відносно. Працюючи над грою з хорошим мережевим прогнозуванням, тепер я бачу глюки там, де раніше цього не робив. Вони рідко впливають на механіку значимо, але вони присутні. Вся суть прогнозу в тому, що невелика неточність у режимі реального часу краще, ніж уповільнена точність; це не змінює того факту, що ви завжди неточні.

1
+1 для "Уявіть історію про те, щоб опинитися у блискучому Всесвіті із порушеними законами фізики чи що-небудь".
Патрик Чачурський

13

Я написав низку статей про цю тему тут: http://www.gabrielgambetta.com/fpm1.html

Перші три статті стосуються вступу до теми, прогнозування на стороні клієнта, узгодження сервера та інтерполяції сутності (це частина, яка відповідає на ваше конкретне питання). Четверта стаття (незабаром) стосуватиметься "стрілянини" :)

Відповідь Тіма Холта - це майже все. У моїх статтях є кілька діаграм, які можуть допомогти вам зрозуміти, що відбувається, але ми з Тімом в основному говоримо те саме.


Гарні речі ggambett!
Тім Холт

2
Так багато гравців не розуміють, як працює цей матеріал, але це так критично для розуміння вічного: "WTF ЧОМУ Я МІСЮ?" питання.
Тім Холт

Або "чому мій персонаж прив'язаний до тієї колони з гігантською гумкою?" на
перерваному

У Вікі Valve є перелік даних, який також стосується цих питань. Сторінка знаходиться на веб-сайті developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Тім Холт

1
Я люблю демо-версію. Який чудовий спосіб візуалізувати те, що відбувається.
Річард Марскелл - Дракір

2

Нерозумно робити повне передбачення власного персонажа на чуйність та на те, щоб інші персонажі відставали на 100 м за послідовністю. Якщо це виглядає погано, тоді подумайте про те, щоб ваш власний персонаж трохи відставав, щоб підтримувати їх синхронізацію. Так чи інакше, вам все одно знадобляться механізми корекції, щоб згладити невірні прогнози на випадок відставання, і ця система буде вирішувати такі ситуації, як описана вами. Не має значення, затримка становить 100 мс або 1 мс - ваш клієнт у певному сенсі завжди «запізнюється», а тому завжди повинен діяти так, як він має справу зі старими даними та застосовувати косметичні ефекти, такі як інтерполяція, щоб виглядати розумним.


0

Зрештою, все про те, щоб зробити доступні доступні мережеві ресурси. В ідеалі ми жили б у світі з нульовою затримкою, і все може бути ідеально синхронізовано. Реально ви оновлюєте клієнтів кожні 100, 200, 300 мс, і для клієнта потрібно створити логіку, щоб те, що трапилося, виглядало гладко. "Гладкість" дуже важлива, врешті-решт, гра просто має відчувати себе гладкою, навіть якщо на задньому кінці між клієнтом та сервером відбувається якась хаотична синхронізація.

Хороший пост та кращу відповідь можна знайти:

Як написати мережеву гру?


0

Проблема насправді не затримка. Це можна компенсувати і передбачити досить добре, щоб приховати будь-які спричинені проблеми. Втрата пакетів теж не є проблемою - мережа повинна бути написана надійною та терпимою для втрати пакету. Однак проблема - це відставання та непередбачувана затримка. Пакети, що надходять із синхронізації, деякі з них скидаються лише через затримки, неможливість передбачення та інтерполяцію через перепади затримки тощо.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.