Мы разрабатываем системы достижений и лидербордов, которые удерживают игроков через цели второго плана и социальное давление. На старте кажется, что достаточно флага в базе и проверки условия, но на практике через полгода вылезают грабли: рассинхрон счётчиков после переустановки игры, невозможность выдать ретроактивные достижения, конфликты в многопоточных средах. Опыт 10+ лет и 50+ реализованных проектов позволяют нам обходить эти проблемы на этапе архитектуры.
Почему достижения сложнее, чем кажется?
На старте проекта достижения выглядят просто: флаг в базе, проверка условия, запись. На практике через полгода разработки обнаруживается следующее:
Состояние счётчиков рассинхронизировано. Достижение «убей 100 гоблинов» требует персистентного счётчика, который обновляется при каждом убийстве. Если игрок переустановил игру, счётчик сбросился — достижение уже не получить, хотя в Google Play / Game Center оно отмечено как выполненное. Это классическая проблема dual-state: локальное состояние и состояние на платформе расходятся.
Ретроактивные достижения. Команда добавляет новое достижение через три месяца после запуска. Игроки, которые уже выполнили условие, не получают его автоматически. Нужна процедура бэкфилла — пересчёт по исторической статистике игрока. Если статистика не хранилась — бэкфилл невозможен, игроки злятся.
Thread-safety счётчиков. В многопоточной среде (Unity с Jobs System, серверная логика) одновременное инкрементирование счётчика без атомарных операций даёт неверные значения. Несколько ивентов одновременно — счётчик прыгает через значения. В 90% случаев мы видим эту проблему на этапе нагрузочного тестирования.
Архитектура системы достижений
Рабочая схема — event-driven архитектура через центральный AchievementService. Вместо того чтобы каждый игровой модуль знал о достижениях и вызывал AchievementManager.CheckCondition(), модули бросают события: GameEvent.EnemyKilled(enemyType, count), GameEvent.LevelCompleted(levelId, stars). AchievementService подписан на нужные события и сам обновляет счётчики.
Каждое достижение описывается конфигом:
- тип (
incremental,single,compound) - список ивентов, на которые реагирует
- условие завершения (лямбда или ScriptableObject с логикой)
- награда
Добавление нового достижения — это новый конфиг, без изменений в игровом коде.
Синхронизация с платформами. Google Play Games Services и Apple Game Center имеют собственные лидерборды и достижения, но работать с ними напрямую — боль. GPG SDK для Unity работает только на Android, Game Center — только на iOS. Для кросс-платформенных проектов используем промежуточный слой: собственная база хранит мастер-состояние, платформенные SDK обновляются как сателлиты. При конфликте (офлайн-сессия) — мерж по принципу «берём максимум» для инкрементальных счётчиков.
PlayFab и GameSparks предоставляют готовые серверные системы достижений с API — для мобильных F2P это часто быстрее и дешевле собственного бэкенда. Achievement (video games)
Как избежать читеров в лидерборде?
Клиентская отправка score без валидации — прямая дорога к читерам на первом месте. Минимум: score подписывается HMAC-ключом на клиенте, сервер верифицирует подпись. Нормальный вариант: сервер сам рассчитывает score по логам игровой сессии, клиент только отправляет события. Мы внедряем античит на обоих уровнях: на клиенте — проверка целостности билда, на сервере — мониторинг аномалий (например, резкий скачок счётчика на 300% за 3 секунды).
Лидерборды: сложность в масштабе
Для игры с 1000 одновременных игроков SQLite или PostgreSQL с ORDER BY score DESC LIMIT 100 работают нормально. При 100k+ записей запрос без правильных индексов начинает тормозить. При 1M+ — нужен Redis Sorted Set.
Redis ZADD leaderboard {score} {userId} + ZREVRANK leaderboard {userId} даёт O(log N) вставку и O(log N) получение ранга. ZREVRANGE leaderboard 0 99 WITHSCORES — топ-100 за microseconds. Это стандарт для мобильных игр с большой аудиторией.
Недельные и сезонные лидерборды. Отдельная таблица (или отдельный Redis Sorted Set) на период + cron-джоб для ротации. При ротации — снапшот победителей в архив, раздача наград через очередь (не синхронно — при большой аудитории синхронная раздача наград убьёт сервер).
Что входит в работу
| deliverable | описание |
|---|---|
| Документация API и схемы данных | описание событий, конфигов и endpoint'ов |
| Инструмент для геймдизайнера | редактор конфигов достижений (web-интерфейс или плагин в Unity/Unreal) |
| Интеграция с платформами | GPG, Game Center, PlayFab — включая синхронизацию и мерж конфликтов |
| Нагрузочное тестирование | проверка лидерборда при 1000+ одновременных запросов |
| Поддержка после запуска | исправление багов, доработка конфигов, консультации команды |
Этапы разработки
- Проектирование схемы — типы достижений, события, хранение состояния, платформы.
- Серверная часть — таблицы/Redis, API endpoints, anti-cheat.
- Клиентская интеграция — AchievementService, подписки на события, UI.
- Платформенная синхронизация — GPG / Game Center / PlayFab.
- Инструменты для геймдизайнера — редактор конфигов достижений.
- QA — тест ретроактивных достижений, тест офлайн-сценариев, нагрузочный тест лидерборда.
| Масштаб | Срок |
|---|---|
| Локальные достижения без сервера (мобайл/casual) | 1–2 недели |
| Серверные достижения + лидерборды для одной платформы | 3–5 недель |
| Кросс-платформенная система с анти-читом и сезонными лидербордами | 6–12 недель |
Стоимость определяется индивидуально после анализа архитектуры проекта и требований к масштабируемости. Оцените ваш проект — напишите нам, и мы предложим план под ваш бюджет.