# Unity-CharacterController: a third person controller you open as a Unity project > Unity-CharacterController is a small C# asset that gives a Unity project a third person character with camera rotation, jumping and gamepad input, distributed as a full project folder with Assets, Packages and ProjectSettings rather than as a package. It works on Unity 2018.3 and later, and the repository has had no push since 2026-04-12. **dbrizov/Unity-CharacterController** — Third Person Controller for Unity - Repository: https://github.com/dbrizov/Unity-CharacterController - Stars: 1,077 · Forks: 144 - Language: C# - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/dbrizov-unity-charactercontroller ## A complete project folder, not a Unity package you install The repository is laid out the way a Unity project is, and that single fact determines how you consume it. The top level holds Assets/, Packages/, ProjectSettings/ and UserSettings/, plus a README.md, a LICENSE.md and a .gitignore. There is no package.json, no manifest entry, no asmdef in the visible tree and no registry it would come from. That means the delivery mechanism is a folder you copy into your own project, or a project you open directly in the editor. The Assets/ directory is where the controller scripts, the scenes and the prefabs live, Packages/ carries the resolved package dependencies of the project the author was working in, and ProjectSettings/ carries the project configuration such as input axes and the physics settings that affect how the controller behaves. This has an obvious benefit and an obvious cost. The benefit is that you get a working configuration rather than a class, because the input axes and the scene setup travel with the code. The cost is that there is no version pin and no upgrade path through a package manager. When the author changes the code, you receive it by copying files, and you have to notice the change yourself. For a project that is still being prototyped, that trade is usually fine. For a shipped title with a CI pipeline, it is a maintenance decision you have to make deliberately rather than inherit. ## What the controller does is described by its controls, not by its parameters The README is short, and the substance is in three places: the requirement, the controls and the demonstration clips. The system requirement is stated as Unity 2018.3.0 or later versions. That is a floor, not a tested range, and nothing in the repository extends it. A current editor is a later version, so the requirement is satisfied, but the project was written against a 2018 generation of Unity and the repository offers no statement about newer releases. The keyboard and mouse scheme is conventional for a third person game. Movement is WASD, the camera is driven by the mouse, and jump is the space bar. An XBOX 360 or ONE controller is supported, with the left stick for movement, the right stick for the camera and the A button for jump. The four animated clips that illustrate the project are the most informative part of the documentation, because they show the behaviour the code is meant to produce. One is a camera rotation clip, one is a jump in place, and two show jumping while moving, one of which is captioned as the zero case and one as the one case. That set of four tells you the controller handles the camera independently of locomotion, and that it distinguishes between jumping from a standstill and jumping at a run, which is the part that usually needs extra work when a character controller is written from scratch. What the README does not contain matters just as much. There are no parameters, no speed values, no jump height, no camera distance, no sensitivity setting and no API description. The behaviour is demonstrated, not specified. ## Getting it into a project, which is a folder copy rather than an install There is no install command to run and no package to fetch. The repository gives you a Unity project, and the documented way to use it is to open the project in the editor and copy what you need into your own project. The first step is to have an editor at version 2018.3.0 or later, since that is the stated system requirement, and to open the project folder rather than the raw repository, so that Unity generates the Library and the imported assets. Once it opens, the Assets/ directory is where the controller scripts and the demonstration scene live, and the scene is what you will actually press play on to see the camera rotation and the jump behaviour rather than reading the code and inferring it. Copying Assets/ into your own project is the step where things can go quietly wrong, and the ProjectSettings/ folder is the reason. The controller reads the horizontal and vertical input axes by name, and those names come from the input configuration in ProjectSettings. If you take the scripts alone and your project names the axes differently, the character will not respond to WASD and you will spend time looking for a code bug that is not there. Taking the whole folder and then reconciling the axis names against your own project avoids that. After the copy, the sensible first check is the jump behaviour rather than the movement, because the demonstration clips exist to show exactly that. Run the character at a standstill and then at a run, and confirm both cases feel the way the clips do. ## The MIT licence and a copyright date from 2015 The licence is MIT, and the copyright notice reads Copyright (c) 2015 Denis Rizov, with the full permission text reproduced in the README and a matching LICENSE.md at the repository root. MIT is a permissive licence with no copyleft, so you may use, modify, merge, publish, distribute, sublicense and sell the code, including inside a closed source commercial game. The one obligation is that the copyright notice and the permission notice travel with all copies or substantial portions of the software, which in practice means keeping the licence text in your project or in your asset folder. The 2015 date is worth noting because it frames the whole project. The copyright line has not been updated in a decade, which is consistent with a personal project that was finished and released rather than iterated on. The repository topics also suggest an earlier era of Unity tooling, listing unity3d alongside character, controller and third-person. The licence position is the strongest part of the package. There is no ambiguity about commercial use, no copyleft to negotiate, and no dual licensing to think about. For a controller, where the code is a starting point that most teams will modify heavily, that matters more than the absence of a release cadence. ## The gap in the documentation is the gap in the API There is no setup documentation at all. The README does not say how to import the controller into an existing project, which prefab to drop into a scene, which scripts to attach, how the input axes are expected to be named, or how the camera is parented. There is no CONTRIBUTING guide, no changelog and no issue tracker reference. Some of that is normal for a small asset. But the input axes point deserves a second look, because a controller that reads horizontal and vertical axes by name depends on the names being present in the project's Input Manager, and the axis configuration travels in ProjectSettings/. If you import only Assets/ into your own project and your axes are named differently, the controller will not move, and the failure will look like a code bug rather than a configuration mismatch. The project as shipped includes the ProjectSettings folder for exactly this reason, and that is the argument for taking the whole folder rather than cherry picking the scripts. The camera is the other unspecified piece. The demonstration shows mouse driven camera rotation, but whether the camera is a child of the character, a separate object with a follow script, or a Cinemachine style rig is not stated. Anyone integrating this will spend their first hour in the scene hierarchy working that out. None of this makes the project unusable. It makes the evaluation a hands on one, which is the correct way to assess an asset whose value is its behaviour rather than its interface. ## Against writing the controller yourself, and against the engine's own The honest comparison is with two other routes, and the project is best understood between them. The first is writing the controller yourself, which is what most teams do for a prototype. A character controller in Unity is not a small piece of work: you need ground detection, slope handling, a jump that behaves sanely at different speeds, a camera that follows without jitter, and input handling that works on both keyboard and pad. The value of this project is that those four things are already working together, and that the jump case distinguishes standing from moving, which is the specific case the demonstration clips highlight. The second is the controller that the engine already provides. Unity ships a character controller component, and the difference in approach is worth being precise about. An engine component is a movement primitive: it moves a collider and reports whether it hit ground. It does not give you a camera rig, a jump state machine tuned for a game, gamepad bindings, or a scene wired up to demonstrate it. This project is a finished gameplay setup built on top of the engine's mechanisms, not a replacement for them. So the decision is not engine component against third party component. It is whether you want a starting configuration or a starting implementation. If you want a configuration, this is it. If you want a fully parameterised, documented, updatable system, neither this nor the engine component gives you that, and the work is yours either way. ## What the repository's own history says about expecting updates The maintenance picture should be stated plainly rather than softened. The repository is not archived, and the last push was on 2026-04-12. There are no GitHub releases, so there is no tagged artefact, no version number to pin and no changelog to check against a newer copy. The default branch is master, the topics include third-person and character, and the presence of UserSettings/ alongside ProjectSettings/ in the top level is consistent with a project that was opened and edited in the Unity editor rather than assembled by a build pipeline. A UserSettings folder holds per machine editor preferences, which is exactly the kind of directory that is noise in a shared repository and evidence of a personal workflow. None of this is a criticism. It is a character project, and character projects are often exactly this: finished once, published, and then left alone. The practical consequence is that you should treat the code as a fixed reference rather than as a dependency with a support line. If you adopt it, you own the copy, and you own fixing it when a future Unity version changes something about the input system or the physics defaults that the controller was written against. That framing also makes the licence decision easy. You are taking a starting point, not a subscription. ## Conclusion Unity-CharacterController fits a solo developer or small team that needs a working third person character this week and would rather open a project and press play than write camera, input and jump code from scratch, and it is a reasonable reference to read for the shape of a third person setup in C#. It does not fit a team that wants a maintained, versioned dependency, because there are no GitHub releases and the last push was on 2026-04-12, and it does not fit a project that needs tunables, documentation of parameters, or an explicit support statement for a current Unity release. Check three things before you adopt it. Check that your Unity version is at or above 2018.3.0, which is the stated system requirement, since the project predates the current editor generations and nothing in the repository says it was verified against a later one. Check how you will take delivery of updates, because the repository is a project folder rather than a Unity package, so there is no package manager entry and no manifest dependency to pin. And check what you are actually getting, since the README names the controls and the version requirement but documents no parameters, no API and no setup steps. The licence is MIT, with copyright held by Denis Rizov from 2015, so you can reuse and modify the code in a commercial project without copyleft obligations. ## FAQ ### What Unity versions does Unity-CharacterController support? The stated system requirement is Unity 2018.3.0 or later versions. Nothing in the repository extends that to a tested range or names a current editor release. ### How do I add a character controller to a Unity project? The repository ships as a Unity project folder with Assets, Packages and ProjectSettings at the top level, so it is opened in the editor or copied into your own project rather than installed from a package registry. The README does not document a step by step import procedure. ### Which controls does Unity-CharacterController use? With keyboard and mouse, movement is WASD, the camera follows the mouse, and jump is the space bar. With an XBOX 360 or ONE controller, the left stick moves, the right stick controls the camera, and the A button jumps. ### Can I use Unity-CharacterController in a commercial game? Yes. The project is released under the MIT License, copyright Denis Rizov from 2015, which permits use, modification, distribution and sale in a closed source project as long as the copyright and permission notice are included. ### Is Unity-CharacterController still being updated? The repository is not archived, but the last push was on 2026-04-12 and there are no GitHub releases, so there is no published version history to track. Treat the code as a fixed starting point you maintain yourself. ## Sources - [dbrizov/Unity-CharacterController on GitHub](https://github.com/dbrizov/Unity-CharacterController) - [Issues](https://github.com/dbrizov/Unity-CharacterController/issues) - [License: MIT](https://github.com/dbrizov/Unity-CharacterController/blob/master/LICENSE) - [README](https://github.com/dbrizov/Unity-CharacterController/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dbrizov-unity-charactercontroller