With very few exceptions, the player should always feel like they are in control. For most games, this control involves some sort of character or vehicle that translates player intent into direct results in the game world.
The player interacts with your character controller at least 90% of the time for most games that include one. Therefore, the character controller shapes the gameplay experience for your players more than most of your other game features combined. In fact, to access most of those features, the player must in some way interact with your character controller so it's absolutely crucial that you spend plenty of time making sure that it feels right.
But what "feels right?" How can we quantify and improve our controller for the best possible player experience?
Over the course of this mini-series, I'll cover some key concepts for making excellent character controllers both in Unity and in general; many of these principles apply outside of the Unity game engine, and even apply to both 2D and 3D games. So, without further ado, let's jump into it!
So, Rigidbody physics, or CharacterController "physics"?
In Unity, there are two main possibilities to form the basis of our controller: Character Controller or Rigidbody components. A Rigidbody is ideal for any game in which we want physics objects to be able to push the player, or for non-bipedal characters such as space ships. However, implementing your bipedal character with a Rigidbody-based controller will incur extra development time since you'll need to use some tricks (like changing the drag coefficient based on input) so in most cases, you will want to use CharacterController components combined with your own input controller which actually sends instructions to this specialized collider.
When deciding which to use, consider how much time will be spent on physics interactions in the game. As a rule of thumb, if less than 40% of gameplay requires physics objects to interact with the player directly, or physics interactions are either one way (character affecting Rigidbodies but not the other way around) then I generally implement a CharacterController-based approach.
This gives us a starting point, and we can begin implementing and testing our choice. Which ever you choose, test it thoroughly for the use cases you intend to have for your specific game. While a CharacterController-based system is better for bipedal characters in general, a Rigidbody-based system is almost always better for anything else (except perhaps four-legged wildlife). I would (almost) never recommend using a CharacterController for any character that needs to be able to fly, because you will end up spending many extra hours programming in fake physics to make your flight, take-off, landing, and in-flight object interactions feel "right". In this case, it's recommended to use a Rigidbody-based system.
Don't fall victim to sunk cost fallacy, however. Even though we implemented one type of controller, if we start to encounter a lot of problems while working with it, we can always try a simplified version of the alternative approach. Remember that each implementation will have it's own needs and nothing will be 100% easy - character controllers of any kind can easily reach 1K+ lines of code.
Which ever you choose, don't give up because in Part Two we will talk about responsiveness, and how the input directly affects the player's experience.
Want to cut out all of the grunt work and dive straight in to your next big game project? Check out the MultiGame Pro Beta for early access to character controllers, input systems and over 140 scripts, features, and editor tools for your next big Unity project.
