Game Tutorial Level Creation
Onboarding kills games more often than bad gameplay. Mobile game statistics stable for years: drop-off at first minute — 40–60% of new users. Most leave not because game is bad but because tutorial didn't explain what to do, or explained so intrusively that annoyed before gameplay started.
Creating tutorial is separate discipline, not "draw arrows and write tips."
Main problem of most tutorials
Linear mandatory tutorial blocking controls — classic anti-pattern. Player can't skip, can't act independently, every step waits for specific button click. After two minutes thinking not "how to play" but "when will this end."
Technically often implemented via single TutorialManager with enum-states: STEP_1, STEP_2... STEP_47. Adding step mid-way breaks numbering, deleting step breaks whole flow. Maintaining such code year later impossible without complete rewrite.
From UX perspective — player learns through action, not text. Showing arrow at button and writing "click here" works worse than letting them make mistake and gently correct.
How we build tutorial from scratch
Architecture based on steps with conditions. Each tutorial step — object with activation condition, completion condition, and action set (show UI-element, block/unblock controls, start animation, play sound). Steps stored in ScriptableObject or JSON-config, not hardcoded. TutorialStep contains:
-
triggerCondition— what should happen to activate step -
completionCondition— what completes step -
actions[]— list of actions on activation -
hints[]— hints with timeout to appear
Such scheme lets designer edit tutorial in Inspector or separate editor without code changes.
Unobtrusive hints with timeout. Hint doesn't appear immediately — only if player doesn't perform action within N seconds. Standard practice but often forgotten. Implemented via Coroutine or DOTween-sequence with delay. If player finds needed button themselves — hint never appears. Those who figure it out not annoyed. Newbies get help.
Track tutorial progress via analytics. Each tutorial step — event in Firebase Analytics or Amplitude: tutorial_step_complete, tutorial_step_skip, tutorial_abandoned. Without this impossible to understand where exactly players drop. On one project analysis showed 30% abandon tutorial at crafting system explanation step — not because hard, but long text opened when players still didn't understand basic mechanics. Reordering steps raised completion from 58% to 81%.
Save tutorial progress. PlayerPrefs with key tutorial_completed — minimum variant. For complex tutorials need current step serialization, so after restart player doesn't start from beginning. Store in cloud (Firebase Firestore / PlayFab), especially for cross-platform games.
Separate about tutorial for complex systems
If game contains several independent systems (crafting, building, combat), linear tutorial doesn't fit. Better works contextual tips system: first time you open inventory — tip about inventory, first time you build — about building. Each system teaches itself on first interaction.
Requires separate FeatureTutorialTracker storing flags inventory_tutorial_shown, crafting_tutorial_shown etc. Architecturally simpler and more scalable than monolithic tutorial.
Work process
- Analyze mechanics — which actions critical for first session, what can be delayed
- Tutorial flow-scheme — sequence of steps, transition conditions, exit points (skip)
- Prototype — quick implementation with placeholders, test on 5–10 people outside team
- Analytics markup — events per step
- Full implementation — hint UI elements, animations, voice-over
- Iterate by data — after first week in production analyze drop-off, make fixes
| Scale | Duration |
|---|---|
| Simple linear tutorial (5–10 steps) | 3–7 days |
| Multi-step tutorial with complex logic | 2–4 weeks |
| Contextual tutorial system for several systems | 4–8 weeks |
Cost determined after analyzing game mechanics and onboarding requirements.





