拿方块人做试玩，你收到的反馈是假的
同一段物理代码加了震动和粒子就被评价"更跟手"。灰盒试玩的反馈不能进决策，除非你把占位资源拉到和实物一致。
Unity 官方博客有一篇 The placeholder asset problem 讲的事很值得单独写一段：灰盒（greybox）原型会让试玩反馈系统性失真，因为视觉保真度直接影响被试者怎么评价你的游戏 —— 他们评的往往不是机制，是"这东西看起来像不像一个成品"。那篇文章给的建议是先把"视觉最小集"补上：清晰轮廓、高对比色块、可区分的表面材质；灰盒只留给内部逻辑验证。
它引用的例子是 2012 年那个讲"juice（打磨/加料）"的演示 —— 同一段物理代码，加上屏幕震动和粒子之后，玩家就觉得操作更跟手。
这条对工程流程的冲击比它听起来大。因为它意味着：
你拿灰盒版本收到的"手感很烂"，和"机制很烂"，是两种无法区分的反馈。
我为什么对这件事特别敏感
因为我自己就是那个"逐张核对牌面点数和配色"的人。
麻将项目里做过一次很实在的教训：占位阶段的牌面只要有一点不对 —— 条子根数错、筒子的圆点排布不像实物、万字的字形歪 —— 反馈立刻从"这个玩法怎么样"滑到"你这个牌不对"。而那种反馈是没法用来决策的：你不知道自己是机制没成立，还是美术没到位，因为两件事被同一个"感觉怪"糊在一起了。
我后来的做法是把占位资源的最低标准定成一条硬规则：
- 占位美术也必须对齐实物。 点数、配色、结构关系这些"能被玩家一眼核对"的属性，占位阶段就要正确。允许它粗糙，不允许它错。
- 把几何抽成数据表，并加断言。 牌面的点位、配色、高度带不是我手画的，是一张表 + 一段生成代码，并且有测试断言表里的约束。这样"改一个视觉细节"是一次数据变更而不是重画，评审时也能逐条核对。
- 验收轮次要显式记账。 那次牌面视觉是跑到第八轮我才敢宣布冻结 TileArt 的点位、配色和高度带；冻结的意义就是之后任何阶段都不许顺手改它。没有"冻结"这个动作，视觉细节会一直在被动摇，而每次动摇都会污染那一轮的所有反馈。
这三条听起来像美术流程，实际上是把"占位资源的失真"压到最小 —— 因为如果占位阶段的东西本身是错的，玩家给你的评价就永远无法归因。
试玩版本该带什么
从那篇 Unity 文章和 juice 演示合起来，我给自己定的门槛是：进入试玩反馈环节的包，至少要满足
- 反馈通道齐全：命中有停顿、有位移偏移、有音画同时（这三样是纯代码/纯参数，不是美术资产）；
- 关键识别属性正确：物件"是什么"必须对（点数、朝向、可交互 vs 装饰），材质和精度可以糊；
- UI 和结算不能是占位文字 —— 一旦玩家开始猜"这个按钮是干什么的"，他就不再在评你的玩法。
第 1 条是我在手感那两篇里写的东西的另一个用途：它们不是"上线前的抛光"，它们是让试玩数据可信的前置条件。
范围控制是同一件事的另一面
CiGA 那份 Global Game Jam 生存指南（2019）里有几个约束我认为是通用的，尽管它写的是 48 小时：
- 时间吃紧时先砍的是菜单、关卡数量、打磨，而不是"核心玩法能不能跑起来"。交一个跑不起来的包和交一个丑但能玩的包，是两种完全不同的结果。
- 节奏上：第二天下午锁死可玩原型，通宵出可执行版本做系统调试，第三天上午只留给调参和稳定性。
- 互试玩阶段禁止重改核心机制。
最后那条我读到时有点被击中的感觉，因为它就是"占位资源污染反馈"的机制版本：试玩是用来收集信号的，你在收信号的当口改发射源，数据就全废了。Jam 里把这条写进纪律，比在日常开发里靠自觉可靠得多。
（同一篇还有个观察值得记：官方按策划/程序/美术/音频分岗挂绳，5 人左右为宜。人数再多，光是"让所有人同意同一个核心玩法"就要花掉相当一部分时间。）
我会检查自己的一件事
拿到一批试玩反馈时，先问："这条反馈能不能在我的灰盒版本上成立？" 如果答案是否 —— 比如它涉及材质、气氛、"看起来专不专业" —— 那它就不是机制反馈，是呈现反馈，需要单独归档，不能拿去砍功能。
把这两类混在一起，是"我们加了 juice 之后玩家说好多了"这类故事反复发生的原因：问题从来不在 juice，是它被用来掩盖一个还没成立的机制。
参考来源
- The placeholder asset problem — Unity Blog
- Juice it or lose it — Martin Jonasson & Petri Purho（2012 演讲；原幻灯片页已不可达，此处为报道页）
- Global Game Jam 生存指南 — CiGA（2019-01-23）