QC之源:一个广为流传的误解
「QuasiConnectivity(半连接性)这个特性是与活塞一同引入游戏的,因为它直接复制了门的代码,这是一个bug,但后来因玩家要求被官方认可并保留了下来。」
不知道从什么时候开始,大多数Minecraft玩家心中都埋下了这样的印象。
无论是贴吧的帖子,还是B站;无论是中文圈还是海外社区,这种说法都广为流传。听起来也确实合理:
“活塞是一个多方块结构,当时唯一有类似结构的红石元件就是门。于是开发者复制了门的代码并修改,却忘记删除‘下半门检测上半门充能’的逻辑,从而意外地引入了QC。”
但是——
事情真的有这么简单吗?
. . .
01|误解
受QC影响的方块目前已知只有四种:门、发射器、活塞、投掷器。
根据Minecraft Wiki的记录我们可以整理出这样一个加入顺序:
- 门:Infdev 2010 加入
- 发射器:Beta 1.2加入
- 活塞:Beta 1.7加入
- 投掷器:正式版 1.5加入
令人意外的是,发射器在Beta 1.2中就已经具备QC特性。这比活塞要早了几乎半年。
更重要的是,反编译Beta 1.7版本中活塞与门的代码后可以发现,它们的充能检测逻辑完全不同,几乎看不出复制粘贴的痕迹。也就是说,QC并不是活塞带来的“bug”。
发射器的充能检测(beta1.7)
boolean var6 = var1.isBlockIndirectlyGettingPowered(var2, var3, var4) || var1.isBlockIndirectlyGettingPowered(var2, var3 + 1, var4);
门的充能检测(beta1.7)
boolean var8 = var1.isBlockIndirectlyGettingPowered(var2, var3, var4) || var1.isBlockIndirectlyGettingPowered(var2, var3 + 1,var4);
活塞的充能检测(beta1.7)
private boolean func_31041_f(World world, int x, int y, int z, int excludeDirection) { return (excludeDirection != 0 && world.isBlockIndirectlyProvidingPowerTo(x, y - 1, z, 0)) || (excludeDirection != 1 && world.isBlockIndirectlyProvidingPowerTo(x, y + 1, z, 1)) || (excludeDirection != 2 && world.isBlockIndirectlyProvidingPowerTo(x, y, z - 1, 2)) || (excludeDirection != 3 && world.isBlockIndirectlyProvidingPowerTo(x, y, z + 1, 3)) || (excludeDirection != 5 && world.isBlockIndirectlyProvidingPowerTo(x + 1, y, z, 5)) || (excludeDirection != 4 && world.isBlockIndirectlyProvidingPowerTo(x - 1, y, z, 4)) || world.isBlockIndirectlyProvidingPowerTo(x, y, z, 0) || world.isBlockIndirectlyProvidingPowerTo(x, y + 2, z, 1) || world.isBlockIndirectlyProvidingPowerTo(x, y + 1, z - 1, 2) || world.isBlockIndirectlyProvidingPowerTo(x, y + 1, z + 1, 3) || world.isBlockIndirectlyProvidingPowerTo(x - 1, y + 1, z, 4) || world.isBlockIndirectlyProvidingPowerTo(x + 1, y + 1, z, 5); }
}
02|时间线
既然原有理论不再可信,我们不妨回顾几个关键红石元件的时间线,试图寻找更合理的解释:
- 2009年5月,Notch在开发日志中提及对“活塞”的兴趣,并提出了Pulley1和Pulley2的概念。
- 2011年1月,发射器随Beta 1.2加入游戏,它已经带有QC特性。与此同时加入的红石元件还有音符盒,但音符盒并没有类似行为。
- 2011年3月,第三方mod作者Hippoplatimus发布了Pistons Mod,首次实现了活塞,该mod被jeb看好,获得并整合了该mod的代码进入Minecraft。
- 2011年6月,Jeb在Twitter上公布了游戏内活塞的早期版本截图。
- 2011年7月,活塞随Beta 1.7加入Minecraft,具有QC。
- 2013年3月,正式版1.5推出,投掷器加入,具有QC。
奇怪的是,Pistons Mod中的代码中,也出现了能够导致QC的额外充能检测逻辑。但这段逻辑,与Beta 1.7版本中官方活塞所用的QC实现方式又完全不同。
PistonMod中的活塞充能判断(beta1.3)
boolean var6 = var1.q(var2, var3, var4) || var1.q(var2, var3 + 1, var4);
这意味着:.
第三方mod作者Hippoplatimus在自己的活塞实现中独立写入了会造成QC的逻辑,而Mojang在重写并合并了其逻辑结构的情况下仍然保留了QC机制。
似乎难以“巧合”或“失误”来解释。这样一看,:QC似乎一开始就是一个“设计”,而不是一个“bug”。
03|所以?
令人遗憾的是,这篇文章并无法为你揭示QC的确切来源。
因为即便整理了所有目前可查的信息,我们仍无法100%还原这段设计背后的完整思路。
至少我们已经知道:
那个“活塞抄了门”的解释,是错误的。
也许,QC的起源,终究会被时间的尘埃掩埋在Minecraft的开发历史中。
但我们希望,这篇文章至少能带给你一点启发:去质疑被视为理所当然的,去审视被众人接受的,去追寻那些仍未知的。 某日,有人像你请教”QC”时,我们希望你也能分享这个未解之谜。