I was surprised at Rick’s suggestion to have more than one collider on the player, and even more surprised at the assumption that bodies will be capsules throughout your games development lifecycle and feet will be rectangular.
It’s generally considered best practice nowadays to use children of a gameObject if you want multiple colliders on it since the video was made, I think…?
The biggest strength of giving colliders to separate children/grandchildren of your player is that each child gameObject can have a separate layer or tag (or both!), so you can do “IsTouching” checks on only certain layers: effectively applying your physics check only on specific body parts such as feet for the ground and torso for enemy attacks,
Also you can animate the movement of different body parts (feet, hands, head, torso etc) independently in a natural skeleton-like way.
If you just need a complex shape on a body ( ie not a capsule or circle or box) then use a PolygonCollider2D and draw out the body+feet+head shape.
Another advantage of having only one collider per gameObject (using children if you need more) is that the variable in script can look for a Collider (or Collider2D ) without having to know whether it’s a box or capsule or polygon collider. This is about the Law of Demeter (LoD) or principle of least knowledge, where your code shouldn’t depend on features that doesn’t fundamentally affect it’s behavior. Put simply: your feet might be boxes, or capsules, or they might be polygon shapes: in the later game design phase you might change your might many times about what collider to use for the feet, and your software developers shouldn’t have to change the code every time they make this change.
Also having both trigger and solid (non-trigger) colliders will possibly lead to bugs in more advanced games where the physics engine doesn’t know whether to send an OnTriggerStay/Enter/Exit message or an OnColliderStay/Enter/Exit message, or both, or in what order to send those two messages to the gameObject.