Unity Character Movement: Character Controller vs. Rigidbody Explained

When building a 3D game in Unity, one of the first major hurdles is setting up player movement. A common point of confusion for beginners is how Unity divides physics and logic, and which movement standard is right for their specific project.

Here is a breakdown of Unity's character movement architecture, based on standard development practices.

Separating the "Body" and the "Brain"

If you open a standard Unity sample project (like the Starter Assets), you will notice that player movement relies on two separate components: a built-in Character Controller and a custom C# script (like a Third Person Controller).

The Body (Character Controller): This built-in component manages the physical presence of the player. It defines an invisible capsule to handle collision detection, slope limits, and step offsets. It ensures the character doesn't walk through walls or get stuck on stairs.
The Brain (Logic Script): The custom C# script handles the gameplay logic. It reads player input, manages jump timeouts, calculates movement speed, and tells the Character Controller exactly where and how fast to move.

By keeping these separate, Unity handles the heavy mathematical lifting of collision detection, giving you complete freedom to code how your specific character behaves.

Why Not Just Parent a Collider to the Hip Bone?

A frequent shortcut developers try is attaching a standard collider directly to the character's hip bone so it follows the animation. However, for main movement logic, this leads to disastrous results:

The Bobbing Problem: Walking and running animations naturally make a character's hips bounce. If the main physics collider is tied to that bone, the engine thinks the player is rapidly vibrating up and down, making smooth movement or camera tracking impossible.
Animation vs. Physics: The Animator and the Physics engine will fight for control. If the animation forces the character into a wall, the physics engine will panic and violently eject the character backwards, causing jittering and model stretching.
Snagging: Changing bone angles means the attached colliders constantly shift. These shifting angles will snag on invisible seams in your 3D models and floors.

Note: Bone colliders are highly useful, but they should be reserved for hitboxes (damage detection) or ragdoll physics, not core movement.

The Two Main Movement Standards

There are two distinct standards for moving a player in Unity, depending on the feel you want for your game.

1. Kinematic Movement (Character Controller)

This approach uses the built-in Character Controller. It uses "fake" physics—ignoring global gravity and momentum unless you script them manually.

Best for: First-person shooters, 3D platformers, and action RPGs.
Pros: It provides pixel-perfect, snappy control. When the player lets go of the joystick, the character stops instantly.

2. Dynamic Movement (Rigidbody Physics)

This standard ignores the Character Controller and uses a standard Rigidbody component combined with a simple Capsule Collider. Movement is achieved by applying physical forces (like velocity) to the player.

Best for: Physics-heavy games, endless runners, or games where characters need to interact with physical objects (like rolling boulders or moving platforms).
Pros: Realistic inertia and momentum.

Is the Character Controller Deprecated?

No. The classic UnityEngine.CharacterController is not deprecated. It is actively maintained, fully supported, and serves as the foundation for Unity's official Starter Assets.

Unity does offer a newer Kinematic Character Controller (KCC) package, but this is a highly specialized system built specifically for the Data-Oriented Technology Stack (DOTS) and complex multiplayer networking. Unless you are specifically building a DOTS-based project, the classic GameObject-based Character Controller is still the recommended choice for standard game development.

(Note: No specific code snippets were utilized in the original thread, but implementing these concepts relies on Unity's standard CharacterController.Move() method or Rigidbody.AddForce() depending on your chosen architecture.)