为什么不推荐使用命令方块开发

by 轩宇1725

首先，我们不妨客观地看待命令方块，它的确有诸多优点，如简单、易用、显眼，且基岩版还自带延迟功能，这对初学者来说无疑是极大的帮助。

确实，在你初学的时候用命令方块是很方便，没人阻止你使用。但随着作品复杂度升高，其缺点会不可避免地显露，此时再强调其便利毫无意义，这也正是我不推荐使用的原因：

安全性

如果你的作品基于大量命令方块，那么你绝对不希望你的命令方块失踪。

然而，命令方块难以备份，即使是备份也需要再世界中放置方块（如果你是备份文本形式的指令…那你为什么不直接用数据包呢），这些方块很容易便可被别人（或者自己）敲掉，除非安装特定插件或者模组，否则这种操作难以恢复。

我曾经与伊桑参与一个项目的开发，策划由于不懂数据包，拒绝了我们使用数据包的提议。于是我们使用命令方块进行内容制作，然而在制作过程中，有人进入了服务器，敲掉了所有命令方块然后放置了一个"kill @e"的循环命令方块，使得前面的内容全都作废。当然，在这个案例中，如果服务器善于备份，或者是我们自己持有命令的副本，可以很大程度地避免损失。然而对命令方块安全性的维护效率还是远远比不上数据包。后者在编辑环境中可以轻易复制，或者撤回错误更改，更不用说基于远程仓库维护的项目。

可维护性

命令方块并不直观，在不安装特定插件或模组的情况下，你必须打开命令方块才能看到里面的内容。相比于数据包打开文件便可清晰地看到几十行指令从上到下有序排列来说，命令方块几乎可以说是开盲盒。很多人会在命令方块上面贴告示牌当做注释，但是“一目十行”依然困难，你必须移动到命令方块旁边才能看到相关注释。（更不用说命令方块在纯净版情况下，只能展示整串命令的一小部分）

在实际开发中，很多作者会选择把自己的命令方块隐藏起来，这又产生了必须记录命令方块位置、命令方块链朝向如何安排等问题。而数据包能以清晰的文件层次来安排你的项目，通过合适的命名或者使用函数标签（tick、load），其他开发者（包括你自己）也可以轻易地找到入口并轻松阅读项目的逻辑。

同时，命令方块必须被加载才能使用，在不打开游戏的情况下就无法编辑，这些种种特性决定了命令方块并不是一个稳定的开发工具。

性能

命令方块作为一个功能复杂的方块实体，其本身带来的空间占用和性能消耗不可忽视（甚至还有作者需要配合大量红石电路来实现相对复杂的逻辑）。命令方块的性能消耗在项目大到一定程度的时候将变得十分显著。

依据个人测试结果，命令方块运行记分板指令的占用最低80倍于数据包运行同一指令（由于记分板命令占用很小，适合用作性能测试，我这里每tick执行了1w条虚拟玩家加分命令），而且大量命令方块会带来相当严重的渲染压力。

（图表中红色部分代表一tick所消耗的CPU时间，白色框上边界代表维持服务器每秒20tick需要小于的最低时间50ms）

可移植性

命令方块相对难以移植，原版将命令方块可以通过使用一键命令方块技术或者使用结构方块导出结构。而数据包可以轻易导出、分发再安装进不同的地图。你只需要对文件进行压缩/解压。（而且命令方块的移植难以确认安全性，唯一的方法就是硬读一键命令方块中每个命令方块的指令，或者使用nbt浏览工具检查结构）

数据包的优越性

数据包——准确来说是函数的性质决定了它有一系列命令方块无法做到的功能。比如宏函数，函数标签，续行符等特性，以及通过继承指令上下文来合并执行者以避免反复遍历实体带来的额外消耗。通常来说，即使忽视命令方块本身带来的消耗，基于数据包设计的架构也往往要比基于命令方块设计的性能更加优秀。在开发一些稍显复杂的逻辑时，使用数据包的开发效率在绝大多数情况下都要优于命令方块。

命令方块的应用场景

当然，这并不意味着命令方块在所有情况下都应被摒弃。命令方块最大的优点就是方便。我最常使用命令方块的场景就是我需要立即检查某条较长的命令是否能得到预期的结果。有时候在一些较随意的场景中，我也会用命令方块来作为函数的入口，因为在这些场景下，专门布置一个数据包响应按钮之类的操作是完全没有必要的。虽然命令方块在某些情况下有其便捷之处，但在大多数正式的开发场景中，数据包仍然是更优的选择。