Мережевий клон понга

У мене є основи TCP-розеток, UDP-комунікації тощо, але я не можу знайти багато того, як застосувати їх до ігрового середовища в реальному часі.

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

Це НАЙБІТЕ, що потрібно розсипати величезну кількість трафіку UDP? Чи варто розглянути щось на кшталт DCCP за його перевантаженими функціями? Або це насправді не проблема з таким масштабним проектом?

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

Чи було б краще змусити клієнтів повідомляти свої позиції весла між собою одноранговими?

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

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

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

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

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

Що стосується проблем з трафіком - ви хочете уникати надсилання більше 20-30 пакетів за секунду за однолітків. У загальному випадку, якщо ви надішлете менші, менші пакети, ви відчуєте (трохи) меншу затримку та менший шанс скинутих пакетів.

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

Це досить широке питання, але я спробую узагальнити важливі аспекти.

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

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

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

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

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

Ви дбаєте про обман?

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

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

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

Google мертвий розрахунок. Надсилання оновлень для 4 гравців не буде суттєвим. Кількість надісланих даних буде в порядку байтів. Отже, це означає, що часте оновлення повинно бути нормальним. З мертвим рахунком ви переміщуєте програвач на клієнті та сервері. Сервер є авторитетом. Коли позиція клієнтів стає занадто далеко від синхронізації з сервером, вона повинна повернутися назад у вирівнювання. http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking Використання UDP - це шлях. Буддати будуть надсилатися часто, що втрачені дані незабаром будуть замінені вхідними даними. Повторна передача пакетів TCP не потрібна для позиції гравця. Подивіться у цій статті для отримання додаткової інформації про те, як підтримувати клієнт та сервер синхронізовано.

Я декілька тижнів тому запрограмував гру-понг на 2 гравця-локальна мережа, ось як я це зробив:

-Одна сторона відкриває сервер, інша підключається автоматично-обидва вони спамують свої лопатки x положення один до одного @ 60 кадрів в секунду або менше [UDP] -Якщо одна сторона вдарить по м'ячу, вони вирішать про кулю нову швидкість і положення і надішлють це до другого [TCP] - якщо м'яч пролітає повз весла, гравець, який пропустив його, контактує з іншим із повідомленням про збільшення балу, і м'яч скидається [TCP] - м'яч постійно моделюється незалежно, що підходить для простої фізики м'яча понга

Це створює приблизно 0,3 до 0,5 Кбайт / с трафіку зі швидкістю 60 кадрів в секунду, і гравці не затримуються у своєму сприйнятті, але лише у тому випадку, якщо пінг знаходиться нижче певного порогу, оскільки нову позицію м'ячів потрібно передати.

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