Прогноз руху для нестріляних

Я працюю над ізометричною 2D грою з середньомасштабним багатокористувацьким гравцем, приблизно 20-30 гравців, підключених одночасно до стійкого сервера. У мене виникли певні труднощі з можливістю гарного виконання прогнозування руху.

Фізика / Рух

Гра не має справжньої фізичної реалізації, але використовує основні принципи для здійснення руху. Замість того, щоб постійно запитувати вхід, зміни стану (тобто / миша вниз / вгору / переміщення) використовуються для зміни стану символьної сутності, якою керує гравець. Напрямок гравця (тобто на північний схід) поєднується з постійною швидкістю і перетворюється на справжній 3D-вектор - швидкість сутності.

У головному циклі гри перед оновленням називається "Оновити". Логіка оновлення викликає "завдання оновлення фізики", яке відстежує всі сутності з ненульовою швидкістю, використовуючи дуже базову інтеграцію для зміни положення сутності. Наприклад: сущность.Position + = суть.Velocity.Scale (ElapsedTime.Seconds) (де "Seconds" - це значення з плаваючою комою, але той самий підхід буде працювати і для цілих значень мілісекунд).

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

Пакет змін і оновлення штату

Коли швидкість сутності символу гравця контролює зміни, на сервер надсилається пакет "переміщення аватара", що містить тип дії сутності (стояти, ходити, бігати), напрям (північний схід) та поточну позицію. Це відрізняється від того, як працюють 3D-ігри від першої особи. У 3D-грі швидкість (напрямок) може змінювати кадр на кадр, коли гравець рухається. Відправлення кожної зміни стану ефективно передасть пакет за кадром, що було б занадто дорого. Натомість, 3D-ігри, здається, ігнорують зміни стану та надсилають пакети "оновлення стану" через фіксований інтервал - скажімо, кожні 80-150 мс.

Оскільки оновлення швидкості та напряму трапляються набагато рідше в моїй грі, я можу втекти, надсилаючи кожну зміну стану. Хоча всі фізичні симуляції відбуваються з однаковою швидкістю і детерміновані, затримка все ще залишається проблемою. З цієї причини я надсилаю звичайні пакети оновлення позицій (подібні до 3D-гри), але набагато рідше - зараз кожні 250 мс, але я підозрюю, що при хорошому передбаченні я можу легко збільшити його до 500 мс. Найбільша проблема полягає в тому, що я зараз відхилився від норми - вся інша документація, путівники та зразки в Інтернеті надсилають звичайні оновлення та інтерполювати між двома державами. Це здається несумісним з моєю архітектурою, і мені потрібно придумати кращий алгоритм прогнозування руху, який ближче до (дуже базової) архітектури "мережевої фізики".

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

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

Прогнозування та компенсація відставання

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

Проблеми

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

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

2. Коли пакет приходить, я намагався інтерполювати позицію пакета зі швидкістю пакета протягом певного періоду часу (скажімо, 200 мс). Потім я приймаю різницю між інтерпольованою позицією та поточною позицією "помилка", щоб обчислити новий вектор, і розміщую його на сутності замість швидкості, що була надіслана. Однак припущення полягає в тому, що інший пакет прийде в цей часовий проміжок, і "неймовірно важко" здогадатися ", коли наступний пакет надійде, тим більше, що всі вони не надходять через фіксований інтервал (тобто / зміни станів). Чи принципово хибна концепція, чи вона правильна, але потребує певних виправлень / коригувань?

3. Що відбувається, коли віддалений плеєр зупиняється? Я можу негайно зупинити сутність, але вона буде розміщена у «неправильному» місці, поки вона не рухатиметься знову. Якщо я оцінюю вектор або намагаюся інтерполювати, у мене виникає проблема, оскільки я не зберігаю попередній стан - фізичний двигун не може сказати "вам потрібно зупинитися після досягнення позиції X". Він просто розуміє швидкість, нічого складнішого. Я неохоче додаю інформацію про стан руху пакетів до сутностей або фізичного двигуна, оскільки це порушує основні принципи проектування та кровоточить мережевий код у решті ігрового двигуна.

4. Що повинно статися, коли суб'єкти стикаються? Існує три сценарії - контрольний гравець зіштовхується локально, два об'єкти стикаються на сервері під час оновлення позиції або віддалене оновлення сутички стикається на локальному клієнті. У всіх випадках я не впевнений, як вчинити зіткнення - окрім обману, обидва стани є "правильними", але в різні періоди часу. У випадку з віддаленою сутністю не має сенсу малювати його, проходячи через стіну, тому я виконую виявлення зіткнень на локальному клієнті і змушую його "зупинитися". Виходячи з пункту №2 вище, я можу обчислити "виправлений вектор", який постійно намагається перемістити об'єкт "крізь стіну", який ніколи не матиме успіху - віддалений аватар застрягає там, поки помилка не стане занадто високою, і вона "забивається" в положення. Як обробляють ігри навколо цього?

Єдине, що потрібно сказати, це те, що 2D, ізометричні, 3D, вони всі однакові, коли мова йде про цю проблему. Оскільки ви бачите багато прикладів 3D, і ви використовуєте лише вхідну систему з обмеженою 2-октантовою швидкістю з миттєвою швидкістю, не означає, що ви можете викинути принципи мережевих зв'язків, що розвивалися протягом останніх 20+ років.

Принципи дизайну прокляті, коли гра порушена!

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

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

Нарешті, навіть якщо ваші вклади обмежені 8 напрямками, фактична зміна може статися в будь-який момент - примусовий цикл в 250 м просто зірве швидких гравців. 30 гравців - це нічого великого для будь-якого сервера. Якщо ви говорите про тисячі ... навіть тоді їх групи розбиті на кілька боксерів, тому окремі сервери несуть лише розумне навантаження.

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

Отже, ваш сервер по суті є "арбітром"? У цьому випадку я вважаю, що все у вашому клієнті має бути детермінованим; вам потрібно переконатися, що все на кожному клієнті завжди дасть однаковий результат.

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

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

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

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

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

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

Першими моїми запитаннями були б: Що не так із використанням моделі, коли сервер має повноваження? Чому не важливо, чи середовище 2D або 3D? Це значно полегшило б ваш захист від читів, якби ваш сервер був авторитетним.

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

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

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

Навіщо потрібно інтерполювати? Авторитетний сервер повинен перекривати будь-які помилкові рухи.

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

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

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