From your screenshot I see that you are using kinematic Rigidbodies. Kinematic Rigidbodies don't behave like Rigidbodies in most ways.

• They ignore forces, as I assume you've already noticed since you implemented your own gravity manually.
• They aren't moved or otherwise physically affected by collisions with non-kinematic Rigidbodies
• As DMGregory noted, they won't fire OnCollisionEnter if they intersect with another kinematic Rigidbody. As far as the physics engine is concerned, two kinematic Rigidbodies cannot collide with one another.

There are only a few highly specific scenarios where it really makes sense to use kinematic Rigidbodies.

If you want your objects to fall and collide using the normal physics engine, uncheck "Is Kinematic".

If you want to keep using your own gravity code, you'll need to also uncheck "Use gravity". If you go that route, you should move the objects in FixedUpdate() instead of Update() since the former is in step with the physics engine and is a safer place to move physics objects. As DMGregory noted, Rigidbody.MovePosition() is a safer function to use for manually moving physics objects. Also, if you keep using your own gravity code, you should disable the MoveBlock component once it lands; otherwise it's going to waste CPU cycles trying to move downward for every fixed update for the rest of the game.

If you use standard (non-kinematic) Rigidbodies and want to ensure that the physics engine is only allowed to move the objects directly downward (preventing any lateral motion), check the boxes under "Freeze Position" for "X" and "Z". This will ensure that the physics engine only moves the Rigidbody along the vertical (y) axis. I believe you're still free to manually move it along the X and Z axes from your code.

Alternatively you could throw out the physics engine, remove the Rigidbody components, and write your own code for determining when the blocks have landed; however, I'd expect that to be more involved than using the physics engine correctly.

From your screenshot I see that you are using kinematic Rigidbodies. Kinematic Rigidbodies don't behave like Rigidbodies in most ways.

• They ignore forces, as I assume you've already noticed since you implemented your own gravity manually.
• They aren't moved or otherwise physically affected by collisions with non-kinematic Rigidbodies
• As DMGregory noted, they won't fire OnCollisionEnter if they intersect with another kinematic Rigidbody. As far as the physics engine is concerned, two kinematic Rigidbodies cannot collide with one another. EDIT: In newer versions of Unity, you can enable collisions between Kinematic Rigidbodies in the project physics settings.

There are only a few highly specific scenarios where it really makes sense to use kinematic Rigidbodies.

If you want your objects to fall and collide using the normal physics engine, uncheck "Is Kinematic".

If you want to keep using your own gravity code, you'll need to also uncheck "Use gravity". If you go that route, you should move the objects in FixedUpdate() instead of Update() since the former is in step with the physics engine and is a safer place to move physics objects. As DMGregory noted, Rigidbody.MovePosition() is a safer function to use for manually moving physics objects. Also, if you keep using your own gravity code, you should disable the MoveBlock component once it lands; otherwise it's going to waste CPU cycles trying to move downward for every fixed update for the rest of the game.

If you use standard (non-kinematic) Rigidbodies and want to ensure that the physics engine is only allowed to move the objects directly downward (preventing any lateral motion), check the boxes under "Freeze Position" for "X" and "Z". This will ensure that the physics engine only moves the Rigidbody along the vertical (y) axis. I believe you're still free to manually move it along the X and Z axes from your code.

Alternatively you could throw out the physics engine, remove the Rigidbody components, and write your own code for determining when the blocks have landed; however, I'd expect that to be more involved than using the physics engine correctly.