Coroutines memory allocation on every yield (bug?)

[Kurt-Dekker]

Coroutines are WAAAAAAAY massive overkill here.

If you just need to shake the camera briefly, just make a float timer and count it down.

As long as the timer is nonzero, shake.

This lets you even use the timer as a relative magnitude: you could shake harder at the beginning and have it taper off, or use an AnimationCurve and have it onset / disappear with whatever rate you want.

ALSO: if the Rigidbody above is on this thing, you’re violating physics by manipulating the transform directly. This might end up in you shaking yourself right into the floor or the wall.

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…

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.…

Coroutines are NOT always an appropriate solution: know when to use them!

Things to check before starting a coroutine?

The main thing to check before calling / making a coroutine is to ask yourself, “Does this even need to be a coroutine?” Generally, if your design requires you to call StopCoroutine(), then don’t make it a coroutine. If you just need something to happen a bit later, this is a more-robust approach: https://gist.github.com/kurtdekker/0da9a9721c15bd3af1d2ced0a367e24e If you’re flipping from one value to another, such as fading in, fading out, changing speeds slowly, etc., coroutines are an AW…

Heartbeat courutine fx

There’s never a need. As @PraetorBlue pointed out in a recent post of his, nobody NEEDS coroutines. They do solve a certain class of problem nicely however, primarily problems of sequencing a set of data or events to happen. Coroutines CAN be interrupted and restarted but doing so exponentially increases your chance of a bug, negating a lot of their inherent benefits. A lot of human behaviors are good coroutines: “Go take a shower.” So that breaks down to: get undressed start the shower …

I would include my link to Bunny’s coro course but Bunny already did that above!