Реалізація для кількох гравців. Чи можу я реалізувати її пізніше, якщо я захочу?


15

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

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

Відповіді:


24

Ось обґрунтовані поради, взяті з посібника з мережевої бібліотеки Zoidcom :

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

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

Це означає, що навіть в одиночній грі на задньому плані працює невидимий сервер. Багатокористувацьку версію тієї самої гри потрібно просто підключити до віддаленого сервера замість локального "one et voila", багатокористувацького. Перевагами цього є:

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

Проекти, що використовують цю схему - це майже всі ігри, що використовують будь-який з двигунів Quake, Civilization 4, Neverwinter Nights та багато інших.

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


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

8
@AttackingHobo: Ви просто описуєте передбачення клієнта. Ви можете мати передбачення клієнта та повноваження сервера разом, і це зовсім не виключає архітектуру, описану в посібнику Zoidcom.

@AttackingHobo @Joe: І Zoidcom насправді підтримує прогнозування на стороні клієнта ^^
Leftium

2

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

Перший раз, коли я спробував зробити багатокористувацьку гру (я навіть не намагався зробити одиночну гру!), Я зрозумів, що спершу я зроблю роботу, а потім додаю мережу. Погана ідея. Мені залишився прототип по-справжньому нудної гри для одиночного гравця, і я не маю підказки, як перетворити це на багатокористувацьку гру. Я цілком виграв його і почав заново, на цей раз писав багатокористувацький мережевий код з самого початку. Все клацнуло.

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.