Configuring the Player GameObject for Stable Top-Down Movement

Welcome back. In the previous lesson, you prepared PlayerController to depend safely on a Rigidbody: Unity adds one when the script is attached, the script caches it in Awake, and movement values are Inspector-configurable without being public fields.

Now you will turn the Player into a well-defined physics object. By the end of this lesson, the Player will have a dynamic Rigidbody, a collision shape, the Player tag, and constraints that permit top-down movement on the $X$-$Z$ plane while preventing unwanted falling and tipping. This configuration is the contract that the next lesson’s physics-based movement code will rely on.

---

The Player needs one clear physical identity

For BattleFire, the Player’s root GameObject should own the components that define how it interacts with the arena:

• A Rigidbody makes the Player a body handled by Unity physics.
• A Collider defines the Player’s solid physical boundary.
• A Tag gives other systems a readable gameplay identity: “this object is the player.”
• Constraints restrict the Rigidbody to the degrees of freedom appropriate for a top-down game.

Keep these components on the same root GameObject as PlayerController. A model can be a child of the Player root, but the root should be the authoritative object for movement and collisions.

There is also an important cleanup step given the earlier version of your project. Your original PlayerController used a CharacterController. Do not keep a CharacterController active alongside the Rigidbody-based setup. They are separate movement systems and can compete over collision and position handling.

If the Player currently has a Character Controller component:

1. Select Player in the Hierarchy.
2. In the Inspector, open the component’s menu.
3. Choose Remove Component.

Make sure the Player is using the newer PlayerController from the preceding lesson, the version that contains [RequireComponent(typeof(Rigidbody))] and caches Rigidbody rb in Awake.

---

What a dynamic Rigidbody contributes

A Collider alone has a shape, but it does not make an object participate as a moving simulated physics body. The Rigidbody is the component that lets Unity resolve contact with the floor and obstacles while your upcoming movement code controls the body through physics APIs.

For BattleFire, the Player will remain a dynamic Rigidbody: Is Kinematic stays off. This matters because physics should resolve the Player’s contacts with walls and obstacles. In the next lesson, the script will move this Rigidbody rather than directly setting transform.position.

---

Configure the Player Rigidbody

Select the root Player GameObject. If the Rigidbody is missing despite the script requirement, use Add Component, search for Rigidbody, and add it.

Use the following as your baseline configuration.

Rigidbody setting	BattleFire value	Reason
Mass	1	A sensible default for a player-sized object. It is not a “speed” setting.
Linear Damping	0	The next lesson will explicitly control player motion rather than relying on air resistance.
Angular Damping	Default	Rotation constraints, rather than extreme damping, are what guarantee no tipping.
Use Gravity	Off	The player is locked to the arena’s movement plane rather than falling under gravity.
Is Kinematic	Off	The Player remains a dynamic body that participates in physics contacts.
Interpolate	Interpolate	Helps the rendered Player look smoother between physics updates, especially once the camera follows it.
Collision Detection	Discrete	A suitable baseline for an ordinary-speed player. Fast bullets will need their own collision decision later.

Under Constraints, enable exactly these options:

Constraint group	Enable	Leave disabled
Freeze Position	Y	X, Z
Freeze Rotation	X, Z	Y

The reasoning is geometric:

• The arena floor lies in the $X$-$Z$ plane, so X and Z must remain available for movement.
• Freezing Position Y prevents vertical drift, falling, and bouncing upward.
• Freezing Rotation X and Rotation Z prevents a collision from knocking the Player sideways.
• Leaving Rotation Y free lets the Player turn left and right to face its movement or aim direction.

Do not freeze Rotation Y. It may initially seem harmless, but it would prevent the player-facing rotation that will be added with movement.

The image uses an older Inspector layout, so do not worry if the labels or spacing differ in your Unity version. The settings’ purposes are the same.

---

Give the Player a solid collision boundary

The Rigidbody is the simulated body; the Collider is the shape Unity uses when deciding whether that body has hit the floor, a wall, or an obstacle.

For a standing character or a simple capsule-shaped placeholder, use a Capsule Collider. It provides a rounded vertical boundary that tends to slide around corners more naturally than a box. If your Player is currently a Unity Capsule primitive, it already has a Capsule Collider; inspect it rather than adding a duplicate.

Configure the Capsule Collider with these principles rather than trying to match every visual detail:

1. Direction: leave it on Y-Axis for an upright top-down player.
2. Center: adjust the center so the capsule is centered on the Player’s body.
3. Height and Radius: make the capsule encompass the torso and feet without extending far beyond the model.
4. Is Trigger: leave it unchecked. The Player needs a solid collider so it cannot walk through arena obstacles.
5. Scale: keep the root Player’s Transform scale close to (1, 1, 1). Extreme or non-uniform scaling makes collider dimensions harder to reason about.

A collider is a gameplay boundary, not an exact copy of rendered geometry. A small amount of visual simplification is generally desirable: a player should not snag on a decorative arm, weapon model, or other detail.

Check your level objects as well. The floor and each obstacle need an appropriate collider—commonly a Box Collider for simple walls and blocks. They do not need Rigidbodies if they are static parts of the arena; the Player’s dynamic Rigidbody provides the moving physics participant.

---

Assign the Player tag

Tags are lightweight labels that let gameplay code identify categories of GameObjects. In BattleFire, assign the Player tag to the root Player GameObject now. Later, EnemyBot can use this identity to find or verify its intended target, and bullets can distinguish the owner or valid targets.

In the Player Inspector:

1. At the top, open the Tag dropdown.
2. Select Player.
3. If Player is not available, choose Add Tag..., add a tag named Player, return to the Player GameObject, and assign it.

Keep two concepts separate:

Feature	What it means in BattleFire
Tag: Player	A semantic identity used by code, such as identifying the player target.
Collider	A physical shape used to block movement and generate collision contacts.
Layer	A collision and rendering categorization system, which will become important when bullets are configured.

A tag does not make collisions happen, and it does not restrict which objects collide. That is why this lesson configures both the tag and the physics components separately.

---

Verify the configuration before movement code

Before proceeding, inspect the root Player GameObject and confirm this compact checklist:

• PlayerController is attached and enabled.
• Rigidbody is attached to that same GameObject.
• Capsule Collider is attached, fitted to the Player, and Is Trigger is off.
• The Player tag is set to Player.
• Use Gravity is off.
• Is Kinematic is off.
• Constraints freeze Position Y and Rotation X/Z, but not Rotation Y.
• No CharacterController remains on the Rigidbody-driven Player.

Save Main after making these changes. Enter Play mode briefly and watch the Player in the Game and Scene views. With no movement code yet, it should stay upright at its intended height rather than falling or rotating. Its final test—moving into obstacles while retaining that stability—comes immediately after the physics movement implementation.

A few configuration mistakes are particularly common:

Symptom	Likely cause	Correction
Player falls through or drops off the arena	Gravity is enabled, Y is not frozen, or the floor has no collider	Turn off gravity, freeze Position Y, and verify the floor collider.
Player tips or spins after hitting an obstacle	Rotation X/Z are not frozen	Freeze Rotation X and Z only.
Player passes through walls	Player or wall lacks a suitable collider, or Player collider is a trigger	Add/fix colliders and leave the Player collider solid.
Player cannot turn	Rotation Y was frozen	Unfreeze Rotation Y.
Inconsistent or strange collision behavior	Rigidbody and CharacterController both remain	Use only the Rigidbody-based setup.

---

Key takeaways

Your Player is now configured for a top-down physics game:

• The Rigidbody makes the Player a dynamic physics participant.
• A Capsule Collider gives the Player a solid, practical collision boundary.
• The Player tag provides a gameplay identity distinct from physics configuration.
• Freezing Position Y and Rotation X/Z preserves the flat, upright top-down behavior.
• Leaving X/Z position and Y rotation unfrozen preserves exactly the movement and turning freedoms BattleFire needs.
• A Rigidbody-based Player should not also use a CharacterController.

Next, you will implement frame-rate-independent movement in PlayerController.cs using the cached Rigidbody and Unity’s physics update cycle.