Розробка систем досягнень (Achievements) та лідербордів

Ми розробляємо системи досягнень (ачівок) та лідербордів — це частина нашої лідерборд розробка. На старті здається, що достатньо прапора в базі та перевірки умови, але на практиці через півроку вилазять граблі: розсинхрон лічильників після перевстановлення гри, неможливість видати ретроактивні досягнення, конфлікти в багатопоточних середовищах. Досвід 10+ років і 50+ реалізованих проектів дозволяють нам обходити ці проблеми на етапі архітектури. Наші рішення дозволяють замовникам економити до 30% бюджету на розробці завдяки готовим модулям. Ми гарантуємо якість інтеграції та підтримку після запуску.

Чому досягнення складніші, ніж здається?

На старті проекту досягнення виглядають просто: прапор у базі, перевірка умови, запис. На практиці через півроку розробки виявляється наступне:

Стан лічильників розсинхронізовано. Досягнення «убий 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 підписаний на потрібні події та сам оновлює лічильники. Подієва архітектура зменшує кількість багів у 3 рази порівняно з прямими викликами.

Кожне досягнення описується конфігом:

• тип (incremental, single, compound)
• список івентів, на які реагує
• умова завершення (лямбда або ScriptableObject з логікою)
• нагорода

Додавання нового досягнення — це новий конфіг, без змін в ігровому коді.

Синхронізація з платформами. Google Play Games Services та Apple Game Center мають власні лідерборди та досягнення, але працювати з ними напряму — біль. GPG SDK для Unity працює тільки на Android, Game Center — тільки на iOS. Для кроссплатформенних досягнень ми використовуємо проміжний шар: власна база зберігає майстер-стан, платформенні SDK оновлюються як сателіти. При конфлікті (офлайн-сесія) — мерж за принципом «беремо максимум» для інкрементальних лічильників. Синхронізація з Game Center та Google Play Games Services виконується через цей шар.

PlayFab та GameSparks надають готові серверні системи досягнень з API — для мобільних F2P це часто швидше та дешевше власного бекенду. Achievement (video games)

Для Unity досягнення реалізуємо через Jobs System, для Unreal Engine ачівки реалізуємо аналогічно.

Як уникнути читерів у лідерборді?

Клієнтська відправка score без валідації — пряма дорога до читерів на першому місці. Мінімум: score підписується HMAC-ключем на клієнті, сервер верифікує підпис. Нормальний варіант: сервер сам розраховує score за логами ігрової сесії, клієнт тільки відправляє події. Ми впроваджуємо античит лідерборду на обох рівнях: на клієнті — перевірка цілісності білда, на сервері — моніторинг аномалій (наприклад, різкий стрибок лічильника на 300% за 3 секунди).

Лідерборди: складність у масштабуванні

Для гри з 1000 одночасних гравців SQLite або PostgreSQL з ORDER BY score DESC LIMIT 100 працюють нормально. При 100k+ записів запит без правильних індексів починає гальмувати. При 1M+ — потрібен Redis сортований список.

Redis ZADD leaderboard {score} {userId} + ZREVRANK leaderboard {userId} дає O(log N) вставку та O(log N) отримання рангу. ZREVRANGE leaderboard 0 99 WITHSCORES — топ-100 за мікросекунди. Redis сортований список у 100 разів швидший за PostgreSQL для топ-100 лідерборду. Це стандарт для мобільних ігор з великою аудиторією.

Тижневі та сезонні лідерборди. Окрема таблиця (або окремий Redis сортований список) на період + cron-джоб для ротації. При ротації — снапшот переможців в архів, роздача нагород через чергу (не синхронно — при великій аудиторії синхронна роздача нагород уб'є сервер).

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

Етапи розробки

1. Проектування схеми — типи досягнень, події, зберігання стану, платформи.
2. Серверна частина — таблиці/Redis, API endpoints, anti-cheat.
3. Клієнтська інтеграція — AchievementService, підписки на події, UI.
4. Платформенна синхронізація — GPG / Game Center / PlayFab.
5. Інструменти для геймдизайнера — редактор конфігів досягнень.
6. QA — тест ретроактивних досягнень, тест офлайн-сценаріїв, навантажувальний тест лідерборду.

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

Підтримка та розвиток ігор

Релиз — це не фінальний білд, а старт системи неперервної підтримки. У нашій практиці 80% проєктів без live ops втрачають до 30% аудиторії в перші два тижні: crash-рейтинг вище 1%, онбординг відсіває 40% нових гравців, контентні оновлення застрягають у рев'ю сторів на 3–4 дні. Ми вирішуємо це зв'язкою Remote Config, crash reporting та A/B-тестів. Зв'яжіться з нами — оцінка поточного стану проєкту займе один день.

Проблеми, які вирішує підтримка та розвиток ігор

• Retention — без онбордингу за даними аналітики D1 падає до 45%. Ми перебудовуємо туторіал: скорочуємо кроки з 10 до 4, додаємо пропуск для повертаючих гравців. Результат: +18% до D3.
• Контентна втома — якщо новий контент не виходить кожні 2–3 тижні, D30 падає на 25%. Вводимо сезонні події через Remote Config без нової збірки.
• Технічний борг — міграція на Unity 6 LTS з попередньої версії знижує FPS-баги на 30%, але вимагає оновлення SDK (Firebase, Adjust, AppLovin). Відкладання призводить до блокування публікації через застарілі бібліотеки.

Live ops як головний інструмент підтримки ігор

Здатність змінювати поведінку гри без перевипуску додатку — основа сучасної пост-релізної стратегії. Правильно побудований pipeline дозволяє змінити баланс, включити івент або протестувати нову монетизаційну механіку за 15 хвилин, не чіпаючи збірку. За вісім років ми пройшли шлях від хотфіксів через стори до повноцінної live ops-архітектури, яка економить до 30% часу на контентні оновлення.

Архітектура Remote Config

Типова схема виглядає так:

Dashboard / CMS
      ↓
Remote Config Provider (Firebase / PlayFab)
      ↓
Game Client (fetch on session start + періодичний polling)
      ↓
Local Cache (fallback при відсутності мережі)

Firebase Remote Config — найбільш поширене рішення для мобільних ігор. Ключі зберігаються в консолі, клієнт отримує їх при старті сесії через RemoteConfig.FetchAndActivateAsync(). Важливий момент: Firebase кешує значення на 12 годин за замовчуванням — у продакшні потрібно явно налаштовувати minimumFetchInterval. Для живих івентів використовуємо minimumFetchInterval = 0 з ручним throttling на клієнті. Firebase Remote Config Documentation.

PlayFab дає більше можливостей для game-специфічних сценаріїв: Title Data, Player Data, CloudScript. Зручно для серверної валідації покупок, зберігання прогресу гравця та A/B-тестування сегментів. Якщо у гри є серверна складова (PvP, leaderboards, інвентар), PlayFab часто вигідніше Firebase за сукупністю функцій. PlayFab підтримує ключі до 1 МБ, що в 16 разів більше ліміту Firebase (64 КБ).

Типова структура ключів Remote Config

Порівняння Firebase Remote Config і PlayFab Title Data

Як Remote Config прискорює доставку контенту?

A/B-тести через Firebase дозволяють розподіляти користувачів за групами та збирати статистику по retention D1/D7, revenue і custom events. Один користувач завжди потрапляє в одну групу завдяки прив'язці до Installation ID. Якщо тест зав'язаний на монетизацію — додатково перевіряємо через Unity Analytics, що розподіл покупок випадковий. Середній ріст retention D7 після впровадження таких тестів — 12%.

Як ми моніторимо стабільність гри?

Без crash reporting ви дізнаєтеся про критичні баги з відгуків, а не з дашборду. Firebase Crashlytics — стандарт для мобільних ігор. Інтегрується через Firebase SDK, автоматично фіксує необроблені виключення C# та native crashes (включаючи IL2CPP).

Crash-free users rate — має бути вище 99.5% для стабільного проєкту. ANR rate — часта проблема при важких завантаженнях на головному потоці. Top crashes за кількістю зачеплених користувачів — не за кількістю подій.

Backtrace використовуємо для проєктів з нативним кодом або складною C++ складовою (Unreal, кастомні плагіни). Backtrace краще декодує символи для нативних крашів. Для Unity-проєктів налаштовуємо Unity Cloud Diagnostics — дає додатковий контекст по помилках движка.

Аналітика та ітерація контенту

Unity Analytics (колишній Unity Gaming Services Analytics) використовуємо для трекінгу воронок. Для більш складних сценаріїв — власний event pipeline з відправкою в BigQuery або ClickHouse. Мінімальний набір подій:

• session_start / session_end
• level_start / level_complete / level_fail
• tutorial_step_N
• iap_purchase / ad_watched
• feature_unlocked

За цими даними видно, де аудиторія відвалюється, який контент не працює і куди вкладати сили наступного апдейту.

Що входить у підтримку та розвиток ігор

• Налаштування Remote Config зі схемою ключів і документацією.
• Інтеграція crash reporting (Firebase Crashlytics, Unity Cloud Diagnostics) з алертами.
• Проведення A/B-тестів і аналіз результатів.
• Контентні спринти: нові івенти, балансування, сезонний контент.
• Щотижнева аналітика та звіти за метриками.
• SLA для критичних багів — до 24 годин.

Процес роботи та терміни

Для проєктів на підтримці використовуємо виділений ритм: щотижневі звіти за метриками, спринти по 2 тижні для контентних апдейтів, черговий інженер на критичні баги з SLA до 24 годин. Всі зміни проходять через стейджинг-середовище перед деплоєм у прод.

Терміни впровадження live ops — від 2 до 4 тижнів залежно від складності та поточної архітектури. Вартість розраховується індивідуально, але в середньому економія на контентні оновлення складає 30–40% бюджету порівняно з традиційними хотфіксами (до $3000 щомісяця). Ми гарантуємо дотримання термінів і прозоре ціноутворення — замовте аудит вашого проєкту, і ми підготуємо кошторис за один день.

Отримати консультацію з налаштування підтримки та розвитку ігор — зв'яжіться з нами. Досвід супроводу понад 50 проєктів різного масштабу підтверджений сертифікованими спеціалістами Unity та PlayFab. Пишіть нам — ми проконсультуємо вас з будь-яких технічних питань.