Bang! We’ve collided! What now?

OnCollisionEnter Vs. OnTriggerEnter — When to use them?

Yesterday we took a look at the basics of Unity’s physics, mostly pertaining to the collisions we are using in our space shooter game. Today we are going to look a little closer at the event hooks that Unity provides for us to respond to those collisions.

Unity gives us a number of event hooks that we can use to respond to different events. In the case of collisions we have 6 of them (each with a 2D variant as well)

  • OnCollisionEnter — Fires when a Collision Occurs
  • OnCollisionStay — Fires during a Collision
  • OnCollisionExit — Fires once a Collision Finishes
  • OnTriggerEnter — Fires when a Trigger Collision occurs
  • OnTriggerStay — Fires while a Trigger Collision continues
  • OnTriggerExit — Fires once a Trigger Collision Finishes

For today's look, we are only going to look at OnCollisionEnter and OnTriggerEnter and when to use each.

OnCollisionEnter

OnCollisionEnter is the event you want to use when you are dealing with the physics based interactions between two or more objects in Unity. When you are concerned with the actual physics of the collision, like the angle of incidence, the force of the collision, the conservation of momentum, or the properties of the point of the collision, this would be the event you would want to use. The Collision parameter that is passed in on this event contains information about the actual physics properties like those mentioned above. It is also important to understand that the physics engine in Unity will calculate the effects of these physics properties on the objects motion and apply them appropriately. This also requires at least one of the objects to have a Non-Kinematic RigidBody attached. If you are planning on checking collisions on objects that are Kinematic, meaning that we are controlling their motion with scripts, you would want to look at using our next event, OnTriggerEnter.

OnTriggerEnter

OnTriggerEnter is used when you want to react to the interaction of two objects but do not need to be concerned with the physics between them like you are with OnCollisionEnter. The Collider parameter that is supplied with this event contains information about the other object involved in the collision as opposed to the actual physics data of the collision itself. This function is used to handle what we called pass-through collisions in yesterdays article. When working with situations like player check-points or spots in the game that could trigger interactions when other objects pass through them, this would be the event we would want to look at. Like the kind of collisions that we use OnCollisionEnter for, trigger collisions require at least one of the involved objects to have a RigidBody attached. Unlike OnCollisionEnter, and the other hard surface collision events, the trigger collisions do not require those RigidBody objects to be non-kinematic. In our space shooter game we are using this type of collision for detecting when our lasers hit our enemies, and when our enemies hit our player because we are not using Non-kinematic Rigidbody objects, we don’t want our objects to bounce off each other, but we do want to handle the interaction between objects.

Below is a chart that Unity provides in their documentation for how RigidBody objects and colliders interact. I have found it helpful, so I will leave it here for you too.

Today we have covered the difference between OnCollisionEnter and OnTriggerEnter and when to use them. I short, use OnCollisionEnter when you want Unity’s physics engine to calculate the result of the collision and update the movement of objects accordingly, and use OnTriggerEnter when you want to know the collision occurred but don’t want the physics engine to take over the result of the collision. Tomorrow, we will look at how we can allow our scripts to communicate with each other. If you enjoyed this article, or want to come along with me as I progress on my journey, follow me at gamedevchris.medium.com.

Unity Game Developer, Software Engineer, Gamer, Musician, and Father. Christopher is a creative that enjoys a challenge and loves coding.