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
- wait until it is warm enough (loop and test water)
- step into the shower
- loop: as long as there are dirty parts:
—> keep washing and rinsing - loop: as long as your hair is dirty:
—> keep lathering and rinsing - final rinse off
- shut off shower
- step out and dry off
- get dressed again
- DONE!
But what you had above was a heartbeat and blood spurt that mostly is NOT happening… when it starts to happen it should only continue until you are healed up, or you are dead.
That is much more amenable to a finite state machine with these states:
- healthy (above 15hp)
- injured (10 to 15 hp)
- more injured (5 to 10 hp)
- critical (1 to 5 hp)
- dead (0hp)
At any instant you can leap completely from one state to another. You could be healthy at 100hp and fall into lava and go straight to 0hp, or be slightly injured and fall to 0hp in lava.
With a coroutine you’d have to write code at ALL the stages to fall through all the intervening things, skip heartbeat 1, blood spurt1, heartbeat 2, all that code can have bugs in it.
With a state machine you just go from healthy to dead when you fall in the lava.
And lets say your healer casts “resurrect 10hp” and hauls you out before the game declares you game over? Bam, right up to “more injured” and heartbeat going, no code in between, don’t have to “go up through” critical.
The construct I wrote above is basically a state machine with an observer pattern: it constantly observes your health to decide what state to be in. Then there’s just a cooldown on the heart beat.