Підсумок для тих, хто не любить довгих відповідей ...
Це можна зробити, але неможливо виконати ідеальну багатокористувацьку фізику, якщо є затримки. Чому затримка впливає на фізику, пояснюється, а потім пропонуються поради щодо зменшення впливу затримок на ваше фізичне моделювання.
Створення багатокористувацької фізичної гри може бути загрожує небезпекою. Неможливо створити "ідеальний" онлайн-досвід багатокористувацької фізики. Ви можете зробити це для того, щоб покращити його, але немає можливості зробити ідеальну фізику з урахуванням затримок.
Проблема полягає в тому, що фізика повинна бути швидкою і чуйною, щоб бути реалістичною, але в той же час повинна бути обчислена на основі комбінованих дій ВСІХ факторів - мається на увазі комбіновані дії всіх гравців. І якщо є затримка, цього не можна зробити в режимі реального часу.
Ви, як розробник, вирішите, чи можете ви тримати під контролем різні фактори, і зрозуміти, що досвід гравця погіршиться, якщо затримка стане занадто високою. Якщо ви можете жити з цим (і ваші гравці можуть), то продовжуйте це робити. Перегляньте наприкінці цієї публікації кілька записок про те, як ви можете продовжувати роботу.
Приклад, щоб показати, як все може зіпсуватись
Уявіть гру, де до гравця підключені два гравці (клієнти). Потрібно 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. Ваша типова гра-шутер зробить щось подібне ...
- Локальний підрахунок, якщо вони потрапили в B, і якщо він схожий на те, що є удар, він відіграє ефект "удару", як кров'яна затяжка. Це робиться на стороні клієнта, щоб гравець відразу побачив реакцію на їх дію. Якщо цього не зробити, гра відчуває себе млявою.
- А також надсилає повідомлення на сервер із записом: "Я стріляв по цьому вектору"
- Коли сервер отримує повідомлення, він переглядає, де ІТ вважає гравців, і вирішує, чи потрапив вектор вистріленого A у B.
- Якщо сервер вирішує удар B, він вирішує B потрапив і надсилає повідомлення клієнтам BOTH із повідомленням про те, що сталося.
- Якщо сервер вирішив, що A НЕ вдарив B, B нормально, а "промахнеться". Це може здатися A, як вони потрапляють ("Я бачив кров!"), Але сервери дзвонять, що вони пропустили.
То як міг A пропустити B, коли це виглядало так, ніби вони їх вдарили? Оскільки B, можливо, перемістився, але A ще цього не бачив, оскільки сервер ще не надіслав клієнту повідомлення "B переїхав сюди".
У Valve на цьому сайті є хороший запис. Дивіться сторінку http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking