Skip to content

A program's rhythm

Sixty iterations a second are rarely needed. How to choose a rhythm and how to set it

A program without wait runs at full speed always. For a blinking lamp that changes nothing; for a program polling a dozen blocks it changes everything: it will do that hundreds of times a second when twice would do.

tick 0
Sensor0
=
in
Operation1
=
Wait2
@counter0number
coppernullnull
checksnullnull

Press “run”. checks grows by two a second, and that is enough: the copper in a container does not change sixty times a second, and if it did you would not see it.

Task A sensible rhythm
watching the stock in a store 2–5 times a second
switching blocks on and off by a condition 5–10 times a second
leading a unit, drawing on a display every tick, no wait
counting something once a wave once every few seconds

The rule is simple: the rhythm is set by how fast the thing you are watching changes. A store changes slowly, a unit every tick.

A processor has exactly @ipt instructions per tick, and it spends that budget on itself — other processors do not suffer from your hurry. Others pay:

  • The lines below. While the program spins its first loop, it never reaches the rest. A tight loop with no wait is not “fast” but “this and nothing else”.
  • Readability. A program that does everything every tick has no shape: you cannot say what happens when.
  • The display. Drawing more often than the frame refreshes is pointless: the buffer is flushed once anyway.

Sometimes waiting is not allowed — a program has to watch a store and lead a unit, say. Then the slow part is measured by time: a processor has @time, the game’s time in milliseconds, and the program keeps a deadline in a variable and does not touch the slow part before it.

tick 0
Operation0
=
Jump -> 01
if
Operation2
=
Sensor3
=
in
Operation4
=
@counter0number
loopsnullnull
deadlinenullnull
coppernullnull
checksnullnull

Press “run” and watch two variables: loops runs in the tens while checks goes up by one a second. The program reads as “if the time has not reached the deadline, start the iteration over”; when it has, a new deadline is set a second ahead and the slow part is done.

In the first second the iteration runs getting on for sixty times, and sensor fires once.

wait measures time in game ticks, and a tick is 1/60 of a second at normal speed. When the game lags or is sped up, the ticks run differently, and wait 1 will not be exactly a second by the clock. For logic that usually does not matter: a program lives in the game’s time, not in yours.

There is another reason not to rely on wait as a precise timer: the waiting starts from the moment the line runs, not from the end of the previous iteration, so the program’s running time is added to the pause.

Unofficial fan project, not affiliated with Anuke. Mindustry sprites, fonts and translations © Anuke, used under GPL-3.0; Fira Code under OFL-1.1. Site code is GPL-3.0.