Authored data assets

This page is the storage half of an authored pipeline: where the data lives, how it references other data, and how it stays readable in version control. The editing half (inspectors, drawers, windows) follows below.

ScriptableObjects hold the data

• DATA-IN-A-SCRIPTABLEOBJECT (HARD). Tunable data that is not tied to one GameObject goes in a class derived from ScriptableObject, created as .asset files. Unity's Manual describes ScriptableObjects as assets that exist in the project independent of GameObjects, which you can drag or pick into fields in the Inspector, and whose main value is as a data store (ScriptableObject data assets).
• One instance per thing. One .asset per enemy type, weapon, level config or wave table, so each one diffs, reviews and reverts on its own. A single giant asset that holds every item becomes one unreadable diff.
• Add the Create menu entry. Put [CreateAssetMenu] on the class so a human can make a new instance from Assets > Create without an agent. The Manual's example uses exactly this attribute.
• Shared, not copied. Prefabs reference the ScriptableObject instead of carrying their own copy of the numbers. The Manual notes that every prefab instance with data in a MonoBehaviour gets its own copy, while a ScriptableObject keeps one copy in memory that all of them reference.
• Writes from code are dirtied. When an editor script changes a ScriptableObject in Edit mode, call EditorUtility.SetDirty on it. The Manual states Unity does not automatically save such changes and that without the call the value can revert when the Editor reopens. Inspector edits save on their own.
• Read-only in a player. The Manual states a standalone player can only read saved ScriptableObject data. Save games and runtime state go elsewhere; the authored asset is never the place a build writes to.

Prefabs and variants

• A thing that appears in a scene is a prefab. Its components, children and serialized references are visible and editable in Prefab Mode, not assembled by a spawner script at runtime.
• Variants for families. Use a Prefab Variant for "the same as X, but different" instead of a code path that patches values after spawning. Per the Manual, a variant inherits from its base prefab, its overrides take precedence, any prefab (including another variant) can be a base, and the Inspector's Overrides dropdown lists every override with Revert All and Apply All. That list is the human-readable answer to "how does this enemy differ from the base one".
• Keep chains shallow. Each level of variant adds a place an override can hide. Prefer a base plus one level of variants, and put shared tunables in a ScriptableObject both reference.

References between assets

• Serialized references, not string lookups. A field typed as the asset (EnemyDefinition, GameObject, AudioClip) is assigned by drag and drop and survives renames. A string path or a name looked up at runtime breaks silently when an asset moves, and nobody can see the link in the Inspector.
• Addressables for loaded-on-demand content. When content must load at runtime rather than ship as a direct reference, use an AssetReference field. The Addressables documentation describes it as a type that references an Addressable asset and can be added as a field on a MonoBehaviour or ScriptableObject (Asset references overview). The reference is still picked in the Inspector and stored in the asset. Whether a project uses Addressables at all is a stack decision the agent asks the user about, as with the other setup choices on the Project setup page.

Text serialization, GUIDs and meta files

• FORCE-TEXT-AND-VISIBLE-META (HARD). Asset Serialization Mode stays Force Text. Per the Editor project settings reference, Force Text converts all assets to text mode, including new ones, and is the default; the same page offers "Reduce version control noise", which writes references on one line. Check both when the project is set up.
• The .meta file is the asset's identity. The Asset metadata page states that each asset gets a unique ID stored in its .meta file, alongside its import settings, and that if an asset loses its .meta file every reference to it breaks: materials lose textures and GameObjects lose script components.
• Commit every .meta with its asset. Move and rename assets inside the Editor, which moves the .meta with them. A move done outside the Editor must move the .meta too. An agent that writes a new asset file from a script checks that its .meta exists and is committed in the same change.
• Never hand-edit a GUID. Stable GUIDs are what lets references survive renames. Regenerating or copying a .meta to "fix" a reference makes two assets claim one identity or orphans every user of the old one.

Making the data editable

• Default Inspector first. Plain serialized fields with [Range], [Tooltip] and [Header] often need no custom code at all. Write custom UI only where the default view is genuinely hard to use.
• Custom inspectors through SerializedObject. For a custom Editor, edit through serializedObject and SerializedProperty. The Editor reference states this automatically handles multi-object editing, undo and Prefab overrides, and that changing script variables directly gives none of these.
• Property drawers for repeated types. A [Serializable] struct used in many places gets one PropertyDrawer so every appearance is readable. The reference notes that since 2022.2 the default Inspector uses UI Toolkit for custom property drawers, and an IMGUI OnGUI version may still be needed when the drawer is used from an IMGUI custom editor.
• Editor windows for whole catalogs. When a human needs to see many assets at once (every item, every wave), an EditorWindow that lists and edits the real .asset files is the surface. It edits the assets; it does not keep a second copy of the data. See Editor tooling for the rules every such window follows.

Related

• Authored over generated: why this is the default.
• Assets and serialization: write-order and save traps when code edits assets.
• Next: Importers and baking.