Authoring and editor lifecycle
Authoring assets describe what Unity should build. They are not the live board used during play.
flowchart TB
accTitle: Authoring asset and runtime build lifecycle
accDescr: Inspector edits change authored assets, validation reports problems, and a successful build creates runtime state independent of those assets.
A["Authored assets"] --> I["Inspector edits"]
I --> A
A --> V["Validation and preview"]
V -->|valid| R["New runtime state"]
V -->|problems| I
Asset roles
- GridBoardAsset describes topology, cells, and definition-level configuration.
- Structure and library assets describe reusable structures.
- GridBoardSetupAsset combines a board, starting placements, and runtime profiles.
- GridBoardAuthoring builds the setup and owns the resulting live state for a scene.
Preview and rebuild
An Inspector edit changes serialized input. A preview is temporary and can be rebuilt at any time. Read GridAuthoringBuildReport before assuming an asset is valid.
A successful build creates runtime state independent of the serialized assets. Editing an asset afterward does not change an existing state. Rebuild the authoring state before relying on the edited values at runtime.
Undo and registration
Built-in Grid Toolkit editors record one logical serialized edit as one Unity Undo operation. Runtime actions are not Unity Undo operations.
Editor registrations may be recreated after script reload. Project-owned adapters must register idempotently and release callbacks they own. Reopen a preview or rebuild state after a reload when the previous result is stale.
What authoring does not own
Keep gameplay state out of assets, preview objects, and editor registries. Preserve serialized type names and project-owned IDs when data compatibility matters. Advanced topology authoring and editor adapter safety rules belong in Authoring and editor adapters.