Character moves without pressing any buttons.

[Kurt-Dekker]

There’s several things wrong above. You may wish to start over with an actual tutorial and follow it correctly.

Here’s two issues that will require some rework:

• movespeed is a float and yet I see you comparing it for equality. This is a no-no. See below.

• you are using GetKeyDown() for what appears to be continuous motion. You should use GetKey() instead

• you are manipulating the transform position and rotation and yet I see a Rigidbody and a collision callback. You WILL have physics problems with this approach.

With Physics (or Physics2D), never manipulate the Transform directly. If you manipulate the Transform directly, you are bypassing the physics system and you can reasonably expect glitching and missed collisions and other physics mayhem.

Always use the .MovePosition() and .MoveRotation() methods on the Rigidbody (or Rigidbody2D) instance in order to move or rotate things. Doing this keeps the physics system informed about what is going on.

Collisions in high speed without unity physic / rigidbody

You say you're not using 2D physics but you're using queries therefore obviously colliders. This IS using 2D physics therefore you need to use it correctly so here are some basic rules: Don't ever modify the Transform if using 2D physics components If you want a 2D Collider to move then add a Rigidbody2D and use its API to move it; many ways to do this. Rigidbody2D don't make it "unresponsive". If you want explicit control then set the body-type to Kinematic; it's what it's for. When you qu…

OnCollisionEnter2D not being called

That’s not related to body-type. You should never drive via the Transform. The main thing to understand here is that the Rigidbody2D role is to write to the Transform after the physics simulation, not the other way around. It acts as a proxy to the Transform because you want physics behaviour. Does “it work” if you write to the Transform and force the Rigidbody2D to read from the Transform? Yes! It works like that because otherwise it’d be reported as a bug and so we’re forced to “support” it.…

Floating (float) point imprecision:

Never test floating point (float) quantities for equality / inequality. Here’s why:

https://starmanta.gitbooks.io/unitytipsredux/content/floating-point.html

Debug.Log(2000.0f * 000.1f); is 200

Now that you have had your coffee, don't forget about floating point imprecision: // @kurtdekker: don't forget about floating point imprecision using UnityEngine; public class FloatingPointImprecision : MonoBehaviour { void Start () { float a = 2000.0f; float b = 0.1f; float product = (a * b); float answer = 200; Debug.Log( "a = " + a); Debug.Log( "b = " + b); Debug.Log( "product of a*b = " + product); Debug.Log( "answer …

Why Doesn't This Code Work?

This will explain it all. In an IEEE single-floating point number you can represent certain numbers perfectly and unambiguously. For instance, 0.5f is precisely represented as 0x3f000000 However, 0.1f CANNOT be precisely represented. One possible approximate representation is 0x3DCCCCCD The analogy is that you cannot show 1/3rd precisely as a decimal. 0.33 is correct to 2 decimal places 0.3333 is correct to 4 places etc. But you can never exactly represent 1/3rd as a decimal numeral. Yo…

“Think of [floating point] as JPEG of numbers.” - orionsyndrome on the Unity3D Forums