BoundingBoxSoftware/CharacterController: A Unity Rigidbody Character Controller That Runs in Update

What the built-in Unity CharacterController leaves unsolved

Unity's built-in CharacterController is a capsule-shaped mover that does not use rigidbody dynamics. The README for this project frames its purpose narrowly: it is a character controller for Unity that covers many edge cases where the built in character controller may fail. The project does not list those edge cases as a checklist, so the practical way to judge it is by the mechanisms it substitutes.

The audience is Unity developers who have already hit one of two walls. The first is the split between physics time and frame time. Unity normally advances physics on fixed time steps, which do not line up with the game's frame steps, and the README states this produces visual discrepancies between physics-driven objects and script-driven objects. The second is where character logic runs. Physics objects are usually updated in FixedUpdate, but the README notes that FixedUpdate runs before the physics update, so what you read back is the raw output of the physics rather than a corrected state.

This is not a general-purpose movement kit. It is a controller for projects that want a character to behave like a rigidbody, colliding and pushing other rigidbodies in the expected ways, while still getting the step-up and slope smoothing that a bare capsule would need hand-written code for.

The Physics Manager, the rigidbody core, and corrections applied in Update

Three mechanisms carry the design. The first is a Physics Manager script, which the README describes as telling physics when to update. Instead of fixed time steps, it updates physics at the beginning of the frame using Time.deltaTime as the time step. The README also documents options to run multiple updates and slice the delta time when the frame rate gets low, a maximum number of slices, and a mode that trades multiple physics updates for old-school game slowdown.

The second is the rigidbody core. The README states that at its core the character controller is a rigidbody and will interact with other rigidbodies in expected ways. That is a different contract from the built-in controller, which is kinematic in spirit and needs manual handling when you want to push objects.

The third is how corrections are applied. Rather than letting physics resolve everything in its own pass, the controller adds corrections itself, such as moving the character up steps and applying world motion, and the README says it tries its best to stop the character from being moved through any collision while doing so. The only physics change it makes is to the rigidbody velocity, and that velocity does not change position until the physics update on the next frame. That sequencing is the whole trick: the visual state is corrected immediately, and the physical state catches up on the next physics step.

Ground handling is separate. A triangulated mesh pattern of raycasts estimates the ground slope from multiple height points, which the README says averages geometry like stairs into a slope for smooth traversal. Stairs therefore stop being a series of vertical faces to the controller and become an inclined surface.

Installing from the repository and getting a character moving

There is no package registry entry, no release, and no homepage for this project. The README does not give install steps, so the source of truth is the repository layout: a Unity project with Assets/, Packages/ and ProjectSettings/, which means you take the scripts out of Assets/ and place them in your own project.

Start by cloning the repository so you can inspect the scripts before copying anything.

git clone https://github.com/BoundingBoxSoftware/CharacterController.git

Open the cloned folder in the Unity version recorded in ProjectSettings/, then copy the character controller scripts and the Physics Manager script from its Assets/ folder into your own project's Assets/ folder. The README does not name the individual script files, so identify them by reading the folder rather than by guessing filenames.

Once the scripts are in your project, add the controller component to a GameObject that has a rigidbody, since the README states the controller's core is a rigidbody. Then drive the character from Update rather than FixedUpdate, which is the behaviour the README describes. What you should see is the character moving on the frame you issued the input, with the velocity change taking effect on the next physics update.

The Physics Manager needs to be present in the scene for the custom update timing to apply. The README describes its options, including multiple updates per frame, delta time slicing, a maximum slice count, and the slowdown mode, but it does not document default values or the exact inspector field names, so confirm those in the script itself.

Where this controller is the wrong tool

The custom physics update is the largest commitment and the largest risk. Replacing fixed time steps with a delta-time step changes how every physics object in the project behaves, not just the character. If you have vehicles, ragdolls, stacked rigidbodies or networked physics that were tuned against Unity's fixed timestep, this controller is not a drop-in addition; it is a change to the simulation loop. The README presents the slicing and slowdown options as ways to cope with low frame rates, which implies the author expects the delta-time step to be a problem under load.

The repository also gives you very little to verify against. There are no releases, no homepage, and no documentation beyond the README. The README does not document rollback, error handling, or how the controller behaves when the Physics Manager is absent. It also does not state which Unity versions are supported. The last push to the repository was on 2026-07-06, so it is not abandoned, but there is no release history to read for compatibility notes.

Finally, if your game is a simple first-person or third-person mover on flat or gently sloped ground, the built-in CharacterController plus a slope limit will do the job with far less integration work. The mechanisms here pay off on stairs, on rigidbody interaction, and on frame-rate independence, not on a flat plane.

How it differs from the built-in CharacterController and from a plain rigidbody

The built-in Unity CharacterController is a capsule collider with Move and SimpleMove methods, and it does not participate in rigidbody dynamics. It will not push a crate, and it will not receive forces. Its ground detection is a grounded flag rather than a measured surface. This project takes the opposite approach on both counts: the README states the core is a rigidbody that interacts with other rigidbodies in expected ways, and ground slope comes from a triangulated mesh pattern of raycasts sampling multiple height points rather than a single ground check.

A plain rigidbody with a capsule collider is the other common alternative, and it is closer in spirit to this project, but it leaves the work to you. You would need to write the step-up correction, the world motion application, and the collision guard that stops corrections from pushing the character through geometry. You would also be living with FixedUpdate timing and the raw physics output the README describes. The difference here is not the underlying body type but where the corrections happen and when physics steps.

The trade-off is control versus cost. A plain rigidbody gives you the standard Unity execution order and every tutorial written about it. This project gives you frame-aligned physics and pre-resolved character corrections, at the price of adopting its Physics Manager and accepting an execution order that most Unity documentation does not describe.

Maintenance, licence and the cost of upgrading

The repository is not archived and the last push was on 2026-07-06. There are no tagged releases, so there is no version number to pin and no changelog to read between updates. Upgrading means pulling the latest commit and diffing the scripts under Assets/ against the copies in your project. If you have modified those scripts locally, which is likely given the absence of documentation for the inspector fields, every pull is a manual merge.

The licence is MIT, stated in the README and present as a LICENSE file at the top level. MIT permits use, modification and redistribution with the licence and copyright notice retained. That makes the project safe to vendor into a commercial Unity project from a licensing standpoint, but it also means there is no commercial entity behind it, no support contract, and no obligation on anyone to fix a bug you report. Check the LICENSE file itself for the exact wording rather than relying on the README's summary. This is a description of the licence, not legal advice.

Editorial conclusion

Adopt it if you want a rigidbody-based Unity character controller that can run in Update and already handles step corrections and stair slope estimation, and if you are willing to integrate a Physics Manager script into your project. Do not adopt it if you need a package with releases, documentation pages or a support channel, since the repository has none of those. Before committing, verify that the Physics Manager script works with your project's existing physics settings, and read the Assets/ folder to confirm which scripts you actually need to copy.

Frequently asked questions

Official sources

1. BoundingBoxSoftware/CharacterController on GitHub
2. Issues
3. License: MIT
4. README