Week 3 Wednesday
Collisions
Demo: Pachinko
Lab: Interaction breakdown
We've already seen collisions, where Unity won't allow two objects to be in the same place at the same time.
We want to know how to listen for them in scripts. But there's a bit to understand first about the types of collisions that Unity detects.
There are three types of collisions in Unity:
As long as a Rigidbody is involved, Unity will pick up the collision and tell both scripts about it via the OnCollision methods.
As long as a Rigidbody is involved, Unity will pick up the collision and tell both scripts about it via the OnCollision methods.
If either side of the collision has "isTrigger" checked on its collider, then it's a trigger collision and Unity will tell us about it via the OnTrigger methods.
Unity will tell us about a trigger collision via the OnTrigger methods.
But it won't resolve the collision – things can overlap with trigger colliders.
Some collisions just shouldn't happen, and Unity won't even tell us about them: when two colliders overlap but there's no Rigidbody involved.
This collision "shouldn't" happen because you're not supposed to move a static collider.
Unity detects these collisions, but it ignores them altogether. It will not pop the objects apart, and no scripts will hear about it.
Imagine and describe the behavior you want.
Add components to the objects and change their settings as needed.
Make a new script and attach it to one of the colliding objects. Or open a script that is attached to one of the objects.
There are no hard and fast rules about which objects should handle the collision. But you probably don't want a Player class handling sixteen kinds of collisions.
Add a collision method to your attached script. You will almost certainly use one of these:
OnCollisionEnter OnTriggerEnter
OnCollisionEnter2D OnTriggerEnter2D
Type a Debug.Log statement into your collision method. I suggest this:
Debug.Log("Collision between "
+ gameObject.name
+ " and "
+ collision.gameObject.name);
(Yes, you can add line breaks in most lines of C# code.)
Run your game.
Note that you can drag one object on top of another in the Scene view to make them collide.
Check that you see your debug message when you expect to.
Now that you know the collisions are happening, you are on firm ground.
You can go ahead and write the code that actually handles the collision (playing a sound, etc.)
But I suggest commenting out the Debug statement rather than deleting it.
There are a whole lot of steps in setting up collisions, and therefore a lot of places you could mess up in the process.
If you observe when you mess up, you'll start to get a sense of where you're most likely to have a problem.
But a list of common problems is below.
Issues with component setup:
Is the collision actually happening?
Issues with collision functions:
There are other properties, like isKinematic, that influence whether a collision happens and which methods are called.
Consult the following elaborate diagram in the Unity documentation for details:
Here are the instructions for this lab.
Here is my first attempt at the exercise.
It is certainly missing some things.