Найкраще рішення для багатокористувацької гри в режимі реального часу для Android [закрито]


11

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

  1. Зробіть сервер на ПК та клієнт на мобільному телефоні, усі комунікації проходять через сервер (ClientA -> PC SERVER -> Усі клієнти)

  2. Використовуйте Bluetooth, я ще не користувався, і не знаю, чи важко зробити мультиплеєр на Bluetooth

  3. Зробіть сервер на одному з пристроїв, а інші пристрої підключаються (через мережу, але я не знаю, чи важко вирішити проблему з пристроями через NAT?)

  4. Інше рішення?


3
Чи плануєте ви, що це гра лише для місцевих дій або ви хочете, щоб люди могли грати з людьми через Інтернет? Ви хостите машини для ігор?
Тетрад

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

Відповіді:


2

Відмова від відповідальності; Я не робив багато з Java і андроїд платформи.

Однак мій більш великий досвід роботи з мовами ".net" на платформах для мобільних пристроїв Windows, поряд з платформою Windows, полягає в тому, що хороші 75-90% всього коду, необхідного для створення та підтримки з'єднання Bluetooth або мережі, підтримуються / підтримується з ОС або бібліотеками, які потребують доступу до обладнання.

Наразі це також справедливо для Android, з ОС, що відкриває способи створення з'єднань даних через Bluetooth або Інтернет, а також включення / відключення відповідного обладнання.

Я б міг уявити, що Bluetooth є кращим способом з'єднання, оскільки це буде найменш дорого реалізованим (Без серверів). І дозволити більш локальне зібрання / гру. Bluetooth досить простий у використанні. він працює аналогічно звичайним мережевим розеткам, коли ви дізнаєтеся, до якого пристрою потрібно підключитися.

Інші вірні в тому, що Bluetooth v2.0 / v2.1 наразі не здатний підтримувати великі навантаження даних. Це зміниться з можливим поширенням версії 3.0 і вище. і існують способи подолати це обмеження.

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

КОН: Кожен гравець насправді грав би свій власний дещо унікальний екземпляр гри, який би був пов’язаний з іншими гравцями, щоб ігра не відходила занадто далеко від синхронізації один з одним.

КОН: Підтримка коду може бути обширною / складною і складно обернути голову залежно від того, чого ви хочете досягти.

PRO: Не потрібен центральний сервер чи пристрій! Не потрібно зберігати $$$.

PRO: Інтенсивний обмін даними відбуватиметься лише тоді, коли гравець (повторно) приєднався або гра була ініціалізована. - Навіть це можна зменшити, гарантуючи, що всі ігри будуть генеруватися, і просуватися однаково всіма гравцями. ПОТЕНЦІАЛЬНО зменшує споживання енергії, що виникає через велике використання мережі.

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

Мені не вистачало часу на впровадження повноцінного ігрового двигуна, який використовує це. Ігри, які я створив, були обмежені відтворенням ігор, схожих на Monopoly та Uno, які, здається, функціонують надзвичайно добре.

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

Я почав будувати гру, схожу на Master of Orion II, але сама гра була трохи для мене самою.


9

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

Сервер на базі комп'ютера

Плюси

  • Перепробував і правдиво
  • Масштабований

Мінуси

  • Потрібно написати "мультисервер", який може приймати кілька ігор одночасно. Це, ймовірно, використовувати трохи іншу технологію, ніж ваш телефон Android. Ви все ще можете використовувати Java, але чи можете ви все-таки використовувати пакети Android?
  • Запускати та обслуговувати можна дорого
  • Ви могли потенційно зняти це в один день з правдивих причин. Вболівальники можуть не раді, якщо сервер вийде з ладу лише через пару місяців після придбання гри.

Peer To Peer з одним з них на контролі

Плюси

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

Мінуси

  • Потрібно написати простий централізований пошук однолітків. (Я зробив моє в php + mysql в пару сотень простих рядків)
  • Сервери працюють на телефонах. Телефони можуть бути повільними. Чи зможуть усі цільові телефони приймати гру?
  • Що станеться, якщо телефон сервера відключається?
  • Хакерам простіше, ніж клієнт-сервер, потрапити

Що стосується Bluetooth, я б очікував, що він буде подібний до методу «однолітків». Я також не думаю, що у вас не повинно виникнути проблем з NAT.

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


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

4

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

Зважаючи на це, розумійте, що вам слід мінімізувати вплив відключеного користувача. У другому варіанті ви по суті зробили телефон на сервері. Якщо цей телефон перейде в МВС, гра фактично закінчена для всіх гравців.

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

Ви також можете розглянути техніку за моделями моделювання блокування-крок. Це може бути реалізовано суто одноранговим способом. Загальна ідея полягає в тому, що кожен клієнт повинен надсилати своє оновлення (серія команд або їх відсутність) кожен крок моделювання. На наступному етапі моделювання команди кожного гравця застосовуються до логіки гри. У багатьох іграх RTS використовується така схема мереж.

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

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

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