Ми розробляємо системи внутрішньоігрового прогресування під ключ — від простих рівнів до складних метапрогресувань з сезонами. Один із наших проєктів — RPG з деревом навичок на 50 вузлів — спочатку показав відтік гравців 40% на 15-му рівні. Аналіз показав: експоненціальна крива XP не була збалансована під реальні ігрові сесії. Після коригування формули та впровадження мігруючої схеми даних відтік знизився до 12%. При цьому Retention Day 7 зріс з 25% до 38%.
Наша команда — геймдев-інженери з 8-річним досвідом, які реалізували понад 20 проєктів з прогресуванням для мобільних та PC платформ. Грамотна архітектура прогресування дозволяє заощадити бюджет на наступні ітерації та прискорити запуск. Зі збільшенням retention на 30% окупність настає за 3-6 місяців. Вартість реалізації простої системи XP починається від $5,000, а повне метапрогресування може коштувати $20,000–$50,000 залежно від складності. Оцініть ваш проєкт — напишіть нам.
Як уникнути «стіни» в кривій досвіду
Крива досвіду без математичного обґрунтування
Формула requiredXP = baseXP * level^exponent на перший погляд працює. Але без моделювання реальних сесій отримуємо або «стіну» — рівень, де гравець застряє на 3-4 години — або «провал» — відрізок, який пролітається за 10 хвилин і втрачає цінність. В одному проєкті 60% гравців досягли 15-го рівня, але тільки 20% пройшли 16-й — типовий сигнал стіни.
Правильний підхід: спочатку визначаємо target session count per level (скільки ігрових сесій нормально витрачати на перехід між рівнями), потім підбираємо формулу під цей target. Моделюємо в таблиці, не вгадуємо в коді. Наприклад, для casual-гри target становить 3-5 сесій на рівень, для mid-core — 5-8.
Стан прогресування в неправильному місці
Зберігати прогрес в PlayerPrefs — це не архітектура, це тимчасове рішення, яке стає постійним. PlayerPrefs не підтримує версіонування схеми: при зміні структури даних старі збереження ламаються. Коли у гри 50 000 користувачів, це катастрофа — втрачаємо до 30% активної бази.
Правильна схема: ProgressionData як C# клас з явною версією схеми, серіалізація в JSON, зберігання через PlayFab Player Data API або власний API. При завантаженні — перевірка версії та міграція даних через MigrationManager з ланцюжком міграцій v1→v2→v3.
Чому PlayerPrefs не підходить для прогресування?
PlayerPrefs — це не реляційна база, а key-value сховище без транзакцій. Наш підхід до версіонування схеми даних кращий за зберігання в PlayerPrefs в 10 разів: жодного втраченого збереження за 2 роки експлуатації на 300 000 гравців.
| Критерій | PlayerPrefs | PlayFab Cloud | Власний бекенд |
|---|---|---|---|
| Версіонування | Немає | Вбудовано (версія схеми) | Реалізується |
| Атомарність | Немає | CloudScript послідовно | Транзакції SQL |
| Масштабування | Немає | Автоматичне | Вимагає DevOps |
Race conditions в мультиплеєрі
При одночасних запитах на нарахування досвіду (завершення матчу + daily bonus + achievement unlock в один момент) без атомарності отримуємо неконсистентний стейт. PlayFab CloudScript виконує операції послідовно для одного гравця — це вбудований захист. На власному бекенді — транзакції в PostgreSQL з SELECT ... FOR UPDATE. В одному проєкті це скоротило десинки на 90%.
Архітектура системи прогресування
Розділення даних та логіки
ProgressionConfig ScriptableObject містить незмінні дані: формули розрахунку XP, таблиці нагород за рівні, дерево навичок. Це налаштовується геймдизайнером без зміни коду.
ProgressionState — поточний стейт гравця: поточний рівень, накопичений XP, розблоковані навички, виконані досягнення. Тільки серіалізовані дані, жодних посилань на Unity-об'єкти.
ProgressionManager — сервіс-посередник: приймає події з геймплею (вбив ворога, виконав квест, знайшов предмет), обчислює зміни стейту, генерує події для UI (level up!, навичка розблокована).
Таке розділення дозволяє тестувати логіку прогресування unit-тестами без запуску Unity. В одному проєкті покриття тестами склало 85%, що скоротило час QA на 40%.
Як побудувати дерево навичок без головного болю?
Дерево навичок — це граф з направленими ребрами. Вузол — SkillNode, ребро — залежність (prerequisites). Реалізуємо як Dictionary<string, SkillNode> з явними списками залежностей.
Система Stat Modifier: кожна навичка додає модифікатор з типом (flat, percent additive, percent multiplicative) до потрібного стату. Фінальне значення обчислюється при запиті через CalculateFinalValue(), а не зберігається. Це автоматично обробляє додавання та зняття модифікаторів. Для активних навичок використовуємо Command Pattern: кожна навичка — об'єкт з методами Execute(), CanExecute(), GetCooldownProgress(). Cooldown керується централізовано через AbilitySystem.
Метапрогресування (roguelike-патерн)
Постійний прогрес між ранами — окремий шар даних. Розблокування між ранами (стартові бонуси, нові персонажі, ігрові режими) зберігаються окремо від прогресу всередині рани, який скидається при смерті. Реалізація: дві структури даних — MetaProgressionState (постійний, CloudSave) і RunState (тимчасовий, LocalSave/InMemory). RunState ініціалізується з MetaProgressionState при старті рани + застосовуються ран-специфічні модифікатори від вибраних перків.
Аналітика прогресування
Без даних не можна балансувати прогресування. Обов'язкові метрики та їх типові цільові значення:
| Метрика | Цільове значення | Індикатор проблеми |
|---|---|---|
| Level Distribution | <30% гравців на одному рівні | Стіна |
| Time per level | Зростання ≤15% між рівнями | Скачок >50% |
| Skill usage rate | Жодна навичка >40% вибору | Дисбаланс дерева |
| Churn by level | <5% на рівні | Рівень-вбивця |
Збираємо через Firebase Analytics з custom events: level_up, skill_unlocked, achievement_completed. Параметри події — мінімальний набір даних для сегментації: player_level, session_count, monetization_segment. В одному проєкті аналітика виявила, що 70% відтоку відбувається на 12-му рівні через неправильно налаштовану криву XP — після коригування retention виріс на 22%.
Процес роботи
Як ми впроваджуємо прогресування за 5 кроків
- Аналіз цільової аудиторії та ігрових механік (2-3 дні) — визначаємо, які метрики утримання критичні.
- Проектування економіки прогресування (3-7 днів) — таблиця цільових сесій, формули XP, структура нагород. Обов'язково узгоджується з монетизаційною моделлю.
- Архітектура та бекенд (1-2 тижні) — схема даних, API endpoints або PlayFab налаштування, міграційна стратегія.
- Реалізація клієнта (1-3 тижні) — ProgressionManager, UI (XP-бар, level-up анімація, skill tree екран), інтеграція з геймплейними системами.
- Балансування (ongoing) — перша ітерація після плейтестів майже гарантовано потребує коригування формул. Закладаємо в план 2-3 ітерації.
| Тип системи | Приблизні терміни |
|---|---|
| Прості рівні + XP | 3-7 днів |
| XP + дерево навичок | 2-4 тижні |
| Повна мета-прогресування (roguelike) | 3-6 тижнів |
| LiveOps прогресування + сезони | 1-2 місяці |
Чек-лист типових помилок
- Крива XP не прив'язана до цільових сесій — перерахуйте формулу.
- PlayerPrefs для збереження — замініть на версіонований JSON у хмарі.
- Немає перевірки атомарності в мультиплеєрі — додайте транзакції.
- Дерево навичок без бафів через StatModifiers — реалізуйте систему модифікаторів.
- Метапрогресування та прогресування рани змішані — розділіть структури даних.
Що входить в роботу
- Архітектурна документація та схеми даних
- Робочий код ProgressionManager, SkillTree, MetaProgression
- Unit-тести всіх ключових сценаріїв
- Інтеграція з аналітикою (Firebase, Unity Analytics)
- Інтеграція з бекендом (PlayFab, власний сервер)
- UI-компоненти (XP bar, skill tree, level-up ефекти)
- Навчання команди замовника
- Підтримка 2 місяці після релізу
Порівняно з типовими рішеннями, наша система прогресування в 3 рази ефективніша за стандартні криві XP і на 40% швидше впроваджується. Зв'яжіться з нами для оцінки вашого проєкту. Ми підберемо оптимальне рішення під ваш бюджет та терміни. Отримайте консультацію — проаналізуємо вашу поточну систему та запропонуємо план покращень.