How to control collisions properly

Hi,
talking about collision methods (OnCollisionEnter, OnCollisionStay, etc.) I was wondering which way is better to control what happens on collision:

1) Classic way: just have the OnCollision methods in each component of a gameobject that need them and use the different methods to determine what happens. So, for example, I have a PlayerController and a CharacterMovement, both components will have their own OnCollisionEnter, OnCollisionExit etc.

2) Collision controller: I was thinking about a collision controller component, so I have a main component that handles the OnCollision methods and then in each of this methods I invoke an event which any other component (my PlayerController, CharacterMovement etc) can subscribe and handle the OnCollision through events call.

- Are OnCollision methods expensive?
- Is it better to just have one main component that manage OnCollision methods instead of many components? - Which of the two way is less expensive?
- Do you have any other idea to control collision?

Thank you very much!

 

Someone please correct me if I'm wrong... I think the most expensive part of collision checking is on the physics engine, depending on the layer collision matrix and collider shapes, regardless of how many OnCollision methods there are.
I usually set up OnCollision methods on all gameobjects which can actively collide, and then have those gameobjects dispatch custom events containing the Collision object (https://docs.unity3d.com/ScriptReference/Collision.html) and state (Enter, Stay, Exit). This way other components can subscribe/unsubscribe to those events as they need to.

 

Thank you for your answer mbaske.
I hope someone else will share the methods they use...

 

Even if they were expensive, alternatives are for more niche situations which usually means they are harder to get used to and less flexible. NavMesh can be considered an alternative to collision for a RTS game since it just needs broad strokes defined as walkable or not.

Maybe you're asking about maintainability? Your preference will decide which you are more comfortable with. The usual pattern however is, having individual components register the collisions themselves is easier in early development, but becomes confusing later on since it's usually forgotten what component registers collision, and in addition what happens upon registering said collision. It happens when a game starts getting complex, and a game's needed/wanted complexity is down more to design than scripting ability.

Having a collision manager is I believe negligibly more efficient than having collision on individual components. Even then, you have to consider the situation for which can even work as you intend, let alone which is more efficient.

As an example, registering a hit with a physics object on a character limb requires the child object "limb" of the character to be able to register its own collision. A manger on the parent object "character" to manage collision just isn't practical if not impossible in that situation.

Again, the performance gain from having a manager is I believe negligible, so the focus for long term development should be maintainability, not efficiency.

EDIT:

Again, depends on the game whether using an alternative is beneficial. As an example, a game that only has guns might only need raycasting for their bullets. If the environment is completely static, the characters might only need CharacterControllers to handle collision with the environment. The animated skeleton and collision volumes depicting the collidable vague human shape on said skeleton, does not need rigidbodies on the individual collidable parts since raycasting is the main, if not only, mode of delivering damage.

 

Thank you Laperen, that's a full and useful answer!
I think I will go for the Collision manager since I just have a single object for my characters (I'm making a 2D game, so they are just sprite with child objects that don't need collisions handler).