Проект на 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 ускоряет внедрение в 2 раза.
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.
| Метод авторизации |
Время интеграции |
Особенности |
| Guest (Device ID) |
1–2 дня |
Низкий барьер, нет восстановления |
| Social Login |
3–7 дней |
Apple Sign In обязателен на iOS, relay email |
| Email + Password |
5–10 дней |
Требует bcrypt, rate limiting, password reset |
| Federated Identity |
2–4 недели |
Зависит от количества провайдеров |
Как мы решали проблему 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%.
Процесс реализации
- Выбор identity provider и проектирование Login Flow: Guest → Social → Email. Это UX-решение с техническими последствиями.
- Проектирование схемы данных профиля с учётом будущего роста (количество предметов, клановая система).
- Реализация server-side validation для всех экономических операций.
- Тестирование edge cases: потеря соединения во время сохранения, дублирование аккаунтов при повторной установке, expiry токена в середине игровой сессии.
- Деплой и поддержка в течение 30 дней.
Что входит в работу?
- Архитектура auth flow и дизайн схемы данных
- Интеграция guest auth, social logins, email/password
- Реализация JWT-токенов, refresh logic
- Server-side validation всех экономических операций
- Написание документации и передача доступов
- Поддержка в течение 30 дней после деплоя
| Масштаб задачи |
Ориентировочные сроки |
| Guest auth + basic cloud save (PlayFab/Nakama) |
1–2 недели |
| Full auth (Social logins + email) + profile |
2–4 недели |
| Кастомная система авторизации + JWT + PostgreSQL |
3–6 недель |
| Account merge + migration с local save |
1–2 недели |
Стоимость рассчитывается после анализа требований. Чтобы получить оценку под ваш проект, свяжитесь с нами — мы подготовим коммерческое предложение с учётом стека и объёма работ. Получите консультацию по архитектуре авторизации — это бесплатно.
Мультиплеер и сетевое взаимодействие
Мы знаем ситуацию: игра уже стабильно работает в одиночном режиме, и вдруг приходит задача — добавить мультиплеер. Именно здесь команды часто недооценивают масштаб работы. Мультиплеер — это не «добавить синхронизацию», а переосмысление игровой логики, выбор сетевой модели и выстраивание серверной инфраструктуры с нуля. Наш опыт разработки сетевого кода для шутеров и стратегий показывает, что правильная архитектура экономит до 40% бюджета на инфраструктуре.
Как выбрать между relay и авторитативным сервером?
Это первое и самое важное архитектурное решение. От него зависит всё: стоимость инфраструктуры, защита от читов, сложность разработки, задержки для игроков. Подробнее о клиент-серверной архитектуре можно прочитать в Wikipedia.
Relay-архитектура (P2P с ретрансляцией)
В relay-схеме клиенты не соединяются напрямую, а обмениваются данными через промежуточный сервер, который просто пересылает пакеты без игровой логики. Такое решение подходит для кооперативных игр с низкой конкуренцией, прототипов и небольших студий без серверной экспертизы.
Инструменты: Photon Relay — быстрый старт, готовые SDK, тарификация по CCU; Unity Gaming Services Relay — встроен в UGS, работает с Lobby и Netcode for GameObjects.
Проблема relay — читерство. Клиент как источник истины может отправлять любые данные. В конкурентных жанрах (шутеры, файтинги, спортивные симуляторы) relay неприемлем.
Авторитативный сервер
Вся игровая логика выполняется на сервере. Клиент отправляет только инпут, а сервер считает физику, коллизии, урон и рассылает результаты. Читер может отправить фиктивный инпут, но сервер его проверит или проигнорирует.
Стек под Unity:
-
Netcode for GameObjects (NGO) — официальное решение для авторитативного мультиплеера. Поверх Unity Transport: NetworkVariable, NetworkObject, RPC-вызовы. Активно развивается.
-
Mirror — форк uNet, зрелый и документированный. Множество транспортов (KCP, Telepathy, WebSockets). Проще в освоении для тех, кто работал с uNet.
-
Nakama — open-source игровой бэкенд с авторитативной логикой на Lua/TypeScript/Go. Подходит, когда нужен матчмейкинг, профили, инвентарь, лидерборды.
Стек под Unreal — встроенная сетевая система на основе авторитативного сервера (Dedicated Server, репликация, RPC). Для большинства жанров хватает нативных инструментов.
Unity documentation: «Netcode for GameObjects is a high-level networking library that simplifies adding multiplayer to Unity projects»
Почему важна компенсация задержки?
Это самый технически интересный аспект сетевого кода в конкурентных играх. Именно здесь команды часто делают ошибки, которые делают шутер или файтинг «ощущающимся неправильно».
Проблема
Игрок видит врага и нажимает выстрел. Между моментом нажатия и получением пакета сервером проходит время — RTT/2. Враг мог сместиться. Если сервер проверяет попадание по текущей позиции, игрок чувствует, что «пули не попадают».
Клиентское предсказание (Client-Side Prediction)
Клиент не ждёт подтверждения от сервера — сразу применяет свои действия локально (движение, анимации, звуки). Когда приходит ответ, клиент сверяет состояние. Если не совпадает — делает reconciliation: откатывается к серверному состоянию и «переигрывает» непотверждённые инпуты.
Требуется хранить историю инпутов и уметь быстро пересчитывать состояние. В NGO реализуется вручную через NetworkBehaviour с кастомной логикой. В Mirror есть NetworkTransformReliable с базовым предсказанием.
Пример кода клиентского предсказания на C#
```csharp
public class ClientPrediction : NetworkBehaviour
{
[ClientRpc]
void ApplyInput(InputData input)
{
transform.position += input.direction * speed * Time.deltaTime;
}
}
```
Серверная перемотка (Server-Side Rewind)
Когда сервер получает команду «выстрел», он берёт временную метку пакета и «перематывает» мировое состояние назад — к моменту, который видел клиент. Проверяет попадание в той «старой» позиции врага. Если попал — засчитывает хит.
Реализация требует:
- хранить историю состояний всех объектов за последние 200–500 мс;
- эффективно интерполировать состояния по временной метке;
- ограничивать глубину перемотки, чтобы не давать преимущество игрокам с высоким пингом.
Без этого механизма игроки с пингом 100+ мс постоянно «промахиваются» по врагам. С ним игра ощущается честной для 95% участников.
Интерполяция vs. экстраполяция на клиенте
Удалённые объекты (враги) клиент не предсказывает — он их интерполирует между двумя последними известными состояниями. Это создаёт визуальное отставание на 1–3 фрейма, но движение плавное. Экстраполяция даёт меньшую задержку, но при изменении направления — резкие «скачки». Большинство шутеров используют интерполяцию.
Серверная инфраструктура
Матчмейкинг и лобби
- Nakama — матчмейкинг из коробки с кастомными правилами на TypeScript/Go.
- PlayFab (Microsoft) — бэкенд с инвентарём, облачными сохранениями, аналитикой. Интегрируется с Azure.
- Unity Gaming Services Lobby — простой для инди-проектов.
Dedicated Servers
Для авторитативного мультиплеера нужны выделенные серверы. Выбор между четырьмя подходами зависит от масштаба и экспертизы. Самостоятельный VPS даёт полный контроль и низкую стоимость при высокой нагрузке, но требует DevOps. Multiplay (Unity) автоматически масштабируется, но дороже и вызывает vendor lock-in. Agones на Kubernetes — гибкий open-source, но сложен. AWS GameLift — зрелая платформа с глобальным размещением, но дорога для малых проектов.
Транспортный протокол
-
UDP — стандарт для real-time игр. Низкая задержка, возможны потери. Большинство библиотек работают поверх UDP с кастомной надёжностью.
- WebSocket — нужен для WebGL. Работает через TCP, чуть большая задержка, но приемлемо для казуальных жанров. Photon и Mirror поддерживают.
- KCP — UDP-протокол с элементами надёжности, компромисс между скоростью и надёжностью (используется в Mirror).
Социальные функции
Мультиплеер — это не только технический синхрон. Игрокам нужны инструменты для взаимодействия. Что мы обычно реализуем:
- Друзья и инвайты — через платформенные API (Steam Friends, Game Center, Google Play Games) или кастомный сервис в Nakama/PlayFab.
- Голосовой чат — Vivox (стандарт для PC/консолей, интеграция через UGS), Agora (кроссплатформенно, включая мобайл).
- Текстовый чат — фильтрация контента: PlayFab Chat или кастомный WebSocket-канал с модерацией.
- Лидерборды — Nakama, PlayFab, GameSparks. Разделяем глобальные и друзей-based.
- Клановая система — нестандартная функция, для большинства проектов достаточно группировки в Nakama.
Аутентификация
Никогда не изобретайте свою систему авторизации. Используйте готовые провайдеры:
- PlayFab — анонимный вход, Steam, Google, Apple, кастомный ID.
- Nakama — аналогично, плюс email/пароль.
- Firebase Auth — хорошо для мобильных игр, глубокая интеграция с Analytics и Remote Config.
Для конкурентных игр важна защита аккаунтов: двухфакторная аутентификация, детектирование подозрительных входов, быстрая блокировка.
Что входит в разработку мультиплеера
Мы занимаемся геймдевом более 8 лет, реализовали 15+ проектов с мультиплеером, включая шутеры с 64 игроками на сервере. В рамках работы предоставляем:
- Архитектурное проектирование (выбор модели, протоколов, инструментов).
- Реализация сетевого кода (синхронизация, авторитет, компенсация задержки).
- Интеграция бэкенда (аутентификация, матчмейкинг, профили, чат).
- Тестирование с имитацией задержек и потерь пакетов.
- Документация и обучение команды.
Что мы фиксируем до старта
-
Жанр и уровень конкуренции — от этого зависит выбор между relay и авторитативным сервером.
-
Максимальное число игроков в сессии — 2–4 или 64 — принципиально разные задачи.
-
Целевые платформы — WebGL требует WebSocket, консоли — сертификации.
-
Ожидаемый пик CCU — влияет на выбор инфраструктуры.
-
Требования к античиту — нужен ли серверный авторитет или интеграция с EasyAntiCheat/BattlEye.
Свяжитесь с нами для консультации — оценим ваш проект за 2 дня. Закажите разработку мультиплеера под ключ: мы проанализируем игру и предложим оптимальную архитектуру.
