Чому деякі мережеві ігри використовують інтерполяцію, а деякі використовують націлювання маршрутів для віддаленого руху?

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

Короткий приклад обох:

Інтерполяційна модель

Подумайте модель Valve, де клієнт часто отримує оновлення позицій, а віддалені оновлюють свої позиції, використовуючи інтерполяцію цих даних.

Шлях пошуку

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

Які типи ігор підходять кожному і коли слід використовувати кожну?

Я працював над кодом мережі для двох мережевих ігор AAA в режимі реального часу, однієї для смартфонів і однієї для портативної консолі.

Щоб безпосередньо відповісти на ваше запитання "чому", ну деякі ігри використовують ту чи іншу, тому що це їм більше підходить, ніж інша. Це залежить не тільки від типу гри, але і від того, про який тип мережі ми говоримо (пов'язані аркадні шафи мають різні умови порівняно з іграми, які призначені для гри в 3G). різні підходи до синхронізації даних!

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

Замість двох можливостей я хотів би запропонувати спектр між жорсткими та м'якими оновленнями.

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

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

• Жорсткі з інтер / екстраполяційними оновленнями схожі на дуже жорсткі оновлення, але для постійних змін даних, для яких практично неможливо надійно надсилати дані щоразу, коли вони змінюються. Подумайте надсилати позицію та вектор швидкості; ви повинні мати можливість інтерполювати дані між двома точками та екстраполювати їх після них. У вас повинен бути план дій у випадку надзвичайних ситуацій, якщо вхідні дані не згодні з вашими екстраполяціями. Я б сказав, що більшість ігор, які потребують оновлення позицій, використовують цей метод.

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

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

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

  Звичайно, планування оновлення даних також може бути таким же жорстким / м'яким, як ви хочете.

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

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

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

Я не розумію процесу розвитку Valve, тому це суто моя думка, але:

Інтерполяція : Я б сказав, що краще для швидких ігор, таких як FPS, наприклад, коли важливо мати постійну позицію для ворога вчасно для гравців. Інтерполяція означає, що, навіть якщо деякі пакети будуть скинуті (AFAIK, більшість мультиплікаційних FPS використовують UDP замість TCP / IP, що не гарантує ні цілісності, ні порядку, в якому пакети надходять), ви будете мати плавний рух по екрану.

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

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

Відповідь піжами на панда є досить хорошою.

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

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

Однак він не згадав про один метод. Вимушені результати.

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

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