Minecraft Wiki

除另有声明,转载时均必须注明出处若簡繁轉換出錯,請以遊戲內為準请勇于扩充与修正内容有兴趣逛逛我们的微博沟通交流,欢迎到社区专页需要协助,请在告示板留言

了解更多

Minecraft Wiki
注册
Advertisement

几乎所有的游戏(包括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版中,游戏循环的每个周期中,以下行为会依次处理:

  • 执行带有tickload标签的函数
  • 主世界下界末地的顺序依次对每个维度进行以下流程:
    • 发送时间至客户端
    • 更新世界边界
    • 天气逻辑
    • 玩家睡眠逻辑
    • 若维度为主世界:
      • 增加游戏内时间和天数
      • 执行计划内函数
    • 对每个已加载区块:
      • 发送区块信息至客户端
      • 区块刻逻辑
    • 尝试生成幻翼灾厄村民僵尸围城
    • 发送实体变更至客户端
    • 尝试卸载区块
    • 处理计划刻
      • 方块的计划刻
      • 液体的计划刻
    • 袭击逻辑
    • 尝试生成流浪商人
    • 处理方块事件
    • 处理实体
    • 处理方块实体
  • 处理玩家实体
  • 如果已过去6000刻,尝试自动保存
  • 处理来自客户端的数据包

区块刻[]

RandomTickRange

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

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

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

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

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

  • 生物自然生成
  • 雷暴天气下,闪电可能在区块内某处生成(1100000的概率)。
  • 每一纵向上的最顶端方块[需要更多信息]116的概率检查天气更新:
  • 区块内一定数量的方块受到随机刻处理,如下所述。

随机刻[]

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)代表了两个游戏刻,长度一般为110秒。最早玩家将其定义为1档红石中继器的延迟。

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

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

活塞刻[]

Information icon
此特性为Java版独有。

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

历史[]

Java版
1.20.223w31a现在区块刻处理时露天方块检查天气更新的频率受游戏规则randomTickSpeed影响。

参见[]

语言

Advertisement