在设计阶段就抓住玩法与叙事的不协调,而不是等到垂直切片

这个词被用得很松,所以先给出真正能动手的那个版本:游戏宣称了关于主角或世界的 某件事,而它交给玩家的动词与之矛盾。 那些著名例子形状都一样——写成不情愿的角色, 机制上却因为杀掉几百人而被奖励;讲匮乏的故事,资源却多到用不完; 文字坚持你在乎的同伴,系统里只是一个跟随位。

为什么它通常发现得太晚

它在测试期才浮出来,因为那是两半东西第一次待在同一个房间里。叙事与系统通常由 不同的人、照着不同的文档并行写。两份文档单独看都没错。矛盾只存在于接缝上, 而那道接缝在任何地方都不作为一份产物存在——直到构建出来为止。

到那时代价大得刚好戳在最疼的地方:要改就得动系统(已经平衡好的几周工作) 或者动故事(已经录音、已经做了动画)。团队几乎总是选第三条路,就是忍着。

这个问题的结构版本

玩法与叙事的不协调不是一个在实机里才发现的写作问题,它是节拍表与机制清单之间的 结构缺口;而要求每一拍都点名承载它的机制,就能在设计期把这个缺口找出来。 一个点不出机制的节拍,意味着故事正在发生、而玩家没有在做任何事—— 那正是玩家口中「游戏嘴上说一套、手上让我做另一套」的那个瞬间。

这个改写就是全部诀窍。「故事配不配得上这个游戏」是一个两个人可以永远争下去的 品味问题;「这一拍由哪个机制承载」是一个要么答得出一个名字、要么根本答不出的问题。

拿它来做什么

用不着工具你也能做。把你的节拍表拿出来,加一列:这一拍玩家用的是哪个机制。 然后看会出现什么:

• 没有机制的节拍。 要么它是过场——可以,但要数一数,并且注意连着三个的时候; 要么它在宣称某件玩家从来没有亲手做过的事。
• 不出现在任何一拍里的机制。 游戏教了这个动词,然后从没让它在叙事上有意义。 这是更安静的那种失败,而且往往更贵,因为有人把它做出来了。
• 绑了机制、但机制与它矛盾的节拍。 不情愿的主角绑在战斗循环上。 把绑定写下来,这件事才看得见;写成散文它就藏起来了。

第三种是大家预期的那种。实际上前两种更常见,而且好修得多, 因为它们在两半都还没做完之前就被找到了。

做成约束,而不是一张清单

清单只会被跑一次。我们把这个绑定做进 schema——没绑机制的节拍是一条验证错误, 不是一条警告——理由是:矛盾并不在节拍表写好的那一刻出现, 它出现在三次修订之后,中段被重构过、两个节拍悄悄丢了动词的时候。

所以要做成约束而不是纪律,靠的不是“人会马虎”这个理由, 而是这个失败是被编辑引入的,而编辑不会停。

它抓不到什么

很多。一个节拍可以点得出机制,却仍然对这个机制不诚实—— 写着「玩家在谈判」,而谈判是一个只有一个真选项的对话菜单。 结构检查确认绑定存在;那是不是一个真的绑定,是判断,而且始终是人的判断。

结构给你买到的是:这个判断落在二十个你看得见的可疑绑定上, 而不是落在一个“感觉不对但说不清在哪”的构建上。