crash-2023-01-14_11.04.40-fml

Gary:

「过度诚实, 谦虚和高度责任感, 是我们这个创作者社区最大的优势。」---?

"套娃升级科技树", 固然可悲, 更不应被引以为豪, 本人在这点上与楼主观点相符, 但不乏有相当一部分人将套娃视为提升可玩性的多快好省方案, 本人难以苟同. 楼主观点上没有展开的一大要点即是"科技包构思简单"的原因, 本人不能断言此论点的真伪, 但限制整合包作者思路的不是别的, 正是大部分其他整合包. 作者自主修改模组本身现有的路线并不是偷懒, 其相比于把模组简单(或者所谓复杂)的串在一起来说, 对作者自身的能力有着更大的考验, 工程量也更大, 如果所有整合包都是这样的"胶水包", 那么自然会不可避免的变得千篇一律. 一言以蔽之, 本人认为整合包作者如果能够自创优秀的流程改编模组原有的流程, 是非常值得鼓励和考验作者能力的, 而并非是"偷懒"的体现. 回到正题, 套娃倘若作为一个适当用来减少涉及元素和部分过于繁琐流程的工具本身无罪, 只是被过多的滥用了. 前文提到过"相当一部分人将套娃视为提升可玩性的多快好省方案", 其荒谬之处就在于此, 导致越来越多的作者效仿并认为这才是"专家级整合包的正道", 造成了现在的景气. 可以说, 楼主能有这样的想法, 是被大风气误导了, 也是很正常的事, 这也是我在开头引用那句话的主要原因. 这可能听着很自大和可笑, 本人但优秀的整合包就该打破原有的常规流程自创新颖内容, 偶尔在此基础上少量运用套娃均衡工程量和复杂度, 只不过有人把这个优势都给套没了, 更有甚者宣传套娃的必要性和合理性, 竖起反面教材的榜样.

接下来, 出于使本文不会过于技术性的目的, 此处不纠结楼主提到的魔改方式等的小谬误, 只谈一谈本人在整合包构思上的主观想法. 以科技包举例, 科技包的重点是自动化, 而自动化基本上来说有四大要点: 效率, 耗材, 体积和造价, 下面分点讨论. 从人类科技进化路线来, 其他三大要素都要为效率服务, 为什么? 因为资源(包括时间), 空间都是有限的, 所以需要科技进步, 提升效率以减少体积, 耗材, 造价, 充分理由有限的资源. 而在 Minecraft 中, 几乎所有的资源都是无限的, 这导致玩家可以肆无忌惮的浪费资源, 这导致在自动化的流程中，效率的作用变得无关紧要. 而在耗材方面, 重要和基础耗材可以趋近于无限的获取, 从可玩性和合理性上来讲, 理应是科技进化造出效率更高的设备促进效率提升减少耗材, 而不是去堆积最基础的东西挂更久的机达成那么一个目的. 下一个是空间, 以空岛, 海岛为首, 空间是无限的且很多基础资源还是来自虚空或者海里, 使得玩家对自动化的体积毫不在乎, 相当一部分还是处于美观的目的, 这同样会影响效率. 造价此处不多谈, 思路基本一致, 粗略地说, 重要的不是质，是量. 造价昂贵的大量机器和耗材云云只需要使用一次, 且仅需一份就能让游戏体验天翻地覆或只有一个用途, 这也是套娃的一种体现. 重点在于, 上文已经提到, 以人类科技进化做比较和参考, 科技包和 Minecraft 千篇一律的一大原因就是一切资源都是无限的, 而追求流程的繁琐和高投入低回报的并不是在这个框架中获得可玩性的优良解决方案, 真实不该繁琐化流程，而是限制资源总量. 我的一位朋友作过一个很有意思的比喻: "一个士兵丢到岛上, 五十天后有人来救我, 五十天怎么活我自己会, 不是非要有那些过程也不是我自己活不下去了", 即只为玩家画好框架和必要的限制, 剩下的让玩家自己自由发挥想象力想办法, 想象你玩一个整合包, 你肯定会优先使用你熟悉的模组和设备, 除非被禁用了, 你大概会弃坑或骂着作者继续玩, 可能限制和自由度二词听上去很冲突, 但在此语境下事实如此. 最后, 我想表达的一言以蔽之: 资源和空间有限后，玩家才会更注重效率，体积等等, 能耕地的永远只有一亩地, 要加的设定不是种地有几百个步骤, 而是要怎么最好效的利用这亩地, 即利用有限资源, 科技不断进步提高效率产量, 甚至你后期可能需要回收前期做过的机器才能凑够继续进步的耗材. 一条路走到黑的单线流程无论看上去多精彩, 都是缺少自由性的, 这都是所有现存整合包枯燥, 千篇一律的一大原因. 以上都是很简单的东西, 只不过似乎没有很多人认真构思过甚至整理表达出来, 本人在此处发表拙见, 各位见丑了.

以上.

德里奇: 楼上两位讲得都很好。

咖喱从整合包设计思路上谈了自己的理解，123 则从玩家的动机层面阐述了自己的看法。

那我来谈一下我的个人拙见，各位权当是瓦舍听戏，我就开始了。

MC 整合包的本质是什么

这个问题抛出来就很吓人。你以为我真的能说出“MC 整合包的本质”是什么？

我也不能，只能给各位一个不成熟的观点。

从函数说起

让我们从数学 / 编程上常用的一个概念“复合函数 / 嵌套函数”开始。

MC 这款游戏中的每一件事，都可以看做一个函数。

y = f(x)

x 是玩家做这件事时需要投入的所有东西，

包括但不限于某种物品材料、某个游戏进度，甚至包括一定长度的游戏时间。

而 y 是玩家从中获得的东西，可能是一种更高阶的材料、一种更强的工具、一种高级的机器，等等。

而 MC 的游戏流程，就是若干个这种函数的复合和嵌套。

如果以“新建存档开局”为起点，“制作熔炉”为终点，这段流程就是：

开局，输入一段游戏时间，获得木头；

输入木头，获得工作台；

输入工作台、木头，输出木镐；

输入木镐和一段游戏时间，获得圆石；

输入工作台、圆石，输出熔炉。

如果把上面五个流程的“函数”记作 a, b, c, d, e,

那这段流程就是“函数” y = a(b(c(d(e(x)))))。

市面上绝大多数的整合包，抛去具体的实现细节，其游戏流程都可以看做是函数的复合和嵌套。

所以“套”正是上述绝大多数整合包的本质。

“套”的“好”与“不好”

那既然都是一个“套”，为什么有的包“套”得好，有的包“套”得不好呢？

我们暂且不从整合包开发者是不是偷懒这种层面去讨论这个问题，

我们站在玩家立场上，替玩家想想。

显而易见，如果整合包每一层的函数都是“工作台”，那就是大家俗称的“套娃”。

那么为了完成这一串嵌套的“函数”，玩家不得不长时间在工作台上摆弄物品，

摆弄完这个，又摆弄那个，整天都盯着那九个格子点来点去，

作为玩家，当然会觉得自己像是巴甫洛夫的狗，仅仅是听着整合包作者“毕业物品”的铃铛，

一遍一遍地流着无谓的哈喇子，却感受不到任何实质性的游戏乐趣。

我在这里抛出一个更进一步的观点：我认为，不仅限于工作台，

任何整合包，如果在流程中大量依赖同一种“函数”，这种整合包都会和“套娃”一样不讨喜。

比如逼迫玩家开局不断地种树、刷石头的空岛包，

它虽然没有用到工作台，但明显过度依赖了输入游戏时间，输出树木 / 圆石的“函数”，

导致游戏体验和工作台“套娃”一样恶劣。

综上所述，我们得出结论：不管是不是工作台，

只要依赖单一的方式来推进游戏流程，就都是不好的、应当避免的。

怎样才能“套”得好

如果今天你想设计一个整合包，而且打算按照上述绝大多数整合包的方式，

设计一个函数嵌套式的游戏流程的话，我会给你如下的建议。

最简单的方法：尽量多地使用各种模组机器

既然依赖单一的“函数”不好，那我们就走到这种情况的反面。

我们多用几种，总可以吧？当然可以。

IC2、GT 之流的老古董都会教你，设计从低级到高级的一大串机器，

并且鼓励你设计自动化将它们串联起来。

这种思路尽管很传统，但是很直接和有效。

你也这样做嘛。你把你整合包里所有的机器列个清单，

找张草稿纸把它们串成一条线，你的整合包流程就出来了嘛。

工作台？让它陪着前期玩家去。

“套娃”就这么轻而易举的避免了，一点都不难。

更好的方法：尽量多地使用游戏机制

模组机器，以方块或实体的形式存在的机器，及其自动化，

仅仅是 MC 众多“游戏机制”的一个狭窄的方面。

挖矿、打怪、探索地牢、解锁进度，你可能会想到这些。

但这时候让我们向魔法 MOD 们取取经，游戏机制还可以更多更复杂。

神秘时代的开局，是在床上睡一觉。

星辉魔法的流程，是不断地建造指定形式的建筑。

还有许许多多可资利用的游戏机制。

因此，你可以从这么多的游戏机制中选择你喜欢的进行拼凑，

让玩家一会要挖挖矿，一会要打打怪，一会要做点机器自动化，

这比起单纯地使用模组机器又更进了一步，

这样的整合包能带给玩家更多的新鲜感和刺激，让玩家更不容易感到厌烦。

还有更好的方法

如果你仅仅满足于上面这种情况，那或许还差一些意思，还不够完美。

你选择的游戏机制是否仅仅是在时间上机械拼凑，

它们之间能不能合理地并行，让玩家不仅感到“高效”的快乐，而且不会闲下来无事可做？

它们之间的联系是否有合理的逻辑关系，甚至顺应整合包的背景故事设计？

你有没有设想过某种原创的游戏机制，让玩家耳目一新，大开眼界？

这些问题都值得不满足于 60 分及格万岁的你深入思考，

我想你一定能给出一个你自己满意的答案。

跳出“套”的框架

这个问题我猜有不少整合包作者曾经想过，

如果没有科技线、没有流程，整合包会是什么样子？

我们不妨从一个不算冷门的模组“幸运方块”上找找答案。

它的游戏机制就几乎没有流程。

一切诉诸概率，你有可能开局就抽到神器，

也有可能抽到一个稀松平常的东西，只好期待抽下一个幸运方块。

它有一个不算小的受众圈子，有不算少的玩家喜欢这样的 MC 游戏。

但反过来说也不算多，甚至一部分玩家对于幸运方块颇有微词。

在我看来，幸运方块 MOD 就对“如何跳出‘套’的框架”这个问题，给出了一种不好不坏的思路。

总结

这么一番分析下来，其实想要设计一个不坏的整合包并不难。

你只要不犯“在流程中过度依赖某一种‘函数’”的忌讳，

在做整合包之前梳理一下所用的所有模组，

把它们的游戏机制拿出来适当排列组合，就能做出一个中规中矩的整合包。

如果你还能加上自己的一点巧思，它就能独树一帜、富有特色、更加精彩。

cneicy / cneicy.github.io

crash-2023-01-14_11.04.40-fml #5

[2021-09-20]个人对国内整合包圈子的主观看法 | 隐退示