Lifecycle Actions and Events — Easy Chapter Generator

Choose the lifecycle edge first

Every side effect should have one deliberate edge: Chapter start, Objective start, immediately before accepted Objective completion, Objective completion, Chapter completion, accepted failure, or before scene load. Placing the same effect on several edges produces duplicate audio, repeated activation, or callbacks that appear out of order.

Chapter startsObjective becomes ActiveStart gates finishStart actionsCompletion acceptedCompletion actionsChapter completes

Ordered Objective action order

Edge	Order inside the edge	Use for
Start	Transport → activate → deactivate → On Objective Start	Position actors, reveal task objects, notify UI
Completion	Persist terminal state → activate → deactivate → On Objective Completion → transport → optional success sound	Hide task props, reveal next cues, invoke project callbacks
Chapter completion	Persist Chapter → On Chapter Completion → Manager completion cue → completion action	Final UI, telemetry, explicit scene policy

The typed Chapter.ObjectiveCompleted event is raised before the current record runs completion actions. Use it when code needs the accepted index at that exact boundary.

Use UnityEvents for inspector-owned responses

UnityEvents are suitable for activating a project controller method, starting an animation, changing UI, or forwarding a completion signal. Persisted listeners are serialized with the scene. Keep the receiver and method stable across upgrades; if a method is intentionally replaced, migrate the listener before removing compatibility wrappers.

Do not bind the same response to both an Objective component's OnCompleted and the Ordered Objective's completion event unless it must happen twice.
Do not call a scene transition from OnBeforeSceneLoad; the Manager is already transitioning.
Do not treat OnFailure as a restart command. It is a notification after failure state is final.
When a result matters, call the typed C# method and inspect its return value instead of relying on a parameterless event.

Test events with observable receivers

During authoring, bind one temporary receiver that increments a counter or writes a distinctive message for each edge. Run one clean sequence, one skipped-condition sequence, one repeated completion request, and one failure. The start receiver must not run for skipped rows; completion receivers must run once for accepted completion; rejected duplicate calls must produce no lifecycle replay; failure listeners must run only after ChapterFailureResult.Failed.

Remove diagnostic listeners before release or keep them behind a project debug flag. Use Events and Event Order for the complete notification contract.