Skip to content

Latest commit

 

History

History
94 lines (71 loc) · 11.8 KB

assignment_4.md

File metadata and controls

94 lines (71 loc) · 11.8 KB
Практична робота №4

Створення мережевої клієнт-серверної гри

Ціль роботи

Розібратися із принципами побудови онлайн-ігор: на великих картах, кімнатах або ж у покроковому режимі.

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

Варіант А. .io-like massive multiplayer (13-16 балів)

Завдання

Гра, що пропонується до реалізації - спрощена версія agar.io.

  1. Клієнт, під'єднавшись до сервера, потрапляє у кімнату великого розміру (без перешкод) разом із іншими гравцями.
  2. Гра відбувається у двомірній площині, кожен гравець відображається колом певного кольору.
  3. Гравець може пересуватися по площині в будь-якому напрямку
  4. По карті випадковим чином розкидані крапки-"їжа", підібравши яку гравець збільшується у розмірі
  5. При зіткненні двох гравців виживає більший, який збільшується в розмірі пропорційно до розміру другого гравця
  6. Гра складається з раундів, що йдуть безперервно один за одним, в кінці раунду на екран виводиться топ гравців за ромзіром, після чого всі активні гравці скидаються до найменшого розміру
  7. В оригінільному agar.io важливою складовою механіки є "виприскування" половини своє маси вперед з більшою швидкістю, з ціллю захопити іншого (меншого) гравця. В рамках завдання це реалізовувати необов'язково, але можна за додатковий бал до завдання
  8. На сервері має бути реалізована система відстежування позиції гравця що дозволяє надсилати йому координати тільки тих точок їжі та противників, що потрапляють в його поле зору
  9. За 2 додаткових бали можна реалізувати протокол спілкування клієнта з сервером по аналогії з наступним варіантом - UDP + бінарна серіалізація.

Деталі

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

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

reversi field

Після переміщення гравця в квадрат В3 з С3, гравець перестане отримувати апдейти з квадратів D2\D3\D4, але почне з A2\A3\A4

При виконанні завдання слід реалізувати подібну систему поділу поля, просто фільтрувати всіх гравців перед відправкою на клієнт не допускається (оскільки це рішення не може бути масштабованим)

Оцінювання:

  • Якість коду - 5 балів
  • Повноцінний гейм-луп з раундами - 4 бали
  • Топ-гравців в кіні раунду - 1 бал
  • Корректно реалізована система оповіщеня гравців про події навколо них - 3 бали
  • Додатковий функціонал - 3 бали

Варіант Б. Room-based multiplayer (12-14 балів)

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

Завдання

Гра - клієнт-серверний 2D-шутер з видом зверху з обмеженням до 4-х гравців в одній кімнаті

  1. Після приєднання до серверу та набору необхідної кількості гравців (2-4), всі гравці стартують на карті в визначених місцях. Графіка не грає ролі - можна використовувати для позначення гравців кружечки з позначкою поточного повороту
  2. Гравці можуть рухатися у всіх напрямках та повертатись
  3. Гравці мають однакову кількість здоров'я на початку раунду
  4. Гравці можуть стріляти кулями в напрямку погляду, куля має певну швидкість та знімає частину здоров'я при ураженні іншого гравця
  5. (Додатково, +2 бали) На полі періодично рандомно з'являються: аптечки, бусти для швидкості гравця та куль, бусти для урону куль.
  6. Раунд закінчується коли в живих лишається один гравець
  7. Протокол спілкування клієнта з сервером під час раунду має бути побудованим на UDP та бінарним (можна викорситовувати готові рішення типу Protocol Buffers, або написати самостійно)

Оцінювання:

  • Якість коду - 4 бали
  • Повноцінний гейм-луп - 4 бали
  • Корректно реалізований бінарний протокол над UDP - 3 бали
  • Додатковий функціонал - 2 бали

Варіант В. Покрокова PvP гра зі спілкуванням через сервер (6-10 балів)

Найпростіший варіант мережевої взаємодії відбувається в покрокових іграх (шашки, шахи, класичні карткові ігри типу покера, колекційні карткові ігри типу Hearthstone, стратегії типу Цивілізації і так далі). В такому випадку зазвичай логіка гри повністю розміщується на сервері, а клієнти стають дуже тонкими - вони вміють відображати стан гри графічно, зчитувати інпут користувача та за допомогою певного протоколу надсилати дані про хід гравця на сервер, де відбувається валідація ходу, зміна ігрового стану та розсилка всім клієнтам повідомлень про ці зміни. Через неінтенсивнний трафік в такому варианті можуть використовуватись як кастомні протоколи на TCP\UDP ак і звичайний HTTP. Логіка гри може бути як повністю зосереджена на сервері так і дублюватися на клієнті (наприклад, для валідації ходу)

Завдання

  1. Обрати покрокову гру зі списку:
  • Quoridor - найпростіший варіант, бо логіка гри у вас вже реалізована (2 бали);
  • "Дурень" (4 бали);
  • Нарди, будь-яка варіація гри (4 бали);
  • Шахи Фішера (5 балів);
  1. Реалізувати клієнт для цієї гри - як і в першій роботі, віузальна частина не принципова, це може бути як повноцінний графічний клієнт, так і ASCII-арт у командному рядку;
  2. Реалізувати сервер, який будеи відповідальним за з'єднання гравців та ігрову логіку;
  3. Процес має відбуватися наступним чином - клієнт при старті під'єднується до сервера та стає в чергу на очікування. Якщо в черзі вже хтось є, то ці гравці починають гру;
  4. Кожен хід має проходити через сервер, протокол спілкування можна обрати на власний вибір (бінарний + UDP - додатковий бал);
  5. По закінченні гри, клієнт може обрати - завершити виконання або ще раз стати в чергу.

Оцінювання:

  • Якість коду - 2 балів
  • Складність гри - 2-5 балів
  • Реалізація мережевої взаємодії - 2 бали
  • Додатковий функціонал - 1 бал

Матеріали: