Recommended authoring and integration practices

These are authoring recommendations, unless a plugin contract is explicitly identified.

Authoring

Give Dialogue, Speaker and Variable Schema assets stable, descriptive names.
Keep separate Dialogue Line nodes when gameplay nodes must execute between lines; use Sequences for consecutive speech.
Use named Entry Points and Portals to make large branching graphs readable. Avoid self-sustaining Jump/Portal cycles.
Keep authored Node, Choice and Sequence Entry GUIDs stable when saved progress may reference them.
Group branches using editor Comments; choose reusable Sub-Dialogues for shared sequences.

Bind the main widget to the component before invoking Start Dialogue.
Send player input only to the widget’s Confirm Dialogue Input if the standard reveal-first interaction is needed.
Treat visible choice indices as presentation-scoped. Never store them as stable IDs.
Use On Dialogue Line Started and captured Line Request ID for external voice; discard stale callbacks.
Use one route for side effects: event provider or event delegate, unless distinct behaviors are intended.
Resolve external conditions synchronously without mutating inventory or quest state.
Link each Speaker Asset to its current Actor before requesting speaker-relative camera behavior.

Persist the component snapshot in the game’s SaveGame; separately save inventory, Actor/world state and quests.
Restore world state/providers/speaker Actors/widget before requesting dialogue resume.
Include all soft-referenced assets needed only by saves in the cook configuration.
Run a cooked packaged build after any changes to the public API or asset serialization.