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

Я роблю просту маленьку MOBA просто для розваги. Я все робив для одного гравця, тоді зрозумів, "о, лайно, мабуть, слід додати мультиплеєр, так".

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

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

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

Так в основному:

• Гравець 1 кидає заклинання, щоб змусити його рухатися на 100% швидше протягом шести секунд
• Місцевий клієнт програвача 1 додає цей буф до свого об'єкта Unit
• Клієнт гравця 1 надсилає на сервер повідомлення з повідомленням: "Ей, я просто кинув цю заклинання"
• Сервер переконується, що він справді мав достатньо мани, щоб кинути це заклинання, і якщо так, додає цей баф до копії сервера цього об’єкта Unit
• Сервер надсилає повідомлення всім іншим клієнтам, в яких говориться: "Ей, цей хлопець просто кинув цю заклинання"
• Кожен інший клієнт отримує повідомлення та переходить "добре добре", і додає цей баф до свого локального об'єкта для цього гравця

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

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

Окрім відповіді Byte56, слід розглянути ще кілька речей:

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

Другим питанням, яке підключається до попередніх, є те, що UDP не має гарантованої доставки. Ви не можете бути впевнені, що кожне надіслане вами повідомлення надходить або навіть надходить у потрібному порядку. Ви можете надіслати пакети 1, 2 і 3, а сервер отримує 3, то 1, а не 2. Часто вони будуть в правильному порядку, і часто вони прийдуть, але не завжди. Отже, вам потрібна система, яка є надійною для втрати пакетів. Досить простої системи підтвердження. Зазвичай використовується бітове поле, яке повідомляє інший вузол, отримав він останні 32 повідомлення (для 32-бітового int), і яке було останнє повідомлення. Таким чином, ви можете позначати повідомлення як критичні чи ні та повторно надсилати, якщо вони не отримують критичних. Тут є досить пристойне обговорення .

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

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

Для отримання додаткових ідей я рекомендую переглянути інші статті у цьому другому посиланні.

Удачі!

Те, що ви описуєте, по суті прогнозування на стороні клієнта , але ви не говорите про те, що відбувається, коли сервер і клієнт не згодні.

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

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

Хронометраж. В інших відповідях не згадуються терміни подій на сервері та різних клієнтів. Залежно від гри, це може бути на що слід дивитися. Затримка (aka Lag) вводить змінну затримку між тим, коли пакет надсилається, і коли він отримується. Час може бути складним, але я спробую якнайкраще пояснити потенційні проблеми. Є кілька ігор, які можна обійти, не переживаючи про це, але ось простий приклад того, де це може спричинити проблеми.

Припустимо, що всі діють на пакети, як тільки приїжджають.

@ Time 0 (wall time), Player 1 puts up a shield   (Message has been sent, but not received by anyone)
@ Time 1, Player 2 shoots player 1   (Message has been sent, but not received by anyone)

Припустимо, що час 0 (T0) і T1 близькі між собою.

Що буде далі, залежить від того, хто на це дивиться, і від порядку, в якому пакети надходять на сервер. Сервер завжди повинен мати остаточне слово. Якщо сервер отримує пакети у вказаному вище порядку, то сервер застосує щит до того, як постріл і програвач 1 (P1) виживе. З точки зору Р1, поставивши сам щит, він побачить щит перед пострілом і виживе. Але що з P2? Вони побачать постріл одразу, тому що вони вистрілили його, але чи побачать щит першими? Якщо (T0 + latency between P1 and the server + the latency between the server and P2) > T1щит підніметься після пострілу, і P2 подумає, що їх постріл убив P1. Серверу доведеться якось виправити цю ситуацію.

Якщо сервер отримує пакети у зворотному порядку (що цілком можливо, навіть якщо T0 <T1), то відбувається навпаки. Р1 неправильний (і мертвий), а Р2 - правильний (і переможець).

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

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

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