Реалізація системи авторизації та профілів користувачів

Проєкт на Unity: казуальний раннер на Android та iOS. Гравці проходять 30 рівнів, купують скіни за внутрішню валюту та реальні гроші. Після скидання телефону прогрес зникає, покупки не відновлюються — результат: негативні відгуки, chargeback'и, падіння доходу на 40%. Така ситуація — прямий сигнал: без серверної авторизації та cloud save монетизація працює вхолосту.

Ми проєктуємо та впроваджуємо систему авторизації та профілів для ігрових проєктів на Unity, Unreal Engine, Godot. Досвід — 5+ років, реалізовано 30+ проєктів з аудиторією від 10K до 1M+ користувачів. Гарантуємо безпеку, account merge та масштабування під навантаження.

Яку архітектуру авторизації обрати?

Guest account (Device ID) → Upgrade to Full Account. Патерн, який максимально знижує бар'єр входу. Гравець запускає гру без реєстрації — створюється гостьовий акаунт, прив'язаний до Device ID / Apple IDFA / Android GAID. Прогрес зберігається. За бажанням — конвертує в повний акаунт (email, Apple Sign In, Google Play Games).

Ключовий момент — account merge: у гравця може бути гостьовий акаунт на одному пристрої та повний акаунт на іншому. Потрібна логіка об'єднання: який прогрес «перемагає»? Зазвичай беремо той, що старший, або той, де вищий рівень. Це бізнес-рішення, яке потрібно прийняти заздалегідь — не в момент першого бага.

Federated Identity (Social Login). Sign In with Apple (обов'язковий для iOS, якщо є інші social logins), Google Play Games (Android), Facebook, Steam. Не потрібно зберігати паролі — провайдер бере аутентифікацію на себе. Отримуємо JWT-токен, перевіряємо його підпис на сервері, видаємо власний session token. У порівнянні з кастомною системою, інтеграція social login через PlayFab скорочує час розробки приблизно на 50% (з 4 тижнів до 2 тижнів). Використання готового backend прискорює впровадження вдвічі.

Sign In with Apple — особливий випадок. Apple вимагає підтримки цього методу, якщо в грі є хоча б один інший third-party login. Крім того, Apple може приховувати email користувача та видавати relay email. Це потрібно враховувати: не можна покладатися на email як унікальний ідентифікатор у Apple-користувачів. Apple Developer Documentation: Sign In with Apple

Email + Password. Класика, але вимагає: зберігання паролів через bcrypt (не MD5 і не SHA1), rate limiting на login endpoint (наприклад, 5 спроб за хвилину з одного IP), secure password reset flow через email з time-limited токенами. У managed backend (PlayFab, Nakama) це є з коробки. У кастомному — потрібно реалізувати самостійно.

Що входить до профілю гравця?

Профіль гравця — це не просто {username, email, level}. Правильна структура розділяє дані за типом та частотою оновлення:

Акаунтні дані (persistent, рідко змінюються):

• playerId — внутрішній UUID, ніколи не змінюється
• email, username, avatarUrl
• linkedAccounts — масив прив'язаних провайдерів (google, apple, steam)
• createdAt, lastLoginAt

Ігровий прогрес (persistent, часто оновлюється):

• level, experience
• completedQuests[], unlockedContent[]
• inventoryId → посилання на окрему колекцію (інвентар може містити до 200 предметів)
• statistics — kills, deaths, playtime, wins/losses

Сесійні дані (ephemeral, не зберігаються):

• Поточна позиція в матчі, тимчасові баффи, сесійна статистика — це в пам'яті сервера, не в БД

Розділення важливе для продуктивності: при вході в гру завантажуємо тільки акаунтні дані та базовий прогрес. Інвентар на 200 предметів підвантажуємо ліниво при відкритті інвентарного екрану — це скорочує час завантаження на 40%. У проєкті з 500 000 MAU ми таким чином знизили пікове навантаження на базу даних на 60%.

Чому безпека критична?

JWT validation на кожному запиті. Session token — JWT із підписом RS256 або HS256. Сервер перевіряє підпис та expiry при кожному API-виклику. Термін дії — 24–48 годин, refresh token — 30–90 днів.

Server-side validation для економічних операцій. Додавання валюти, застосування промокодів, результат матчу — тільки через серверний код. Клієнт може показати результат оптимістично, але остаточний стан визначає сервер. Інакше — memory editor дають гравцеві мільйон монет за 5 хвилин.

Rate limiting. Login endpoint: максимум 5 спроб за хвилину з одного IP. Це захист від brute force. У PlayFab і Nakama вбудовано. У кастомному — через Redis + sliding window.

Як ми вирішували проблему account merge на реальному проєкті?

Реальний кейс: казуальний раннер, Android+iOS. Спочатку — local save тільки. Після додавання монетизації (скіни за IAP) — терміново потрібен cloud save. Додали PlayFab auth (Guest + Google Play Games + Apple Sign In) за 2 тижні. Проблема, яку не передбачили: частина гравців мала прогрес на Android під google-акаунтом і намагалися зайти на iPad — account merge видавав конфлікт. Знадобився додатковий екран «виберіть, який прогрес зберегти» + 3 дні доопрацювання. Рішення: при конфлікті показуємо обидва профілі, гравець обирає. Автоматика — якщо різниця в рівні більше 5, бере старший. Цей підхід знизив кількість звернень до підтримки на 30% і зменшив відтік гравців після зміни пристрою на 15%.

Процес реалізації

1. Вибір identity provider та проєктування Login Flow: Guest → Social → Email. Це UX-рішення з технічними наслідками.
2. Проєктування схеми даних профілю з урахуванням майбутнього зростання (кількість предметів, кланова система).
3. Реалізація server-side validation для всіх економічних операцій.
4. Тестування edge cases: втрата з'єднання під час збереження, дублювання акаунтів при повторній установці, expiry токена в середині ігрової сесії.
5. Деплой та підтримка протягом 30 днів.

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

• Архітектура auth flow та дизайн схеми даних
• Інтеграція guest auth, social logins, email/password
• Реалізація JWT-токенів, refresh logic
• Server-side validation всіх економічних операцій
• Написання документації та передача доступів
• Підтримка протягом 30 днів після деплою

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

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

Ми бачили десятки проєктів, які застрягали на півроку, коли справа доходила до розробки мультиплеєра. Ви збудували гру для одного гравця, білд стабільний, і раптом приходить завдання — додати мережеву гру. Саме тут більшість команд серйозно недооцінюють обсяг робіт. Мультиплеєр — це не «додати синхронізацію», це переосмислення ігрової логіки, вибір мережевої архітектури та побудова серверної інфраструктури з нуля. Наш досвід — понад 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-гри з повним стеком. Вартість розраховується індивідуально після аналізу вашого проєкту. Замовте консультацію — ми оцінимо ваш проєкт і запропонуємо оптимальне рішення під ключ. З нами працюють студії з України, Європи та США; наші сертифіковані спеціалісти гарантують якість мережевого коду на рівні топових релізів.