Minecraft Wiki

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

了解更多

Minecraft Wiki
→‎游戏流程:​ tweak translation
第30行: 第30行:
 
*** 方块计划刻
 
*** 方块计划刻
 
*** 液体计划刻
 
*** 液体计划刻
** 袭击逻辑
+
** [[袭击]]逻辑
 
** 对每个加载的区块:
 
** 对每个加载的区块:
 
*** 向客户端发送区块信息
 
*** 向客户端发送区块信息
 
*** 区块刻逻辑
 
*** 区块刻逻辑
** 流浪商人尝试生成
+
** [[流浪商人]]尝试生成
 
** 方块事件被处理
 
** 方块事件被处理
 
** 运算实体
 
** 运算实体

2021年6月22日 (二) 12:35的版本

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

游戏刻

Minecraft的循环程序是以每秒20周期的固定速度运行的,即TPS: 20.0。因此每刻发生在每0.05秒。在游戏中的一天将正好为24000刻,或20分钟。但是这个速率也不是完全固定的。如果电脑的性能不足以跟上这个速度,一个游戏刻的运行时间就被延长,每秒的游戏刻就会变少。由于游戏中的绝大多数动作都是以游戏刻而不是真实世界的时钟作为时间基准,这意味着在较慢的电脑上很多事情都要花更长的时间来完成。

每过去一刻,游戏的各方面都会更新:移动的实体位置会发生变化,生物会检查周围环境并更新自身的行为,玩家的生命值和饥饿值会根据玩家的处境发生变化,等等。这些游戏的方面是服务端的行为,和负责渲染游戏本身的客户端的更新速度没有关系。也就是说,游戏的帧率(FPS)不影响TPS,电脑的图形性能不会影响到游戏机制。

和每秒刻数(TPS)相关的一个单位是每刻毫秒数(MSPT),即服务器实际上用来计算一刻所需的时间。只有在MSPT不超过50时,TPS才可以达到20。以下的游戏机制比较消耗资源,容易导致服务端卡顿:

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

游戏流程

Information icon
此特性为Java版独有。

在每个游戏刻以下行为依次处理:[2][3]

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

区块刻

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

Java版中,在每个游戏刻中,加载等级在31级或以下、区块中心与最近的玩家的水平距离小于128的区块会执行区块刻。

基岩版中,在每个游戏刻中,所有已加载区块都会执行区块刻。

区块刻有许多影响:

  • 生物自然生成
  • 雷暴天气下,闪电可能在区块内某处生成(1100000的几率)。
  • 每一纵向上的最顶端方块有116的几率检查天气更新:
    • 在寒冷的生物群系中,如果条件合适,会结成冰。
    • 如果在下雪,并且条件合适,一片可能被放置。
    • 如果在下雨,炼药锅可能被填充并最终填满。
  • 区块内某一个方块会接受到随机刻更新。

随机刻

每个区块被划分为16个区段,每个区段包含16×16×16=4096个方块。在每个游戏刻,执行区块刻的区块中,每个区段默认会被随机选出3个方块(可以重复)[仅Java版]或1个方块[仅基岩版]给予一个“随机刻”。可以通过使用命令/gamerule randomTickSpeed <数量>来改变每个区段给予随机刻的方块数。大部分方块不会有影响,除了如下这些:

因为随机刻是被随机赋予的,因此无法预测某个方块何时会接收到随机刻。随机刻的间隔的中位数为47.35秒,即有50%概率不超过47.35秒,也有50%概率超过47.35秒,也有可能需要更短或更长的时间:例如,有1.5%的概率间隔时间小于1秒,也有1%的概率超过5分钟。随机刻的间隔的平均值为68.27秒。对上述数据的计算原理,参见维基百科几何分布

计划刻

一些方块可能会请求在将来的某一个游戏刻更新方块,这种更新方块的方式被称为计划刻。在一段时间后必定发生并且行为可以预测的变化,往往使用这种“计划刻”——比如,红石中继器会计划2游戏刻之后来改变它的状态,水会计划1游戏刻之后来流动。同一个方块上,计划刻与随机刻可能会起到不同的影响。

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

Java版中,计划刻有两种:方块刻和液体刻。[4]

相同执行时刻的方块刻首先根据优先级然后根据创建顺序执行。优先级的较小值对应游戏处理计划刻期间较早的执行。

若红石中继器指向红石二极管,且红石二极管的朝向非反向,中继器的方块刻将有-3的优先级。若中继器准备熄灭,则优先级为-2。否则中继器将有-1的优先级。

若红石比较器指向红石二极管,且红石二极管的朝向非反向,比较器将有-1的优先级。

所有其他方块刻将有0的优先级。

然后每个带液体计划刻的方块将执行液体刻。

每个游戏刻所能计划的最大方块数是65536个。

红石刻

一个红石刻代表着两个游戏刻。这将在一个红石电路中的信号创造一个0.1(110)秒的延迟。也就是说信号从地点A到地点B是增加了0.1(110)秒的延迟。一刻只能属于信号时间的增加,因此,一个信号的传送时间在刻的角度讲是永远不会是减少的。在红石的语境中,“刻”总是指红石刻。

参考