Разработка систем достижений (Achievements) и лидербордов

Наша компания по разработке видеоигр ведет независимые проекты, совместно с клиентом создает игры и оказывает дополнительные операционные услуги. Опыт нашей команды позволяет нам охватить все игровые платформы и разработать потрясающий продукт, соответствующий видению клиента и предпочтениям игроков.

От иммерсивных приложений до игровых миров и 3D-сцен

Наша выделенная команда для VR/AR/MR-разработки, Unity-продакшна и 3D-моделирования и анимации с собственными кейсами и презентациями.

Посетить персонализированный сайт
Показано 1 из 1 услугВсе 242 услуг
Разработка систем достижений (Achievements) и лидербордов
Средняя
~5 рабочих дней
Часто задаваемые вопросы

Наши компетенции

Какие этапы разработки игры?

Последние работы

  • image_games_mortal_motors_495_0.webp
    Разработка игры для компании Mortal Motors
    683
  • image_games_a_turnbased_strategy_game_set_in_a_fantasy_setting_with_fire_and_sword_603_0.webp
    Пошаговая стратегия в фэнтези сеттинге With Fire And Sword
    862
  • image_games_second_team_604_0.webp
    Разработка игры для компании Second term
    491
  • image_games_phoenix_ii_606_0.webp
    3D-анимация — тизер для игры phoenix 2.
    533

Разработка систем достижений (Achievements) и лидербордов

Достижения и лидерборды — не декоративные элементы. Правильно выстроенная система achievement удерживает игрока через цели второго плана, а лидерборд создаёт социальное давление, которое работает лучше большинства push-уведомлений. Но технически обе системы имеют неочевидные грабли, на которых ломаются даже опытные команды.

Почему достижения сложнее, чем кажется

На старте проекта достижения выглядят просто: флаг в базе, проверка условия, запись. На практике через полгода разработки обнаруживается следующее:

Состояние счётчиков рассинхронизировано. Достижение «убей 100 гоблинов» требует персистентного счётчика, который обновляется при каждом убийстве. Если игрок переустановил игру, счётчик сбросился — достижение уже не получить, хотя в Google Play / Game Center оно отмечено как выполненное. Это классическая проблема dual-state: локальное состояние и состояние на платформе расходятся.

Ретроактивные достижения. Команда добавляет новое достижение через три месяца после запуска. Игроки, которые уже выполнили условие, не получают его автоматически. Нужна процедура бэкфилла — пересчёт по исторической статистике игрока. Если статистика не хранилась — бэкфилл невозможен, игроки злятся.

Thread-safety счётчиков. В многопоточной среде (Unity с Jobs System, серверная логика) одновременное инкрементирование счётчика без атомарных операций даёт неверные значения. Несколько ивентов одновременно — счётчик прыгает через значения.

Архитектура системы достижений

Рабочая схема — 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 это часто быстрее и дешевле собственного бэкенда.

Лидерборды: сложность в масштабе

Для игры с 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. Это стандарт для мобильных игр с большой аудиторией.

Анти-чит для лидерборда. Клиентская отправка score без валидации — прямая дорога к читерам на первом месте. Минимум: score подписывается HMAC-ключом на клиенте, сервер верифицирует подпись. Нормальный вариант: сервер сам рассчитывает score по логам игровой сессии, клиент только отправляет события.

Недельные и сезонные лидерборды. Отдельная таблица (или отдельный Redis Sorted Set) на период + cron-джоб для ротации. При ротации — снапшот победителей в архив, раздача наград через очередь (не синхронно — при большой аудитории синхронная раздача наград убьёт сервер).

Этапы разработки

  1. Проектирование схемы — типы достижений, события, хранение состояния, платформы.
  2. Серверная часть — таблицы/Redis, API endpoints, anti-cheat.
  3. Клиентская интеграция — AchievementService, подписки на события, UI.
  4. Платформенная синхронизация — GPG / Game Center / PlayFab.
  5. Инструменты для геймдизайнера — редактор конфигов достижений.
  6. QA — тест ретроактивных достижений, тест офлайн-сценариев, нагрузочный тест лидерборда.
Масштаб Срок
Локальные достижения без сервера (мобайл/casual) 1–2 недели
Серверные достижения + лидерборды для одной платформы 3–5 недель
Кросс-платформенная система с анти-читом и сезонными лидербордами 6–12 недель

Стоимость определяется индивидуально после анализа архитектуры проекта и требований к масштабируемости.