Minecraft Wiki

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

了解更多

Minecraft Wiki
Advertisement

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

游戏刻

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

有一个与每秒刻数(TPS)相关的统计量,称作每刻毫秒数(milliseconds per tick,缩写为MSPT),即服务器实际用于完成一刻内计算的耗时。只有当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的概率检查天气更新:
  • 区块内一定数量的方块受到随机刻处理,如下所述。

随机刻

区块中每16方块高度为一节子区块,也就是说子区块是一个16×16×16=4096方块大小的一节立方体。各节子区块从最低的Y水平面开始垂直分布。每个区块刻随机抽选区块内每一节子区块的一些方块。被选中的这些方块会被给予一个“随机刻”。

Java版中,每一节被抽选的方块个数可由/gamerule randomTickSpeed指定(默认为3),而且一个区块刻内可以选中同一个方块多次。在基岩版中,同样可由randomTickSpeed指定(默认为1),但是该选项只会确定一个相对的速度,并非实际的数值。

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

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

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。

红石刻

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

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

活塞刻

Information icon
此特性为Java版独有。

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

参见

Advertisement