Що бере участь у створенні в режимі реального часу багатокористувацької платформерної гри?

Я створюю платформерну гру, яка має функцію "кооперативу", яку я хотів би працювати над мережами / Інтернетом.

Тепер я прочитав про мережеве ігрове програмування, включаючи такі статті, як те, що повинен знати кожен програміст про мережеві ігри, і тому я розумію різницю між такими методами, як "Peer-to-Peer" і "Архітектура прогнозування сервера-клієнта":

Я зробив висновок, що для будь-якої гри в реальному часі, яка буде грати через Інтернет, Peer-to-Peer lockstep просто не є можливим.
Я також стурбований тим, що навіть для платформера проста архітектура клієнт-сервер (без якогось прогнозування клієнта) призведе до деградованого ігрового процесу через затримку між дією та реакцією, спричинену круговою поїздкою на сервер. (Сказавши, що я хочу усунути потребу в центральному сервері, і тому лише один з гравців, клієнт, насправді відчує це відставання).

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

Як би я пішов про створення робочої системи передбачення клієнта для багатокористувацької платформерної гри?

networking multiplayer platformer

— Джастін
джерело

Одне, про що вам доведеться набагато менше турбуватися в кооперативній грі; це обман;)

— Джонатан Коннелл

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

— TravisG

-1, "Скільки роботи" є суб'єктивним.

— Тетрад

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

— Нейт

@Tetrad Вибачте - я дуже намагався зробити це питання максимально об'єктивним, але моє запитання зводиться до "чи важко створити працюючу систему прогнозування клієнтів для гри типу Y" - якщо ні, то я навчусь, як я йди, але мій час обмежений, тому навчання, що занадто багато роботи після X днів гри, занадто пізно. Я б спробував надати більш детальну інформацію про Y, але я не хочу ставити питання "занадто локалізованим". Основна проблема тут - це рух, який є загальним для всіх платформерів (я хочу, щоб інші вважали це питання корисним). Якщо я можу вдосконалити це питання, то оцінюються пропозиції.

— Джастін

Відповіді:

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

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

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

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

— Нейт
джерело

Це приблизно так само просто, як і клієнтський серверний підхід (за винятком того, що один клієнт розміщує сервер -> вам не потрібен спеціалізований сервер, але вам доведеться пройти що-небудь рядок UDP + NAT Punchthrough, який так чи інакше потребує виділеного сервера). По-друге, ви пропонуєте метод блокування кроку (як ви говорите про надсилання повних ігор), це не IMHO, найкращий метод, якщо гра працює через Інтернет (мабуть, через локальну мережу), де клієнт-сервер набагато простіше впровадити.

— Валмонд

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

— Нейт

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

Нечітка відповідь нечітка відповідь ;-)

— Валмонд
джерело

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

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

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

— Адам
джерело