Creating and Verifying Player Prefab Changes

Hello again. Your Main scene now has a physics-driven Player and a camera that follows it without becoming part of the Player hierarchy. The next step is to preserve that configured Player as a reusable asset rather than treating the current scene object as the only copy.

This completes the final workflow piece of the Unity Foundations module: create Player.prefab, understand the relationship between the prefab asset and scene instances, then prove that a purposeful change to the asset reaches every linked Player in the scene. This matters immediately for future enemy, bullet, and UI work, where reusable configuration prevents repeated setup and inconsistent copies.

---

The prefab relationship: asset, instance, and override

A prefab asset is the saved, reusable definition stored in the Project window. A prefab instance is a scene GameObject connected to that definition.

For BattleFire, Assets/Prefabs/Player.prefab should contain the Player’s shared setup:

• the root Player GameObject and its child visual objects, if any;
• Rigidbody, collider, and top-down movement constraints;
• Player tag and layer choices;
• PlayerController and its default movement values;
• eventually, the health and shooting components added in the next module.

A Player placed in Main.unity is an instance of that asset. Its placement in the arena can differ from the prefab default, while its shared configuration still comes from Player.prefab.

This distinction prevents a common mistake: a scene is a particular level layout; a prefab is a reusable object definition. BattleFire will normally have one active Player in a match, but the prefab lets you reuse the same correctly configured Player in a test scene, a later level, or a runtime spawn system.

One terminology correction worth keeping precise: a regular scene GameObject can have scripts and components. What makes a prefab different is not the mere presence of components; it is that the configured hierarchy is saved as an asset that can create and update linked instances.

---

Inspect the Player before saving it

Before creating the asset, exit Play mode if it is active. Unity discards Inspector edits made during Play mode when you stop, so creating or configuring a prefab during testing can leave you with an incomplete setup.

In the Hierarchy, select the root Player object. This is the object that owns the Rigidbody and movement script, rather than a mesh or model child beneath it. Confirm the following baseline:

Check	What to verify
Root object	It is named Player.
Physics	It has the Rigidbody and collider configured in the earlier lesson.
Movement	PlayerController is attached and has your intended defaults.
Identity	Its tag is Player; preserve the layer you chose for the arena.
Camera separation	Main Camera remains a separate root object, not a child of Player.
Child objects	Any meshes, renderers, or visual children belonging to the player are nested under Player.

For a reusable player, values such as moveSpeed, Rigidbody constraints, collider dimensions, and material assignments belong in the prefab. By contrast, the Player’s position in this particular arena is usually a scene-specific choice. When you create a test copy later, it should be at another location, not stacked exactly on the current Player.

---

Create Player.prefab

Set up the Project window so Assets/Prefabs is visible. Then create the asset:

1. In the Hierarchy, select the root Player GameObject.

2. Drag it into Assets/Prefabs in the Project window.

3. Release it in the folder and name the new asset Player if Unity has not already assigned that name.

4. Select the new Player.prefab asset in the Project window to confirm it is located at:

   Assets/Prefabs/Player.prefab
   

5. Look back at the Player in the Hierarchy. Its icon should now indicate that it is a prefab instance. Unity’s exact icon styling varies by version, but prefab instances are commonly shown with a blue prefab icon.

The Player did not disappear from Main. The object in the scene is now the first instance of the asset you created. This is exactly what you want: it remains the playable Player already placed in your arena, but its common configuration now has a durable source.

Save the scene with File > Save or your normal save shortcut. This records the scene’s reference to Player.prefab as well as its scene-specific placement.

Open the prefab asset, not just an instance

Double-click Player.prefab in Assets/Prefabs. Unity opens Prefab Mode, displaying the prefab in isolation. The breadcrumb at the top of the Scene view shows that you are editing Player.

Prefab Mode answers a useful question: “What will a newly created Player contain by default?” It is the safest place to edit shared Player configuration deliberately.

If Auto Save is enabled in Prefab Mode, changes to the prefab asset are saved as you make them. If it is disabled, Unity asks you to save when leaving Prefab Mode. Either way, do not assume a change has propagated until you return to Main and inspect the instances.

---

Verify propagation with a controlled change

A real propagation test needs at least two scene instances. You will add a temporary second Player, make one shared prefab edit, verify the edit on both instances, then remove the test copy. Do this outside Play mode.

1. Add a temporary test instance

1. Return to Main using the breadcrumb or back arrow in Prefab Mode.
2. Drag Player.prefab from Assets/Prefabs into an open part of the Scene view or Hierarchy.
3. Rename the new scene object Player_PrefabTest for clarity.
4. Move it somewhere visible and not overlapping the real Player, such as a few units to one side.

Changing the test object’s Transform position is expected. The two Players need distinct locations in this scene. Treat that position as a local scene decision, not as the shared Player configuration you are about to test.

Do not enter Play mode with two active Players unless you intentionally want to test that setup. This instance exists only to validate the prefab link.

2. Change a shared setting in the prefab asset

Open Player.prefab in Prefab Mode again. On the root Player object, locate PlayerController and change:

Field	Original starting value	Test value
Move Speed	5	6

The exact old value may differ if you tuned it earlier. Record your current value, change it by a noticeable amount, and save the prefab asset.

This is a good propagation test because moveSpeed is clearly a shared gameplay default. It belongs to the Player definition, unlike the test instance’s position.

3. Confirm both instances updated

Return to Main. Select the original Player and inspect PlayerController:

• Move Speed should now show the new test value.

Then select Player_PrefabTest:

• Move Speed should show the same new test value.

At this point, you have verified the central prefab contract: modifying the source asset changed both linked instances. For a quick visual confirmation, you can also select both scene objects and inspect their prefab connection indicators.

Finally:

1. Decide whether 6 is the speed you want for BattleFire.
2. If it is only a test value, reopen Player.prefab and restore the original value.
3. Delete Player_PrefabTest from Main.
4. Save Main.unity.

Your scene should again contain one playable Player, now linked to the reusable Player.prefab.

---

Overrides: when one instance should differ

A prefab’s value is the shared default, but Unity also lets an individual instance intentionally differ. Such a difference is called an override.

For example, placing Player_PrefabTest at a different arena position creates a useful local Transform difference. Likewise, a future tutorial scene might intentionally give the Player a different starting health. In both cases, that particular instance can retain a local setting without redefining every Player everywhere.

The important consequence is this: an overridden property is protected from later changes to that same property on the prefab asset. If one Player instance has a local Move Speed override of 8, changing the prefab’s Move Speed to 6 does not replace that local 8.

Select a prefab instance in the Hierarchy and locate Overrides near the top of its Inspector. It identifies differences between that scene object and its source prefab.

Choice	Meaning	BattleFire use
Revert	Discard the selected instance change and restore the prefab value.	Use when an accidental Inspector edit made one Player inconsistent.
Apply	Write the selected instance change back to the prefab asset.	Use only when the change really should become the default for all Player instances.
Revert All	Discard all local instance changes.	Useful for resetting a temporary test object.
Apply All	Write all listed changes to the prefab.	Use cautiously; it may include unwanted scene-specific changes.

The screenshot shows an added Rigidbody as an override. Applying that component would make it part of the prefab asset, so all linked instances would receive it. Reverting it would remove that instance-only addition.

For this project, avoid applying a Player instance’s scene placement back to Player.prefab just because it appears in the Overrides menu. The prefab should provide a sensible default transform, but Main decides exactly where the match’s Player begins.

A reliable habit is:

1. Make a change in Prefab Mode when it is a shared Player default.
2. Make a change on a scene instance when it belongs only to that scene or one special copy.
3. Use Apply only after checking that the instance change truly belongs in every Player.

---

Key takeaways

You have converted the configured Player into Assets/Prefabs/Player.prefab and verified its shared behavior:

• A prefab asset is the reusable Player definition; a scene Player is a linked instance.
• Dragging the configured root Player from the Hierarchy into Assets/Prefabs creates the asset and links the original object.
• Prefab Mode edits the shared source, and saved changes propagate to linked instances.
• A second temporary Player instance provides a concrete way to test propagation safely.
• Scene position is commonly an instance-level choice; do not automatically apply it to the shared prefab.
• The Overrides menu lets you inspect, revert, or deliberately apply instance-specific changes.

Next, BattleFire moves into combat foundations: you will implement current health, damage handling, and safe health clamping in PlayerHealth.cs.