# YAML prefab serialization example This page demonstrates annotated YAML excerpts of prefab instances, nested prefabs, and prefab variants from Unity project files. The excerpts are trimmed for readability: the original files contain more `m_Modifications` entries than this page shows. For a description of the data model that these excerpts follow, refer to [YAML serialization of prefabs](/engine/6000.3/manual/working-with-scenes/text-scene-format/yaml-prefab-serialization.md). The page covers the following concepts: * [Prefab instance in a scene](#prefab-instance-in-a-scene) * [Nested prefab](#nested-prefab) * [Prefab variant](#prefab-variant) ## Prefab instance in a scene ##prefab-instance-in-a-scene The following excerpt is from a scene file that places an instance of a rock prefab into the scene. The instance overrides the rock's position, rotation, and name. ```lang-yml --- !u!1001 &11866470 PrefabInstance: m_ObjectHideFlags: 0 serializedVersion: 2 m_Modification: serializedVersion: 3 m_TransformParent: {fileID: 1122852772} m_Modifications: - target: {fileID: 599465214307944399, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3} propertyPath: m_LocalPosition.x value: 39.341 objectReference: {fileID: 0} - target: {fileID: 599465214307944399, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3} propertyPath: m_LocalPosition.y value: 4.425 objectReference: {fileID: 0} - target: {fileID: 599465214307944399, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3} propertyPath: m_LocalPosition.z value: 26.527 objectReference: {fileID: 0} - target: {fileID: 599465214307944399, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3} propertyPath: m_LocalRotation.w value: 0.69781095 objectReference: {fileID: 0} - target: {fileID: 8354524949365800270, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3} propertyPath: m_Name value: Rock_05_Prefab (4) objectReference: {fileID: 0} m_RemovedComponents: [] m_RemovedGameObjects: [] m_AddedGameObjects: [] m_AddedComponents: [] m_SourcePrefab: {fileID: 100100000, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3} --- !u!4 &11866471 stripped Transform: m_CorrespondingSourceObject: {fileID: 599465214307944399, guid: 95cf80858ee0c4940b72f62b17aefd41, type: 3} m_PrefabInstance: {fileID: 11866470} m_PrefabAsset: {fileID: 0} ``` Key points in the excerpt: * The `PrefabInstance` element with fileID `11866470` represents the instance. Its `m_SourcePrefab` field references the rock prefab asset (by `guid`) through the prefab asset handle (fileID `100100000`). * `m_Modification.m_TransformParent` references a `Transform` component in the same scene file, making the prefab instance a child of that scene object in the hierarchy. * Each entry in `m_Modifications` contains one property override. The `target` identifies the object inside the source prefab by `guid` and `fileID`, and a combination of `propertyPath` and `value` specify the overridden property and its value. * The stripped `Transform` element (element with the `stripped` attribute) at fileID `11866471` is a placeholder for the `Transform` component on the prefab instance's root GameObject. Other objects in the scene use this placeholder whenever they reference the prefab instance's root, for example in the `m_Children` list of the parent scene object's `Transform` component. The original `m_Modifications` list in the source file also contains the other rotation components and euler-angle-hint overrides; they're omitted here for readability. ## Nested prefab ##nested-prefab The following example is the complete prefab file that nests one other prefab inside it. ```lang-yml %YAML 1.1 %TAG !u! tag:unity3d.com,2011: --- !u!1 &6949479575104989305 GameObject: m_ObjectHideFlags: 0 m_CorrespondingSourceObject: {fileID: 0} m_PrefabInstance: {fileID: 0} m_PrefabAsset: {fileID: 0} serializedVersion: 6 m_Component: - component: {fileID: 1188189139150009913} m_Layer: 0 m_Name: Stone_01_Prefab m_TagString: Untagged m_Icon: {fileID: 0} m_NavMeshLayer: 0 m_StaticEditorFlags: 2147483647 m_IsActive: 1 --- !u!4 &1188189139150009913 Transform: m_ObjectHideFlags: 0 m_CorrespondingSourceObject: {fileID: 0} m_PrefabInstance: {fileID: 0} m_PrefabAsset: {fileID: 0} m_GameObject: {fileID: 6949479575104989305} m_LocalRotation: {x: 0, y: 0, z: 0, w: 1} m_LocalPosition: {x: 0, y: 0, z: 0} m_LocalScale: {x: 1, y: 1, z: 1} m_ConstrainProportionsScale: 0 m_Children: - {fileID: 8712595929885449456} m_Father: {fileID: 0} m_RootOrder: 0 m_LocalEulerAnglesHint: {x: 0, y: 0, z: 0} --- !u!1001 &9179429690634107675 PrefabInstance: m_ObjectHideFlags: 0 serializedVersion: 2 m_Modification: serializedVersion: 3 m_TransformParent: {fileID: 1188189139150009913} m_Modifications: - target: {fileID: 919132149155446097, guid: 5a62bd76f7db850498f128cc2e7b59d2, type: 3} propertyPath: m_Name value: Stone_01_Mesh objectReference: {fileID: 0} - target: {fileID: 4742473837712756890, guid: 5a62bd76f7db850498f128cc2e7b59d2, type: 3} propertyPath: m_FadeMode value: 1 objectReference: {fileID: 0} - target: {fileID: 4742473837712756890, guid: 5a62bd76f7db850498f128cc2e7b59d2, type: 3} propertyPath: m_AnimateCrossFading value: 1 objectReference: {fileID: 0} m_RemovedComponents: [] m_RemovedGameObjects: - {fileID: -1027982724379016789, guid: 5a62bd76f7db850498f128cc2e7b59d2, type: 3} m_AddedGameObjects: [] m_AddedComponents: [] m_SourcePrefab: {fileID: 100100000, guid: 5a62bd76f7db850498f128cc2e7b59d2, type: 3} --- !u!4 &8712595929885449456 stripped Transform: m_CorrespondingSourceObject: {fileID: -8679921383154817045, guid: 5a62bd76f7db850498f128cc2e7b59d2, type: 3} m_PrefabInstance: {fileID: 9179429690634107675} m_PrefabAsset: {fileID: 0} ``` Key points in the example: * The outer prefab's root is serialized as two separate YAML elements: a `GameObject` element (fileID `6949479575104989305`) and its `Transform` component element (fileID `1188189139150009913`). Unity writes them both directly into the file, the same way it writes any non-prefab GameObject. * The `m_Children` field on the outer `Transform` component element lists the fileID of the stripped `Transform` placeholder element for the nested instance (`8712595929885449456`). This reference places the nested prefab's root as a child in the outer prefab's hierarchy. * The `PrefabInstance` element with fileID `9179429690634107675` represents the nested prefab instance. Its `m_SourcePrefab` field references a different prefab asset (the `Stone` source prefab), identified by `guid`. * The `m_Modification.m_TransformParent` field on the nested `PrefabInstance` references the outer `Transform` component element. As a result, the nested instance is placed under the outer prefab's root in the hierarchy. * The stripped `Transform` placeholder element at fileID `8712595929885449456` is the target that the outer `Transform` component's `m_Children` field points to. Its `m_CorrespondingSourceObject` field identifies the specific `Transform` component inside the source `Stone` prefab that this placeholder represents. * The `m_RemovedGameObjects` list contains one entry, which indicates that one child GameObject from the source prefab is removed from this nested instance. The `m_RemovedComponents` and `m_AddedGameObjects` lists are empty. The original `m_Modifications` list in the source file contains additional transform and static flag overrides, they're omitted here for readability. ## Prefab variant ##prefab-variant The following excerpt is from a prefab variant file. The variant is a horizontally flipped version of a base door prefab. ```lang-yml %YAML 1.1 %TAG !u! tag:unity3d.com,2011: --- !u!1001 &5365984487090290000 PrefabInstance: m_ObjectHideFlags: 0 serializedVersion: 2 m_Modification: serializedVersion: 3 m_TransformParent: {fileID: 0} m_Modifications: - target: {fileID: 1262770979034925880, guid: 89d4c08db6b9096438cb6c7718d47f26, type: 3} propertyPath: m_Name value: DoorFusuma_100x200_01_Prefab (38) Variant objectReference: {fileID: 0} - target: {fileID: 1727893522013754926, guid: 89d4c08db6b9096438cb6c7718d47f26, type: 3} propertyPath: m_LocalScale.x value: -1 objectReference: {fileID: 0} - target: {fileID: 1761800793405478535, guid: 89d4c08db6b9096438cb6c7718d47f26, type: 3} propertyPath: m_LocalScale.x value: -1 objectReference: {fileID: 0} - target: {fileID: 7660580366407964633, guid: 89d4c08db6b9096438cb6c7718d47f26, type: 3} propertyPath: m_LocalScale.x value: -1 objectReference: {fileID: 0} m_RemovedComponents: [] m_RemovedGameObjects: [] m_AddedGameObjects: [] m_AddedComponents: [] m_SourcePrefab: {fileID: 100100000, guid: 89d4c08db6b9096438cb6c7718d47f26, type: 3} ``` Key points in the excerpt: * The root YAML element of the variant file is a `PrefabInstance`, which has class ID `1001`. A non-variant prefab file, by contrast, starts with a `GameObject` element. * The `m_Modification.m_TransformParent` field is `{fileID: 0}`. The `PrefabInstance` element has no parent transform because it's the root of the file. This is characteristic of prefab variants. * The `m_SourcePrefab` field references the base prefab that the variant inherits from. * The entries in the `m_Modifications` list contain the property overrides that make this variant distinct from the base. In this example, the negative `m_LocalScale.x` property values on three `Transform` components flip the door geometry horizontally. The original file contains additional transform and position overrides that complete the flipped layout, they're omitted here for readability. ## Additional resources * [YAML serialization of prefabs](/engine/6000.3/manual/working-with-scenes/text-scene-format/yaml-prefab-serialization.md) * [Format of text serialized files](/engine/6000.3/manual/working-with-scenes/text-scene-format/format-description.md) * [An example of a YAML scene file](/engine/6000.3/manual/working-with-scenes/text-scene-format/yamlscene-example.md) * [YAML class ID reference](/engine/6000.3/manual/working-with-scenes/text-scene-format/class-idreference.md) * [Nest prefab instances in other prefabs](/engine/6000.3/manual/working-with-gameobjects/prefabs/nested.md) * [Create variations of prefabs](/engine/6000.3/manual/working-with-gameobjects/prefabs/prefab-variants.md) * [Smart merge](/engine/6000.3/manual/get-started/project-configuration/version-control/smart-merge.md)