Hey
In the Starter assets, the third person character prefab has a CharacterController (which appears to provide a capsule collider of sorts) and a ThirdPersonController script which produces a configurable sphere for checking ground collision. As far as I can tell, this only affects the animation.
In the code for the latter, the properties have the following comment:
If the character is grounded or not. Not part of the CharacterController built in grounded check
So now i’m just wondering - why does it go to the trouble/expense of creating an entirely new thing to check if the player is grounded, rather than use the same mechanism the CharacterController provides? Having them separate kind of leads to situations where you can have the animation “falling” even though the CharacterController is making sure the player is NOT physically falling.
I thought it might be some sort of reusability thing, but the ThirdPersonController requires the CharacterController anyway.
Are there use cases where having the ground check separate to the thing that actually stops it falling through the ground is ideal?
It’s probably because the components are developed independently by different developers. Personally I find it pointless, but it’s not gospel so feel free to just craft your own solutions. Nobody here is the authority on this, there’s no hard rule.
Seems odd, given they’re both included inside the same Starter assets package. You’d think they’d be somewhat examples of ‘best practice’ no?
Either way, it’s only really something I’ve come across as I dissect it a bit to create my own for learning purposes. It also seems that most external beginner examples are using spheres of sorts rather than taking advantage of the CharacterController implementation. Just wondered if there’s a reason, such as issues I’ve yet to discover. Else if there’s a definitive way that seems to work as a solid go-to for most when doing this sort of thing, I might as well save my time and go that way
Absolutely not. Most if not all the learning assets are fairly bad for optimised best practises. They’re there to help you get to grips with Unity.
If you wanted best practises, it would be a considerable amount more code, with way higher expected experience.
But I agree with Unity’s choice because it’s all about onboarding at this stage, and when and if it’s actually ever a performance problem, you can dig deeper. For most people even these basic examples will never be a problem.
Fair point there. Cheers I guess these little oddities and such only become a problem when you’ve got much further down the line with your game, by which time you’ve probably picked up enough knowledge to go back and improve/fix them.
Exactly right, and … even more likely, Unity got there first and optimised it. One of the things Unity does is look at how filthy we are with their engine and optimise the paths that tend to be abused such as transforms and so on.
From all the years I’ve been here the worst habit I see are indies becoming stunned by indecision and premature optimising. I see the ones making a lot of money, put out something that’s not really optimal. The difference is one of them is putting stuff out to begin with.
Anyway I don’t even do any of this. My way is simply using Contact Modification API to roll an entire character controller. As I have complete feedback from contact points, I’ve always got a ground check freely available, so I didn’t need to check, just query what was already there.
That’s the sort of stuff you can revisit later on when you’re all powered up