Unity Workflow LibraryUWLAbout

Topic 12 · Authored content

Authored over generated

Why game data must live in assets a human can open and edit in the Editor, and what that rules out.

Markdown version

An agent can produce a working feature fastest by writing a generator: a class that builds the level, the item table or the enemy roster in code when the game starts. It works on the first run and becomes a black box on the second. Nobody can see the data without running the game, nobody can change one value without editing C#, and a review shows a diff of code instead of a diff of content. This topic sets the opposite default: the content a game runs on is authored data in serialized assets, and code reads it.

The default

  • AUTHORED-IS-THE-DEFAULT (HARD). Every value a designer could want to change (numbers, lists, references, layouts, curves, spawn points) lives in a serialized asset in the project: a ScriptableObject .asset, a prefab, a scene, or an imported file with its settings in the .meta. Code holds behaviour and reads that data. A system whose content only exists after the game has started is not finished.
  • NO-HIDDEN-RUNTIME-STATE. If the answer to "what is in this table" is "run the game and log it", the data is hidden. Move it into an asset, or bake the generator's output into one (see Baking and importers).
  • HUMAN-EDITS-WITHOUT-AN-AGENT. The test of done is that the developer can open the Editor, select the asset, change a value in the Inspector and see the effect, with no agent and no code change. This is the same bar the Editor tooling page sets for every system's authoring surface.

Why authored beats generated

Property Authored asset Opaque runtime generator
Debugging Select the asset and read the values Attach a debugger or add logs and re-run
Designer control Edit a field in the Inspector Ask someone to edit C# and recompile
Review The diff shows which value changed The diff shows code; the data change is implied
Reproducibility The committed file is the content Depends on seed, order and code version
Merging Text YAML merges like any text file Two code edits to one generator collide
  • Debuggability. A bad value in an asset is found by looking at it. A bad value inside a generator is found by reasoning about the code that produced it.
  • Designer control. Unity's own guidance puts authoring-time data in ScriptableObjects: the Manual describes storing "data defined at authoring time" in a ScriptableObject and reading it from a MonoBehaviour at runtime (ScriptableObject data assets).
  • Diffable, reviewable data. With Asset Serialization set to Force Text (the default, per the Editor project settings), scenes, prefabs and .asset files are text, so a content change shows up as a readable diff.

What this rules out

  • A static table of hard-coded entries in a C# file that a designer would want to tune.
  • A bootstrap that spawns and configures the level from code when the scene loads, leaving an empty scene in the Editor.
  • Values computed at startup from other values and never written anywhere a human can see them.
  • Hidden objects (HideFlags.HideAndDontSave) used to hold content rather than transient editor state.
  • An agent-only workflow: a script the agent runs to change content, with no Inspector path for a human to make the same change.

When generation is fine

Procedural generation is not banned. It is fine when both of these are true:

  1. Its parameters are authored. The seed, ranges, weights and rules live in a ScriptableObject or importer settings that a human edits in the Inspector.
  2. Its output is baked into inspectable assets, or is genuinely per-session. Level geometry, item tables and placements are written into prefabs, scenes or .asset files that are committed. Generation that must differ every play session (a roguelike run, a random loot roll) may run at runtime, but its rules and tables are still authored assets, and a debug view shows what it produced.

If neither is true, the generator is a black box. Rework it before building on it.