Як синхронізувати такі дії, як стрибок у мультиплеєрі?


11

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

Припустимо, клієнт A рухався, він знаходився на 100 м в 10,2 разу зі швидкістю 100 м / сек і надсилав цю інформацію. Клієнт B отримає цю інформацію дещо пізніше, нехай це буде 10.4. Тож у клієнта B я можу використовувати передбачення та розміщувати клієнта A на 120м. Але що робити, клієнт зробив стрибок на 110 м на 10.3. Я не можу цього передбачити, і оскільки я використовую передбачення, я не можу показати клієнту стрибок у минуле.

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

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


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

@Christian hey! Дякую за відповідь. Я знаю про такий підхід, але це може зробити геймплей хитким, якщо затримка висока, і до того ж я використовую систему BaaS в реальному часі AppWarp, тому вся моя логіка лежить лише на стороні клієнта.
Суяш Мохан

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

Нещодавно я знайшов цю серію підручників, щоб дати хороші поради щодо керування затримкою, схоже, це було б відносно до ваших інтересів: посилання
Kris Welsh

Відповіді:


8

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


4
Я використовував такий підхід, коли писав свою першу мережеву гру для багатьох гравців. Насправді я використовував @ ggambett's в якості посилання. Це добре спрацювало для мене.
NoobsArePeople2

1

Існує досить детальне записування щодо двигуна-джерела. Можливо, деякі відповідні вихідні коди також доступні як частина вихідного SDK.

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

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

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