For instance, I have a lot of things that need to happen only a certain amount of time after an object is instantiated, and if and when it does happen, I would imagine that checking the time.time every frame is bad.
So that will doWhatever after 3 seconds, but even after it does whatever, it’s still checking the damn time every frame. If I have dozens of GO’s that are doing this every frame, I imagine that’s bad. So, what is the normal way to do timers? Is it to spawn a GO that has this timer in it, then sends the signal when the condition is met, and then kills itself to conserve resources? So, custom timer objects?
as long as the GO is ‘alive’ than Update will be called so you can’t stop it from running without disabling or destroying the GO. With thousands of GO’s, Update will be called thousands of times per game update there is no getting away from that.
It’s up to you. Basically the CreateTimer function looks like this:
public Timer CreateTimer() {
Timer result;
if (_timerPool.Count > 0) {
result = _timerPool[0];
_timerPool.Remove(0);
} else {
GameObject go = GameObject.FindWithTag("timerObject");
result = go.AddComponent<Timer>();
}
return result;
}
Also, to make the story complete. A timer can be held on to by an object (if it wants), or object can call GameManager.Instance.ReleaseTimer(myTimer);
The timer will then be put back in the timerPool for later use
So I can create a coroutine in a script on each GO that needs it using the coroutine example above with no retained computation overhead when the coroutine is yielded?