@djlink Yeah, this is usually my stance also! I prefer clean and readable to more efficient but ugly/dense.

Although, conversely, these less common approaches won't become more common if devs don't star using them.

There's also a third point: Coroutines are a Unity-only feature. Async/Await is a pretty common pattern outside Unity, so devs coming from other backgrounds (which was my case) might have an easier time dealing with that approach!

@glitchypixel @djlink Could you elaborate on what the better alternatives are to using Async/Coroutines? Like doing everything on update? Including waiting for some condition/time?

I find that for me, when using Async methods, my code becomes cleaner, as opposed to doing things on update/Coroutines. The methods start becoming very single purpose and organized, although I then have this whole complexity of lifecycle management to deal with, which does often hurt readability.

@glitchypixel @djlink Hey! Thanks for your input! I think those are all important points. In regards to the comment on using jobs, that's been my approach. When I have one task I need to move out of the main thread, I just use an Async method.

When working on Dawn of Defense, we had to do map generation, which was blocking the main thread for roughly 6 to 7 seconds (on my machine). After switching to an async method, we could then have a loading screen while the map is generating.

@djlink Have you used the "new" async/await support in Unity? I've been trying it out and while it does initially feel more complex (but more capable), it does feel like it would be cleaner to use, after getting used to it.

My worry is that all code written with async/await would then become virtually unmaintainable to a lot of developers whom aren't used to that workflow.

You can learn more about the game and wishlist it here:

https://store.steampowered.com/app/2781660