In-Game Progression Development
Progression is the sensation of growth. The player must feel they've become stronger, smarter, closer to the goal. When this sensation disappears — the session ends. Technically progression is a set of interconnected systems: experience, levels, skills, unlocks, achievements, meta-progression. Each requires its own architecture.
How to break progression technically
Experience curve without mathematical basis
The formula requiredXP = baseXP * level^exponent seems to work initially. But without modeling real play sessions we get either a "wall" — a level where players get stuck for hours — or a "drop" — a section completed in 10 minutes that loses value.
Right approach: first define target session count per level (how many gameplay sessions normally spent transitioning between levels), then fit the formula to that target. We model in a spreadsheet, not guess in code.
Progression state in the wrong place
Storing progress in PlayerPrefs isn't architecture, it's temporary that becomes permanent. PlayerPrefs don't support schema versioning: changing data structure breaks old saves. With 50,000 users, that's a disaster.
Correct scheme: ProgressionData as C# class with explicit schema version, serialization to JSON, storage via PlayFab Player Data or custom API. On load — check version and migrate via MigrationManager with migration chain v1→v2→v3.
Race conditions in multiplayer
Simultaneous requests to credit experience (match completion + daily bonus + achievement unlock at once) without atomicity creates inconsistent state. PlayFab CloudScript executes sequentially per user — this is built-in protection. Custom backend — PostgreSQL transactions with SELECT ... FOR UPDATE.
Progression system architecture
Data and logic separation
ProgressionConfig ScriptableObject contains immutable data: XP calculation formulas, level reward tables, skill tree. This is configured by game designer without code changes.
ProgressionState — current player state: current level, accumulated XP, unlocked skills, completed achievements. Only serializable data, no Unity object references.
ProgressionManager — intermediary service: accepts gameplay events (killed enemy, completed quest, found item), calculates state changes, generates UI events (level up!, skill unlocked).
This separation enables unit testing progression logic without running Unity.
Skill tree and ability trees
A skill tree is a directed graph. Node — skill (SkillNode), edge — dependency (prerequisites). Implement as Dictionary<string, SkillNode> with explicit dependency lists.
Passive skills (damage bonuses, speed) conveniently via Stat Modifiers system: each skill adds StatModifier with type (flat, percent additive, percent multiplicative) to target stat. Final value calculated on request via CalculateFinalValue(), not stored. Automatically handles adding/removing modifiers.
Active skills (abilities) — via Command Pattern: each skill object with methods Execute(), CanExecute(), GetCooldownProgress(). Cooldown managed centrally via AbilitySystem updated in Update().
Meta-progression (roguelike pattern)
Permanent progress between runs — separate data layer. Unlocks between runs (starting bonuses, new characters, game modes) stored separately from progress within run, which resets on death.
Implementation: two data structures — MetaProgressionState (permanent, CloudSave) and RunState (temporary, LocalSave/InMemory). RunState initialized from MetaProgressionState at run start + run-specific modifiers from chosen perks applied.
Progression analytics
Without data you can't balance progression. Essential metrics:
- Level Distribution — how many players at each level currently. If 60% stuck on level 15 — that's a wall.
- Time per level — average time between level-ups. Should grow smoothly, no jumps.
- Skill usage rate — which skills players choose. If one skill taken by 80% — tree is unbalanced.
- Churn by level — player drop-off by level. Sharp churn spike on specific level — problem there.
We collect via Firebase Analytics with custom events: level_up, skill_unlocked, achievement_completed. Event parameters — minimum dataset for segmentation: player_level, session_count, monetization_segment.
Work process
Design progression economy (3-7 days). Target session table, XP formulas, reward structure. Must align with monetization model.
Architecture and backend (1-2 weeks). Data schema, API endpoints or PlayFab setup, migration strategy.
Client implementation (1-3 weeks). ProgressionManager, UI (XP bar, level-up animation, skill tree screen), gameplay system integration.
Balancing (ongoing). First iteration post-playtest almost certainly needs formula adjustments. We factor this in.
| System Type | Approximate Timeline |
|---|---|
| Simple levels + XP | 3-7 days |
| XP + skill tree | 2-4 weeks |
| Full meta-progression (roguelike) | 3-6 weeks |
| LiveOps progression + seasons | 1-2 months |
Cost calculated individually after analyzing game mechanics and target platforms.