Why does the Cruisy McDrive temporarily enter the square?

When Cruisy McDrive collides with the square, it temporarily pushes inside of the square as long as you are holding your movement key. (You can observe this in the video.) When you let go of the movement key, Cruisy McDrive finally “pops” out of the body of the square. What is causing this, and how do you get Cruisy McDrive to stop exactly at the boundary and not temporarily go inside the other object (square in this case).

1 Like

Not sure about this because I didn’t go rewatch it, but my first guess is that Cruisy McDrive might have been on “discrete” collision detection, because this is how rigidbodies are made by default. Until they are changed to “continuous” collision detection, objects that test a collision too much may break the collision occasionally.

I did try changing the collision detection, but it had the same result. After searching more online, I think the answer is because we are using the translate method to set the position of the object directly, and then the physics engine basically says “nope, you can’t be there” and pushes the object out. If I want to have it collide and stop I think I would have to use the AddForce method on the Rigidbody2D which is basically like asking the physics engine permission to go to a point and it would say “You can’t go there, because you’ll stop here.”

Hi @Mourdekai,

Welcome to our community! :slight_smile:

You are right. The “problem” is caused by the physics simulation. The “physics” in Unity is just a simulation. It’s not the real world. This means that the colliders are not actual solid bodies, and we can move into them a bit depending on how much we are “pushing” the game object forward this frame.

After we moved our game object, the physics simulation calculates stuff in the scene. It notices that our Cruisy McDrive collider is inside the square collider. Since both colliders are “solid”, the Cruisy McDrive collider gets pushed out of the square collider.

This effect will always happen to a degree in a performant game because, as aforementioned, this is just a simulation meaning a huge calculation. For more precision, the computer would have to calculate more often, which would slow our game down. So, we have to decide what we prefer: a laggy game or a fast but not that realistic game?

Later in the course, we will learn about Rigidbody2D methods. If you want to challenge yourself, look the AddRelativeForce method up in the API. With this method, you could probably gain more precision within the physics simulation without affecting the performance of your game. However, since Delivery Driver is the first game in this course, Rick does not want to make things too complicated and focusses on the Transform object.

I hope this confirmed what you figured out yourself and helped you a bit. :slight_smile:


See also:

Thank you for confirming what I found and providing a more detailed explanation. I’ll look forward to learning those methods later in the course.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms