System Model — Easy Chapter Generator

Four responsibilities, one progression owner

Easy Chapter Generator separates ordered data from scene detection. A ChapterManager chooses the Chapter and owns cross-scene concerns. A Chapter owns one ordered array. Each ChapterObjective record stores identity, eligibility, lifecycle work, and state. A scene Objective component or external script detects the game-specific condition and submits an exact completion request.

ChapterManagerWhich Chapter should run?

ChapterWhich ordered position is current?

ChapterObjectiveIs this position eligible, active, or terminal?

Scene component / UnityEvent / project codeHas this exact gameplay condition been satisfied?

Ordered record versus scene detector

Concern	Ordered Objective	Scene Objective component
Lives in	Serialized Chapter array	A GameObject in the scene
Owns	ID, title, state, conditions, delay, actions and events	Collider, timer, target list, branch signals, or custom mechanic
Starts progression	Only when selected by its Chapter	Never
Completes progression	Accepts an exact request while active	Requests through Objective Link
Can exist alone	Yes, if completion comes from UnityEvent or code	No meaningful completion without a matching ordered record

This distinction prevents a trigger, button, or third-party integration from silently changing the sequence. Detection can be replaced without changing progression identity.

The linear invariant

Within an active Chapter, at most one nonterminal Ordered Objective is current. Entries before it are Completed or Skipped; later entries remain Not Started. If an entry's required boolean conditions are not satisfied, the Chapter marks it Skipped and immediately evaluates the next entry. A request for any ID other than the exact active ID is rejected.

Not StartedEligibility checkActiveCompleted or SkippedNext position

Failure is separate: an accepted explicit failure changes the Chapter to Failed and marks the affected active or waiting Objective Failed. It does not choose a restart, load a scene, or modify saved terminal progress.

Where integrations belong

Use a UnityEvent when a component already exposes the exact signal you need. Use public Manager or Chapter methods when external code owns the decision. Derive from Objective when the scene needs a reusable detector with its own fields and reset state. Implement IPathMovementAdapter, INpcRouteAdapter, or IProgressStore only when replacing the corresponding project boundary.

Avoid a second script that keeps its own “current objective index.” It will diverge on skipped conditions, persisted progress, step-back, failure, or scene handoff. Read the current state from ChapterManager and let the active Chapter remain authoritative.

Ownership does not move when systems integrate

Responsibility	Owner	Observable result
Select startup and current progression	`ChapterManager`	One current Chapter ID, state, Objective ID, and transition flag
Advance one bounded sequence	`Chapter`	Exactly one eligible ordered position can accept completion
Store conditions, timing, actions, events, and terminal state	`ChapterObjective`	The row remains stable even when its scene detector changes
Detect a button, trigger, timer, placement, arrival, or custom mechanic	Scene component or project code	An exact request is submitted; the caller does not advance the list itself
Present dialogue, inventory, camera, input, movement, UI, and full save data	Your project	Game systems react to progression without being replaced by it

Scene loading does not transfer ownership to the source Chapter. The source Manager writes a one-use destination handoff, Unity loads the target scene, and that scene's Manager validates and consumes it before applying its Editor-only testing override or Default Chapter.

Worked model: a console followed by an exit zone

1
The Manager selects chapter_lab. The Chapter evaluates its first row, use_console.
2
A ButtonObjective linked to use_console receives the accepted UI choice and requests completion. It cannot choose the next row.
3
The Chapter accepts the exact active ID, runs that row's completion work, persists Completed, and activates reach_exit.
4
A TriggerObjective linked to reach_exit detects occupancy. The Chapter accepts it, reaches the end of the array, and reports Chapter completion.
5
The Manager plays Chapter feedback and applies the configured completion action. Project UI and camera code remain listeners, not progression owners.

Replace either detector without rewriting progression

The console may later use dialogue code and the exit may use a custom Objective. As long as each submits the same exact linked ID, the Chapter data, persistence keys, order, and completion policy stay valid.