几乎所有的游戏（包括Minecraft）都是由一个大的程序循环驱动的。正如时钟中的每个齿轮都与钟摆同步一样，驱动游戏仿真所涉及的每个任务都与游戏循环相同步。相称地，游戏循环的一个周期被称之为一刻（tick）。

游戏的一刻是指Minecraft的游戏循环运行一次所占用的时间。正常情况下，游戏固定以每秒钟20刻的速率运行，因此一刻的时间为0.05秒（50毫秒，或一秒钟的二十分之一），使得游戏内的一天刚好持续24000刻，也就是20分钟。然而，如果计算机无法跟上这个速度，那么每秒刻数（ticks per second，缩写为TPS）会减少。由于绝大多数操作都是基于刻数而非现实中的时间来计时，许多操作在速度较慢的计算机上需要更长的时间。

有一个与每秒刻数（TPS）相关的统计量，称作每刻毫秒数（milliseconds per tick，缩写为MSPT），即服务器实际用于完成一刻内计算的耗时。只有当MSPT不高于50时，TPS才能维持在20。通常情况下，以下因素是服务器端卡顿的主要诱因：

在Java版中，MSPT值在调试屏幕中显示为“ms ticks”。打开帧生成时间图表（Alt + F3）时可查看TPS值。这两种显示都只能在多人游戏的主机或单人游戏上可见，因为数据来自Minecraft游戏里的内置服务端。

在Java版中，游戏循环的每个周期中，以下行为会依次处理：

随机刻的范围，以草在泥土上的生长传播所示。注意，草是服从区块边界分布的。中间的红色和蓝色箭头分别标记+X和+Z方向。玩家位于区块的(7,7)位置，略微面朝区块的西北角，这意味着-X和-Z方向边缘上两个区块的中心纳入了128方块的半径内，从而得到区块刻处理。正北方和正西方边缘的两个一区块面积的草突出证实了这一点。（以上为北）

作为游戏刻的一部分，每个游戏刻都会对特定的区块处理区块刻。

在Java版中，加载类型为强加载（请参见区块#加载等级）且其中心与玩家（非旁观模式）之间的水平距离小于128个方块的区块在每次游戏刻内得到处理。这里应该注意以下几点：首先，区块应当加载成处理实体的区块；其次，如果区块接收到区块刻，即使区块中的某些方块超出128个方块半径，它们也可以像正常情况一样接收随机刻；最后，因为128方块是水平距离，所以玩家沿Y轴的位置无关紧要。

在基岩版中，每个游戏刻内，所有加载的区块都得到区块刻处理。

以下行为在某个区块得到区块刻处理时会发生：

在Java版中，在每个游戏刻，执行区块刻的区块中，每个区段默认会被随机选出randomTickSpeed个方块给予随机刻，数量可由/gamerule randomTickSpeed自定义（默认为 3）。在基岩版中，每个游戏刻每个区块默认会随机选出区段数×2.5×randomTickSpeed个方块给予随机刻，同样可由/gamerule randomTickSpeed自定义（默认为 1，但等效于在Java版中的2.5倍数值）。同一个方块可以被选中多次。

大部分方块不会受到随机刻影响，但是以下方块会利用它做一些事：

因为随机刻是被随机赋予的，无法预测某个方块何时会接收到随机刻。

在Java版中，因为随机刻是随机产生的，所以没有办法预测一个方块下一次得到随机刻的时机。两次随机刻时间间隔的中位数为47.30秒（946.03游戏刻）。也就是说时间间隔有50%的几率等于或短于47.30秒，有50%的几率等于或长于47.30秒。不过，有时候这个时间间隔会长得多或短得多：比如，时间间隔有1.38%的几率会比一秒还短，且有1.23%的几率比五分钟还长。方块每次更新时间的平均数为68.27秒（1365.33游戏刻）。若要了解这些数字背后的数学原理，请参阅几何分布。

一些方块可能会请求在将来的某一个游戏刻更新方块，这种更新方块的方式被称为计划刻。在一段时间后必定发生并且行为可以预测的变化，往往使用这种“计划刻”——比如，红石中继器会在Java版中计划一刻之后改变其状态，水在需要流动时会计划一个计划刻。

作为游戏刻的一部分，已经请求计划刻的方块所在之处会得到给定量的刻。

在Java版中，计划刻有两种：方块计划刻和液体计划刻。方块计划刻的处理顺序首先取决于优先级，其次取决于计划顺序。优先级越小，执行时间越早。若红石中继器指向红石二极管的背面或侧面，则该中继器将有-3的优先级。若中继器准备熄灭，则优先级为-2，否则中继器将有-1的优先级。若红石比较器指向红石二极管的背面或侧面，比较器将有-1的优先级。其他所有方块计划刻的优先级都为0。方块计划刻执行完后，将处理液体计划刻。液体计划刻没有优先级，仅根据计划顺序依次执行。

在Java版中，每个游戏刻内所能处理的最大计划刻数是65536。在基岩版中，每个游戏刻内，一个区块所能处理的最大计划刻数为100。

一个红石刻代表了两个游戏刻。红石刻在一个红石电路信号中产生1⁄10秒的延迟；也就是说，从地点A到地点B的信号传输耗时要增加0.1秒。刻只会引起信号时间的增加，因此一个信号的传输时间永远不会因为刻而减少。红石中继器会带来1-4个红石刻的延迟。默认的延迟时间为1红石刻，可以通过对红石中继器点击使用物品键来调整，可由方块上的滑块位置看见。

在基岩版中，红石刻作为游戏机制是并发的，红石信号的传递受到红石刻的影响。

在Java版中，红石刻不是“真实”存在的事物，但是这个由社区创造的术语使得红石工作更加简单，因为绝大部分红石元件都有整2倍于游戏刻的延迟。

即时更新理论认为活塞启动的延时为0，实体阶段至方块事件阶段属于一游戏刻，即以方块事件阶段的结束划分游戏刻，这种游戏刻称为活塞刻。音符盒和钟发声的启动延迟和活塞相同，也是0活塞刻。计划刻元件按活塞刻计的延时则不固定。