9.4 — Your Scene Is Data: Metadata & Files

Step 1 — look in the folder, not in Unity. Open Assets/_Scenes/ in Finder or Explorer. There are exactly three files: Start.unity, Overworld.unity and Platformer.unity. That is the whole game. Those three are also the three entries in ProjectSettings/EditorBuildSettings.asset, in that order — indices 0, 1 and 2 — which is what SceneManager.LoadScene(scene) in SceneSwitch.cs is indexing into. Nobody ever types the word "Overworld" into that code, and it still loads the right scene.

Step 2 — open one in a text editor. Not Unity. Right-click Overworld.unity and open it with TextEdit, Notepad or VS Code. It is YAML: human-readable key: value text. Every object in the scene is one block, and every block starts the same way — a Unity class id, an &, and a file id that is unique inside that one file:

--- !u!1 &6040774585044851471
GameObject:
  m_Name: Turret
  m_TagString: Enemy
  m_Component:
  - component: {fileID: 4844124505973536318}
--- !u!212 &-8321157105715108983
SpriteRenderer:
  m_Sprite: {fileID: 1391597418, guid: 465f5cb57952b46b387408a348ba8589, type: 3}
  m_SortingLayer: 4

The number after !u! is the KIND of thing, and the project uses only a handful of kinds, all of them readable in the file itself:

Step 3 — find your own turret. There is no turret in Platformer.unity and none in Start.unity: search either one for the word "Turret" and you get nothing. The turrets are in the Overworld, under an object named Turrets, and each one is a !u!1001 block. That block does not contain a turret. It contains a guid, a short list of changes, and nothing else — because the turret itself lives in Assets/Prefabs/Turret.prefab, and the scene is only keeping a note about it.

Step 4 — the file beside the file. Every asset in the project has a second file next to it with .meta on the end — every sprite, every script, every prefab, and every folder including _Scenes. Open Assets/Prefabs/Turret.prefab.meta. It is seven lines:

fileFormatVersion: 2
guid: 54f2fe71921990e48b811a0b3b35835f
PrefabImporter:
  externalObjects: {}
  userData:
  assetBundleName:
  assetBundleVariant:

That is the entire file. The asset next to it holds the turret; the .meta holds the turret's name as far as the rest of the project is concerned — the guid, a 32-character number that is unique across every project on earth. The .png sidecar is the same three lines followed by two hundred and seventy-one more: texture type, pixels per unit, pivot, filter mode, compression, and the rectangle of every sprite sliced out of the image. All of that is metadata — description, not content. The picture does not know any of it.

Step 5 — follow one reference all the way. This is the whole lesson in four lines. In Overworld.unity, search for stripped. You will find blocks like this one:

--- !u!4 &861464021 stripped
Transform:
  m_CorrespondingSourceObject: {fileID: 4281311786053241907, guid: 69c7343f050914c7787bbbe42c07b5b8, type: 3}
  m_PrefabInstance: {fileID: 186509170}

Read it as a sentence: the Transform you are looking for is not written here. It lives in the asset whose guid is 69c7343f050914c7787bbbe42c07b5b8, as the object numbered 4281311786053241907 inside that asset. Now go and check it. Assets/Prefabs/Coin.prefab.meta carries that exact guid, and Assets/Prefabs/Coin.prefab contains --- !u!4 &4281311786053241907. You have just walked from a scene, through a sidecar, into a prefab, using nothing but a number. That is what serialization means in Unit 9: the object in memory has been written down as text, and the pointer between two objects has been written down as a guid instead of a memory address.

Step 1 — change a value without opening Unity. Make a copy of Overworld.unity first. Then find the block --- !u!1001 &208023028 — one of the two turret instances — and read its override list. One entry changes m_LocalPosition.x to 15.13. Now open Assets/Prefabs/Turret.prefab and read the turret's own root Transform, --- !u!4 &4844124505973536318: m_LocalPosition: {x: 0, y: 0, z: 0}. The prefab says the turret is at zero; the scene says this turret is at 15.13. That is what an override is — a value on the instance, not on the asset.

Now change 15.13 to something absurd, close Unity first if it is open, reopen the scene, and press Play. The turret has moved. You edited the game without opening the Inspector, which is the same power as the palette edit from 9.2, one level deeper.

Step 2 — diff a playtest edit. Close Unity. Copy Overworld.unity again, open Unity, move three objects, save, close. Now compare the two files — VS Code's compare, or just search for the changed numbers — and notice how small the diff is. Each object you moved is a handful of changed m_LocalPosition values inside one !u!1001 block, one number per axis. Your entire semester of level design is that readable.

Step 3 — find the metadata that is out of date. Stay in the turret instance and read the first entry in the same override list:

- target: {fileID: -28657926046577547, guid: 54f2fe71921990e48b811a0b3b35835f, type: 3}
  propertyPath: m_IsTrigger
  value: 0

That says: in the asset whose guid is 54f2 — the turret prefab — find the object numbered -28657926046577547 and set its m_IsTrigger to 0. So go and find it. Search Turret.prefab for 28657926046577547 and you get zero hits. Search the whole project and you get one hit: this line, the one looking for it. There is no such component. The prefab has six anchors and none of them is that number, and the prefab holds no collider at all — so an entry that claims to be setting a collider's trigger flag is describing an object that does not exist. The Player instance carries the same kind of ghost: m_GravityScale, aimed at a number that is an anchor nowhere in the project.

This is not a bug you have to fix, and it is the best thing in the file. Somebody edited these files as text — the prefabs and the scenes — and never re-saved them in Unity. The scene still remembers the version of the prefab it was written against, and that version had a collider. Unity, when it next opens and saves that scene, will quietly drop the dead entry, because Unity reads the prefab to find out what exists. A text file cannot. That is the difference between a file that is true and a file that is merely old, and it is why the same scene file behaves differently after somebody re-saves it.