6
\$\begingroup\$

I am making a custom tick system to suit my needs (calling normal ticks every 0.2 seconds, medium ticks every 5 seconds etc...)

I followed the tutorial in this video: CodeMonkey tick system tutorial

In his tutorial, he implements the tick counting as shown:

    private const float tickTimerMax = 0.2f;

    private void Update()
    {
        tickTimer += Time.deltaTime;

        if (tickTimer >= tickTimerMax)
        {
            tickTimer -= tickTimerMax;
            Tick++;

            // Happens every 0.2 seconds.
            OnTick?.Invoke(this, new OnTickEventArgs {Tick = Tick});
        }
    }

However, in other sources I have seen that instead of subtracting tickTimerMax from tickTimer, we just straight up set the tickTimer to 0, as shown:

if (tickTimer >= tickTimerMax)
    {
        tickTimer = 0;
        Tick++;
    }

It's hard to say if there's a big difference between these two methods, because at first glance they seem to do the same thing, but clearly they have their differences. So I'm wondering, which one I should use?

\$\endgroup\$

1 Answer 1

Reset to default
13
\$\begingroup\$

The second solution will perform slightly less ticks than expected over time, because when tickTimer is slightly larger than tickTimerMax (which is almost always going to happen due to floating point inaccuracies), then the remaining time gets discarded. Those differences accumulate. So when your game runs for a minute and you check how many 0.2 second ticks were processed, you might notice that they were in fact less than 300.

The first solution is more accurate, because any time left will be credited to the next interval. But of course you don't always need accuracy. The inaccuracies get larger with worse framerate. So when the system you are triggering here is computationally expensive but not actually that important, then one could argue that dropping it more frequently when the framerate is already bad might be a feature and not a bug.

By the way, there is another option which I often use. Replace the if with a while:

private void Update()
{
    tickTimer += Time.deltaTime;
    while (tickTimer >= tickTimerMax)
    {
        tickTimer -= tickTimerMax;
        Tick++;
        OnTick?.Invoke(this, new OnTickEventArgs {Tick = Tick});
    }
}

This covers the edge-case that a lag-spike resulted in a frame taking longer to render than multiple intervals. In that case the while-loop results in multiple ticks being performed in a loop in order to make the simulation catch up with the lost time. This solution is preferable when you really want to avoid the simulation from lagging behind.

A word of warning, though: When tickTimerMax is 0 or negative, then the script will be caught in an infinite loop. That usually means you need to kill Unity and restart it, which might result in losing unsaved work.

\$\endgroup\$
6
  • \$\begingroup\$ Very detailed answer, got more information than I came for. Absolutely amazing. \$\endgroup\$ Commented Mar 2, 2021 at 10:41
  • \$\begingroup\$ If your OnTick takes more than 1 tick to run, the while solution also results in a death spiral. \$\endgroup\$ Commented Mar 2, 2021 at 23:38
  • \$\begingroup\$ I thought that by design it's supposed to avoid the "death spiral" \$\endgroup\$ Commented Mar 3, 2021 at 6:54
  • \$\begingroup\$ This code technically won't deadlock, because the timer does not change while ticks are being processed. But if you indeed demand more tick updates than the users CPU can handle, it will become slower and slower with every update, because the backlog of ticks increases. But that problem is on a conceptual level. When your ticks require more CPU time than you have available, then what you actually need is to reconsider what you are calculating in those ticks and if you really need to calculate that stuff that often. Or at least think about what behavior you expect in that situation. \$\endgroup\$ Commented Mar 3, 2021 at 9:35
  • \$\begingroup\$ Great. And loop is how I'm doing it. Theres also the downside however, if Unity is paused for example, that it will then try to catch up on thousands of ticks the moment you press resume. It's kind of what you want for spikes but not pauses... \$\endgroup\$ Commented Sep 21, 2023 at 9:36

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.