刻

几乎所有的游戏（包括Minecraft）都是由一个大循环程序运行的。相称地，循环程序的一个周期被称之为一“刻（tick）”。

游戏刻

Minecraft的循环程序是以每秒20周期的固定速度运行的，即TPS（每秒刻数）为20.0。因此每游戏刻为0.05秒。每过去一游戏刻，游戏的各方面都会更新：移动的实体位置会发生变化，生物会检查周围环境并更新自身的行为，玩家的生命值和饥饿值会根据玩家的处境发生变化，等等。游戏中的一天正好为24000游戏刻，相当于现实中的20分钟。游戏中的绝大多数功能都是以游戏刻而不是现实时间作为时间基准。

但是这个速率也不是完全固定的：如果发生卡顿以至于电脑的性能不足以跟上这个速度，一个游戏刻的运行时间就延长，每秒中游戏刻就会变少。和每秒刻数（TPS）相关的一个单位是每刻毫秒数（MSPT），即服务器实际上用来计算一刻所需的时间。只有在MSPT不超过50时，TPS才可以达到20。

以下的游戏机制比较消耗资源，容易导致服务端卡顿：

• 漏斗收集上方物品。可以通过在漏斗上添加容器方块防止这一行为发生。也可以直接换成吞吐量更大的水流运输。
• 红石电路更新。应该在时钟等线路上增加开关，以避免不必要的状态改变。另外红石造成的亮度更新也会造成卡顿，可以通过尽量减少空气空间避免。
• 生物AI。可以使用照明控制怪物的产生，并使用更高效的技术养殖家畜。
• 有些Mods可以优化或简化游戏逻辑。由于Mods是第三方内容，本Wiki不会特别声称其适用性。

但游戏的帧率（FPS）不影响TPS，电脑的图形性能不会影响到游戏机制。

游戏流程

在Java版中，在每个游戏刻以下行为依次处理：

• 执行带tick或load标签的函数
• 按主世界、下界、末地的顺序对每个维度进行如下进程：
  • 同步客户端时间
  • 世界边界更新
  • 天气逻辑
  • 玩家睡觉逻辑
  • 若维度为主世界：
    • 更新gametime以及daytime
    • 计划的函数执行
  • 计划刻被处理
    • 方块计划刻
    • 液体计划刻
  • 袭击逻辑
  • 对每个加载的区块：
    • 向客户端发送区块信息
    • 区块刻逻辑
  • 幻翼、灾厄村民、猫和僵尸围城尝试生成
  • 向玩家发送实体更新
  • 区块卸载
  • 流浪商人尝试生成
  • 方块事件被处理
  • 运算实体
    • 方块实体运算
• 玩家实体被处理
• 6000游戏刻一次的自动保存
• 来自客户端的包被处理

区块刻/区块遍历

作为游戏刻的一部分，每个游戏刻都会对特定的区块依次执行区块刻^[仅Java版]/区块遍历^{[仅基岩版]}。在Java版中，在每个游戏刻中，加载等级在31级或以下、区块中心与最近的玩家的水平距离小于128的区块会执行区块刻。

区块刻、区块遍历有许多影响：

• 生物自然生成。
• 雷暴天气下，闪电可能在区块内某处生成（¹⁄₁₀₀₀₀₀的几率）。
• 每一纵向上的最顶端方块有¹⁄₁₆的几率检查天气更新：
  • 在寒冷的生物群系中，如果条件合适，水会结成冰。
  • 如果在下雪，并且条件合适，一片雪可能被放置。
  • 如果在下雨，炼药锅可能被填充并最终填满。
• 区块内方块会接受到随机刻更新。
• 在基岩版中，计划刻会执行。

随机刻

随机刻作为区块刻/区块遍历的一部分执行。在基岩版中，在每个游戏刻中，所有加载的区块都会执行随机刻。

每个区块被划分为16个区段，每个区段包含16×16×16=4096个方块。

在Java版中，在每个游戏刻，执行区块刻的区块中，每个区段默认会被随机选出3个方块（可以重复）给予一个“随机刻”。在基岩版中，每个游戏刻每个区段默认会随机选出1个方块给予一个随机刻。大部分方块不会有影响，除了如下这些^{[需要在基岩版上验证]}：

• 小麦、胡萝卜、马铃薯和甜菜根可能生长或拔除。
• 蘑菇可能传播或拔除。
• 藤蔓可能传播。
• 冰和雪可能融化。
• 树叶可能枯萎。
• 耕地的湿润程度会更新。
• 仙人掌、甘蔗、海带、竹子、紫颂花、紫水晶簇和满足生长条件的滴水石锥可能生长。
• 草方块和菌丝可能传播或变成泥土。
• 树苗可能长成树。
• 熔岩可能使附近的方块着火。
• 发光的红石矿石或深层红石矿石会熄灭。
• 下界传送门方块可能生成一个僵尸猪灵。
• 海龟蛋破裂或孵化。
• 营火冒出烟雾粒子。
• 铜质方块可能会锈蚀。
• 上有水源或熔岩源的滴水石锥正下方的炼药锅可能会被逐渐填充。

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

在Java版中，随机刻的间隔的中位数为47.35秒，即有50%概率不超过47.35秒，也有50%概率超过47.35秒，也有可能需要极短或极长的时间：例如，有1.5%的概率间隔时间小于1秒，也有1%的概率超过5分钟。随机刻的间隔的平均值为68.27秒。对上述数据的计算原理，参见维基百科几何分布。

可以通过使用命令/gamerule randomTickSpeed <数量>来改变每个区段给予随机刻的方块数。

计划刻

一些方块可能会请求在将来的某一个游戏刻更新方块，这种更新方块的方式被称为计划刻。在一段时间后必定发生并且行为可以预测的变化，往往使用这种“计划刻”——比如，侦测器会计划2游戏刻之后来改变它的状态。

作为游戏刻的一部分，之前请求的计划刻如果已到达指定时间，如果区块的加载等级小于33（不包括33）^[仅Java版]或区块已加载^{[仅基岩版]}，计划刻就会被执行。否则推迟执行，直到区块被加载。

在Java版中，计划刻有两种：方块计划刻和液体计划刻。

执行时刻相同的方块计划刻的执行顺序首先取决于优先级，优先级相同则取决于创建顺序。优先级较小的执行时间较早。

• 若红石中继器指向红石二极管，且红石二极管的朝向非反向，中继器的计划刻将有-3的优先级。若中继器准备熄灭，则优先级为-2。否则中继器将有-1的优先级。
• 若红石比较器指向红石二极管，且红石二极管的朝向非反向，比较器将有-1的优先级。
• 其他的所有方块计划刻优先级都为0。

方块计划刻执行完后，将执行液体计划刻。液体计划刻没有优先级，仅根据创建顺序依次执行。

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

在基岩版中，计划刻作为区块遍历的一部分执行。

红石刻

参见：红石电路§红石刻

一个红石刻代表着两个游戏刻。在红石的语境中，“刻”常指红石刻。

活塞刻

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

参见

• 红石电路Wiki