GM:“现在你们来到了新房间里,黑暗就像年迈的祖母为你们张开怀抱。”
PC:“那么这里有什么动静?”
GM:“并没有……”
PC:“我感觉这里太危险了,我们离开吧……”
GM:“等等……你们不做点什么吗?比如察觉?啊,你成功了,这个钥匙是你的!”
够了,我几乎受够了这种可笑的情节设计!主持人们,当你们设计了一个无法让PC扮演的情节后就不要期望PC会配合你们完成那不存在的RP。赶快检查一下你们的团务笔记,把那些“藏在箱子底部的BOSS门钥匙”,“火把状的门开关”,“完全隐形一直默默看着玩家的NPC”或者“顺便找个地方写下的不起眼的暗号/密码”给从跑团里拿出去,没有人会找到他们,这种桥段的设计除了制造卡关,击碎玩家的热情,激化团内矛盾外有什么合理的存在意义吗?
有的GM说:“尽管有这种桥段,但我从来不敢把他们放在主线故事的道路上,我就藏点奖励什么的……”这样确实不错,但是本来对于很多模组设计者来说跑团的规则就限制了很多,减少一种推动主线故事行进的方式是不能接受的。
“你在胡扯八道些什么?又说不让用,又非要用,你这不是自相矛盾吗?”
别着急,我将要分享的是如何合理的在团内插入这些“难以发生”的桥段。
几乎所有的这种桥段都可以分为两个部分的组合:触发和响应。
“获得箱子底部的消息”是触发,“拿到可以打开BOSS门钥匙”的部分是响应。理论上来说你可以在触发里得到各种各样的响应:“打开BOSS门的钥匙”,“精制品+1附魔长剑”,“记载光墙术的魔法书”,“曾经有过金币的布袋”……另一方面你也可以通过各种各样的触发来获得响应:“墙角松动的砖块”,“路过对你们心存戒心的老太太”,“刚刚干掉的强盗的尸体”。
那么,没错,聪明的你已经想到了一些简单的方法来实现触发和响应的组合。我大可以设计一把“拿到可以打开BOSS门钥匙”但并没有写它实际上会出现在什么地方,然后我们在地图上多标记几个地点,这些地方都可以存在这把“拿到可以打开BOSS门钥匙”。这样玩家就很难拿不到钥匙了。
你甚至可以得到一些拓展,设计一些藏宝点,只要丢骰子,里面就有可能得到各种各样的宝藏。
触发-响应系统是一个从上文分析里抽离的概念,创建这样一个系统的概念有利于我们去创作更加复杂的类似情节。
全局是一个相对的概念,你可以将它覆盖在某场团,某场战斗,某个房间,某个世界,某个多元宇宙……全局是与局部相对,创建全局意味这将是你的整个触发-响应系统的效应范围——这点很重要,千万不要让触发系统溢出全局,这将为你的实现和GM的运作产生很大影响。
当响应目标未完成在非终点触发的时候,你需要通过一个触发终点来实现触发的最终完成。
这些小奖励或者消息是为了避免玩家探索得到的消息过于密集和提升玩家短期热情而创造的。
与触发终点正好相反,队尾存在是为了避免触发超过需求,而让触发无事可做的情况创作的。和甜点一样,这是一个锦上添花的操作,因为GM大可以删除那些多余的触发,但这不会让你设计的流程节奏变得乱七八糟吗?
事实上跑团到结束前,世界上并不会真的存在这么一个队列,你不一定真的要将上面那些东西排成一列,整个队列是在跑团中由约束自动产生的。一个触发-响应系统可以发生多种响应队列,合理分析出其中最好情况和最坏情况有利于我们分析系统的完善程度和合理性。
想要创造一个可以合理运行的触发-响应系统,你需要遵守以下约定:
所有的响应都一定要在到达触发终点后可以被捕获,否则你会让在运行惰性情况团(存在目标响应未在需要捕获期限前被捕获的情况的团)的GM无法继续进行跑团。
“BOSS的大门可能需要多把钥匙,它们都可以被大门边的看守尸体捕获”,因为你设置了多把钥匙,但是看守只带了一把,所以在“站在BOSS门前的玩家需要触发一把以上把钥匙”的情况下GM无法继续进行跑团。
触发终点应当是可以忽略的或接受队尾的,你不能创造了一个“一定会给予玩家帮助的仙女”作为触发终点,这将导致仙女无忙可帮。
你绝对不能创造一个可以逾越全局的交互,这将为系统带来无法估计的影响,最后系统会变得一团糟。
这需要被严格审查,糟糕的甜点设计可能会让你感受到“千里之堤,溃于蚁穴”。
尽管现在你已经知道了一个可以运行的触发-响应系统是什么样子的,但基于易于操作和管理的考虑,我认为你可以接受以下建议:
数倍于响应的触发是完全合理的,这需要多花一些功夫。相信我,花不了多少,基本上是个墙角你就可以设计。不过我不建议你这么做,原因基于下文。
你不会希望玩家因为老在墙角发现宝藏而找遍每一个墙角,你也不会希望玩家因为在每个地方发现金币而认为城市里有人故意散布金币。单个独特的元素是偶然,但是连续出现不免让人生疑。
我建议你将创造元素这件事情分时间打乱做,用清单管理,因为同一时间人的思维会陷入很大的惯性。
全局的唯一作用是辅助设计,牢记全局是设计成败的关键之一。
确保在极端情况下系统可以被正常运行对提高系统的稳定性很重要。
这是一场战斗遭遇,我们需要在战斗结束的时候保证PC打败看守BOSS大门的守卫打开大门迎战BOSS。但是作为模组作者的你很清楚战斗太多了,在决战前额外安排一场战斗对于这个模组来说是无可奈何的事情。
我们现在设立全局为这场遭遇。响应为:“打败看守BOSS大门的守卫,打开大门”和“让PC迎战BOSS”。
打败守卫和打开大门的触发终点我们设计为直接战斗和守卫的尸体;
劝降守卫是个不错的方法,但是在战斗前的劝降会让跑团流程变得异常不合理。所以我们决定扩大全局,在玩家到达这场战斗前会路过守卫的家乡,在那里救位姑娘可能会让守卫换一种抵抗的方法(进行良心质问?然后玩家趁虚而入?记住,玩家需要知道前因后果,不然这会让他们困惑。)
路过守卫睡觉的地方的时候就把他解决了,然后安排一个BOSS呼叫守卫但是无人回应的桥段也不错。伪装,弄瞎他眼睛,偷走武器……这些都是不错的触发,将他们写在模组里。
打开大门的钥匙什么的你可以放在一万个角落。与BOSS战斗?小路什么的都可以(守卫会冲进来护驾?你要考虑这种情况。)
写点精制品大棒,丢两个金币。这种无关紧要的奖励就行。如果玩家已经劝降了守卫却来到了他的宿舍,留封小信,留两块金币,Done!
当玩家已经连续查出了几个主线故事,为了不让主线过早完结,这种小甜点就派上作用了。
边界检查:你要确保你的修改全都在全局范围内,没有逾越雷池半步。
分割全局:开始将全局按涉及章节,遭遇分割。
往复检查:你要确定以下两点没有问题:
触发终点不存在于可选情节;
有关其他全局的重叠区域。
当我再玩像《博德之门》、《辐射》和《巫师》这样的作品的时候,我意识到传统跑团的创作方式在对体量的适应性上已经无能为力,标准化的创作,校对,修改的流程尚未创作。我不同意很多人关于跑团中非线性叙事的想法,在我的理解里,非线性叙事的首要服务对象是GM,当一位GM在开始讲述一个结构极为复杂的叙事的时候怎么样控制流程运作是非线性叙事首先要解决的。
在写这篇文章之际是我第四次重构我的模组《北歌Vol.1:艾尔萨托的陨落》,我不清楚最后这篇模组是否能以我期望的效果完成并为人们带去我的理念与情感,还有我对演出的想法。但是我不会放弃。
如果你在创作一个尚未完成的故事,想要通过一些方法为其增加一些色彩,开个dev分支,我的方法可以试试。
这个理论尽管看起来很美好, 但是它有一个明显的问题: 给 GM 带团的时候心智负担太重了, 要不就要把一大堆东西记在脑袋里, 要么就非很大力气做一堆提示, 带团的时候疯狂在纸堆里翻找. 所以很多时候只能借用其中的一部分理念再加上跑团的时候随机应变.
但是最近我在一定程度上解决了这个问题, 我开始尝试使用 Next.js + MUI + MDX 的技术方案编写模组, 这个方案的好处是可以在用 MD 的方式写模组的同时使用自己编写的组件. 于是我重新想到了这个文章, 我决定用自定义组件的方式来简化这个模型的使用. 下面是结果:
你还可以点击卡片来标记这个东西有没有被获取. 进一步的我计划在组件中加入 suggestion 参数来标记建议的进度方便城主控制发放物品的速度.
评论区
共 2 条评论热门最新