Will a character controller cause potential problems?

Unity Engine
1

Hey Everybody!

So I have question relating to character controllers vs rigidbodies. My limited experience with either of them is giving me a little trouble and was just wondering your opinion. From what I understand I can create a basic/fake physics system with a character controller but I’m not sure if i’m setting myself up for problems with this one.

I’ll give you a brief run down of the project I’m working on and what i’m trying to accomplish:

It’s 3d side scroller, 3d assets 2d controls.
There are currently 3 characters and they exist on the screen at the same time
One character has the ability to move objects that must interact with these characters - Moving Blocks

The characters must be affected by the Moving Blocks
The characters, ideally, will not collide with each other
I’m also trying to force deterministic behaviour…

I was wondering which would be better to use in my current situation, Character Controller vs Rigidbody. I’ve read that using both is sometimes buggy and I would like to stay away from that as much as possible if that’s the case. I believe using a character controller and attempting to create my own physics will allow my game to be deterministic as well, I could be completely wrong with that as well.

Any help is much appreciated.

2

character controller positives:

  • Very simple to move however you’d like to
  • Simple things such as characterController.isGrounded and characterController.Move and characterController.SimpleMove giving data about the last movement made.
  • You can do most of the physics without needing to tap into FixedUpdate which is a penalty to avoid.

character controller negatives:

  • Unless you constantly are moving the character controller, things hitting the controller will only generate collision methods during a call to either characterController.Move or .SimpleMove
  • Not being on FixedUpdate will result in lossy physics that are dependant on framerate ( assuming you dont interval updates yourself )
  • You can only use the capsule shape ( or sphere if you adjust the capsule as so )
  • You will end up writing alot of physics for every sort of movement style you plan on having per character
  • You’ll need to program most interactions between rigid bodies ( like applying forces on collision )

using only a rigid body pluses:

  • as long as your not setting transform.position directly collision events will fire off as ushual
  • great for things like vehicles that do not need a raw position change
  • you can use any collider available and assign physics materials
  • as long as you modify the physical elements like velocity, force, torque things should be stable in sane conditions.
  • constraints.

minuses:

  • you basically need to come at this decision like you are going to let the physics move the character and you just drive the physics.
  • still requires a good amount of code, and if you need to put some feature entirely new to drive physics on fixedupdate it can really clog the games framerate quick.
  • it doesnt offer any of the benefits of character controller
  • trying to rely on collision events past things like visual effects is ushually a fruitless en devour because of the amount of rules with when messages get send and when they don’t.

So you can come to your own conclusions, but i’d probably say unless its like a marble, or driving game you’re only real choice is to use character controller if you plan on using unity’s collision system. Tapping into things like rigidbodies beyond constraints is something that i feel is just too much of a strongarm approach that ushually results in something thats slower than the character controller.

With that said though, to me the biggest pitfall of the character controller is making up for the framerate reliablity. I think if you stick to .SimpleMove which applies gravity you might be okay, but it still doesnt handle things like manual velocity acceleration over a fixed time. Using a catch-up time interval system is one of the ways to accomplish this without tapping into fixedupdate and you can account for fractional increments so it plays back smooth.

3

The character controller has been riddled with bugs and technical issues as late as Unity 3.1. I don’t know if it still is, but that’s really irrelevant. All a character controller is is a glorified collider. It offers very little in terms of physics. It lets you move your character in a straightforward manner, but that’s it. It can only detect collisions with other colliders when the character is moving. Kinda pointless unless one of your character’s abilities is invulnerability while motionless. Collisions with rigidbodies aren’t even registered unless the character controller initiates the contact with the rigidbody. To detect collisions properly, you’d still need to attach a rigidbody to your character. But a character with both a character controller and a rigidbody produces such jerky movements and actually messes up the collision events. Add to that the fact that a rigidbody can simulate everything that a character controller can, and you’re left asking yourself why you’d even want the character controller with your rigidbody at all. You’ll just end up stripping your character of the character controller and end up with the rigidbody. You’ll still need to use a collider, but the rigidbody can take care of everything else. The only people who should ever use a character controller are beginners, non-serious devs who only really care about “finishing” a game so they can brag about it to whoever cares, and people who have developed a workaround to its inherent bugginess. Thats my 2 cents. Keep the change.

4

Thanks alot for the replys, sorry for the late response but I went with a rigidbody and a capsule collider for my characters. I change the velocity of the characters in fixedupdate and simulated gravity.

I created a controls class that listens for inputs in Update then, using a C#Messenger system, I broadcast the specific input to whoever is listening. The characters velocity is changed in FixedUpdate while the Inputs are broadcast during Update. Will this method still help ensure a deterministic behaviour?

5
6

Yes, but that only further enforces the notion that a rigidbody is better than a character controller. Also, a character controller colliding with a static rigidbody will not send a collision event because collision with a character controller cannot wake up a sleeping rigidbody.

7

Huh? I have a player using a CharacterController for movement and has a kinematic Rigidbody component. Nothing jerky, it plays as smooth as a real Super Mario game (wich in my world is perfect controls for a 2D platformer). I find the Character Controller to be very good since it gives you very good control over the player’s movement without relying on physical correctness. You can do all the unrealistig movement of classic video games. As for the player colliding with enemies, I use a little trick. Every creature, be it a player or an enemy has a child object which is a rigidbody with a collider. This “collision sensors” as i call them have their layers set to that they can only collide with each other, no scenery. Works perfectly fine.

1 Like