Як я можу зробити багатокористувацьку гру однолітків? [зачинено]

Як я можу зробити багатокористувацьку гру p2p? Мені хотілося б мати без серверів багатокористувацьку гру. Але тоді, як усі клієнти знають один одного?

Чому p2p-протокол настільки відомий в передачі файлів, але не в мультиплеєрних іграх?

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

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

Значна кількість ігор використовує однорангові мережі, включаючи більшість стратегічних, спортивних та водійських назв. Майже у всіх іграх Xbox360 та PS3 використовується мережа p2p. Архітектура клієнт-сервер використовується в основному в іграх від першої особи або MMO.

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

Коли ви створюєте двигун p2p, всі клієнти потребують повного стану ігрового світу, і всі вони повинні синхронізуватися.

Для отримання більш детальної інформації про архітектури p2p та клієнт-сервер я пропоную вам прочитати наступну статтю: Що повинен знати кожен програміст про мережеві ігри .

І якщо ви новачок у мережі взагалі, огляньте інші чудові статті на цьому сайті. Гленн - мережевий геній.

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

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

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

Він не відпустив коментар в Інтернеті, тому я цитую його тут:

Пропозиція "рівний-одноранговий" з першого допису насправді є цікавою відправною точкою, хоча часом це трохи наївно: Першою можливістю буде поєднання системи зі стандартною моделлю клієнт / сервер із прогнозуванням, як викладено у вашій публікації про ігрові мережі. Нижній пінг P2P суттєво зменшить відставання передбачень між гравцями залежно від їх розташування: ефект, ймовірно, не буде видно для більшості геймерів у США, але тут у Європі пінг з 200+ є нормальним для більшості серверів, а пряме з'єднання зменшить прогнозування відставання від рівня європейського сервера.

Справжній підхід P2P без сервера є дещо складнішим: Основна проблема, що стосується децентралізованих мереж, - це забезпечення послідовності, особливо якщо моделювання може постраждати від ефектів метелика через дещо різний час виконання команд, що надсилаються по мережі, або проблеми з плаваючою точкою. Це можливо, принаймні періодично встановлюючи мережу стану кожного об'єкта (програвачів, NPC, ...). Навіть не потрібно було б робити це відразу для всіх об'єктів, і кожен клієнт міг заволодіти певними об'єктами. Мережа достатньої кількості об'єктів за певний час повинна зменшити різницю, яка накопичується між кожною синхронізацією об'єкта, достатньою, щоб стати неактуальною навіть для інтервалів синхронізації секунди або більше.

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

[...]

Ви можете знайти тему, на яку я посилаюсь, на веб-сторінці http://www.devmaster.net/forums/showthread.php?t=14640 .

Думаю, хтось згадав про проблеми з брандмауером, які стосуються однорангових програм в одній із ниток статті. Можливим рішенням може бути NAT-Punchthrough:
- NAT Punchthrough Overview
- Peer-to-Peer-комунікація через мережеві адресні перекладачі

Немає 100% успішності, тому ви повинні сказати гравцям відкрити порт.

Хорошим прикладом ігрового процесу «справжній рівному» є стратегічна гра в реальному часі, така як Starcraft.

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

Коли один гравець виконує дію, команда / наказ («перемістити zergling до X, Y») може бути надіслана всім іншим гравцям, які будуть виконані всіма екземплярами симуляції на частку секунди пізніше.

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

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

Трохи нечесно стверджувати, що він не відомий іграми, коли його використовують більшість ігор стратегії в реальному часі (серії "Зоряні ремесла", "Команди та перемоги") та багатьох ігор FPS (Call of Duty: Modern Warfare 2).

Це говорить про те, як ви дізнаєтесь про гру, залежить від сервісу, який ви використовуєте або створюєте. Але навіть як тільки хтось дізнається про гру, все одно може бути один або більше однолітків, рівних за інших. Розглянемо випадок із 3-ма клієнтами, які бажають грати, одного за відкритим натом, 2 - за суворими (закритими) натами. Відкритий натрівник може приймати з'єднання з інших двох. Але 2 суворі не можуть підключитися безпосередньо один до одного, вони вимагатимуть відкритого нату для ретрансляції пакетів. Якщо відкритий nat peer впаде з гри, знадобиться знайти або іншу естафету, або гра буде порушена.

Ви також можете перевірити Badumna (www.badumna.com), який вважає себе одноранговим мережевим рішенням для онлайн-ігор. Здається, синхронізацію стану ігор здійснюють розподіленим способом, і відповідно до їх веб-сайту є версія Flash.

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

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

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

Мене трохи цікавить ця справа. Ви говорите, що існує багато проблем із створенням гри p2p замість класичної моделі клієнт-сервер. Але я впевнений, що p2p схожий на клієнт-сервер, але кожен аналог має шанс стати сервером. Щодо LAG, якщо ви додаєте ще одну машину як сервер, є більше ймовірностей, що багато клієнтів віддаляються від сервера, але використовуючи p2p, у лобі немає додаткових машин. Ви можете керувати тестами затримки та створювати групи з мінімальним ping. Щодо генеруючого трафіку, як я дізнався, ви повинні попросити клієнтів передавати менше, ніж я маю на увазі, що клієнти повинні зрозуміти, що всі інші клієнти готові мати на увазі.

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