[Released] Character Movement Fundamentals - A Rigidbody-based Character Controller

Hey I am having some issues with creating a controller . Would you help me

 

Can you help me make a controller for my game. Sent an email

 

Hi! I really would like to buy this asset, but I have a few question before:

1- Is it mobile friendly?
2- I'm seeing some examples in this other unity asset: https://assetstore.unity.com/packages/tools/physics/character-controller-pro-159150#description. It has gravity square and round planets and different kinds of rotating platforms. Is it easy to implement those in your asset? Or has some kind of integration already?
3- Is it easy to implement Agents? ( I mean for implementing some kind of following)
4- There is some kind of crouch implementation already? If not, it is easy to implement or I'll going to need special rules for scaling and out of the "hole"?
5- There is some kind of weight? So I can have platforms that change direction according to the character weight and position on it. (there is an exemple in the asset above too)
6- Can I pause/resume character integrations?
7- Has Collision information? (ground normal, slope angle, edge detection, wall angle, etc.).

Thanks! =D

 

Hi!

1. Generally speaking, yes. But you'll need to write a bit of custom code to handle mobile input.
2. It's relatively easy to implement a 'planet walker' setup (there will be an example scene for this included in the next version, 2.1). Rotating platforms are currently not supported out-of-the-box, though.
3. If you're referring to Navmesh agents specifically, then you'll probably need to implement some kind of custom system, since Navmesh agents and rigidbodies are not really compatible with each other in Unity (if used on the same character at the same time).
   
4. Crouching is fairly straightforward to implement - there's already a function set up you can use to change the controller's height at runtime. Turning this into a 'crouch' system can be done with a few lines of code.
5. No, currently the controllers don't exert any force on the ground below them. It's possible to 'fake' this effect though, if needed (by manually applying forces to rigidbodies detected by the ground detection system).
6. Yes, there's a few different options to disable character movement, depending on your specific use-case (cutscenes, pausing the game, temporarily disabling input, [...]).
7. The ground detection system currently stores the main surface point, surface normal and collider reference. Edge detection and wall angle is currently not supported, though.

I hope this helps!

 

What's performance like for having multiple controllers running, are there any stress test results?

 

I'm just starting to dive into the controller and it seems pretty solid so far. What would be the best way to add acceleration and deceleration variables to a custom controller. Currently the controller immediately goes to full movementSpeed when pressing a key or pushing a joystick to the full extent. Cheers!

 

I don't have have any specific stress test results ready right now, but I have had hundreds of controllers running around in the same scene without any problems (on my 5 year old laptop).
I suspect that the real performance bottleneck would be the character meshes attached to the controllers, rather than the controller code itself.

I'll try to do some stress tests in the future, if I find the time!

There's two basic ways to implement this kind of functionality: You can either dig into the 'AdvancedWalkerController's' code and add some basic smoothing to the current movement velocity (which requires a bit of C# coding experience) or you can just smooth the input going into the controller (which is a lot simpler).

The best choice depends on whether you want the acceleration/deceleration mainly for the visual effect (in which case smoothing the input is completely sufficient) or if you need a more complex system that actually tracks the current speed, and adjusts the speed toward a specific target speed.

Either way, please feel free to contact me directly via email (support@j-ott.com) with more details about your project and I'll try to go more into the specifics, if you're interested!

 

I think the discord invite is broken, when i try to use it, discord says that the invite is invalid or expired

 

Strange, I just checked and it seems to work fine on my computer. Did anyone else encounter the same problem?

 

I found the problem, i was already in 100 Discords servers, which is the maximum

 

Hi Jan, i wanted ask you if this assets can support a parkour game, and if there are some things already done (ex : wall run, sliding etc.)

 

Hi! The controller's included in the package are mostly geared toward general 3D platformer movement, so they don't have genre-specific features (like wall running or sliding) built-in by default.
However, you could add these movement options yourself, if you have some experience with C# coding.

I'm not aware of any use-cases like that, but you could try asking on the official Discord server!

 

Hi Jan,

I am in the early stages of implementing a character controller. I'm intrigued by the great reviews and the 'free rotation' controller of yours since I need the Player's character to walk on walls and ceilings. I also need the Player to fly and swim which means there is no 'floor' to make contact with. I'm not afraid of coding (I'm an engineer) but don't have much experience game coding. I'm imagining setting an altitude just by using key presses to move up and down the y-axis and then staying fixed at that height. I'll probably want to rotate the Player horizontally like you would be flying or swimming. Is there a way to use your controller to help me with at least part of the solution or would I code up something new and 'turn off' your controller off while the character flies?. Any thoughts/suggestions are appreciated. - Larry

 

Hi Larry,

Generally speaking, I'd always recommend creating a separate 'swim controller' or 'fly controller', if you want to switch between different movement types during gameplay.

You can have multiple controller scripts attached to your character and enable/disable them as needed (so only the currently relevant one is active at a time). For example, whenever your character enters a body of water, you'd simply disable the regular 'AdvancedWalkerController' and enable your custom 'SwimController'.

This way, you can keep your character's movement modular and you don't need to create one big controller script that handles all movement states.

I hope this helps!

 

hi, i just install unity new input system, and than Capguy is not working. can you help me?
i see threre is a
CharacterJoystickInput component, but i don't know how to make it work with new input system.

thanks!

 

Hi!

Currently, the CMF package only comes setup with Unity's default input system. In order to make use of the new input system, you'll have to create a custom input script, which gets its input from the new input system.

If you're interested, there's a whole chapter in the manual that explains the very basics of writing custom input scripts (chapter 7, page 34).

I hope this helps! Please feel free to contact me via the support email (support@j-ott.com) if you get stuck!

 

Makes sense, thanks Jan.

 

Question Jan,

I'm trying to add a 'glide' ability when the Jump input is pressed & held while in the air... Reading through some of the documentation it seems I may need to do this in the Mover script (I think...)

Would it be best to add a new function/if statements when the isGrounded check is performed? E.g. If collider != grounded, and holds "Jump" input -- then gliding starts?

Thanks!

 

While modifying the 'AdvancedWalkerController' is one way to implement a gliding ability, an easier approach would probably be to create a separate "GlideController" script (that only handles the gliding movement).
There's also a chapter in the user manual (chapter 8, page 37), which goes over how to write custom controller scripts, if you're interested.

During the game, you could then switch between the regular 'walker' controller and your 'glide' controller when needed, by simply disabling one script and enabling the other (so there's always one 'controller' active at a time).

If you do want to modify the 'AdvancedWalkerController' directly though, you'll probably need to add quite a bit more code than just a modified 'grounded' check, since the grounded state of the controller affects a lot of other systems inside the controller.

I haven't tried to implement gliding movement yet, so I can't really recommend a best approach here - but please feel free to contact me via email (support@j-ott.com) if you need any help.

 

Ah I see. Making a separate controller to switch for gliding makes perfect sense.

Thanks Jan!

 

Hello Jan,

Great Asset. The code are more understandable for me than other similar asset. Thanks!

I'm struggling adding code to make my character climb at ladder. I need a simple state where the vertical inputs are transformed in up and down translate.
I'm a bit stuck because the character keep on being grounded and don't want to come up.

Any idea on how to implement it?

 

Hi!

Similarly to the previous question, I'd recommend disabling the controller script once the character reaches the ladder (and enters the "ladder-climbing state") and enable a custom script that handles the up/down translation of the character.

Once the character stops climbing the ladder, you'd simply turn on the controller script again (and disable your custom ladder-climbing script).

As a general rule of thumb: It's always easier to use Unity's component enabling/disabling system compared to modifying any code directly, when it comes to implementing movement that is temporary or highly situational (like a ladder).

I hope that helps!

 

Did not see that way.

Good idea since the controller constantly calculate things that are not related to hanging to a ladder such as vertical momentum and stuff.

I will do it that way.

Thanks for tip!

 

Does it do Mario Galaxy/outer wild gravity?

 

The controllers can be freely rotated (even at runtime), so implementing (for example) planetary gravity is just a matter of continually aligning the character toward the center if the planet (or wherever you want the gravity to point at), by using a custom C# script.

Hope that helps!

 

yes, thanks

 

Hi everyone!
Just a quick heads-up: I'll be out of office until September 1st and will most likely have no internet access in the meantime.

I'll try get back and respond to all questions and support requests as soon as possible when I return, though!

Best wishes,
Jan Ott

 

Quick update: Version 2.1 has just been approved by Unity and can be downloaded at the Asset Store now.

[Click here to visit the Asset Store page.]​

NOTE:​

There has been a minor change to the camera system setup in this update! A few adjustments might be necessary when updating from version 2.0. Please create SAFETY BACKUPS of your projects before importing this updated version, just to be safe!

Spoiler: Version 2.1

MOVER:
- 'Mover' now supports scaled colliders. (NOTE: It is still recommended to keep the controller's collider and root at scale (1, 1, 1), for physics stability reasons. Please consider changing the collider size instead and only scale the model/mesh of your character.)

CONTROLLERS:
- 'AdvancedWalkerController' now also has a 'SetMomentum()' function for easier access to the controller's momentum.
- Slight change to jump logic inside 'AdvancedWalkerController': Jump key now needs to be released before controller can jump again. This prevents the controller from continually jumping if jump key is held down.
- Main controller update code was moved to its own 'ControllerUpdate()' function (which is called in FixedUpdate()).
- Added 'ClickToMoveController' script, a basic example of top-down, mouse-controlled movement.

CAMERA SYSTEM:
- Streamlined 'CameraController'. All mouse input handling was moved to 'CameraMouseInput' script.
- 'CameraMouseInput' now has a 'Mouse Input Multiplier' variable, that can be used to control mouse sensitivity.
- Fixed bug in 'CameraController' - script can now handle a project timescale of '0'.
- 'CameraDistanceRaycaster' now uses a separate "target" object for its obstacle raycasting. This target object can be freely moved around at run-time, allowing users to easily change the camera's position while the game is running.

PREFABS & SCENES:
- Scenes are now organized into 'Showcase' and 'Special' folders.
- Added example 'PlanetWalkerScene'.
- Added example 'ClickToMoveScene', which demonstrates the new 'ClickToMoveWalker' controller prefab.
- Moved 'ExternalCameraScene' to 'Special' folder.
- Added a 'blank' and 'animated' controller prefab for the new 'ClickToMoveController' component.

MISC:
- Removed 'MoveTowardVectorLength()' function in 'VectorMath' class. Unity's built-in 'Vector3.MoveTowards()' function is now used instead.
- Updated 'MouseCursorLock' - script should now work properly in newer Unity versions.
- Added 'AlignRigidbodyToTarget' script, which is used to align the controller to the planet's center in the 'PlanetWalkerScene'.

As always, you can contact me via email (support@j-ott.com) if you have any questions about the package or the new update!

 

Hi Jan, I'm trying to look for a solution for a character movement that's relative to a dynamic object. I.e. a character that's on a boat. A boat has its own rigidbody. So the character should respect the boat's rotation and velocity. I wanted to know if your asset supports that?

 

Hi! The package doesn't come with this kind of functionality by default, unfortunately.

Theoretically, it should be possible to add the current velocity (and rotation) of the boat to the controller with a custom script, but depending on your specific use-case, it might be a bit tricky to implement - since both the controller and the boat are technically dynamic rigidbodies, they will affect each other's positions and roations (since they will collide with each other), which can get very unpredictable.

Feel free to contact me directly via 'support@j-ott.com' with more details about your game and its gameplay and I'll look further into this (or suggest an alternative solution)!

 

Just an idea: The boat rigidbody should be marked as kinematic. The character should be a child of the boat. Then move the character relatively to the parent (the boat) with local commands.
Maybe this solution is not possible...

 

Yes, using a kinematic rigidbody for the boat would simplify the implementation quite a bit.

I'm not sure if parenting the controller to a kinematic rigidbody would work, though - in my experience, parenting rigidbodies in general often leads to glitches and other physics stability issues. Different Unity versions seem to handle this specific case (parented colliders) very differently as well.

 

Ok, I understand. Yea the feature that I was thinking about is a tricky one Anyway, thanks for the quick response

 

I asked this question on discord channel:

hi. would you know if this works with puppet master?

With this to work (non integrated), you would have to switch off the controller, let puppetmaster do its thing, and once finished turn on controller again. The only part where the two might not mix well, is that puppetmaster will most likely be in a different transform position and rotation once it is ready to return control to controller. If you can set controller position and rotation before controller becomes active, that would most likely work.

 

Yes, I'd assume that you'll have to "sync" (or re-center) the controller before turning it on again. The specific implementation of that heavily depends on how Puppetmaster moves the controller though - I haven't really tried the 'Puppetmaster' asset yet, but please feel free to contact me directly via email (support@j-ott.com) if you run into any technical issues and I'll try to help out!

 

Just a quick heads-up for anyone interested: The 'Character Movement Fundamentals' package is currently part of Unity's Anniversary Sale - and available at 50% off.

[Click here to visit the Asset Store page.]​

 

Hi - I just bought the asset but having a problem. Grateful for your help.

For my game mechanics I need the objects with the character controller to have a mass and work with the physics engine so they can do things like jump on a see-saw and then the see saw will pendulum. I thought this was built into the scripts. How can I do this, please?

Antony

 

Hi Antony! Although the CMF controller system is rigidbody-based, it is not a 100% physics-driven controller, since its ground detection is raycast-based.

As a result, the controllers don't really have any weight to them - however, it's possible to "fake" this (to some degree) by adding a downward force to whatever rigidbody the controller is currently standing on (using the 'Mover's 'GetGroundCollider()' function).

It's not very complicated to setup, but please feel free to contact me directly via email ('support@j-ott.com') if you have any questions!

 

Is it possible to add smooth zoom in/out to the third person camera controller?

 

How do I use CMF with Unity's new Input System?

 

I think I just replied to your question via email, but I'll just post my response here as well, in case anyone else is interested:

If you're referring to moving the camera closer (or further away) from the character model (as opposed to an actual zoom, like the scope of a rifle, for example), then the easiest way to implement this would be to add a simple script to the 'CameraTarget' gameobject (located at Root>CameraRoot>CameraControls>CameraTarget) and adjust the transform's local z-position (based on user input, like the mouse wheel, for example).

To smooth out the transition, you could just keep track of the current z position and lerp/smoothdamp the value over time, for example.

The easiest way to implement any custom input (including the new input system) is to create a new input component and adding it to your controller (replacing the default 'CharacterKeyboardInput', for example) - please feel free to check out chapter 7 (page 34) in the user manual for more information on that.

 

I tried doing that. I managed to get it working for the horizontal and vertical movement inputs, but I'm struggling to figure out how to get the jumping working. The isJumpButtonPressed function always returns false no matter what I do with the input system. What am I doing wrong?

 

P.S.: How do I set up multiplayer with this asset?

 

P.S.S: How do I implement camera controls for the new Input System? (How do I use Cinemachine with CMF?)

 

Hard to say - I'd need to see the code of your input script first. Could you maybe contact me directly via email ('support@j-ott.com') and attach your code?

I don't really have a lot of experience with networked multiplayer unfortunately, so I can't provide a lot of help here. I'd recommend asking in the official CMF Discord server - a few people have successfully used the package in multiplayer games, so they can probably point you in the right direction.

You'd first need to remove the 'CameraController' and 'CameraInput' components (which are attached to the 'CameraControls' gameobject). Afterwards, you're free to manipulate this transform as you wish - or use Cinemachine to control the rotation.

 

Just bought! I've wondered, what's the difference between a kinematic controller and a rigidbody controller such as this in practice? I understand something like Unity's CharacterController or KCC do not use real physics at all, and are therefore more suited for unrealistic gameplay such as Doom or Quake, but I believe CMF is able to do un-realistic game styles like those with a few setting tweaks, so I'm interested in what difference it makes if a controller is rigidbody-based or kinematic?

 

The main difference between 'kinematic' controllers (such as Unity's CC component) and 'dynamic' controllers (like the CMF package) is how collisions between the controller and other colliders are handled, on a technical level.

Kinematic controllers usually use a combination of raycasts/spherecasts and overlap calculations to check whether the controller can move the intended distance - and if they detect an obstacle, they only move a fraction of the original distance, so the controller doesn't walk into walls.

However, this also means that kinematic controllers will ignore other physics objects - they won't move other rigidbodies or be moved by a rigidbody, for example (unless someone specifically writes code to handle that).

Dynamic controllers use the physics engine to move around the scene and as a result will interact with other rigidbodies and colliders (push them, be pushed, [...]).

Of course, there are different ways to steer a controller using physics: For example, you could only use Unity's 'AddForce()' function to move the controller around (and make use of the physics engine's gravity and friction), which results in very "realistic"/weighty, albeit potentially sluggish, controls (which can be a great fit for certain games).
Another option is directly setting the controller's rigidbody velocity (that's how CMF handles movement) - which approximates the snappiness of kinematic controllers, though it won't necessarily be physically accurate (which isn't really a concern for most games).

(CMF controllers are also kind of a special case, since they use raycasts to determine the current ground below the controller, but I don't want to get too technical here).
---

I hope that helps clear things up a bit - let me know if you have any other questions (or follow-up questions)!

 

Thanks, that does help! I always assumed physics-based controllers would have that sluggish, weighty feeling, but this isn’t the case when the movement itself is being controlled by the controller and really only the collisions are physics dependent? So, it’s technically possible to have rigidbody-based controller that’s just as responsive and turn-on-a-dime as ChaacterController?

 

Sure! Whether a controller is moved directly based on player input (=kinematic) or the player input is used to set a rigidbody's velocity (and then moved by the physics engine) (=dynamic), the visual result and responsiveness should be pretty much identical.