Does unitask/async make sense over simple deltatime timer for cooldowns etc

[illispi]

Trying to wrap my head around when should i use async/await in game dev context.

[spiney199]

I wouldn’t use it for cooldowns. Async is generally for processes that can take some indeterminate amount of time, where you don’t want it to lock up the program. Namely file loading, reading, writing, etc. Which is why you see it for systems like addressables, and for scene loading.

Using async for cooldowns would just be massively over-complicating something otherwise simple.

[benstokess]

Thanks @spiney199 for sharing the beneficial information. I also face this problem.

[Kurt-Dekker]

@spiney199

Using async for cooldowns would just be massively over-complicating something otherwise simple.

Agreed. Unfortunately this is common, especially with async-happy or coroutine-happy tutorial makers.

Cooldown timers, gun bullet intervals, shot spacing, rate of fire:

Fire Rate Issues

This is commonly called a “cooldown timer.” You can google for examples and tutorials, but the simplest way is this: have a private float gunHeat; variable In Update(), if that variable is greater than zero, subtract Time.deltaTime from it (this cools down the gunHeat) if (gunHeat > 0) { gunHeat -= Time.deltaTime; } When you go to fire: — A. only fire if that gunHeat variable is zero or less. — B. set that variable to the time (in seconds) you want to have between shots. if (User…

NEVER NEVER NEVER use coroutines for a cooldown. It is never appropriate.

[tleylan]

I’m a bit puzzled… cooldowns are a common behavior. Why would folks write unique code for every situation? I’m looking at it like an IRL alarm clock.

Why not a CoolDown service that other code can register with. An event is fired when the cooldown time they requested is reached.

Yes the code that processes the time is the question here but again I’m surprised (a bit) that there aren’t a half-dozen “cool down” libraries.

[Kurt-Dekker]

Writing libraries is about adding value: you write a library to capture a significant piece of work that has well defined inputs and well defined outputs.

Cooldown timers are trivial. Librarifying them doesn’t help.

Plus there’s ten billion different options / variations, etc. Here’s a few:

• can it be reset mid-way, before it expires? Now your library needs an extra call!
• should an attempt to reset mid-way before it expires be ignored? Now your library needs two calls or a call with a parameter
• should an attempt to reset it midway be cause for alarm, eg, log an error and go investigate why something higher up in the application chain could even possibly have attempted this?
• does it stop counting down under certain conditions, eg, you hit reload on your pistol, then stuff it into your pocket… should the timer continue while in your pocket? Hm, could be different depending on the game.
• does the cooldown need to be updated to a UI widget to show how close to cooldown it is? Now you need a call to set a callback, register an event, or inspect the value
• does something cause the cooldown interval to change (Eg, a buff or debuff)? Now you need a buff interface!

Again… write libraries where you add value. Otherwise you end up with a mass of librarified generic code and you don’t DARE change any of it because by now you have forgotten “Gee does this library even allow resetting before it is expired?” etc

[tleylan]

Perhaps my use of the term library was off the mark and I should have written template or guide. I was shocked to learn that there are 10 billion different options.

I any case I will continue to write whatever it is that I do with my custom logger, API calls to APIs I’ve written, etc. If it needs to reset midway I’ll spend the $50,000 and spend the 3 years needed to adjust it.