Розробка внутрішньоігрової прогресії
Прогресія — це відчуття зростання. Гравець повинен відчувати, що став сильніше, розумніше, ближче до цілі. Якщо це відчуття пропадає — сесія закінчується. Технічно прогресія — це набір взаємозв'язаних систем: досвід, рівні, навички, розблокування, досягнення, метапрогресія. Кожна потребує власної архітектури.
Як зламати прогресію технічно
Крива досвіду без математичного обґрунтування
Формула requiredXP = baseXP * level^exponent на перший погляд працює. Але без моделювання реальних сесій отримуємо або "стіну" — рівень, де гравець застряває на кілька годин — або "провал" — відрізок, який пролітається за 10 хвилин та втрачає цінність.
Правильний підхід: спочатку визначаємо target session count per level (скільки ігрових сесій нормально тратити на перехід між рівнями), потім підбираємо формулу під цей target. Моделюємо в таблиці, не угадуємо в коді.
Стан прогресії в неправильному місці
Зберігати прогрес у PlayerPrefs — це не архітектура, це тимчасове рішення, яке стає постійним. PlayerPrefs не підтримують версіонування схеми: при зміні структури даних старі збереження ломаються. Коли у гри 50 000 користувачів, це катастрофа.
Правильна схема: ProgressionData як C# клас з явною версією схеми, серіалізація в JSON, зберігання через PlayFab Player Data або власний API. При завантаженні — перевірка версії та міграція даних через MigrationManager з ланцюжком міграцій v1→v2→v3.
Race conditions у мультиплеєрі
При одночасних запитах на начислення досвіду (завершення матчу + daily bonus + achievement unlock в один момент) без атомарності отримуємо неконсистентний стан. PlayFab CloudScript виконує операції послідовно для одного гравця — це вбудована захист. На власному бекенді — транзакції в PostgreSQL з SELECT ... FOR UPDATE.
Архітектура системи прогресії
Розділення даних та логіки
ProgressionConfig ScriptableObject містить незмінні дані: формули розрахунку XP, таблиці наград за рівні, дерево навичок. Це налаштовується геймдизайнером без зміни коду.
ProgressionState — поточний стан гравця: поточний рівень, накопичений XP, розблоковані навички, виконані досягнення. Тільки серіалізуємі дані, ніяких посилань на Unity-об'єкти.
ProgressionManager — сервіс-посередник: приймає події з геймплею (вбив ворога, виконав квест, знайшов предмет), обчислює зміни стану, генерує події для UI (level up!, навичка розблокована).
Таке розділення дозволяє тестувати логіку прогресії unit-тестами без запуску Unity.
Skill tree та дерево навичок
Дерево навичок — це граф з направленими ребрами. Вузол — навичка (SkillNode), ребро — залежність (prerequisites). Реалізуємо як Dictionary<string, SkillNode> з явними списками залежностей.
Passive навички (бонуси до урану, швидкості) зручно реалізувати через систему Stat Modifiers: кожна навичка додає StatModifier з типом (flat, percent additive, percent multiplicative) до потрібного стату. Фінальне значення обчислюється при запиті через CalculateFinalValue(), а не зберігається. Це автоматично обробляє додавання та зняття модифікаторів.
Active навички (здібності) — через Command Pattern: кожна навичка — об'єкт з методами Execute(), CanExecute(), GetCooldownProgress(). Cooldown керується централізовано через AbilitySystem, який оновлюється в Update().
Метапрогресія (roguelike-паттерн)
Постійний прогрес між ранами — окремий шар даних. Розблокування між ранами (стартові бонуси, нові персонажі, ігрові режими) зберігаються окремо від прогресу всередині раніи, який скидається при смерті.
Реалізація: дві структури даних — MetaProgressionState (постійна, CloudSave) та RunState (тимчасова, LocalSave/InMemory). RunState ініціалізується з MetaProgressionState при старті раніи + застосовуються ран-специфічні модифікатори від обраних перків.
Аналітика прогресії
Без даних неможливо балансувати прогресію. Обов'язкові метрики:
- Level Distribution — скільки гравців на кожному рівні в момент часу. Якщо 60% застрягли на рівні 15 — там стіна.
- Time per level — середній час між level-up. Повинна зростати плавно, без скачків.
- Skill usage rate — які навички вибирають гравці. Якщо один навичка беруть 80% гравців — дерево несбалансоване.
- Churn by level — відток гравців у розрізі рівнів. Різкий ріст відтоку на конкретному рівні = проблема саме там.
Збираємо через Firebase Analytics з custom events: level_up, skill_unlocked, achievement_completed. Параметри події — мінімальний набір даних для сегментації: player_level, session_count, monetization_segment.
Процес роботи
Проектування економіки прогресії (3-7 днів). Таблиця цільових сесій, формули XP, структура наград. Обов'язково узгоджується з монетизаційною моделлю.
Архітектура та бекенд (1-2 тижні). Схема даних, API endpoints або PlayFab настройка, стратегія міграції.
Реалізація клієнта (1-3 тижні). ProgressionManager, UI (XP-бар, level-up анімація, skill tree екран), інтеграція з геймплейними системами.
Балансування (ongoing). Перша ітерація після плейтестів — майже гарантовано потребує корректування формул. Закладаємо в план.
| Тип системи | Орієнтовні терміни |
|---|---|
| Прості рівні + XP | 3-7 днів |
| XP + дерево навичок | 2-4 тижні |
| Повна мета-прогресія (roguelike) | 3-6 тижнів |
| LiveOps прогресія + сезони | 1-2 місяці |
Вартість розраховується індивідуально після аналізу ігрової механіки та цільових платформ.