You are responsible for a comprehensive **first-hour, onboarding, new-player-experience, starter-state, and early-game flow polish pass**.

Your job is to make the opening experience clear enough that a genuinely new player can:

- begin playing without unnecessary confusion;
- understand the game's basic interaction language;
- perform the core actions required to progress;
- recognize early objectives;
- understand meaningful success and failure;
- recover after ignoring or misunderstanding guidance;
- reach representative enjoyable gameplay quickly enough to understand the game's appeal;
- continue learning through play rather than constant explanation.

The primary question throughout this task is:

> **What would confuse, stall, mislead, overwhelm, bore, or unnecessarily delay a genuinely new player during their first hour?**

Then fix those problems.

This is an **implementation task**, not merely an onboarding review.

Do not stop after:

- listing confusing moments;
- documenting onboarding problems;
- recommending tutorial prompts;
- identifying bad sequencing;
- producing a first-hour report;
- creating a UX backlog.

Inspect the actual opening experience.

Play or simulate it from fresh state.

Identify concrete friction.

Trace each problem to its underlying cause.

Implement the smallest effective correction.

Replay from fresh state.

Continue while meaningful, safely actionable first-hour problems remain.

Use continuously:

> **experience → identify friction → trace cause → implement → validate → replay from fresh state**

The goal is:

> **Leave behind the same game, but make its first hour substantially clearer, smoother, more engaging, easier to recover from, and less likely to lose players before they understand its appeal.**

---

# Onboarding Is Not a Tutorial Dump

Do not solve every problem by adding more text.

A strong opening usually teaches through:

- context;
- sequencing;
- interaction;
- environmental cues;
- consistent controls;
- objective design;
- feedback;
- progressive disclosure.

Avoid defaulting to:

- tutorial walls;
- giant instruction panels;
- repeated modal popups;
- long explanations before gameplay;
- permanent HUD clutter;
- excessive arrows;
- explanations of systems the player cannot use yet.

The goal is not:

> **explain the entire game immediately**

The goal is:

> **teach the next thing the player actually needs to understand.**

---

# Preserve Discovery

Do not remove healthy discovery.

Players may reasonably be expected to:

- inspect the environment;
- experiment;
- notice landmarks;
- explore;
- learn optional systems gradually;
- discover non-critical mechanics.

Fix confusion that blocks progress or misrepresents the game.

Do not eliminate all uncertainty.

A player asking:

> **What happens if I try this?**

can be good.

A player asking:

> **What am I supposed to do, and how could I possibly know?**

usually deserves investigation.

---

# Core Scope

Inspect onboarding required for **existing gameplay**.

Relevant areas may include:

## First Launch

- startup;
- account/character creation where applicable;
- first menu;
- initial loading;
- initial settings;
- first entry into gameplay.

## Starter State

- spawn location;
- inventory;
- equipment;
- currency;
- health/resources;
- unlocked abilities;
- quest/objective state;
- default settings;
- initial world state.

## Controls

- movement;
- camera;
- selection;
- interaction;
- inventory;
- combat;
- abilities;
- menus;
- context actions.

## Core Interaction Language

- clicking/selecting;
- targeting;
- interacting;
- approaching;
- attacking;
- gathering;
- crafting;
- looting;
- talking;
- opening menus.

Only include systems the game actually uses during the opening.

## First Objectives

- first task;
- first quest;
- first waypoint;
- first destination;
- first NPC;
- first combat encounter;
- first gathering interaction;
- first crafting interaction.

## Feedback

- success;
- failure;
- rewards;
- XP;
- item acquisition;
- level-up;
- objective progress;
- damage;
- interaction failure;
- cooldown/resource failure.

## Recovery

- lost player;
- ignored instructions;
- closed panels;
- abandoned objective;
- moved away from intended path;
- missing starter item;
- failed interaction;
- death;
- disconnect where applicable.

## Opening Pacing

- time before meaningful input;
- early travel;
- forced waiting;
- unnecessary setup;
- menu friction;
- repeated confirmation;
- backtracking;
- early grind.

Only inspect first-hour systems that actually exist.

---

# Explicitly Out of Scope

This is **not primarily**:

- a gameplay redesign;
- a full tutorial-system rewrite;
- a balance overhaul;
- a major progression redesign;
- a content expansion;
- a new feature sprint;
- a late-game UX pass;
- a visual-art overhaul;
- broad UI redesign;
- technical-debt cleanup;
- repository cleanup;
- broad accessibility work;
- broad performance optimization.

Small changes in adjacent systems are allowed when directly required to remove a first-hour blocker or meaningful onboarding problem.

Do not use onboarding work as justification to redesign the entire game.

---

# Preserve the Game's Identity

Do not make the game feel generic simply because generic onboarding conventions are familiar.

Preserve:

- tone;
- pacing;
- control style;
- exploration;
- mechanical identity;
- progression philosophy;
- visual language;
- humor;
- difficulty;
- intended player agency.

If the game is meant to feel:

- relaxed;
- mysterious;
- old-school;
- exploratory;
- skill-driven;
- minimalist;
- demanding;

the onboarding should support that identity.

Do not impose a modern tutorial-heavy structure without evidence.

---

# Fresh-Player Rule

Test from the closest practical equivalent to:

> **a brand-new player who knows nothing about the project.**

Where possible use:

- new account;
- new character;
- empty save directory;
- default settings;
- fresh profile;
- clean first-launch state.

Do not rely on:

- developer knowledge;
- remembered controls;
- known map layout;
- old save data;
- debug teleportation;
- hidden mechanics;
- prior familiarity with internal terminology.

Repeatedly ask:

> **How would a player know this?**

If the answer is only:

> **because the developer knows it**

investigate.

---

# Preserve Existing Work

Before making substantive changes, inspect version-control state where available.

Do not:

- overwrite unrelated modifications;
- revert unfamiliar work;
- remove existing onboarding work without understanding it;
- use destructive cleanup commands merely to simplify testing.

When current work overlaps first-hour systems:

1. inspect it;
2. determine apparent intent;
3. preserve that intent;
4. integrate carefully;
5. avoid replacing active work with speculative redesign.

---

# Investigate Before Asking Questions

Use the project as evidence.

Inspect relevant:

- first-run code;
- starter-state setup;
- spawn configuration;
- quest/objective data;
- prompts;
- UI;
- input maps;
- progression data;
- tutorial triggers;
- dialogue;
- navigation cues;
- world layout;
- save initialization;
- tests;
- documentation;
- complete sibling systems.

Ask for clarification only when:

- opening intent genuinely cannot be established;
- several materially different onboarding paths are equally plausible;
- a major product decision is required;
- changing early progression would significantly affect balance;
- required external systems are unavailable.

Do not ask questions merely because onboarding investigation takes effort.

---

# Runtime Experience Is the Strongest Evidence

Where practical, play the opening.

Do not judge first-hour quality only from:

- source code;
- quest text;
- objective definitions;
- UI files.

Observe:

- what appears on screen;
- when it appears;
- what the player can actually do;
- what feedback is received;
- how long transitions take;
- how the environment directs attention;
- whether guidance survives deviation.

If runtime testing is unavailable:

- state that limitation;
- use the strongest project evidence available;
- do not claim fresh-player behavior was directly observed.

---

# Implementation Over Auditing

The onboarding audit exists to produce an **implementation queue**.

Do not spend most of the task:

- documenting every first-hour event;
- writing tutorial philosophy;
- building giant journey maps;
- listing hypothetical new-player concerns.

Once a meaningful friction point is sufficiently understood:

> **fix it.**

Then restart from fresh state and verify the revised flow.

---

# Execution Strategy

Work autonomously where possible.

If the environment supports independent agents, workers, subprocesses, or fresh contexts, use them when they materially improve coverage.

Do not require delegation.

A single capable session must still be able to perform the pass sequentially.

Good independent investigation areas may include:

- first-launch flow;
- starter state;
- controls;
- first objective;
- navigation;
- HUD understanding;
- early failure/recovery;
- first reward;
- opening pacing.

Serialize changes to shared:

- opening sequence;
- starter inventory;
- progression state;
- spawn;
- first quest;
- tutorial infrastructure;
- persistence;
- multiplayer account initialization.

Do not let independent workstreams create contradictory onboarding.

Use fresh-context reviewers where possible because prior project knowledge makes onboarding problems easy to miss.

---

# Onboarding Priority Queue

## P0 — Hard New-Player Blocker

Examples:

- cannot progress;
- broken fresh save;
- required starter item missing;
- impossible first objective;
- required NPC absent;
- softlock;
- broken spawn;
- first interaction impossible;
- first quest cannot advance.

Fix immediately.

## P1 — Major Quit Risk

Examples:

- core mechanic unexplained and not discoverable;
- objective points to wrong location;
- control instruction is incorrect;
- required system appears unusable;
- player is likely to become permanently lost;
- first important reward appears meaningless;
- starter state contradicts expected flow.

Prioritize heavily.

## P2 — Meaningful Friction

Examples:

- poor sequencing;
- early information overload;
- unnecessary travel;
- redundant clicks;
- unclear navigation;
- weak feedback;
- excessive menu friction;
- avoidable backtracking;
- recovery is unnecessarily difficult.

Fix where worthwhile.

## P3 — Finishing Polish

Examples:

- wording;
- prompt timing;
- minor first-use clarity;
- small pacing adjustments;
- minor redundant instruction.

Address after larger problems.

---

# Walk the Opening Step by Step

For every important opening step ask:

1. **What should the player understand or do?**
2. **What information does the player currently have?**
3. **What action is expected?**
4. **How can the player discover that action?**
5. **How is success confirmed?**
6. **How is failure explained?**
7. **What leads naturally to the next step?**

When the chain breaks, determine why.

Possible root causes:

- missing information;
- wrong sequencing;
- poor environment cue;
- bad starter state;
- inconsistent controls;
- weak feedback;
- missing recovery;
- objective ambiguity;
- UI clutter;
- unnecessary friction.

Fix the root cause rather than immediately adding text.

---

# First 60 Seconds Test

Inspect the first minute carefully.

Ask:

- Can the player get into gameplay promptly?
- Can they move?
- Can they orient themselves?
- Is there an obvious nearby thing worth interacting with?
- Does the interface immediately overwhelm them?
- Are controls shown when they become relevant?
- Does something communicate the game's identity quickly?

Look for:

- long dead time;
- unnecessary menus;
- repeated confirmations;
- unclear spawn orientation;
- cluttered first screen;
- too many simultaneous prompts.

Do not require immediate spectacle.

Require meaningful player agency.

---

# First Spawn Review

Inspect what the player sees immediately after spawning.

Ask:

- Where is the camera facing?
- What is visually prominent?
- Is the expected route visible?
- Is the first NPC/object easy to distinguish?
- Is the player facing away from the intended destination?
- Is the first objective immediately contradicted by world composition?

A correct objective can still fail if the environment communicates something else.

---

# Starter-State Audit

Validate fresh-player:

- inventory;
- equipment;
- currency;
- health;
- resources;
- spawn;
- skills;
- unlocks;
- abilities;
- quest state;
- settings;
- character state.

Look for:

- missing required item;
- duplicate item;
- obsolete starter item;
- equipment not equipped as intended;
- unusable starter equipment;
- contradictory unlock;
- accidental debug currency;
- stale quest flag;
- incorrect default.

Starter-state bugs often masquerade as onboarding problems.

Fix the state rather than explaining around it.

---

# First Control Test

Determine which controls a player genuinely needs first.

Teach them close to first use.

Avoid front-loading:

- every hotkey;
- every menu;
- advanced camera controls;
- optional systems;
- combat actions before combat exists;
- crafting controls before crafting exists.

Ask:

> **What is the minimum control knowledge needed for the next meaningful action?**

Teach that.

Then continue.

---

# Input Prompt Accuracy

Verify every first-hour control reference against actual bindings.

Look for:

- outdated keys;
- old interaction names;
- missing controller equivalent where supported;
- platform-specific mismatch;
- instruction referring to removed input;
- UI text hardcoded independently from input mappings.

Where practical, derive prompts from authoritative binding data.

Do not create a large input-remapping architecture just for onboarding.

---

# First Interaction Test

The first meaningful interaction should help teach the game's broader interaction language.

Examples:

- click/select NPC;
- interact with object;
- approach resource;
- choose dialogue;
- collect item.

Ask:

- Does the player understand what is interactable?
- Is the interaction method discoverable?
- Does the game visibly respond?
- Does the player learn a pattern that transfers elsewhere?

A first interaction that behaves unlike the rest of the game teaches the wrong lesson.

---

# Interaction Language Consistency

Early interactions should establish reliable expectations.

If several interactions use the same basic concept:

- selecting;
- clicking;
- approaching;
- confirming;

their early behavior should be coherent.

Do not teach special-case onboarding controls that disappear immediately afterward unless necessary.

---

# First Objective Test

Inspect the first objective.

Ask:

- What exactly is the player expected to do?
- Where must they go?
- What object/NPC/system is involved?
- How can they identify it?
- What happens after completion?

The objective should usually provide enough:

> **what / where / how / why**

to act.

It does not need to remove all exploration.

---

# Objective Text Quality

Remove or correct:

- ambiguous verbs;
- internal developer terminology;
- incorrect controls;
- references to renamed systems;
- duplicate instructions;
- excessive prose hiding the actual action;
- objective descriptions that assume unavailable knowledge.

Preserve:

- flavor;
- tone;
- story;
- character voice.

Do not rewrite dialogue merely because it could be shorter.

Rewrite only when it directly causes onboarding failure or serious confusion.

---

# Objective Tracking

Where objective tracking exists, verify:

- objective appears when relevant;
- state updates;
- completion is visible;
- obsolete objective disappears;
- incorrect old text is not retained;
- returning to the objective after diversion still works.

Do not add a quest tracker if the game intentionally does not use one.

Improve existing behavior.

---

# First Core Loop Test

Determine when the player reaches gameplay representative of the game's actual appeal.

Possible core loops include:

- combat;
- gathering;
- crafting;
- exploration;
- questing;
- social interaction;
- character progression.

Ask:

> **How long before the player experiences something that meaningfully represents why this game is enjoyable?**

Look for unnecessary delays caused by:

- travel;
- setup;
- menus;
- dialogue;
- trivial errands;
- forced waiting;
- redundant prerequisites.

Do not artificially rush intended atmosphere or narrative.

Remove friction that delays the actual game without adding value.

---

# First Success Feedback

When the player succeeds at an early action, verify they can tell.

Examples:

- objective updates;
- XP appears;
- resource enters inventory;
- enemy dies;
- level increases;
- crafting succeeds.

Avoid success that occurs invisibly.

The player should understand:

> **my action worked**

without requiring developer knowledge.

---

# First Reward Test

Inspect the first meaningful reward.

Ask:

- What did the player receive?
- Where did it go?
- Is the change visible?
- Why does it matter?
- What can the player do with it?
- Does it naturally lead toward the next action?

Do not explain the whole economy.

Make the immediate meaning understandable.

---

# XP / Progression Feedback

If the player receives early XP or progression:

- verify it is visible enough;
- verify the relevant skill/stat is understandable;
- verify level-up feedback makes sense;
- verify the player can discover where progress is shown.

Do not add constant progress popups merely because progression exists.

---

# First Failure Test

Cause an early realistic failure.

Examples:

- attack stronger enemy;
- try without required resource;
- move out of range;
- fill inventory;
- click unavailable object;
- fail an action;
- die.

Ask:

- Is failure understandable?
- Can the player recover?
- Does the feedback teach something useful?
- Is the player trapped?

Failure can teach.

Failure should not silently dead-end the opening.

---

# Death / Respawn Review

If death is realistically possible in the first hour, test it.

Verify:

- respawn works;
- objective state remains valid;
- starter items are handled correctly;
- player knows how to continue;
- early progress is not accidentally destroyed;
- respawn location does not strand the player.

Do not make death consequence-free if punishment is intentional.

Focus on recoverability.

---

# Recovery Test

Deliberately ignore onboarding.

Examples:

- walk the wrong way;
- close the panel;
- skip dialogue;
- abandon the obvious route;
- cancel an interaction;
- reopen the game;
- die;
- return after distraction.

Ask:

> **Can the player recover without external documentation?**

The opening should not depend on the player following one exact script perfectly.

---

# Lost-Player Recovery

If the player walks away from the intended path:

- can they identify the objective again?
- can they reopen relevant information?
- does the map/world provide useful orientation?
- can they find the necessary NPC/object?
- does returning still trigger correctly?

Avoid overusing:

- giant arrows;
- glowing trails;
- hard teleportation;

unless already part of the game's visual language.

Prefer persistent world readability where possible.

---

# Reopenability

Important onboarding information should usually be recoverable if closed accidentally.

Examples:

- controls reference;
- objective;
- tutorial note;
- quest description.

Do not require every one-time prompt to be permanently accessible.

But avoid making critical information disappear forever after one accidental dismissal.

---

# Information Budget

Treat player attention as limited.

For every prompt ask:

> **Does the player need this information right now?**

If no:

- delay it;
- remove it;
- move it to contextual UI;
- let normal gameplay reveal it later.

Players cannot meaningfully absorb several unfamiliar concepts simultaneously.

---

# Progressive Disclosure

Prefer:

> **teach → use → reinforce → expand**

over:

> **explain everything → hope the player remembers**

Example:

1. teach movement;
2. use movement;
3. teach interaction;
4. use interaction;
5. introduce inventory when the player receives an item;
6. introduce crafting when they reach crafting.

Adapt this pattern to the actual game.

---

# Prompt Timing

A prompt appearing too early may be as ineffective as one appearing too late.

Check whether instructions appear:

- before relevant system exists;
- during another important event;
- after player already failed;
- simultaneously with several other prompts.

Move guidance toward the moment of relevance.

---

# Tutorial Modal Review

Inspect modal tutorial windows.

Ask:

- Does gameplay need to stop for this?
- Is the information critical?
- Could contextual UI teach it instead?
- Does it repeat something already obvious?
- Will players immediately dismiss it unread?

Keep modal interruptions only when justified.

---

# Persistent UI Versus Tutorial Fix

If information is relevant throughout the game, do not repeatedly teach it through one-time onboarding text.

Examples:

- current objective;
- cooldown state;
- health;
- inventory capacity;
- resource requirement.

If the persistent interface is unclear:

> **fix the persistent interface**

rather than adding a tutorial explaining the unclear interface.

---

# HUD Introduction Pass

Inspect what appears on the HUD at first spawn.

Ask:

- Which elements are immediately relevant?
- Which concepts are unexplained?
- Which can wait?
- Is important state visually buried?

Do not necessarily hide later-game UI.

But avoid forcing the player to understand everything at once.

---

# First Menu Use

If the opening requires using a menu:

- make the correct entry discoverable;
- ensure the menu opens reliably;
- ensure the target control is understandable;
- ensure closing/reopening works;
- avoid requiring unnecessary submenus.

A first-hour objective should not become a menu-navigation puzzle unless that is intentional gameplay.

---

# Inventory Introduction

When inventory first matters, ensure the player can understand:

- where acquired items appear;
- how to select/use them;
- whether capacity matters;
- what the relevant visual state means.

Do not explain every item type immediately.

Teach only what the current action needs.

---

# Equipment Introduction

If equipment is required early:

- ensure starter equipment exists;
- make equip behavior discoverable;
- ensure requirements are understandable;
- confirm stat/application feedback;
- avoid requiring an obscure equipment workflow without guidance.

Do not teach advanced build theory.

---

# Combat Introduction

If combat appears during the first hour, inspect:

- target selection;
- attack initiation;
- range;
- health;
- damage feedback;
- death;
- rewards;
- target switching;
- disengagement where necessary.

The first fight should teach the game's real combat language.

Do not make it a separate tutorial-only combat system.

---

# Gathering Introduction

If gathering appears early, inspect:

- how resource nodes are recognized;
- tool requirements;
- interaction;
- repeated action;
- reward;
- XP;
- depletion;
- inventory interaction.

Teach the reusable interaction pattern.

Do not overexplain resource tiers or later skill progression.

---

# Crafting Introduction

If crafting appears early, inspect:

- where crafting happens;
- recipe selection;
- required ingredients;
- output;
- XP;
- failure;
- inventory interaction.

Avoid making the first recipe require unexplained prerequisite chains.

---

# NPC / Dialogue Introduction

If NPC interaction matters early:

- make interactable NPCs recognizable;
- ensure dialogue advances predictably;
- make important options understandable;
- ensure closing dialogue does not trap state;
- ensure objective progression follows correctly.

Do not rewrite story simply to shorten onboarding.

---

# Navigation Pass

Inspect early movement between objectives.

Ask:

- Is the destination visible?
- Is there a landmark?
- Is the route obvious enough?
- Does the objective give useful orientation?
- Are there misleading paths?
- Does the environment visually support the route?

Prefer:

- landmarks;
- paths;
- signs;
- environmental framing;
- consistent map markers;

over excessive textual directions.

---

# Opening Landmark Review

Important early destinations should be distinguishable.

Examples:

- central building;
- trainer;
- resource area;
- crafting station;
- gate;
- quest NPC.

If the player must visit an important destination immediately, ensure it does not visually disappear into generic surroundings.

---

# Starter Area Density

Inspect whether the starter area is:

- too empty;
- too cluttered;
- visually confusing;
- packed with irrelevant interactables;
- full of systems the player cannot understand yet.

The first location should communicate useful priorities.

Do not remove world richness merely to create a tutorial zone.

---

# Sequencing Audit

Look for systems introduced in the wrong order.

Examples:

- objective requires tool before player can acquire tool;
- crafting introduced before resources;
- inventory explanation before any item exists;
- UI references skill system not yet relevant;
- combat reward explained before first combat;
- shop introduced before player owns currency.

Prefer fixing sequence over adding explanation.

---

# Prerequisite Timing

For each early objective trace:

> **objective → requirements → acquisition → execution → reward**

Look for prerequisites introduced too late.

Examples:

- required item not provided;
- level requirement impossible;
- necessary NPC unavailable;
- tool comes after the action requiring it;
- currency required before first source exists.

Fix root sequencing.

---

# Early-System Overload

Look for several systems unlocking simultaneously.

Examples:

- crafting;
- skills;
- inventory;
- equipment;
- quests;
- map;
- abilities;

all appearing at once.

Ask whether the player actually needs each concept immediately.

Delay introduction where safe.

Do not necessarily delay the underlying functionality if discovery is intended.

---

# Early Travel Friction

Inspect required travel during the first hour.

Look for:

- long empty walks;
- repeated backtracking;
- route with no meaningful activity;
- destination difficult to identify;
- starter task sending player unnecessarily far away.

Do not eliminate travel if exploration is part of the game.

Remove travel that delays understanding without contributing anything.

---

# Waiting Friction

Look for first-hour:

- long timers;
- excessive cooldowns;
- mandatory waiting;
- loading delays caused by avoidable flow;
- repetitive action loops before meaningful reward.

Do not broadly rebalance timing.

Correct obvious early friction that prevents players from reaching representative gameplay.

---

# Menu Friction

Count unnecessary early interactions such as:

- repeated confirmations;
- redundant screen changes;
- opening several panels;
- closing modal after modal;
- repeated item selection.

Where workflow can be simplified without redesigning mechanics, reduce unnecessary friction.

---

# Backtracking Review

Early backtracking is especially expensive because the player does not yet understand the world.

Ask:

- Does the backtracking teach something?
- Does the environment change?
- Is there new gameplay?
- Is it merely returning to the same NPC after every tiny step?

Preserve deliberate quest structure.

Remove gratuitous first-hour repetition where safe.

---

# First-Hour Grind Review

Do not rebalance the whole progression system.

But inspect whether the first hour forces repetitive grinding before the player can understand the broader game.

Examples:

- gathering many identical resources before crafting once;
- killing excessive enemies before unlocking anything;
- repeating a trivial action too many times before new context appears.

If clearly excessive, make the smallest targeted adjustment.

---

# First-Use Feedback

For every major system first encountered, verify the first successful use communicates what occurred.

Examples:

- interaction;
- combat;
- gathering;
- crafting;
- item use;
- equipment;
- XP;
- currency.

This does not require a tutorial popup.

Often:

- animation;
- UI response;
- sound;
- state change;
- concise message;

is enough.

---

# Terminology Review

Look for early use of:

- internal names;
- unexplained abbreviations;
- lore terms treated as mechanics;
- inconsistent terminology;
- system names the player has never encountered.

Do not strip flavor.

Ensure mechanically necessary language is understandable in context.

---

# Error Message Review

First-hour errors should be actionable.

Weak:

> **Invalid action**

Better, when appropriate:

> **You need a pickaxe to mine this.**

Do not expose internal implementation terminology.

Do not overexplain obvious failures.

---

# Objective Completion Feedback

When an early objective completes:

- update state promptly;
- make completion visible;
- avoid leaving obsolete directions;
- clearly expose the next step.

A completed objective remaining on screen can make players repeat finished actions.

---

# Objective Chain Continuity

Inspect transitions between early objectives.

Avoid gaps such as:

1. objective completes;
2. nothing happens;
3. player has no reason to know where to go next.

Not every game needs a constant objective chain.

But if the opening intentionally follows one, ensure the transitions are coherent.

---

# First Session Save / Resume

If saving or persistent accounts exist, test:

1. start fresh;
2. progress partially through onboarding;
3. exit/disconnect;
4. return.

Verify:

- objective state survives;
- starter items are not duplicated;
- completed tutorials do not repeat incorrectly;
- necessary guidance is still recoverable;
- player is not stranded halfway through a sequence.

---

# Multiplayer New-Player State

If multiplayer exists, test fresh-player onboarding under actual multiplayer conditions where practical.

Inspect:

- spawn;
- other players nearby;
- shared resources;
- NPC availability;
- objective state;
- server persistence;
- reconnect.

Do not redesign multiplayer onboarding unless current multiplayer behavior breaks the opening.

---

# Fresh-State Data Integrity

Confirm fresh-account initialization happens exactly once.

Look for:

- duplicate starter items;
- duplicated currency;
- repeated first rewards;
- repeated introductory quest creation;
- missing initialization after reconnect;
- initialization triggered on every login.

Treat progression duplication/loss as high severity.

---

# Sibling Comparison

Use well-functioning later systems as evidence.

If a first-hour version of a system behaves differently, ask whether that difference is intentional.

Examples:

- first interaction versus normal interaction;
- first combat versus normal combat;
- first gathering versus normal gathering;
- tutorial inventory versus regular inventory.

Avoid teaching behavior the player must immediately unlearn.

---

# Pattern-Based Friction Hunt

When one onboarding problem is found, search for the same pattern nearby.

Examples:

If one objective references a renamed control:

> inspect other opening objectives.

If one starter item is missing:

> inspect all starter-state initialization.

If one prompt appears before its mechanic:

> inspect other tutorial triggers.

If one recovery path fails after panel closure:

> inspect other first-hour panels.

Do not blindly replicate fixes.

Search for repeated assumptions.

---

# Fresh-Context Review

Where practical, use a reviewer or test context with as little prior knowledge of the project as possible.

Give no unnecessary internal explanation first.

Ask them to evaluate:

- where they hesitate;
- what they misunderstand;
- what they cannot find;
- what they ignore;
- where they become overloaded;
- what seems boring;
- where they would consider quitting.

Require concrete evidence.

For each meaningful finding establish:

## Moment

Where in the opening does it occur?

## Expected Understanding

What should the player know?

## Actual Problem

What causes confusion or friction?

## Evidence

What in the current experience creates the problem?

## Fix

What is the smallest effective correction?

Do not accept generic:

> **onboarding could be clearer**

feedback.

---

# Work in Onboarding Waves

Do not change every first-hour element simultaneously.

## Wave A — Hard Blockers and Starter State

Fix:

- broken spawn;
- missing items;
- impossible objectives;
- bad initialization;
- softlocks;
- incorrect prerequisite state.

Validate from fresh state.

## Wave B — First 5–10 Minutes

Polish:

- first movement;
- first interaction;
- first objective;
- first route;
- first useful UI.

Validate from fresh state.

## Wave C — Core Loop Introduction

Ensure the player reaches and understands representative:

- combat;
- gathering;
- crafting;
- questing;
- exploration;

where those systems actually belong in the opening.

Validate.

## Wave D — Rewards, Failure, and Recovery

Test:

- reward understanding;
- mistakes;
- death;
- ignored guidance;
- navigation failure;
- panel closure;
- save/resume.

Validate.

## Wave E — Pacing and Friction

Remove unnecessary:

- travel;
- waiting;
- backtracking;
- menu steps;
- confirmations;
- early grind;
- information overload.

Validate.

## Wave F — Last 10%

Polish:

- wording;
- timing;
- prompt duplication;
- stale objective text;
- small navigation issues;
- redundant explanations.

---

# Reassess After Every Wave

Replay from fresh state.

Ask:

- Where would I hesitate?
- What assumes prior knowledge?
- What appeared before I needed it?
- What did I need but was never taught?
- What guidance did I ignore?
- What objective was unclear?
- Where did the pace drag?
- When did I first understand what is fun about the game?
- Can I recover after making a mistake?
- Did we add too much explanation?
- Did we remove useful discovery?

Reprioritize.

---

# Productive Onboarding Loop

Do not stop after the first obvious friction fixes.

Changes expose new layers.

Examples:

- correcting spawn reveals unclear objective;
- objective fix reveals poor path visibility;
- path fix reveals overlong travel;
- travel fix reveals weak first reward;
- reward fix reveals unclear progression UI.

Continue:

> **experience → identify friction → trace cause → implement → validate → replay from fresh state**

while meaningful first-hour problems remain.

Do not manufacture tutorials merely to continue working.

Stop when remaining findings are:

- minor;
- subjective;
- intentional discovery;
- dependent on major new content;
- dependent on broader progression redesign;
- outside first-hour scope.

---

# Anti-Overtutorial Review

Before completion, explicitly review whether the onboarding became excessive.

Ask:

- Did prompts become too frequent?
- Did modal interruptions increase?
- Are obvious actions now overexplained?
- Did discovery disappear?
- Is the player reading more than playing?
- Did onboarding become slower?
- Did permanent HUD clutter get added for a temporary issue?
- Are systems explained before they are relevant?
- Does the game now feel patronizing?

Remove unjustified instruction.

---

# Anti-Hand-Holding Review

Do not confuse clarity with constant direction.

Ask whether the player can:

- understand the goal;
- recognize available actions;
- recover from mistakes;

without being continuously told exactly where to click.

Preserve agency.

---

# Anti-Scope-Creep Review

Before completion inspect changes made during the pass.

Undo work that:

- redesigned core mechanics;
- materially rebalanced progression without necessity;
- introduced new features;
- built a giant tutorial framework;
- rewrote late-game systems;
- removed meaningful exploration;
- made the game substantially more linear;
- added speculative onboarding content.

Ask:

> **Was this required to help a new player understand and progress through the existing opening?**

If not, reconsider it.

---

# Regression Review

After onboarding changes verify:

- normal returning-player behavior;
- save/load;
- first quest;
- starter inventory;
- progression;
- interactions;
- UI;
- controls;
- multiplayer initialization where applicable.

Do not break the actual game to improve the tutorial.

---

# Final Fresh-State Validation

Before finishing, perform the closest practical equivalent of a complete fresh first-hour run.

Validate:

1. first launch;
2. fresh spawn;
3. initial controls;
4. first interaction;
5. first objective;
6. first representative core loop;
7. first reward;
8. first realistic failure;
9. recovery after deviation;
10. save/exit/reload where applicable;
11. transition out of onboarding into normal play.

Do not rely on debug skipping unless a specific test requires it.

---

# Completion Standard

The first-hour/onboarding pass is complete when, to the degree available testing can establish:

1. fresh-player initialization works;
2. no known opening softlock remains;
3. required starter items/state are correct;
4. basic controls are discoverable;
5. the game's core interaction language is understandable;
6. the first meaningful objective is actionable;
7. important objective transitions are coherent;
8. navigation through the opening is reasonably clear;
9. early UI does not require excessive prior knowledge;
10. first success produces understandable feedback;
11. first meaningful reward is interpretable;
12. representative core gameplay is reached at an appropriate pace;
13. realistic early failure is recoverable;
14. ignoring guidance does not permanently strand the player;
15. unnecessary early friction is reduced;
16. unnecessary information overload is reduced;
17. prompts appear near relevant moments;
18. incorrect/outdated onboarding instructions are removed;
19. save/resume during the opening works where applicable;
20. returning-player behavior is not broken;
21. meaningful discovery remains;
22. the game has not been turned into an overexplained tutorial;
23. no discovered P0/P1 first-hour issue remains unresolved without an explicit blocker;
24. no known regression introduced by onboarding work remains.

The objective is not:

> **make it impossible for a player to ever be confused**

The objective is:

> **give a genuinely new player enough information, sequencing, feedback, and recovery to understand the game's basic language and reach its appeal without unnecessary friction or hand-holding.**

---

# Final Report

When complete, provide a concise onboarding report.

## 1. Overall Result

Summarize the most important improvements to the first-hour experience.

## 2. Opening Flow Changes

Describe meaningful changes to:

- first launch;
- spawn;
- first interaction;
- first objective;
- transition into core gameplay.

## 3. Mechanics Clarified

Describe which core mechanics became easier for a new player to understand.

## 4. Starter-State Fixes

Summarize relevant:

- inventory;
- equipment;
- currency;
- spawn;
- quest state;
- unlock;
- default-setting;

corrections.

## 5. Pacing and Friction

Describe improvements involving:

- travel;
- waiting;
- menus;
- confirmations;
- backtracking;
- early grind;
- information overload.

## 6. Failure and Recovery

Summarize how early mistakes, ignored guidance, navigation errors, death, panel closure, or other relevant recovery scenarios were improved.

## 7. Fresh-State Validation

State exactly what was actually tested, including relevant:

- new accounts/characters;
- fresh saves;
- first-launch flows;
- objective progression;
- interactions;
- rewards;
- failures;
- save/resume;
- multiplayer onboarding.

Do not imply testing occurred when it did not.

## 8. Discovery Preserved

Describe important places where guidance was deliberately kept restrained to preserve:

- exploration;
- experimentation;
- game identity;
- player agency.

## 9. Deliberately Unchanged

Describe noteworthy friction or ambiguity preserved because:

- it appears intentional;
- it supports discovery;
- evidence was insufficient;
- correcting it would require broader redesign;
- another specialized pass should own it.

## 10. Remaining Risks

List only meaningful unresolved first-hour risks.

For each include:

- **Moment/System**
- **Problem**
- **Severity**
- **Why unresolved**
- **Recommended next action**

Do not pad this section with microscopic wording preferences.

---

# Final Directive

**Do not ask how to explain the whole game.**

Ask:

> **What does the player need to understand next, and what is the cleanest way for the game itself to teach it?**

Do not assume developer knowledge.

Do not front-load future systems.

Do not solve bad sequencing with more text.

Do not solve unclear permanent UI with one-time tutorials.

Do not turn discovery into instructions.

Do not make the opening slower through excessive explanation.

Repeatedly ask:

> **How would a brand-new player know this?**

> **What does the player need right now?**

> **What is the cleanest way to communicate it through play?**

> **Can the player tell whether their action worked?**

> **What happens if they ignore the guidance?**

> **Can they recover after a mistake?**

> **How long until they experience what is actually appealing about the game?**

Continue:

> **experience → identify friction → trace cause → implement → validate → replay from fresh state**

while meaningful first-hour friction remains.

Leave behind the **same game**, but make its first hour substantially clearer, smoother, more engaging, more recoverable, and less likely to lose players before they understand its appeal.