分类： 游戏设计

分类
游戏设计

《Loop Hero》的数值设计

《Loop Hero》国内又叫《循环英雄》，写下这篇文章的时候，我的游戏总时长已经达到了29.6小时，打败了2次最终BOSS，算是基本退烧了，这篇文章主要想从游戏设计的角度谈一谈我对《Loop Hero》的一些数值设计的理解。

整体游戏架构是很标准的Roguelite游戏，内层循环围绕着“转圈路径+卡牌+地块”进行了大量创新的设计，也是这个游戏最为亮眼的地方；外层设计则是比较常见的城建成长系统，建设“主城”可以不断提高能力、解锁卡牌甚至解锁更多职业。

对于Roguelite游戏来说第一个要做的就是数值的分割，哪些放在内层循环，哪些放在外层循环上，并且为了保证roguelike的体验，势必关键数值的大头是在内层循环中投放（并且随着每次内层循环的结束消逝的），少部分数值在外层循环中投放。比如最关键的2个基本属性：攻击力和生命值，外层的投放都是少的可怜，拿生命力来说，外层就是几点几点的投放，比如【古董衣柜】和【古董橱架】，而内层的话一局游戏下来，一件衣服提供的生命值少则几百多则上千；至于攻击力，外层则根本没有投放，最多也就是【老油画】这种对BOSS伤害提高4%的设计。

《Loop Hero》在这方面做的是很不错的，数值的分割做得十分稳妥，但也有一些数值爆炸外层投放，比如【伯爵之座】，每件提供1%的吸血，努力搞个几十件，效果就赶超了《魔兽争霸3》的疯狂面具；再比如【农夫的长柄镰刀】，造成的伤害的3%转化成对所有单位的伤害，努力搞个几十件，效果吊打《Dota》的狂战斧和《英雄联盟》的提亚马特。

以上两张图都是我的游戏截图，其实我用了修改器调了资源，跳过了后期较为无聊的刷资源阶段，否则30个小时的游戏时间是刷不出来这么多东西的。

考虑到这些道具的获得成本很高，并且具有随机性，因此就算数值爆炸基本也是后期的体验，既然设计者认为游戏到了这个阶段数值爆炸也无所谓了，那么这种体验也是无可厚非的。

《Loop Hero》面对的最大困难，以及解决的最好的，我认为是攻击速度的投放问题。

攻击速度主要是靠卡牌+地块来投放的，每格【森林】+1%攻速，每格【灌木丛】+2%攻速，并且【河】可以使相邻地块效果翻倍，配合“图书馆”不断把不想要的牌洗成灌木丛和河，很快就可以铺满满地图的灌木丛和河，玩家的攻速加成可以轻松达到300%甚至更多。

从数值上来说这可能是没问题的，毕竟大家也习惯了很多打怪的时候看起来像“抽风”一样的游戏，比如《流放之路》，或者很多的MMO，但说实话，让玩家看到自己控制的角色在“抽风”毕竟不是个什么值得夸耀的设计。更何况很多命中后有概率触发的效果会和攻速叠加，导致数值爆炸发生不可控的情况，因此对于攻击速度的投放，大部分游戏都是慎之又慎的，尤其是长线大框架数值的游戏比如MMO。

令人咋舌的数值投放，闪避上限为75%，一件38级鞋子就可以提供74%……后面40级的鞋子一件就可以拉满，但我没截图

《Loop Hero》虽然是个单机游戏，数值投放比较粗放（比如【闪避】是直接投放的概率，上限75%，而一件40级的鞋子就可以提供75%的闪避，直接拉满……），又由于攻速是通过卡牌+地块投放的，也就是说真心想堆的人会把这个数值搞到非常夸张的地步，我们又不想要让玩家看着自己的角色“抽风”，怎么办呢？

《Loop Hero》的设计者搞了个体力值的设计，解决了这个问题。体力值的机制如下：

体力值初始是满的。每次攻击都会消耗一定的体力值。当体力值尚未耗尽时，会以一个固定的速率恢复（这时体力槽为灰色）。当体力值耗尽后，体力值会以一个更慢的速率进行恢复（这时体力槽为蓝色），并且角色的攻击速度会骤然降低（目测是恢复到没有攻速加成的基本攻速，但未证实），直到体力值回满，并且体力值耗尽的越快，恢复慢越慢（如果体力槽为红色，那么恭喜你，会恢复的非常慢）。

这个设计不是很直观，这一点是它的问题，很多人玩到后面也没明白为什么自己打着打着突然就打不动了，实际上就是因为攻速堆得太高了导致体力透支。这个设计在动作游戏中玩家很好理解，因为各种需要支付体力的动作是玩家自己主动发动的，而在《Loop Hero》中因为英雄是自动攻击的，因此这个机制就变得不直观了，尤其是体力耗尽的越快恢复越慢这一点，更让人觉得困惑。比如我参考的这篇攻略的作者，就完全没有意识到这个体力机制的存在：

https://www.gamersky.com/handbook/202103/1368916.shtml

但是这个设计可以说很好的抑制了攻击速度的收益，从整体的攻击次数上来统计的话，攻速越高，那么不能享受攻速加成的攻击次数的占比就越多。这个设计是非常不错的，可以说我从中学到了一手。

同时，作者又搞了另外一个设计，进一步来解决攻速过高的问题，即地块【绿洲】：玩家攻速-0.5%，其他生物攻速-1%。这张牌收益是正的，并且可以轻松的回收10%~20%左右投放出去的攻速。

最后分析下我最终的BD：

卡组（10张）：

【村庄】【麦田】
【吸血鬼别墅】【战场】【血魔树林】【图书馆】
【森林】【河流】【沙漠】
【遗忘皆空】【军械库】

补给：【伯爵之座】【农夫的长柄镰刀】【老油画】，前2者每样搞几十个，剩下的搞老油画。

小贴士：

  • 【血魔树林】的吞噬效果可以很有效的对抗【血肉傀儡】的【临死一击】以及【焦火蠕虫】的【撤退】。
  • 【农夫的长柄镰刀】的AOE效果似乎也会同时触发吸血效果，一刀下去就满血。
  • 【前哨站】基本是盗贼专用的，盗贼的杀人后不掉东西掉奖杯可以避免前哨站抢装备的负面效果。另外如果玩家是死灵法师，前哨站还会把玩家一起打，所以只有盗贼用这张牌是没有负面效果的。
  • 【追忆迷宫】可以快速的占据大量空间，这样可以更快的让BOSS刷出来。
  • 【法术伤害】的效果据说是无视敌人的护甲直接造成伤害，但未经证实。
  • 【土屋】的效果是影响补给的上限，因此想要把狂战斧堆满就猛造土屋吧。
  • 修改器我用的三大妈的一修大师修改器，后续版本是否可用未经证实：https://www.cr173.com/soft/1330874.html
  • 更详细的数值公式反推可以见这篇文章（包括体力的机制里里面也有详细的数值）：https://www.gamersky.com/handbook/202103/1369951.shtml

分类
游戏设计

如何写游戏策划文档？

我看了一个大佬分享如何撰写游戏设计文档的视频：

不过如果你翻不了墙也没关系，接下来我会把每一页PPT都截下来，并且说明其要点。由于文章很长，下面是整体目录：

  • 游戏策划文档有必要吗？
  • 文档是写给谁的？
  • 写文档的阶段
    • 愿景陈述
    • 高概念
    • 游戏设计文档（GDD）
    • 产品模块分解（PBS）
    • 详细开发文档
  • 如何写好一个详细开发文档？
    • 保证可读性
    • 可视化
    • 力求精准
    • 不惧怕改动
    • 及时更新
  • 最佳实践
    • 边玩边做
    • 别怕砍功能
    • 管理好需求变更
    • Story Mapping
    • 其他策划工具推荐
    • 其他忠告
    • 扩展阅读

目录里面我认为重要的部分我都加粗了，感兴趣的同学可以跳着看。首先要说明的一点是，大佬分享的经验更类似于传统的单机开发流程，而我在整理的时候会将其整理为对我们以免费、长线、不断迭代的游戏更为合适的版本。

下面进入第一个话题，既然我们要讲如何写游戏策划文档，那么第一个问题是……

游戏策划文档有必要吗？

一提到策划文档（或者按英文的说法叫游戏设计文档，Game Design Document，缩写GDD），很多人都会蹦出来说这玩意没必要，无外乎以下几种说辞：

  • 就算你写了也没人看
  • 写文档花的时间太多了，有这时间不如去实际开发功能
  • 我们是敏捷迭代，不需要文档
  • 变化太快了，文档只要你写了就是过期的
  • 我们慢慢迭代就好，不需要文档

在大佬看来，这些都是很差劲的说辞，而我也很认同这个观点，我们不妨一条一条驳斥上面的说法：

写了没人看？

并不是文档没用，而是策划的锅，说明你写的烂！
写了没人看？——并不是文档没用，而是策划的锅，说明你写的烂！

写的烂的文档的几大特点：

  • 洋洋洒洒的大段文本
  • 用的工具不对
  • 文档没做到时刻保持最新
  • 无关紧要的内容
  • 相应内容很难找到
  • 写的受众不对

这些具体怎么办，下面会说。接下来驳斥第二条：

变化太快了，文档总是跟不上需求变更？/既然我们不确定最终做出来的是什么，为什么要为中间品写文档？

不要害怕文档发生变化，文档发生变化是正常的，一开始的时候不知道最终做出来的东西是什么样的并不是不需要文档的借口。

正确的做法是每一步都有扎实的文档，并且当发现不对的时候就改变，并且时刻将改变更新到文档中去。

所以一不要怕变化，二变化之后要及时更新。

最后第三条：

敏捷迭代不需要文档？/有空写文档不如去实际开发功能？

大佬驳斥这一点的时候给出了一个例子：敏捷迭代中也是有计划的，这个东西叫Backlog（也就是待做事项列表），里面会有所有要做的内容以及任务的分配，整个团队要持续对这个待做事项列表进行维护，确保任何时点团队成员都知道完成整个项目还有多少内容要做。这个东西其实就是游戏设计文档。

在视频将近结尾的地方大佬又把敏捷迭代拿出来说了一遍，因此我把这段提前了也整理在了这里。

首先大佬表示，所谓的敏捷迭代在游戏行业中并不是什么新鲜东西，最早的雅达利的游戏基本都是靠敏捷迭代搞出来的。另外敏捷迭代和非敏捷迭代其实也没有特别大的区别，都要有功能的说明、功能的优先级、都注重于如何尽快实装、并且也都一直在用User Story（从玩家角度出发详细的描述一个玩家玩这个游戏的各种过程）或者Epic（从玩家的角度来出发描述如果能怎么样这个游戏会很牛逼）来提需求。而且，敏捷迭代还有一系列问题：

  • Backlog（待做事项列表）只有一大堆功能，但没有任何结构、图片说明和索引。
  • 上下文和链接都不容易理解。
  • 同时要维护待做事项列表、游戏设计文档是很累人的
  • 产品到底谁说了算？制作人？策划？老板？还是谁？

其实上面说的这四点我不太懂，因为我不太清楚真正的敏捷迭代是啥样的，但从过亲身经历我可以举个栗子说明一下，没有文档的日子过起来是什么样的：

  • 你要盖一栋10层的楼，你觉得很简单，盖完了。
  • 接下来接到了需求，要加盖10层。好，这没啥难的，因为你对1-10层熟悉得不得了，11-20层盖的很顺利。
  • 接下来的几个月你去做别的东西了，半年后老板要你回来，跟你说1-5层要改成商铺。你花了很大代价想起来了当年1-10层是怎么盖的，终于把1-5层改成商铺了。
  • 接下来要在房顶上加个游泳池。
  • 接下来要粉刷外部墙壁。
  • 接下来要在8层打通一个天桥连接到隔壁楼。
  • 接下来要给1-20层加装电梯，整个楼层都要打通一个电梯井。
  • 接下来要在房顶的游泳池下面做一个餐厅，屋顶要是透明的可以看见拥有池中的水。
  • 接下来要盖地下停车场。
  • 接下来要给1-20层加装空调，这会破坏你之前粉刷的墙壁。
  • 接下来要加盖21-30层，然后你才想起来现在20层的楼顶上还有个游泳池，并且下面还有个透明房顶的餐厅。
  • 并且21-30层都要有粉刷后的墙壁、电梯以及空调。

如果你没有一个时刻更新的最新文档的话，你觉得你能活到第几步？

讨论完了文档的必要性后进入第二话题：

文档是给谁写的？

这分为对内和对外两部分。对内：

  • 程序员
  • 其他策划
  • 美术（视觉与听觉）
  • QA

对外：

  • 老板或项目负责人，反正是你需要给个交代的大佬
  • 外包
  • 外部QA
  • 有的时候还包括媒体、品宣、市场等

那么我们给他们写文档看是为了达到什么目的？

  • 对要做什么样的东西达成共识（不管是对内还是对外）
  • 帮助团队聚焦（不管是对内还是对外）
  • 是预估工数、排优先级以及功能依赖性的基础
  • 是QA团队测试计划的基础，定义了什么样叫“做完了”
  • 是需求变更的基础

写文档的阶段

大佬讲一个文档的生命周期分为了五个阶段：

  • 愿景陈述
  • 高概念
  • 游戏设计文档（GDD）
  • 产品模块分解（PBS）
  • 详细开发文档

如文章开始所说，大佬的这个阶段划分也是按照典型的传统单机开发流程来写的，因此我会按照我的理解来将其转换为更接近与免费、长线游戏的版本。

愿景陈述和高概念两个阶段我会简单带过，重点在后面三个阶段。

愿景陈述阶段

愿景陈述的目的：

  • 与开发组达成共识
  • 一切所有后续文档的基础
  • 用来检验所有后续的文档是否偏离初衷
  • 永远是一篇游戏设计文档（GDD）的第一段或第一页
  • 定义整个游戏的核心精华体验

具体内容：

  • 最多1-2页
  • 从体验开始说
  • 核心玩法
  • 主要与次要游戏主题

大佬又举了个例子

《帝国时代》是一款历史题材的PC即时战略游戏，通过结合《魔兽争霸2》的RTS玩法与《文明》系列的历史与经济元素，体验地球上最初的文明的崛起。

我想说的是，上面这段例子写的非常牛逼，能写出这种例子的人，已经不是普通策划了。

愿景陈述这东西对于我们从业者来说其实很难经历到，因为我们一般都没有从头立项的资格与能力，但是我们可以吸收这一段的精华，将其转换为每一篇策划文档开头的设计目的，通过提纲挈领的方式快速写清整个文档要达成一种什么样的效果，可以让阅读的人判断后续的内容写的是否有偏离。

总之，任何一篇涉及到稍微大一点的功能的文档，都应该以这个作为开篇，即这篇文档说描述的功能要达成一种什么样的效果。

按照我的 【需求 -> 思路 -> 设计】三步来走的话，这步是第一步：确定目的。

  • 需求：我们要达到什么目的
  • 思路：我们通过哪些功能模块达到这个目的
  • 设计：这些功能模块具体是怎么运作的

当然如果拆的更细的话可以分为四步：

  • 需求：我们要达到什么目的
  • 思路：我们通过什么方式达到这个目的
  • 设计：我们通过提供哪些功能模块来实现上述思路
  • 实现：我们通过具体完成哪些工作可以完成上述设计

总之很灵活，但是要做的事情都是一样的。

高概念

高概念的目的：

  • 又叫设计草案、概念稿或提案圣经
  • 把产品卖出去的工具
  • 把你的点子展现给感兴趣的发行商
  • 为需要开发的内容定下目标
  • 定义目标群体、年龄、性别等
  • 最好和第一版原型同时提交

具体内容：

  • 最多10-20页
  • 核心特色与卖点
  • 核心玩法，早起、中期、后期玩法的展现
  • 线框图，原型与竞品
  • 目标受众群体，性别，市场信息，盈利手段
  • 研发团队说明

最后说明：

  • 什么时候来做高概念？——愿景陈述之后，提交给感兴趣的发行商之前。
  • 高概念是给谁看的？——对外给发行商，制作人或各种大佬看，对内给开发团队成员看。

我想说的是，能够把高概念阶段搞定的人已经不是一般的策划了，而是有立项能力的制作人了，关于制作人需要什么能力以我的水平来探讨有点力不从心，因此这段就简单略过了。

下面进入重头戏，第三部分：

游戏设计文档（GDD）

GDD的目的：

  • 描述所有主要的功能，愿景，质量，这样团队的开发成员能够大致判断各个模块的复杂度。
  • 游戏玩法与循环的说明，并列出游戏功能的优先级。
  • 规模要根据团队的开发能力来规定。
  • 量力而行，别贪多。
  • 保持简单、清晰。

具体内容：

  • 所有相关的游戏功能与玩法循环
  • 定义规模与品质要求
  • 说明美术风格需求
  • 关卡、世界观或主线剧情需求
  • 盈利手段，如果是免费游戏的话还有玩家分层规划
  • 一般不包括：具体公式、数值、设定、配表等等等等

最后说明：

  • 什么时候做GDD文档？——预生产阶段，就是规划项目计划、时间估算以及预算的时候。
  • GDD是给谁看的？——内部团队，要能确定时间估算，要生产的资产列表，以及进行风险评估等等。外部团队大佬以及主要的相关利益者也要能看到。

这部分内容对于我们的实际工作就有意义的多了，因为GDD已经描述了多有主要功能模块，而我们日常的工作其实就是在打磨一个个的工作模块。

按照我的【需求 -> 思路 -> 设计 】三步来走，这一步其实就是思路阶段。它不包含详细的开发用文档，但已经可以说明白每一个功能模块具体都要做什么了，因为开发团队已经可以拿着它来预估工数了。并且我们可以回头根据需求来判断，这个思路是否是解决需求的最好思路，或者说这个解决思路的代价我们能否接受。只有当我们确定了需求和思路都没问题的时候，进入详细设计阶段才有意义。

下面是第四个阶段：

产品模块分解（PBS）

PBS的目的：

  • 能够整体总览所有功能模块与资产
  • 包括敏捷迭代的全部内容
  • 后续计划与进度估算的根本
  • 有助于排优先级

具体做法：

  • 用脑图
  • 列出功能点
  • 列出资产
  • 列出技术
  • 不分解具体的任务，只写详细的功能描述
  • 不包括资源分配和依赖关系

最后说明：

  • 什么时候做PBS？——与GDD同步做，GDD开始的时候做，结束的时候一并结束
  • 给谁看的？——设计游戏的主要系统，PM，产品负责人

显然，PBS的作用是从宏观上辅助GDD的，因此当我们并不需要从宏观的角度出发，项目已经进入后续稳定的迭代阶段的时候，就不需要PBS了。

但是当我们制作一个复杂的大功能的时候，将其分解为各个模块是非常有必要的。由于在我们的策划团队中PM也是由策划担当的，但功能拆分并不是由策划来做的，而是策划给出详细设计文档后由程序和美术各自估算工数的，所以PBS在实践层面意义不大，或者说它本身就是GDD的一部分。

当我们功能过大的时候，学会用类似PBS的方式拆解功能是很关键的，也是PM的核心能力。

最后是第五部分：

详细开发文档

详细开发文档的目的：

  • 所有下次迭代相关的功能的非常详细的设计文档
  • 详细到什么程度算合适？要详细到可以拆解任务并且按照人时来分配任务的地步
  • 详细到会明确的列出所有要完成的内容的列表，因此完成全部列表里面的项目后就可以认为开发完成了
  • 包括所有的详细的公式、数值、配表等等
  • 应该与技术组或程序员紧密合作

具体内容：

  • 功能优先级（哪些是必做的，哪些是要做的，哪些是最好能做的）
  • 每个功能模块的竞争力（简单做做就好，还是要有一定竞争力，还是要另辟蹊径，甚至大幅革新）
  • 每个功能模块的大致目的
  • 实装一个功能的具体要完成的内容，用列表、用例甚至伪代码的方式来详细说明
  • 策划说明
  • 风险
  • 变动记录

最后说明：

  • 什么时候做？——正式开发阶段，每个迭代开始前
  • 给谁看的？——程序员与QA，大佬，以及外部QA

显然这段是非常干货的，就是【需求 -> 思路 -> 设计 -> 实现】阶段的最后一个阶段：实现了。因为前面说的一大堆都是前期设计阶段，这部分终于到了撰写用于实际开发的文档的阶段了，也就是大部分策划实际工作面临的内容，毕竟做一个游戏有创意的部分只占10%，剩下90%都是苦力活儿，而干好了这90%才有机会去做那10%。

那么如何才能写好一个详细开发文档？

分为几个方面：

  • 保证可读性
  • 可视化
  • 力求精准
  • 不惧怕改动
  • 及时更新

保证可读性

简短是高端的体现：

  • 保持简短，不要罗里吧嗦
  • 用列表写内容，不要写大段文本
  • 如果一个功能比较大，拆分成数个比较小的子功能
  • 避免冗余
  • 使用超链接，交叉引用，以及表格
  • 自己发明一套模板，并且坚持用下去


下面是大佬举的一个例子：

功能总览：

  • 这个小游戏会在屏幕上方显示4个不同颜色的容器。它们分别代表千，百，十与一（十进制）。
  • 容器上方会显示一道数学题。下方的触摸屏上会显示一条传送带，上面有不同颜色的圆球在运动。
  • 玩家必须用控制唱针“抓住”对应的球并把它们扔到对应对应的正确的容器中。
  • 玩家必须根据数学题的正确答案来为每个容器装入正确的数量的球。每个容器只能保存0至9个球。

功能实现：

  • 为了把正确的球放入正确的容器中，玩家必须用唱针指向被选中的球，并且持续按住唱针。
  • 然后圆球就“扎”在了唱针上，离开传送带随着唱针移动。
  • 玩家必须把唱针移动到正确的容器上然后“抖”一下唱针，这样球就会落入玩家的NDS的上面一块屏幕中的容器中。
  • 如果玩家在“抖”唱针之前就松开了唱针，圆球会掉落回传送带上。
  • 玩家必须持续的抓球放球，直到数学问题得到正确解答。当所有容器都被填上了正确的球的时候，程序要能自动判断已经回答正确了。
  • 在这种情况下屏幕上会播放一种视觉反馈，以及一个积极的音效，来告诉玩家他赢了。

可视化

一图胜千言：

  • 尽可能的通过可视化的方式来说明功能，做原型也好，做界面迁移图也好
  • 找其他游戏或电影或各种媒体的例子来说明你的功能
  • 可视化的工具：PPT，Visio
  • 注意：不要抢UI设计师或美术的活儿，你做的东西只是用来说明功能的
  • 不要越俎代庖告诉别人怎么做他们的工作

几种可视化的例子：

原型（Prototype）
界面迁移图（Menu -Flow）
不知道Click-Dummy咋翻译，我觉得这里大概说的就是线框图（Wireframe）

力求精准

你的陈述应该要么是“YES”要么是“NO”：

  • 别用“可能”，“也许”这种词
  • 别用“我们”这个词
  • 别光顾着说玩家能做什么，同时也要说清楚玩家不能做什么
  • 别假设你的读者精通各种缩写（如DOT、AOE啥的）

不惧怕改动

好产品都是改出来的：

  • 记住，允许计划变动不是你不写文档的借口
  • 拥抱改变：根据反馈来强化、迭代你的设计
  • 只有通过清晰的文档，才能评估方案改变的工数影响
  • 所有功能都要写好变更记录
  • 每次修改的时候都写明白修改的原因，否则半年之后又会有人把这个问题拉出来讨论一遍

及时更新

  • 时刻保证文档是最新的
  • 别用离线的文本管理方式，那样每个人手里都会有一份不同的文档，并且没人知道最新的是什么
  • 所有文档都必须纳入版本管理中
  • 用好Wiki，谷歌文档之类的工具

最佳实践

到上面就说完了如何写游戏详细设计文档，最后一个环节是大佬分享了自己的其他建议，分为七个部分：

  • 边玩边做
  • 别怕砍功能
  • 管理好需求变更
  • Story Mapping
  • 其他策划工具推荐
  • 其他忠告
  • 扩展阅读

边玩边做

  • 和团队成员定期玩自己做的游戏
  • 当游戏进入可玩阶段后，至少一周一次勇于批评，勇于接受批评
  • 时刻保持接受外部反馈

别怕砍功能

  • 做的玩意不行——砍掉！
  • 德国设计师（做加法）vs美国设计师（做减法），做后者！
  • 小心功能膨胀
  • “没东西可加了不是完美，没东西可减了才是完美”

管理好需求变更

  • 确保工作流程中有对应的环节是允许需求变更的
  • 确保需求变更针对于你游戏的核心特色是有益的
  • 确保需求变更是通过一个正式的流程来通过或被否决的
  • 所有需求变更都做好变更日志，不管是通过了的还是否决了的

Story Mapping

大佬丢了个链接来说明啥叫Story Mapping：

http://www.thoughtworks.com/de/insights/blog/story-mapping-visual-way-building-product-backlog

并且还配了个例子的图：

但我还是没看懂。不过我觉得Story Mapping归根结底是管理需求的一种手段，具体咋用我没看懂，所以这段跳过。

其他策划工具推荐

  • 脑图工具，比如Xmind或者Mind Manager
  • Trello（用来跟踪美术资产开发进度比较有用）
  • PPT，Visio，Balsamiq，甚至铅笔来做线框图
  • 用来放设计文档的Wiki（比如Confluence）
  • 谷歌文档（国内就别想了）

其他忠告

  • 在预开发阶段做多迭代，而不是已经开发了频繁改动
  • 设计原型越早、越多越好，能运行的原型永远比纸面上的文档强
  • 先做最重要也是最有风险的部分
  • 勿忘初心：你是最终为体验是否有趣负责的人
  • 如果确定要改动内容，在交付实际开发之前，先跟大佬打好招呼……说白了就是不要私自改动设计！

扩展阅读

  • 如何写游戏设计文档：
http://www.zenofdesign.com/wp-content/uploads/2014/12/Writing_Design_Docs_2008.pdf
  • Story Mapping：链接我前面贴过了这里不重复了
  • 400 Project（需科学上网）：
http://www.finitearts.com/pages/400page.html
  • 游戏策划的五个规则：
http://www.gamesauce.biz/2010/09/07/bruce-shelleys-five-rulessteps-for-a-game-design%E2%80%99s-first-draft/
  • 游戏怎样才能屌（我试了没打开，科学上网也没用）：
http://pixelpaton.com/?p=3385
分类
游戏设计

主属性脑洞

我一直在追求一套能够描述所有流行文化中主流的战斗方式的主属性系统，这是达成我的目标——设计一款包含所有流行文化中常见的战斗方式的游戏的根本。

为了做到这一点，我决定首先分析一下其他游戏是怎么做的，那么第一款应该拿出来说的，也是我产生我想要设计一款前面提到的游戏的根本原因，还是POE，它的主属性采用了传统的“力敏智”三元设计：

  • 力量，决定近战伤害的能力与生命值
  • 敏捷，决定了远程物理伤害的能力与闪避
  • 智力，决定了法术伤害的能力与护盾

这三元设计是非常重要的一部分，甚至很大程度上主宰了POE的诸多设计思路，比如他的职业设计就是由三种主属性设计延伸而来的：

  • 力量职业：野蛮人
  • 敏捷职业：弓箭手
  • 智力职业：女巫
  • 力量+敏捷职业：决斗者
  • 力量+智力职业：圣堂武僧
  • 智力+敏捷职业：刺客
  • 力量+敏捷+智力职业：白富美

然而POE存在一个问题，也是相当多的剑与魔法RPG存在的问题，即远程物理职业定位的尴尬。POE在“力敏智”三元设计之外，还采用了“剑与魔法”的二元设计，这也是《暗黑破坏神2》的设计，在POE的提现中为“攻击”与“法术”的二元设计，以及“物理伤害”与“元素伤害”的二元设计。

当“力敏智”三元设计与“剑与魔法”二元设计碰到一起发生了的是什么呢？最典型的结果就是圣堂武僧，这是一个力量与智力混合的职业，因此理论上来说其特色是拥有大量元素伤害的攻击型角色。但实际玩的时候玩家很快就会发现，原来野蛮人和决斗者也是有着大量元素伤害的，因此有着元素伤害的攻击型角色并不是圣堂武僧的专利。当然，这是大大扩充了POE的可玩性的，是值得学习的地方，但熟悉了游戏机制的玩家会发现职业之间的不同之处并没没有那么大，因此可以说虽然职业的设计是由“力敏智”三元设计延伸出来的，但从游戏机制上关系已经不大了。

我们会发现，“力敏智”三元设计元素有很多种战斗方式是无法进行描述的，这并不是POE的问题，因为POE的世界观整体框架是与《暗黑破坏神2》一脉相承的暗黑幻想，在这个剑与魔法的世界观下三元设计够用了，但如果想要实现我说想的“能够描述所有流行文化中主流的战斗方式的主属性系统”，可能这还不够。

不够的话我们是否可以加入一些？

啊哈，聪明的你可能会立刻举手说，“我们不妨看一眼D&D的六个主属性都是什么呀！”没错，我也是这么想的。D&D的六个主属性除了力敏智之外，还有一个体格，一个感知，一个魅力。体格是没用的，POE移除了体格是个非常正确的设计，因为《暗黑破坏神2》中加点的方式就是主属性够穿装备就行其他都加体格。体格的问题是他是一个完全防御向的属性，而“力敏智”三个属性一般都是攻击向的。在战斗节奏比回合制的D&D快无数倍的ARPG中，将进攻和防御属性合并在同一个主属性中的POE是非常聪明的，因此我也决定研习他们的设计思路。

D&D的感知是很有用的，它描述的是角色洞察的能力、常识、意志力和直觉。其实这描述的是三个方面，但是我发现洞察能力和直觉是同一个能力，但意志力是完全无关的一个能力，而常识又是另外一个不相干的能力。

用番茄说明D&D的六个属性

如果只考察“直觉和洞察能力”这一面，有点类似于感官的敏锐程度。在克苏里题材的游戏中，人物的敏感性是一个很主要的属性，因为越敏感的人越容易感知到克总，因此艺术家、精神病都是最先成为克总使徒的人。对于重点在于描述战斗而不是冒险和解密的ARPG中，感知的作用就大幅削弱了，因为当我们只考察“敏锐”在作战方面的表现的话，会发现很大程度上它和“敏捷”是重叠的。

如果只考察“意志力”这一面，有一个类似的游戏《洛奇》是有意志这个属性的，他的效果是提高暴击率，并且在受到致命伤害时降低致死的几率，而是变为空血的“重伤”状态，在游戏机制上来说玩家这个时间角色依然没有死亡可以正常行动，但是生命值是负值，必须通过治疗手段恢复成正直才能不死。在这个情况下如果再次受到伤害则会直接死亡。

如果只考察“常识检测”一面，就像上面的番茄里面的图一样，与ARPG的战斗系统没有任何关系，因此可以无视了。

这时候我觉得不妨跳出来传统的“力敏智”与“剑与魔法”设计，看看别的游戏是怎么做的。这时候我想到了《激战2》。《激战2》中有4个主属性：

  • 力量，增加直接伤害
  • 精准，增加暴击几率
  • 坚强，增加护甲
  • 活力，增加生命

然后他还有5个次要属性：

  • 专注，增加buff持续时间
  • 状态伤害，增加debuff伤害
  • 专精，增加debuff持续时间
  • 凶狠，增加暴击伤害
  • 治愈力，增加加血能力

从以上我们能分析出来，《激战2》大体的设计思路分为直接伤害型选手，主要输出属性为力量精准凶狠，间接伤害型选手，主要输出属性为状态伤害和专精，然后应该是还有一种辅助选手，主属性是专注和治愈力，同时玩家又要兼顾坚强和活力。

《激战》在设计思路上是非常重视BUFF与DEBUFF的，这时候我又想起了另外一个游戏《恐怖黎明》，在设计思路上是严格区分了“直接伤害”与“持续性伤害”的，可以说这一点与《激战》的设计不谋而合。

所以经过了这么一番折腾之后，我在想如果引入这两个游戏的效果是什么样：

感知作用是增加持续伤害能力，同时减弱受到的DEBUFF伤害与持续性伤害。

意志的作用是增加BUFF的效果，同时受到致命伤害时一定几率免死，即增加了玩家的有效生命值。

如果再采用DND的九宫格来区分的话，我们会有一个明显的倾向：意志偏向于守序、神圣，智力偏向于中立， 感知偏向于混乱、邪恶。我们可以发现，这五个主属性似乎是可以和《万智牌》的五种颜色对应上的：

  • 力量——红，山脉
  • 敏捷——绿，丛林
  • 智力——蓝，海洋
  • 感知——黑，沼泽
  • 意志——白，平原

这样一来，我们是否可以像POE一样也通过主属性的复合来设计一些职业就很容易了，因为万智牌本身就已经存在着相当多的杂色卡了：

  • 力量，依然是野蛮人
  • 敏捷，依然是弓手
  • 智力，是法师，更类似于《魔兽世界》的法师
  • 感知，是术士，更类似于《魔兽世界》的术士
  • 意志，是牧师、圣人、天使
  • 力量+敏捷，依然是决斗者
  • 力量+智力，是魔法骑士、战斗法师，更类似于JPRG的魔剑士
  • 力量+感知，是死亡骑士，类似于《魔兽争霸3》的DK与憎恶一类的生物，或者《指环王》中的戒灵
  • 力量+意志，是圣堂武士、十字军或武僧，是近战的圣职者
  • 敏捷+智力，是猎魔人、牛仔、赏金猎人
  • 敏捷+感知，是恶魔猎手、邪教徒、虚空杀手、刺客、忍者
  • 敏捷+意志，是忍者、审判官、法师杀手
  • 智力+感知，是神秘学者、奥术师
  • 智力+意志，是图书管理员、贤者、《权力的游戏》中的学者
  • 感知+意志，是背信僧、堕天使

如果我们把这套东西转化成科幻世界观下的东西……也就是DC和漫威的东西，又会得到什么？（不考虑其中的各种挂逼级角色，只考虑主流角色）

  • 力量：代表人物是绿巨人、格鲁特、神奇四侠的石头人
  • 敏捷：代表人物是鹰眼（闪电侠应该算挂逼级角色吧……）
  • 智力：代表人物是钢铁侠、神奇四侠的大佬
  • 感知：代表人物是红女巫
  • 意志：代表人物是X教授
  • 力量+敏捷，代表人物是金刚狼
  • 力量+智力，代表人物是雷神
  • 力量+感知，邪恶的力量型角色，主角不多反派倒是挺多，主角也就一个德拉克斯吧
  • 力量+意志，代表人物是美国队长
  • 敏捷+智力，代表人物是火箭浣熊、黑豹、蜘蛛侠、 黑寡妇（万金油放哪都差不多）
  • 敏捷+感知，代表人物是死侍、勇度、星爵、卡魔拉（怎么这么多银河护卫队的）
  • 敏捷+意志，代表人物是蝙蝠侠、绿灯侠
  • 智力+感知，代表人物是暴风女、凤凰女（怎么这么多X战警的）
  • 智力+意志，代表人物是幻视、神盾局长、奇异博士
  • 感知+意志，大量亦正亦邪的角色，代表人物是洛基、万磁王、曼哈顿博士

这样的脑洞目前看来没啥实践意义，但对于POE这种经历了几年的更新后已经趋近于没啥新东西可做的游戏来说，开一个新的维度也许是一个让游戏能再续上好多年的好手段。