Розробка чатів та соціальних модулів ігор під ключ

Ми розробляємо мультиплеєрні чати та соціальні модулі, які не ламаються під навантаженням і не створюють race condition з ігровою логікою. З нашим 7-річним досвідом у геймдеві та 30+ реалізованими проєктами ми знаємо, як побудувати real-time шар, який витримує пікові онлайни без деградації RTT.

Чому чат на одному каналі — погана ідея?

Найчастіша помилка — використовувати один транспортний канал для ігрових подій і повідомлень чату. У Photon Realtime кожен канал має FIFO-гарантію всередині себе, але не між каналами. Якщо ігрові RaiseEvent з кодами руху гравця та текстові повідомлення йдуть через channel 0, при сплеску активності в чаті затримка позицій зростає до 200–300 мс навіть при хорошому пінгу. Рішення: виділити окремий unreliable-канал для чату з низьким пріоритетом та reliable-канал для системних повідомлень (kick, ban, invite).

Що входить у роботу?

• Архітектурна документація (схема даних, канали, пріоритети)
• Інтеграція Photon Chat або кастомного сервера
• Реалізація історії повідомлень, пагінації, TTL-очищення
• Модерація (ML-фільтр, rate limiting, mute/ban)
• Соціальний граф (друзі, гільдії, запрошення)
• Пуш-сповіщення (FCM, WNS) через асинхронну чергу
• Навантажувальне тестування з ботами на headless Unity
• Вихідний код, README, міграції, навчання команди

Де зазвичай ламається перша реалізація

Друга проблема — зберігання історії. Багато команд зберігають історію чату прямо в кімнаті Photon через CustomRoomProperties, що працює доти, доки не перевищується ліміт 1 КБ на властивість. Після цього повідомлення просто втрачаються без помилки на клієнті. Правильний підхід: виносити історію на окремий мікросервіс з PostgreSQL або Redis Streams, а в кімнаті тримати лише покажчик на останній прочитаний offset.

Третя біль — модерація в реальному часі. Наївна фільтрація через RegExp на клієнті обходиться за секунди. Серверна валідація через webhook у Photon WebHooks v2 додає latency до кожного повідомлення. Робочий компроміс: асинхронна постмодерація з миттєвим показом повідомлення відправнику та затриманою доставкою іншим через буфер 50–100 мс, за які встигає відпрацювати ML-фільтр.

Як вибирати між Photon Chat і кастомним сервером?

Якщо ваш проєкт — mid-core з гільдіями, кастомними ролями та модерацією, кастомний сервер окупається за рахунок контролю. Для простих казуальних ігор з одним чатом достатньо Photon Chat.

Як будуємо соціальний шар поверх ігрової сесії

Чат — це видима частина. Під ним зазвичай потрібні: список друзів, інвайти, система гільдій/кланів, статуси онлайн/офлайн, сповіщення. Photon надає Photon Chat як окремий SDK з власними серверами — він вирішує базові завдання (публічні канали, приватні повідомлення), але не вміє в кастомні ролі та права доступу. Для ігор з гільдіями це обмеження критичне.

Типова архітектура, яку використовуємо для mid-core проєктів: Photon Chat для real-time delivery + власний REST API на Laravel/Node для управління структурами (гільдії, ролі, mute/ban), PostgreSQL для персистентності, Redis Pub/Sub для broadcast подій між інстансами API. Unity-клієнт підписується на Photon Chat channel за ID гільдії, а метадані (назва, аватар, учасники) підтягує через REST при вході в лобі.

На одному з проєктів — мобільна battle royale на 100 гравців — ми зіткнулися з тим, що при одночасному вході 80+ гравців у матч-лобі Photon Chat видавав spike підключень, який валив регіон EU-West приблизно раз на тиждень. Виправили через exponential backoff на клієнті (від 500 мс до 8 с, jitter ±200 мс) та lazy subscription: канал команди підключається тільки після підтвердження складу, а не в момент JoinRoom. Знизили навантаження на реєстрацію на 40%.

Які інструменти використовуємо?

Для Unity-проєктів основний стек: Photon Chat SDK, Photon Realtime для ігрових подій, Mirror Networking або Netcode for GameObjects як альтернативи для p2p-схем. Серверна частина чату — Photon WebHooks v2 для хуків на події + кастомний мікросервіс для бізнес-логіки. Докладніше про Photon Chat можна дізнатися в офіційній документації.

Для кроссплатформенних проєктів (PC + Mobile + Console) важлива підтримка OpenID Connect для єдиної авторизації. Соціальний граф (друзі, блокування) зазвичай реалізуємо через окрему таблицю з self-referencing FK та індексом на (user_id, friend_id, status) — без нього запит «чи є хтось із моїх друзів онлайн» при списку 500+ осіб дає full scan.

Пуш-сповіщення про повідомлення поза грою: Firebase Cloud Messaging для Android/iOS, WNS для Windows. Інтеграція через чергу — щоб піковий трафік сповіщень не блокував основний API.

Етапи роботи над модулем

Спочатку розбираємо ТЗ: типи каналів, максимальний онлайн, вимоги до історії, чи потрібна модерація, платформи. На цьому етапі з'ясовуємо, чи достатньо Photon Chat з коробки або потрібен кастомний бекенд.

Потім проєктуємо схему даних: таблиці chat_rooms, chat_messages, chat_members, індекси, політика TTL для старих повідомлень. Паралельно — архітектура real-time шару.

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

Навантажувальне тестування — окремий етап. Симулюємо піковий онлайн через Photon Load Balancer + власні боти на headless Unity instance.

Вартість розраховується індивідуально після аналізу вимог та поточної архітектури проєкту. Готові обговорити ваш проєкт? Зв'яжіться з нами — оцінимо терміни та вартість розробки чату під ключ.

Типові помилки при самостійній реалізації

Зберігати user_id відправника тільки на клієнті — сервер повинен підтверджувати ідентичність через токен, інакше будь-який пакет можна підмінити. Не реалізовувати rate limiting на рівні сервера — 10 повідомлень за секунду від одного клієнта кладуть канал. Використовувати синхронний запит до БД на кожне вхідне повідомлення замість батчингу — при 1000 повідомлень/с це 1000 INSERT/с, що вбиває Postgres без connection pool та bulk insert. Забувати про ON DELETE CASCADE в таблицях учасників при видаленні кімнати — залишає orphaned records, які потім знаходять тільки при аудиті.

Замовте розробку чату — отримайте готове рішення з документацією та підтримкою. Ми гарантуємо стабільність під навантаженням і прозорий процес.

Мультиплеєр та мережева архітектура

Ми бачили десятки проєктів, які застрягали на півроку, коли справа доходила до розробки мультиплеєра. Ви збудували гру для одного гравця, білд стабільний, і раптом приходить завдання — додати мережеву гру. Саме тут більшість команд серйозно недооцінюють обсяг робіт. Мультиплеєр — це не «додати синхронізацію», це переосмислення ігрової логіки, вибір мережевої архітектури та побудова серверної інфраструктури з нуля. Наш досвід — понад 8 років на ринку, 40+ релізів для PC, консолей і мобілок — каже: помилка в архітектурі на старті коштує втричі більше, ніж виправлення на етапі прототипу.

Як обрати архітектуру мультиплеєра для вашої гри?

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

Relay-архітектура (P2P з ретрансляцією)

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

Коли це доречно:

• Кооперативні ігри з низьким рівнем конкуренції (спільне проходження, стратегії в реальному часі з малою кількістю гравців)
• Прототипи та ранні версії
• Маленькі студії без серверної експертизи

Конкретні інструменти:

• Photon Relay — найпопулярніший вибір для Unity. Швидкий старт, готові SDK, зрозуміла тарифікація на основі CCU.
• Unity Gaming Services Relay — вбудований в екосистему UGS, працює разом із Lobby та Netcode for GameObjects.

Проблема: читерство. Якщо клієнт є джерелом істини, він може відправляти будь-які дані. Для конкурентних жанрів (шутери, файтинги, спортивні симулятори) relay-архітектура неприйнятна.

Авторитетний сервер

Вся ігрова логіка виконується на сервері. Клієнти відправляють тільки введення (натискання кнопок, напрямок руху); сервер обчислює фізику, колізії, шкоду — і розсилає результати клієнтам. Це стандарт для будь-якого конкурентного жанру. Авторитетний сервер зменшує кількість читерів на 95% порівняно з relay.

Стек для Unity:

Стек для Unreal: вбудована мережева система на основі авторитетного сервера. Dedicated Server, репліка акторів, RPC — все це частина движка. Для більшості жанрів достатньо нативних інструментів.

Чому компенсація затримки критична для шутерів?

Це найбільш технічно цікавий аспект мережевого коду в конкурентних іграх. Розберімо детально — саме тут більшість команд робить критичні помилки, які роблять шутери та файтинги «неправильними на відчуття».

Проблема

Гравець бачить ворога і натискає кнопку пострілу. Між моментом натиснення та моментом, коли сервер отримує пакет, проходить час — RTT/2 (половина круглої затримки). За цей час ворог міг змінити положення. Якщо сервер перевіряє влучання по поточному положенню ворога замість того, яке бачив стрілець — гравець відчуває «кулі не влучають».

Клієнтське передбачення (Client-Side Prediction)

Клієнт не чекає на підтвердження від сервера. Він одразу застосовує свої дії локально — рух, анімації, звуки. Коли приходить відповідь сервера, клієнт порівнює свій стан із серверним. Якщо вони збігаються — все добре. Якщо ні, відбувається узгодження: клієнт повертається до серверного стану і «переграє» всі непідтверджені введення.

Це вимагає зберігання історії введення на клієнті та швидкого перерахунку стану. У NGO це реалізується вручну через NetworkBehaviour з користувацькою логікою передбачення. Mirror пропонує NetworkTransformReliable з базовим вбудованим передбаченням.

Серверна перемотка (Server-Side Rewind)

Коли сервер отримує команду «постріл» від клієнта A, він бере мітку часу з пакета та «перемотує» світовий стан — назад до того моменту, який бачив клієнт A. Перевіряє влучання в цьому «старому» положенні ворога. Якщо влучив — влучання зараховується.

Реалізація вимагає:

• Зберігання історії станів (положень усіх об’єктів) протягом останніх 200–500 мс (виходячи з максимально допустимого пінгу)
• Ефективної інтерполяції станів за міткою часу
• Обмеження глибини перемотки, щоб не давати переваги гравцям із дуже високим пінгом

Без цього механізму в шутерах гравці з пінгом 100+ мс постійно «промахуються» по ворогах. З ним гра відчувається справедливою для всіх.

Інтерполяція vs. екстраполяція на клієнті

Віддалені об’єкти (вороги) клієнт не передбачає — він їх інтерполює між двома найновішими відомими станами. Це створює невелике відставання на екрані (зазвичай 1–3 мережевих тики), але рух виглядає плавним. Екстраполяція (передбачення руху ворога) дає менше зорової затримки, але при зміні напрямку створює різкі «стрибки». Ми рекомендуємо інтерполяцію для більшості жанрів.

Серверна інфраструктура

Матчмейкинг та лобі

• Nakama — включає матчмейкинг з коробки, напишіть користувацькі правила підбору в TypeScript/Go.
• PlayFab (Microsoft) — повнофункціональний ігровий бекенд. Матчмейкинг, інвентар, хмарні збереження, аналітика. Добре інтегрується з Azure.
• Unity Gaming Services Lobby — простий, але достатній для більшості інді-проєктів.

Виділені сервери

Авторитетний мультиплеєр вимагає виділених серверів. Варіанти розміщення:

Транспортний протокол

• UDP — стандарт для ігор у реальному часі. Низька затримка, можливі втрати пакетів. Більшість ігрових движків та бібліотек працюють поверх UDP з користувацькою логікою надійності.
• WebSocket — необхідний, якщо цільова платформа WebGL. Працює через TCP, що дає трохи більшу затримку, але прийнятно для казуальних жанрів. Photon та Mirror підтримують WebSocket-транспорт.
• KCP — UDP-протокол з елементами надійності. Використовується в Mirror як компроміс між швидкістю та надійністю.

Соціальні функції

Мультиплеєр — це не лише технічна синхронізація. Гравцям потрібні інструменти для взаємодії.

Типові функції:

• Друзі та запрошення — через API платформ (Steam Friends, Game Center, Google Play Games) або користувацький сервіс у Nakama/PlayFab
• Голосовий чат — Vivox (стандарт для ПК/консолей, інтеграція через Unity Gaming Services), Agora (крос-платформа включно з мобайлом)
• Текстовий чат — важливо модерувати контент. Готові рішення: PlayFab Chat, користувацький WebSocket-канал з модерацією
• Лідерборди — Nakama, PlayFab, GameSparks. Важливо розділяти глобальні та лідерборди на основі друзів
• Система кланів — нестандартна функція, вимагає окремої розробки. Для більшості проєктів достатньо групування в Nakama

Автентифікація

Ніколи не придумуйте власну систему авторизації. Використовуйте встановлені провайдери:

• PlayFab — підтримує анонімний вхід, Steam, Google, Apple, користувацький ID
• Nakama — аналогічно, плюс email/пароль з коробки
• Firebase Auth — добре підходить для мобільних ігор, глибока інтеграція з Firebase Analytics та Remote Config

Для конкурентних ігор захист облікових записів критичний: двофакторна автентифікація, виявлення підозрілих входів, швидке блокування скомпрометованих облікових записів.

Що входить у нашу роботу

Ми надаємо повний цикл розробки мультиплеєра:

• Аналіз вимог — визначаємо жанр, кількість гравців, цільові платформи, очікуваний CCU
• Проектування архітектури — вибір між relay та авторитетним сервером, транспортний протокол, стек
• Реалізація мережевого коду — синхронізація, лаг-компенсація, клієнтське передбачення, серверна логіка
• Серверна інфраструктура — налаштування виділених серверів, матчмейкінг, балансування
• Інтеграція соціальних функцій — авторизація, друзі, чат, лідерборди, голосовий зв’язок
• Тестування та оптимізація — профілювання мережі, стрес-тести до 1000+ CCU, виправлення stutter та пакет-лосс
• Супровід після релізу — моніторинг, масштабування, оновлення протоколів

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

Що потрібно зафіксувати перед початком розробки

1. Жанр та рівень конкуренції — визначає вибір між relay та авторитетним сервером
2. Максимальна кількість гравців на сесію — 2–4 гравці та 64 гравці — принципово різні завдання
3. Цільові платформи — WebGL вимагає WebSocket, консолі вимагають сертифікацію мережевого коду
4. Очікуваний піковий CCU — впливає на вибір інфраструктури та план масштабування
5. Вимоги до античиту — потрібна серверна авторитет, інтеграція EasyAntiCheat або BattlEye

Строки: від 4 тижнів для базового мультиплеєра до 6+ місяців для конкурентної AAA-гри з повним стеком. Вартість розраховується індивідуально після аналізу вашого проєкту. Замовте консультацію — ми оцінимо ваш проєкт і запропонуємо оптимальне рішення під ключ. З нами працюють студії з України, Європи та США; наші сертифіковані спеціалісти гарантують якість мережевого коду на рівні топових релізів.