Мы разрабатываем системы внутриигровой прогрессии под ключ — от простых уровней до сложных метапрогрессий с сезонами. Один из наших проектов — RPG с деревом навыков на 50 узлов — сначала показал отток игроков 40% на 15-м уровне. Анализ показал: экспоненциальная кривая XP не была сбалансирована под реальные игровые сессии. После корректировки формулы и внедрения мигрирующей схемы данных отток снизился до 12%. При этом Retention Day 7 вырос с 25% до 38%.
Наша команда — геймдев-инженеры с 8-летним опытом, реализовавшие более 20 проектов с прогрессией для мобильных и PC платформ. Грамотная архитектура прогрессии позволяет сэкономить бюджет на последующие итерации и ускорить запуск. С увеличением retention на 30% окупаемость наступает за 3-6 месяцев. Оцените ваш проект — напишите нам.
Как избежать «стены» в кривой опыта
Кривая опыта без математического обоснования
Формула 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(), а не хранится. Это автоматически обрабатывает добавление и снятие модификаторов. Для active навыков используем 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 месяца после релиза
Свяжитесь с нами для оценки вашего проекта. Мы подберём оптимальное решение под ваш бюджет и сроки. Получите консультацию — проанализируем вашу текущую систему и предложим план улучшений.