几乎所有的游戏(包括Minecraft)都是由一个大的程序循环驱动的。正如时钟中的每个齿轮都与钟摆同步一样,驱动游戏仿真所涉及的每个任务都与游戏循环相同步。相称地,游戏循环的一个周期被称之为一刻(tick)。
游戏刻[]
Minecraft的绝大多数运算在一个大循环内执行,执行了一次这个循环就执行了一刻。为避免歧义,玩家一般将其称之为游戏刻(Game Tick,简称gt)。
一般情况下,游戏固定以每秒钟20刻的速率运行,因此一刻的时间为0.05秒(50毫秒,或一秒钟的二十分之一)每秒刻数(ticks per second,缩写为TPS)可用于衡量游戏的运行速度,也可通过/tick rate
修改其默认值。然而,如果计算机无法跟上这个速度,那么TPS会减少。由于绝大多数操作都是基于刻数而非现实中的时间来计时,许多操作在速度较慢的计算机上需要更长的时间。
有一个与每秒刻数(TPS)相关的统计量,称作每刻毫秒数(milliseconds per tick,缩写为MSPT),即服务器实际用于完成一刻内计算的耗时。在未使用/tick rate
修改时,游戏的正常运行速度为20TPS。只有当MSPT不高于50时,TPS才能维持在20。通常情况下,以下因素是服务器端卡顿的主要诱因:
- 漏斗会频繁尝试检查其上方是否有物品。用任一含有物品栏的容器方块或堆肥桶即可停止此类检查。也可以利用水更快地运输散装物品。
- 红石机构。红石元件,尤其是红石粉会导致大量的方块更新、亮度更新和卡顿。关闭一些暂不使用的红石装置和时钟、尽量减少空气空间有助于缓解卡顿情况。
- 生物AI。可以用照明控制怪物的生成,并使用更高效的技术养殖家畜。
在Java版中,MSPT值在调试屏幕中显示为“ms ticks”。打开帧生成时间图表(Alt + F3)时可查看TPS值。这两种显示都只能在多人游戏的主机或单人游戏上可见,因为数据来自Minecraft游戏里的内置服务端。
游戏流程[]
在Java版中,游戏循环的每个周期中,以下行为会依次处理:
区块刻[]
作为游戏刻的一部分,每个游戏刻都会对特定的区块处理区块刻。
在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。
红石刻[]
一个红石刻(Redstone Tick,简称rt)代表了两个游戏刻,长度一般为1⁄10秒。最早玩家将其定义为1档红石中继器的延迟。
在基岩版中,红石刻作为游戏机制是并发的,红石信号的传递受到红石刻的影响。
在Java版中,红石刻不是“真实”存在的事物,但是这个由社区创造的术语使得红石工作更加简单,因为绝大部分红石元件的延迟都是2gt的整数倍。
活塞刻[]
即时更新理论认为活塞启动的延迟为0,实体阶段至方块事件阶段属于一游戏刻,即以方块事件阶段的结束划分游戏刻,这种“游戏刻”称为活塞刻。音符盒发声的启动延迟和活塞相同,也是0活塞刻。计划刻元件按活塞刻计的延迟则不固定。
历史[]
Java版 | |||||
---|---|---|---|---|---|
1.20.2 | 23w31a | 现在区块刻处理时露天方块检查天气更新的频率受游戏规则randomTickSpeed 影响。 |
参见[]
版本 | |||||||
---|---|---|---|---|---|---|---|
开发周期 |
| ||||||
技术 |
| ||||||
多人游戏 | |||||||
游戏订制 |
版本 |
| ||||||
---|---|---|---|---|---|---|---|
开发 |
| ||||||
技术性 | |||||||
多人游戏 | |||||||
特色功能 |
语言