Ordered Objectives

The ordered record is the progression contract

A ChapterObjective is not a MonoBehaviour. It is the serialized record inside a Chapter that gives one position a title, stable identifier, conditions, timing gate, start work, completion work, sound choice, and runtime state. The list order determines progression; hierarchy order of scene GameObjects does not.

An Ordered Objective can be completed by an included scene component, a custom Objective subclass, a UnityEvent that calls a public entry point, or external code that calls the active Chapter. It therefore remains useful even when no scene-side detector is needed.

From eligibility to visible start

1. Evaluate conditionsRequired True State must be true; Required False State must be false. Empty fields impose no condition.
2. Skip or activateAn ineligible entry becomes Skipped and persists that terminal state. An eligible entry becomes Active.
3. WaitThe unscaled Start Delay elapses, then an optional external-animation gate waits for SignalExternalAnimationCompleted.
4. Run start workTransport actions execute, objects activate/deactivate, and On Objective Start fires.

The state becomes Active before delayed start work executes. A completion request can therefore be accepted while the coroutine is waiting; accepted completion stops that pending start routine so late start actions cannot fire afterward.

Accepted completion order

1. Typed Chapter signalObjectiveCompleted(index) is raised immediately before completion actions.
2. Terminal state and persistenceThe record becomes Completed and writes its exact progress token.
3. Scene actionsConfigured objects activate or deactivate, then On Objective Completion is invoked.
4. Transport and audioCompletion transport actions run; optional success feedback plays unless this is a step-back operation.
5. AdvanceThe Chapter evaluates the next ordered position or completes itself.

Calling TryCompleteObjective(id, false) uses the same acceptance check but marks the row Skipped and omits completion actions. This is an intentional control operation, not a shortcut for a component that should complete normally.

Stable IDs and scene copies

The Identifier is compared with StringComparison.Ordinal; spelling and case must match exactly. The Editor generates identifiers and exposes Copy ID for integrations, but the assisted Objective Link selector should be preferred for scene components. Duplicating an Ordered Objective creates another progression entry; duplicating a linked scene component can create two detectors bound to the same entry, which Validation reports as a duplicate binding.

Deleting the record leaves a linked scene component without a valid target. Moving the component to another Chapter hierarchy does not change its serialized ID automatically; use the assisted repair controls and re-run Validation.

Order and editing controls are part of behavior

The generated container is an authoring convenience, not the data record. It may hold zero, one, or several scene components, and an Ordered Objective may have no container at all when UnityEvents or project code provide completion. Keep unrelated gameplay objects outside it so duplication and deletion remain understandable.

Five states and one active position

Only one row can be Active, even during Start Delay or Wait For External Animation. Those gates delay start actions; they do not make another row eligible. SignalExternalAnimationCompleted() releases the wait but does not complete the Objective.

Three supported completion paths

All three routes converge on the same acceptance guard. A component may detect a condition early, a UI event may fire twice, or network code may repeat a callback; none can complete a later, missing, already terminal, or differently linked row. See Objective Link and the compiled external-completion example in Complete and Control Progression.

Persistence and idempotency

Completed and Skipped are written under the exact Chapter and Objective identifiers. Hydration applies those states without running old start actions, completion actions, UnityEvents, transport, or sounds. Active and Failed are temporary. A row stored as Completed or Skipped is passed over when a Chapter resumes; the next nonterminal row is evaluated normally.

Idempotency is enforced at the progression boundary: the first valid exact request advances; subsequent calls return false because the Chapter already moved. Component-local IsCompleted also suppresses repeated OnCompleted emission after acceptance. Callers that trigger visual or save consequences should react only to the accepted result or documented lifecycle event.

Example: one Chapter with four different rows

1. 1
   Add Inspect panel and complete it from a ButtonObjective. Its completion action enables a generator.
2. 2
   Add Charge generator with Required True State panel_read, a two-second Start Delay, and a MultiActionObjective requiring POWER and COOLING.
3. 3
   Add Wait for door animation, enable Wait For External Animation, and release it from the Animation Event. Complete it later from the door controller.
4. 4
   Add Reach exit with a TriggerObjective. Leave its success sound enabled and use On Objective Completion to hide the marker.
5. 5
   Test with panel_read true and false. The second row should be Active in the first run and Skipped in the second; no later row should ever become active at the same time.

Validation and focused diagnosis