作为一名建筑装饰玩家，如果向你推荐一款家具模组，你会作何考虑？着眼于这款模组的美术风格、模型品质、内容数量？亦或是担忧这款模组的适用版本、模组兼容性、易用性？如果你是一名模组作者，又将如何在这些方向选择取舍？
过去，我在“原版装饰模组”[1]这一课题提出过不少回答。在一年的探索、积累与沉淀之下，我编写了《松果核》家具框架。
《喵工坊》的初创与对家具的独特诠释
一年前初涉数据包开发时的我，正在为生存服务器制作内容。当时我就已经萌生了在游戏内制作家具的想法。那段时间正值 Minecraft 1.20.6 更新，物品组件的诞生为游戏内自定义物品提供了众多的可能性。于是经过了一两个月的建模和开发，我与制作模型的朋友共同创作了第一个作品——《喵工坊》。它完整的诠释了我们当时对于“原版装饰模组”的思考：将家具设计为特殊“方块”，占据 1*1*1 的独立空间，并且仔细处理和原版方块之间的放置和空间占据关系，通过“方块”的类比来增加玩家对家具的亲切度。家具同时拥有丰富的交互效果，甚至可以在游戏内自定义，为多人与服务器应用也做好了充分的准备。这些想法其实非常独特，与一众常见的家具模组相比甚至有一些“不合群”，我甚至难以用好坏来衡量它所带来的反响。
但若不论反响，《喵工坊》的编写在当时无疑是先进的，它使用了 Java 版自 1.19.4 以来的几乎所有功能——展示实体与交互实体、函数宏、物品组件。这些功能的加入将数据包推向了前所未有的高度，也使得《喵工坊》达到了如 MOD 般的易用性。但相应的，它的最低版本被无奈的限制在了 1.21。《喵工坊》自发布以来，我收到的绝大多数留言都在询问低版本适配的可能性。深感无奈的同时，我也浅浅的感叹了 Minecraft 生态的复杂度。可惜我并不会编写 MOD，这大概会是《喵工坊》目前一个不大不小的遗憾。
对内容宣发的思考与《松果核》的诞生
也是自《喵工坊》的发布开始，我逐渐注意到它在设计之初遗留下的种种问题。版本兼容、内容更新、资源兼容……它们无不驱使着我去反复思考“原版装饰模组”的出路。作为一款装饰模组，自然会有很多玩家为《喵工坊》的模型而“买单”，这也是我们今后继续宣传《喵工坊》的一个重要支点。我们在初版发布时就已经在其中添加了近千个模型，如今的模型数量更是达到了两千有余。即使这样，对我们而言，如何保证后续的模型更新仍然是一个挑战。制作 Minecraft 模型门槛不高，但优秀的模型仍需要花费大量的精力。可以预见，在将来的某个时间，我们也会无力再制作新的模型。尽管基础的兼容性更新并不困难，但《喵工坊》作为一款不温不火的装饰模组，若是失去了新增内容的宣发支点，很可能就意味着其生命周期的结束。
于是我也试探性的询问过一些模型作者的合作意愿，而得到的结论是，大部分的作者更注重作品的独立性，希望由自己来发布自己的作品。我曾经提出过一个想法：让《喵工坊》能够支持模型扩展包。如此，模型作者可以自行发布扩展包，玩家只需要安装《喵工坊》本体和其他作者的扩展包即可游玩。可惜，《喵工坊》略显薄弱的基础架构否定了这样的可能，而且其他作者大概也不愿让自己的模型作为他人的“附属品”。
《喵工坊》的前路仍待探索，但在和其他作者的交流中，我注意到了一些新的契机。很多作者其实能够制作非常优秀的模型，但他们因为缺乏相应的技术，没有机会让自己的模型在游戏里得到表现。这时如果我能发布一个足够方便的新工具，让模型作者能够自行将模型转化为数据包和资源包，并且如同独立发布一般，由他们交到玩家手中呢？这听上去就是一件非常具有意义的事情，无论对于作者、玩家、甚至整个游戏社区来说都有着积极的推动作用。到这里，我们的答案似乎呼之欲出了。但其实不然，一朵巨大的乌云仍然盘旋在原版装饰模组上空——资源包的冲突。
长久以来，资源包都依靠着 Minecraft 规定的自定义模型编号来运作。通过定义一个编号与模型的映射表，可以使同样的原版物品在游戏中有不同的显示。大部分的装饰资源包都会利用这个映射表，将自定义模型添加到皮革马铠、烟火之星这种在原版中作用不大，又能够支持染色的物品上。而正是这个有着关键作用的映射表，在不同的资源包中竟然是冲突的。对于某个特定的原版物品，即使映射表中的编号并没有冲突，Minecraft 也只会读取优先级最高的那一份映射表。这意味着如果我们安装了两个家具资源包，二者均以烟火之星作为原版物品来定义模型编号，那就只会有一个家具包能够正常显示。这样一个“特性”为资源包带来了致命的兼容性问题，也极大的限制了原版装饰模组的可能性——直到 1.21.4 带来的资源包更新。
“任何物品都可以调用任何模型”，这仅仅是资源包更新冰山一角，但成为了实现上文所述“理想”的最后一片拼图。现在，我们可以制作出一个非常简便易用的生成工具，它的作用就是帮助那些完全没有数据包基础的模型作者，创建一个简单可靠的数据包家具模组。作者只需要把模型和贴图导出，根据实际需要填写一些简单的家具配置，再运行一个脚本程序，就能够欣赏自己的模型被转换成数据包和资源包的美妙过程。把它导入游戏，就可以直接在游戏内合成、摆放家具，并为它们染色。不仅如此，使用这个工具创建的所有家具包可以无冲突地同时使用，这意味着不同的作者可以放心的发布他们的作品，而玩家也可以像搭配模组一样去添加这些家具包。
这就是我所编写的《松果核》了。
数据包还是 MOD？
对于基于数据包开发的《松果核》，我其实也难以窥视其前景。我希望有更多的玩家去体验基于数据包开发的内容，因为它们开发更快，能紧随版本。当你想亲自尝试制作时，数据包的门槛也相对较低。但目前而言，大部分的玩家可能还是更喜欢传统的 MOD 形式，毕竟那边能有更丰富的内容，版本落后也就不成问题。我相信作为本刊的读者，大家都已经亲历过无数次这样的讨论甚至辩驳。我曾经告诉自己，无论玩家还是作者，大家只是选择了自己的偏好，我可以去坚持自己开发数据包的想法。我愿意去相信数据包仍然拥有广阔的前景，但每每读到 bilibili 的留言，我还是会不由自主地怀疑：我该去把它们做成 MOD 吗？
也许还是来期待下次 Java 快照能带来怎样的惊喜或惊吓吧。
原版装饰模组，即使用数据包与资源包，不依赖MOD或插件，在原版游戏下即可为游戏添加装饰性内容的扩展包。尽管从技术角度，称其为数据包或资源包更准确，但为了能听上去亲切一些，这里还是称其为“模组”，并加以“原版”二字来与非原版的 MOD 进行区分。 ↩︎