如何写游戏策划文档?

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

不过如果你翻不了墙也没关系,接下来我会把每一页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

干死玄学策划:Why与How

这篇文章AT君一直想写,趁着这周双休来写一下(其实是因为八月只写了一篇博客,要抓住八月份的尾巴!)。

标题《干死玄学策划:Why与How》说明了文章的两部分:第一部分:为啥要干死玄学策划,第二部分:如何干死玄学策划。下面正式开始!

为啥要干死玄学策划

既然要反对玄学,那么首先就要说明一下什么是玄学,AT君由于并不喜欢讨论玄学内容,因此理解比较粗浅,在我的理解中,凡是出现过下面两个图的现象的策划,就是玄学策划

这两个图总结下来就是两方面的问题:

  • 感觉某个东西不对,但说不出来问题在哪。(上图)
  • 知道某个东西好,但说不出来好在哪。(下图)

这两个问题在策划的工作中可以说是致命的,这个致命体现在两方面:

  • 在策划的内部交流中,谁也无法说服谁,一个觉得主角叫张三好,一个觉得叫李四好,撕逼撕一宿也没有结果;
  • 在和外部的交流的过程中,无法给出其他人(主要是美术,其次是程序)要删改某些功能的理由,只是强调“这么改绝对更好”,这句话的可信程度基本等于“我半藏玩的贼6”,在其他部门中的声望变成仇恨。

AT君认为,策划这个职业最重要的两个属性是能力(个人策划力)魅力(团队靠谱力),想要走得远要两条腿抓两条腿都要粗。由于国内没啥像样的教育机构,因此几乎没有科班出身的策划,所有策划(AT君并不是针对某个人,而是指在座的各位,包括我自己)多多少少都有些玄学。玄学策划在能力方面一般都是值得肯定的,都有比较强的判断能力,自身的底子不会太薄,但玄学策划普遍无法说服别人,茶壶煮饺子,会被其它人恨,魅力约等于0,团队中人人都想弄死策划,所以玄学策划等于被打断了一条腿,另一条腿再粗也是个残疾

AT君认为,玄学策划的问题的根本在于,缺乏把自己的判断力总结成规范化的原则与方法的能力。

缺乏这种能力的话,对内来说,玄学策划只能授人鱼不能授人渔,如果新人策划跟着玄学策划学本事,就真的只能“师傅领进门修行在个人”,只能靠自己的悟性从工作中总结经验,手把手的跟着学,从受到的“鱼”中自己领悟“渔”,而这种策划多了,就更会觉得策划本身就是这么一个特别有禅意、特别讲究顿悟的职业,有经验的老司机们都这么玄,那我自然也要尽快地变得更加玄才行,从而产生更多的玄学策划,陷入一种恶性循环;而实际上,策划和木匠、厨子没啥区别,并没有多少禅意在里面,一点都不玄。

对外来说,由于缺乏高屋建瓴的能力,往往其他部门的人(尤其是美术)做了很多工作了回头被一句“感觉不对”噎死,而更大的问题是改倒是不怕,但不知道要往什么方向改,玄学策划往往会丢出“要大气”,“要有《满江红》的感觉”,鬼他妈知道《满江红》什么感觉?一千人有一千个林黛玉,是不是也有一千个《满江红》?要求其他人也靠悟性和感性去理解自己的玄学需求,是一种极不负责任的做法,很容易做完了又被说“感觉不对”,浪费了大量的试错时间,美术要加班,策划要陪着,项目要延误。因此,玄学策划害人不浅。

最后一个问题是,玄学策划久而久之会陷入一个巨大的幻象中,就是自己总是怀才不遇的,为啥会这样呢?因为玄学无法向别人证明自己屌不屌,在无法证明的前提下人总是会觉得自己是屌的——没人愿意承认自己是个傻逼,心理防御机制就是这样的,人性弱点,所以策划普遍是骄傲的。你要问玄学策划们为啥干了这么多年工作还没有一个很屌的成果来证明自己,他们会说玩家都是傻逼,美术画的太他妈烂,程序代码一坨翔,投资人是煤老板,老板瞎鸡巴改等等理由,反正理由不在自己身上,因为老子特别的玄,你们这帮傻逼都不懂。

这就是AT君对玄学策划的理解,以及为啥要干死玄学策划的理由。

如何干死玄学策划

那么咋才能不玄学呢?也就是说,咋才能获得把自己的判断力总结成规范化的原则与方法的能力呢?由于AT君也是一个以玄起家的策划,并没有什么权威性的答案,只能说说自己的理解,一家之言仅供参考。

AT君认为策划要摆脱玄学,要做到以下三点:

  1. 意识到自己的倾向性;
  2. 懂基本的美术设计原理;
  3. 懂编程的基本原理。

从下往上说,更容易一些。第三点,懂编程的基本原理,这个不难,学写代码就行了,如果不知道该学啥,就学VBA,总是没错的,一定能用上,能把VBA用的贼6,跟程序打交道就不成问题了,而且什么东西技术上能实现什么东西技术上实现不了,基本都能心里有数。

第二点,懂基本的美术和设计原理,这个看起来好像比起农代码更玄一些了,因为美术这东西你懂的,感性,艺术家,blahblahblah,其实都是扯淡,第二点的关键是以设计师的眼光去看待游戏,而不是以艺术家的眼光。艺术家很玄学,而设计师跟上面说的木匠厨子一样,一点都不玄。那么设计师咋入门?AT君的建议是看锤子设计师罗子雄的TED演讲(虽然最近网传他已经离职了),我经常把这个视频拿出来反复观看,因为这种直接告诉你可操作的方法的超级干货视频是非常少见的:

http://open.163.com/movie/2015/7/B/M/MATL76APV_MATL8FCBM.html

除了这个视频以外,AT君还建议多看各种为游戏美术从业人员提供的教学视频,作为策划不是去学技术的,而去学思想和方法的,这是非常关键的,能出来讲课的老师,基本都是脱离了玄学美术(是的,和策划一样,美术也有“玄学美术”)水平的,能达到这种水平的都是能授人渔的美术的,多看一些,能大幅提高和美术进行沟通的效率,封印自己的“感觉不对”大招。AT君最近就一直在看腾讯的GAD的美术讲座,感觉受益良多(妈的腾讯是不是该给我广告费)。总之,第二点一点都不玄,除了设计方面的基本常识以外,还要懂技术美术方面的常识,如序列帧动画的原理,骨骼动画的原理,法线贴图的原理,PBR材质的原理等等,玄吗?闹太套。

最后,第一点,意识到自己的倾向性,这个非常关键,但也是最玄的,因为这玩意等同于策划的心法。曾经有一本游戏设计书,把这一段描写成策划要进入一种冥想的状态,在玩游戏的时候,脑子里还有另外一个自己在观察自己的心路历程,什么时候自己感到好玩,什么时候感到无趣,也就是说,不再是以单纯的玩家在玩游戏,而是在以设计师的角度来品游戏。这个太玄了,因此AT君更建议用“干死玄学策划口诀”来代替这个神秘的冥想:

  • 萝卜青菜,各有所爱;
  • 萝卜青菜,各有所爱;
  • 萝卜青菜,各有所爱。

重要的口诀念三遍。比如AT君非常不爱玩三消游戏,玩起来简直是味同嚼蜡,如果是Ego膨胀的没边的玄学AT君会认为这种游戏都是垃圾,爱玩的都是傻逼,从King公司离职去做《MineCraft》的Markus Persson才是具有Real Gamer Soul的Hardcore Indie Developer(为了装逼此处用英文),然而事实并不是如此——事实只是萝卜青菜各有所爱罢了。反过来讲也一样,比如暴雪脑残粉玄学AT君会觉得《魔兽世界》太他妈好玩了,玩起来觉得没意思的人都是傻逼,和他们说话简直会被传染上傻逼细菌,而事实也并不是如此——事实只是萝卜青菜各有所爱罢了。而对三消游戏恨之入骨的玄学AT君却发现《骑士故事》、《战神的挑战》这种三消居然很好玩,那么AT君就要接下来想是不是因为加入了战斗元素使自己这种不爱玩三消的人开始变得喜欢玩三消的?意识到自己爱玩什么类型的游戏,不爱玩什么类型的游戏,尤其是那些爱玩自己不爱玩的类型的游戏的玩家为什么爱玩这些游戏的原因,是“萝卜青菜”口诀的关键。

学会了第一段口诀后,再学“干死玄学策划口诀·其二”

  • 不要吹毛求疵,要去芜存菁;
  • 不要吹毛求疵,要去芜存菁;
  • 不要吹毛求疵,要去芜存菁。

具体一点来说就是,只盯着毛病看的人,成长的非常慢,而从差劲的作品中都能学习到的人,才是成长快的人。比如大喷子玄学AT君在玩一个非常垃圾的游戏(这个游戏真的很垃圾),觉得这个游戏太他妈烂了,简直就是一坨翔,从而直接枪毙了该游戏,觉得这个游戏没有任何值得学习的地方,但却没发现这个游戏的TIP是动态的,按屏幕的左半边TIP会在右面出现,按屏幕的右半边TIP会在左侧出现,总是不会挡住的,而自己做的游戏怎么按TIP都在屏幕中间经常被自己的手指挡住;

最后,“干死玄学策划口诀·其三”:

  • 知其然没意义,知其所以然才有意义;
  • 知其然没意义,知其所以然才有意义;
  • 知其然没意义,知其所以然才有意义。

比如,面对着一个并不是很靠谱的策划案,暴乱狂策划玄学AT君咆哮着喊不行,这个案不好,而压根不想去理解提出这个案的背后的想法和动机是什么,要达到什么目的,是否达到了这个目的,是否会引出其他问题,是否解决了最初的需求等等,这些连想都没想就掀桌了,这还是在靠“棒喝”去让人顿悟的玄学做法,特别low。再比如,大喷子玄学AT君策划觉得首充界面放一个大美女实在是太他妈的low了,却没想想为啥要这么做,只是因为别人这么做自己也跟着这么做,典型的知其然不知其所以然。再比如,暴雪脑残黑AT君觉得《炉石传说》攻打暴风城的这个乱斗太他妈无聊了,简直是一坨屎,每回合变的数值更高的暴风城杂兵这也叫设计?却忽略了这个模式通过这个机制做到了菜鸡玩家必有一赢可以来随便刷钱,高手玩家可以来挑战自我的设计结果。如果暴雪脑残黑AT君能意识到这一点,并且尝试设计一个能达到同样设计结果的更优秀、更好玩的模式,那才是靠谱的策划,脱离了玄学的策划,一个有益于所有人的策划。

面向体验的设计与面向用户的设计

这篇文章所要探讨的是,在我们设计一款游戏的时候,我们到底如何判断各种idea是否符合我们的目的?或者说我们到底是如何产生这个目的的?

这是一个很抽象的东西,但举起例子来又很具体——大家都知道《口袋妖怪》中不会出现烟酒、脏话、暴力等元素,让任何一个人去做续作,他都会清楚出现这些东西就意味着砸招牌。那么到底是什么来决定了《口袋妖怪》之所以成为《口袋妖怪》的呢?

我们暂时抛下这个问题不管,先让AT君先解释一下本文标题的含义。所谓面向体验的含义就是,“我们要设计一款提供XXXXXX这种体验的游戏”,而面向用户的设计的含义就是,“我们要设计一个XXXXX用户群喜欢的游戏”。这两种设计思路并非完全对立,但大部分时候在面对项目组其他人的质疑的时候,你都必须要进行解释为什么做某些事情是必要的,而最根本的解释无非是以上两个中的某一个。

大家都知道,《口袋妖怪》之父田尻智的初衷是为了满足自己儿时森林冒险,捕捉昆虫,然后与同学交换昆虫的梦想。也就是说,这是一个典型的“面向体验的设计”。绝大多数游戏设计师们都有喜爱设计自己喜爱的游戏类型的倾向,因为他们往往自己就能代表目标群体,《口袋妖怪》显然就是这种设计思路下诞生的游戏。

但《游戏设计基础》一书的作者Ernest Adams认为,这种做法并不够专业,因为我们作为专业的游戏设计师,往往要设计一些并不是自己非常喜爱或擅长的类型的游戏,在这种情况下难道我们还能撂挑子不干了不成?

Ernest Adams还举出了一个看似非常有说服力的例子:儿童游戏。大家都知道,游戏设计师都是成年人,儿童是不可能自己为自己设计游戏的,因此儿童游戏的存在正说明了“面向用户的设计”的威力——成功的游戏设计师能够为自己绝对代表不了的目标群体来设计游戏。

但实际上,AT君认为这个例子站不住脚,那些成功的儿童游戏,实际上还是“面向体验的设计”所产生的结果,也就是说出色的儿童游戏设计师,要么是在基于自己的童年经历设计游戏,要么是自己已经是有很丰富育儿经验的父母,他们还是在基于个人的经历来判断这些体验是否是适合儿童的——说白了还是在为童年的自己或自己的孩子来设计游戏!

而当我们在很深的层面上理解了目标用户底层的心理需求的时候,我们就并不在是为了冷冰冰、抽象而又远在天边的用户群体来设计游戏,而是在基于体验设计游戏了。

抛离了体验的“面向用户的设计”很容易产生爆米花大片,用战术上的勤劳来掩盖战略上的懒惰,因为当主创人员并不知道到底要为目标用户提供什么体验的时候,就只能挑一些俗气的手段来提高品质。比如我们要制作一款以男性青年为目标群体的游戏,那么偷懒的做法就是放好多美女,因为男性青年必然是绝大多数都喜欢美女的,我的这个决策可以让所有抱有不满意见的同事闭嘴,但所有人内心深处都是鄙视这种做法的,并且知道这样做绝对产生不了最顶级的大作。这些游戏实际上并不是在提供体验,而是在利用人性弱点来让自己的游戏数据更好看而已,加美女,加赌博,加炫耀性内容,加各种让人产生虚假满足感的内容,这样的游戏会让人觉得空虚。AT君并不是在批评这种做法不好,人人都喜欢美女这不错,《守望先锋》中毕竟也都是屁股,但我们也都清楚,只靠屁股是诞生不了大作的。

也就是说,所谓的“面向用户的设计”,依然会分为两种,高级的一种是设计人员会把目标群体想要的体验内化然后再创作,就像那些深得人心的广告一样,明白什么能打动用户;而低级的一种就是以数据为指导的懒惰做法。SuperCell的主创人员认为,游戏数据只能用来证明你的改动是否成功,却永远无法作为改动设计的依据。AT君也在秉持着相同的观念。

再说回游戏设计师身上,一个好的游戏设计师必须要意识到自己的倾向性,意识到自己终究是有所擅长有所不擅长的。大家都知道席德梅尔擅长设计策略游戏和模拟游戏,那么如果让他去设计格斗游戏或者FPS游戏,失败的几率是非常高的。

因此,我反对Ernest Adams那种所谓的专业性论调,这种作品终究会由于缺乏灵魂而让人感到失望。让游戏设计师专注一个自己擅长的领域并且深钻下去,才是更靠谱的做法。比如笔者AT君完全不明白三消游戏有什么好玩的,因此显然我并不适合King这种专门做三消的公司。这并不是说三消这种游戏不好玩,只是我明确的意识到了自己的口味是完全无法代替目标用户的,就算赶鸭子上架让我拙劣的模仿一款三消游戏,最终做出来的东西也很有可能是东施效颦。

然而,这也并不是说游戏设计要上升到玄学的角度。《东京玩具箱》的主人公是一个游戏设计师,漫画中的他会经常说“我的灵魂感觉还不够”之类的脑残发言,并且在最终的加班关头靠灵光一闪想出来的绝妙点子让游戏的品质大幅提升——而那只是漫画而已。实际的游戏设计中,这种灵光一闪所占的比例实在是太少了,绝大多数实际上都是科学方法诞生出来的设计。希望各位策划新人们不要走了邪路,玄学害人!

AT君的被动技能概论

大家好我是AT君,这篇文章起因是用来探讨塔防游戏的设计思路的,但有着更广泛的应用,在很多游戏如MOBA或ARPG中,当技能愈发变得复杂的时候,一个技能的效果往往是多元的,我们如何把握技能的复杂度,是本文想要探讨的。本文仅仅探讨被动技能,但被动技能实际上只是少了玩家操作水平以及消耗资源两个维度的主动技能——即【永远自动施放】的【无消耗】技能,因此它更适合作为探讨技能的切入点,而且也更适合塔防游戏,因为玩家能够主动操作的内容并不多。当然,也更适合挂机游戏!^o^

本文会同时从两个维度来探讨被动技能——机制复杂度,以及技能设计的定位和意义。下面就正式开讲,首先是最简单的被动技能:

A级:基础数值型

基础数值型技能的特点是发挥稳定,因为它涉及最核心的游戏机制运算,几乎不受外部环境影响,或者即时在受外部环境影响的情况下,依然能够发挥稳定。下面是一些例子:

  1. 火焰伤害提高10%
  2. 攻击速度提高10%
  3. 攻击范围提高10%
  4. 暴击率+5%
  5. 力量+5
  6. 护甲提高10%

这些技能与其说是技能,不如说是装备属性,然而也确实有很多技能只是对基础属性作出调整,就已经产生了足够强大的效果。

基础数值型也可以造成很多很神奇的效果(我们不妨叫他们为A+级技能),这一般是对某些特殊的变量(一般是百分比型变量和布尔型变量)进行极端的变化导致的:

  1. 你能够穿过敌人(碰撞体积降低至0)
  2. 变成飞行单位(修改了单位的移动类型)
  3. 你不会被淹死(水中呼吸时间长度无限)
  4. 你不会被摔死(下落最大速度降低至某个安全的值)
  5. 物理无敌(物理抗性提高至100%)

由于A级技能发挥稳定,因此它几乎不会影响玩家的策略或选择,因为一般只是单纯的堆属性,或者在弥补自己较弱的属性,就像《魔兽世界》一样,毕业后先把某个属性堆够指标再去追求其他属性即可,所以基本是没有策略性的。

B级:转化数值型

转化数值型与基础数值型的区别是,前者是需要动态计算的,而后者是静态不变的。数值转化型的特点是将某一数值进行简单的运算后,赋值在另一个数值上,虽然是动态的,但效果一般都是永久或瞬间的,机制简单。

  1. 造成的伤害3%转化为生命值
  2. 降低受到的伤害至最高10点
  3. 造成致命一击时,恢复5%最大生命值
  4. 每损失1%生命值,提高1%攻击速度
  5. 每损失1%魔法值,提高1%魔法恢复速度
  6. 每增加40点额外生命,提高1点法术伤害
  7. 每1.4点法术伤害,提高1点生命值

这些都是数值转化型的很好例子。B级技能都没有比较复杂的触发条件,因而也几乎不会影响玩家的策略和选择,和A级技能一样属性自然是越高越好。如果B级技能加上比较复杂的触发条件,就会变成下一段落的技能:

C级:动态数值型

C级动态型指的是在某个事件发生或者达到某个需要判断条件时,才会改变单位数值的一种技能。相比之下B级技能只是根据一个变量来计算另一个变量,而C级技能生效条件更复杂,发挥更加不稳定,带来的效果一般也更强大,因而比起B级会更大程度上地影响玩家的策略或行为,而不像B级技能一样依然和A级一样是多多益善,这可以成为区分B级和C级技能的分水岭。下面是一些例子:

  1. 造成致命伤害时,恢复5%最大生命值
  2. 每击杀一个敌人,伤害永久+1
  3. 濒死时,移动速度提高50%
  4. 开宝箱时,伤害提高30%,持续10秒
  5. 脱离战斗8秒后,每秒恢复1%最大生命值
  6. 10码内每有一个敌人,伤害提高4%
  7. 10码内每有敌人时,伤害提高20%
  8. 每过1秒暴击率提高4%,造成暴击1秒后效果消失
  9. 每攻击3次,你的下次攻击伤害提高50%

注意5,它增加了一个持续时间的概念,A级和B级技能由于都是持续生效或瞬间的而没有这个概念。我们会发现,由于5号技能持续时间的加入,C级技能更加类似于BUFF的概念了。

注意6和7,他们实际上是有一个类似于“叠加层数”的概念的,下一段会对这种技能进行进一步分析。

8和9是这种技能的最复杂形态,我们需要很多机制来描述一个BUFF,才能实现8和9这种技能,这些机制可以分为三部分:

BUFF的产生

  • 导致BUFF层数增加的事件
  • 每当事件发生时进行叠加的概率
  • 每当事件发生时,距离上次事件发生要求的最小时间(即增加层数的内置CD)
  • 每当事件发生时叠加的层数
  • 每当事件发生时对BUFF剩余持续时间的修正值
  • 每当事件发生导致BUFF层数满足某个表达式时,修改另一个BUFF的层数

BUFF的效果

  • 单层效果
  • 最大叠加层数
  • 最大持续时间

BUFF的消失

  • 导致BUFF层数减少的事件
  • 每次事件发生时进行减少的概率
  • 每当事件发生时,距离上次事件发生要求的最小时间(即减少层数的内置CD)
  • 每当事件发生时减少的层数
  • 每当事件发生时对BUFF剩余持续时间的修正值
  • 每当事件发生导致BUFF层数满足某个表达式时,修改另一个BUFF的层数

注意,BUFF的产生和BUFF的消失可以有多个事件,即我们可以配置复数个BUFF的产生规则,以及复数个BUFF消失规则,比如《英雄联盟》的电刀,在移动时和攻击时都会增加叠加层数。有了这套规则集,我们就可以用来描述技能8和9的效果了:

技能8:

  • BUFF-A:每过1秒叠加1层BUFF,BUFF的单层效果是+4%暴击率,持续时间无限,最大叠加层数25。
  • BUFF-B:产生暴击时,叠加1层BUFF,叠加事件有1秒的内置CD,BUFF效果什么也没有,最大叠加层数为1,1秒钟后清空所有BUFF-B,当BUFF-B层数由于减少而降低至0时,清空BUFF-A的层数。

技能9:

  • BUFF-A:每次攻击/造成伤害时叠加1层BUFF,BUFF效果什么也没有,最大叠加层数为3,当由于叠加而导致层数大于等于3时,设置BUFF-B的层数为1层,没有消失条件。
  • BUFF-B:单层效果为伤害提高50%,最大叠加层数为1,层数消减事件为发动攻击/造成伤害,消减层数为全部,当层数由于消减而降低至0时,清空BUFF-A的层数。

以上只是两个例子,具体的执行逻辑还需要更细节的设计,但总的来说就是这个思路。这里不建议把BUFF-B的增加条件设置为BUFF-A的层数变动,建议BUFF-A的层数变动时去调BUFF-B,个人认为这大概符合“I will call you, you don’t call me”的原则,但由于我不懂程序,具体还是需要和程序大大们商量的。

利用这种BUFF机制我们可以制作出非常复杂的技能,比如《英雄联盟》的电刀,然而要注意这种技能是否有意义。上面的技能8,我个人认为这种机制非常复杂但只对一个数值进行操作的技能一般来说是没有什么意义的(就说你呢《暗黑破坏神3》),它的效果几乎可以被下面这个技能代替:

  • 你的下次攻击必定暴击,这个特效有10秒CD。

诚然在数值上他们不是等价的,但我宁愿用后面这个技能,他更可控,更能预期技能的效果,也就是说他会影响我的操作,甚至影响我的玩游戏的思路,这样它才能够算一个C级技能,而如果它只是不稳定地为我提高暴击率的话,那么它只是一个B级技能。相比之下技能9就更有意义,它的发挥是可预估的,并且在总体上相当于“33%几率造成150%伤害”,《风暴英雄》中全面用这种机制代替了《魔兽争霸3》中每次攻击进行随机的暴击机制,很有借鉴意义。然而,虽然《风暴英雄》的暴击机制和《英雄联盟》的电刀很有趣,但他们对玩家的操作强度要求也很大,因此在设计的时候也要注意是否要由于玩家的水平而让这种技能的发挥相差很多。

D级:阴阳数值型

阴阳数值型听起来挺怪的,实际上指的就是那种同时有正面效果和负面效果的基础数值型技能,虽然它们也是基础数值型,但由于一正一负,就会变得很有趣,尤其是当它们会涉及到A+级属性时:

  1. 你的攻击速度提高三倍,但你的伤害降低至三分之一
  2. 你的攻击必定命中,但你的攻击永远不会暴击
  3. 你永远无法闪避,但你永远不会被击晕
  4. 你的伤害提高15%,但你的防御降低15%

我们可以发现技能4并不会对玩家的玩法影响太大,因为它只是在数值层面的微调,1与4是同类但由于变化非常大而产生了巨大的效果,在某些时候它的攻速带来的巨大收益是远远高于伤害降低的惩罚的,而2与3都是修改了A+级属性(这些属性往往是百分比或布尔型属性)而导致的特性发生巨大变化的例子。

也正是由于当这种阴阳数值型的变化剧烈时带来的收益过于巨大,因此在单独设计这种技能的时候它的数值往往看起来是亏很多的,1号技能甚至需要更高的伤害惩罚才能与其他的技能价值相当,但更高的伤害惩罚会使得这种技能的泛用性降低,玩家只有在使用高攻速收益低伤害收益的策略时这种技能才有用,所以不建议把这种技能的数值设计得过于夸张,效果为一般技能的二三倍就够了,比如:

  • A技能:攻速+30%
  • B技能:攻速+100%,伤害-70%

B技能和A技能相比已经相当变态了!

E级:基础特效型

基础型特效是静态的特效,只是一种效果的基础计算方式,它们需要动态的BUFF机制才能够实际产生作用,除非是瞬间型特效。

特效如果只是一些对数值的运算,那么就和A级技能十分相似了,但很多特效是会影响单位的状态或行为方式的,这种特效算本文中称呼他们为E级技能,下面是一些常见的特效:

  1. 减速:移动速度降低x%。
  2. 致盲:视野降低值x。
  3. 点燃:每秒损失x%最大生命值的生命。
  4. 恐惧:逃离施法者。
  5. 定身:无法移动。
  6. 死亡:单位死亡。
  7. 复活:单位从死亡的状态又活过来了。

1号与2号只是对数值的简单修改,是A级技能。

3号运算方式比较复杂,但如果架构支持按最大百分比造成伤害的话也不难。

4和5会影响单位的行为方式,是非常复杂的特效。

6和7则是影响底层机制的瞬间特效,要看游戏的底层机制具体是如何运行的才能设计清楚。很多游戏中,伤害作为一种核心的底层机制,也是一种特效,因此要看特效在不同游戏中的定义是什么了,这种特效与事件更为类似,但很多特殊技能都需要这种特效,比如直接杀死敌人,无敌,复活,变形,融合,复活等等,这些特效简单来说就是在技能描述中,那些需要你明确地向软件工程师解释其运行机制,而不能让软件工程师按照字面意思自己猜想运行机制的字眼。

F级:动态特效型

与C级技能相似,动态特效是在某些事件发生或满足某个条件的时候才会生效的特效,也是特效的最基本生效方式。下面是一些例子(红字为上文提过的特效字眼):

  1. 敌人生命值不足10%时,50%几率秒杀敌人。
  2. 敌人死亡时尸体发生爆炸,对周围的敌人造成伤害。敌人越胖爆炸半径越大,敌人最大生命值越高爆炸伤害越高。
  3. 敌人死亡后尸体会转而为你而战,生命值与攻击力为生前的一半,持续15秒。15秒后敌人的尸体会破碎,破碎的尸体无法再被复活
  4. 在地上扔一颗地雷,需要3秒才能准备好,准备好后当有敌人触发时,会对范围内的敌人造成伤害。
  5. 在地上扔一个陷阱,当有敌人踩中时,会对这个敌人造成流血效果,并且使之无法移动,持续5秒。
  6. 将敌人传送回他5秒前所在的位置。
  7. 在目标敌人脚下洒下一大滩半径为10的污油,污油上面的敌人移动速度降低50%。当污油受到火焰伤害后会被点燃,点燃的污油会对上面的敌人每秒造成x点火焰伤害。会飞的敌人不会受到污油的影响。
  8. 一定几率冻结敌人,并且一定几率秒杀被冻结的敌人。对敌人造成的单次伤害越高,冻结、秒杀敌人的几率越大。
  9. 你有一定几率把敌人吃进肚子里,你会暂时获得敌人的技能,敌人在你肚中每秒损失一定生命值,当敌人被完全消化殆尽时,你会受到治疗,治疗量等于该敌人的最大生命值,并且可以再次吞食一个敌人。

”Summon“这个字眼是啥意思,就要跟程序设计师商量

 

1号技能利用了E级的击杀敌人效果,属于比较简单的特效。

2号技能当敌人死亡时会产生一个瞬间的AOE效果,我们需要游戏支持AOE效果才能实现这个技能,并且AOE效果的范围和数值需要是动态的变量,而不是固定的常量。

3号技能引入了“尸体”、“复活”、“转换单位控制权”、“宠物”的概念,这些机制都需要游戏专门支持才能实现,单位的状态和行为比较复杂。

4号技能需要对“地雷”是个什么性质的东西进行定义,它可能拥有单位的部分属性,但又具有一些一般单位不具有的特性与状态,地雷的具体实现方式是用马甲单位还是专门定义一种地雷类型,比较复杂。如果玩家有一个造成的所有伤害为自己恢复生命值的技能,地雷造成的伤害是否算玩家造成的也需要说明(以及玩家制造的宠物、复活的尸体、搭建的炮台等等)。

5号技能与4号技能类似,但它被触发后造成的不是4号技能的瞬间效果,而是一个持续性效果。

6号技能的具体实现方式可能非常特殊!

7号技能与4、5类似,同时引入了一个“地面效果”的概念,油污的性质也需要定义,并且它也拥有诸多的状态,当点燃后表现上会变得不同,而且还会造成伤害。

8号技能会根据目标的状态动态调整自己的属性,实际上是一个比较简单的技能。

9号技能是这些技能中最复杂的,我们需要对“被吞食”的敌人的状态做出定义,如何获得该敌人的技能也很复杂。

被动技能到了F级动态特效型,复杂度就基本已经到头了。实际上大部分游戏都用不到这么复杂的技能,只有少数大型游戏才会用到这么复杂的技能,并且复杂度如此高的技能大多是玩家只控制一个化身的ARPG或者MOBA类游戏。F级的技能往往会成为一个玩家打造其角色能力的核心思路,比如“我想玩一个能够召唤很多尸体为我而战的死灵术士”,那么自然3号技能就比8号技能更符合我的玩法风格,8号技能给人感觉更像是寒冰射手或者是冰系法师才会用到的东西。如果一个游戏中存在大量的F级技能,那么A到E级技能基本都是为了打造以F级技能为核心而作为辅助存在的技能(但实际上D级技能就已经有可能成为BUILD的核心了)。如果我们在F级技能的基础上引入施法验证器、冷却时间、消耗资源等等概念的话,很容易就可以将其打造为主动技能,但其平衡起来的困难度也可想而知,这就是为啥为《英雄联盟》调平衡几乎是个不肯能的任务的原因——因素太多啦。所以如果不到不得已,尽量降低技能的复杂度,同时设计的时候使其能够对玩家的玩法或策略做出影响,才是我认为最好的技能设计思路(想想前面关于我吐槽《暗黑破坏神3》恶魔猎手暴击率技能的例子!)。

总的来说我认为复杂度在《地牢围攻2》以及《风暴英雄》这种级别就已经够满足绝大多数需求了,如果更加复杂到了《英雄联盟》的地步,很容易变成玩家也玩不明白,平衡也调不明白的地步了!

《星际争霸2》新种族设计

《星际争霸2》2.1版本上线后,能够制作加载在标准对战地图上的MOD了,因此我萌发了为《星际争霸2》设计一个全新种族的想法——实际上很多的idea都来自于《魔兽争霸3》和《星际争霸》。通过这次练习能够更加加深我对策略游戏的了解,同时也能加强对数值的了解,不过由于我制作MOD的水平有限,因此估计要抱不少大腿,即便如此依然希望我能做完这个MOD!

新种族特性

农民为飞行单位,每个2人口。与其他三个种族传统的采矿方式不同,这个新种族的农民一直趴在矿上就可以进行采集——我打算通过单位变形的方式来做到这一点。这借鉴于《魔兽争霸3》中暗夜小精灵采木头的方式,并且在《自由之翼》中人族也可以通过升级来获得不需要农民就可以自动采集的瓦斯矿。

农民建造单位时会被隐藏,这个类似于《星际争霸》中虫族以及《魔兽争霸3》中兽人与暗夜的农民建造方式,而这两者的区别是建造完后虫族的农民与建造了古树建筑的暗夜农民会消失,而建造非古树建筑和兽人建筑的农民造完了后不会消失。我比较倾向于建造完后不会消失这种设计,与其他三个种族都不同,其次由于农民是飞行单位,会产生一些很有趣的策略。

建筑物可以在任意空地上建造,这与《星际争霸》中的人族类似,而虫族和神族的建筑都要在能量场和菌毯上建造。

种族单位通用的特性则是当生命值低于一定值时+2护甲,这适用于该种族的所有建筑和单位。

科技树设计

按照《魔兽争霸3》和《星际争霸》的设计传统,科技树有两种设计方式。《星际争霸》中的虫族与《魔兽争霸3》中的所有种族类似,基地能够升三本。神族与人族没有类似的升本机制,但科技树结构其实较为相似。我打算采取与虫族类似的三本基地设计。

123

所有战斗单位都是从兵营中生产的。这是我从虫族的生产方式和人族神族的生产方式折中后选择的一个方案。基地生产非战斗单位,还有一些特殊单位如利维坦也能够生产单位。兵营拥有类似于《魔兽争霸3》暗夜建筑的扎根拔根技能,扎根后才能生产,拔根后可以移动。

单位设计

我看了半天编辑器,决定使用对战中没出现过的虫族单位来拼凑一个新的种族,虫子们拥有足够多的建筑物和单位模型——托《虫群之心》的福(笑)。

  • 农民:2人口,轻型飞行单位。2本升级提高移动速度。2本升级为运输单位。
  • 蝗虫:0.5人口,中程对地单位,轻型杂兵版蟑螂。1本升级射程+1。3本升级受到致命伤害时依然能存活2秒。
  • 畸变体:3人口,地面重型突击单位。可以跨越小型单位。升级后获得技能【专注光环:周围所有友军护甲+1。】
  • 大胖子:1人口,对地对空远程狙击型轻型单位。升级后攻击能够降低目标的护甲。【技能:魔兽3狼骑的网,能够把空军拽到地面上来】
  • 激素虫:1人口,地面施法单位。升级后变为空中单位。【技能1:嗜血,自杀并使周围友军大幅提高攻击速度和移动速度。】【技能2:自杀并产生一道火墙,持续灼烧上面的地面敌方单位。】【技能3:自杀并击晕敌方单位3秒,无法击晕巨型单位。】
  • 胡蜂(地面):2人口,快速突击近战部队,升级后能够变形为胡蜂(空军)。不需要瓦斯建造。【脱离战斗后快速回血。】升级后获得【技能:死亡时会使周围的其他胡蜂移动速度提升,持续一段时间。】
  • 女武神:3人口,中距离大范围AOE攻击,高伤害低精度。《星际争霸1》代人族女武神翻版,不过是地面单位而且攻击即对地又对空。升级后攻击忽视敌方护甲。升级后射程+1。
  • 胡蜂(空军):2人口,肉搏型专业对空部队,升级后能够变形为胡蜂(地面)。不需要瓦斯建造。【脱离战斗后快速回血。】升级后获得【技能:死亡时会使周围的其他胡蜂移动速度提升,持续一段时间。】
  • 隐形虫:1人口。飞行单位。侦查与反侦查部队。【技能1:永久隐形。】升级后获得技能2。【技能2:自杀并使某个友军永久隐形。】
  • 守护者:2人口,1代虫族守护者翻版,远程对地重型攻击单位。【技能:攻击造成范围伤害,但每次攻击消耗25点能量。】升级后能量初始值和最大值提高50。
  • 经典皇后:2人口,空中施法单位。【技能1:寄生虫,获取目标单位视野,持续一段时间。】【技能2:诱捕,1代皇后经典技能。】
  • 残暴虫:4~8人口,巨型单位,对地近战肉搏,对空反巨型单位远程轰击,地面终极单位。升级后获得技能2。【技能1:击杀单位后根据被击杀的单位的最大生命值恢复生命值。】【技能2:每次攻击提高10%攻速,最多叠加5层,持续5秒。】
  • 利维坦:8人口,只能造一个,巨型单位,由3级基地变形而来,空军究极单位。拥有多种攻击方式,并能当做兵营生产空军部队。【技能1:大和炮。】【技能2:死亡时孵化出大量胡蜂(空军)与胡蜂(地面)。】

设计的过程中我添加了很多符合我口味的近战单位。我一直觉得《星际争霸2》中的近战单位太少了,人族只有SCV,其他两个族不算上农民只有小狗、雷兽、叉子、黑暗圣堂武士四种近战单位。所以我一口气为新种族设计了3种近战单位,而且胡蜂对空也是肉搏的,这类似于《魔兽争霸3》的石像鬼和角鹰兽。《星际争霸2》加入了肉搏空军会变成什么样呢?这也很令人好奇!

先写到这里吧!现在只是设计阶段,等年后开始抽时间制作。

最后祝大家新年快乐!以后估计我会继续写一些这个系列的新文章,或者再更新这篇文章的。

2月2日更新:

目前的农民设计有两个问题:1,初期探路问题无法解决,该族农民人口占据过高导致探路会浪费过多劳动力。2,农民占据人口过高,若用农民去建造建筑与其他种族比会浪费大量时间,同样也是浪费劳动力。

目前的解决方案为将农民降低至1人口,农民变身为采集水晶的建筑时需要再花费50水晶1人口,建造时间为17秒(与建造1个农民的时间相同)。另外由于这个种族前期缺少反骚扰手段,准备给主基地增加一个被动技能:周围一定范围内的所有己方单位增加移动速度,这样农民造建筑物拖沓的问题得到了解决,己方单位面对对方快速单位反骚扰能力很差的问题也可能会得到解决。1人口的农民被派去探路也比较容易被接受,不会浪费过高劳动力。

飞行农民由于移动速度较慢,在直线型的路径上探路速度必然慢于其他种族,而若路线曲折则优于其他种族,这也会导致该种族与地图的相性产生很大的变化,这种动态我想是可以接受的。

2月7日更新:

农民在现在的游戏中,其功能有4点:移动,攻击,建造,采集。由于农民能够移动,因此可以作为前期侦查的手段;由于能够攻击,所以能够产生一种搏命的战术;建造和采集则是其更根本性的存在目的。如果我们将农民的移动方式改为空中,则其攻击方式也可能会受到影响,无论如何设计都和其他种族的近战地面农民部队有所不同。另外由于其飞行移动方式的优势,如果我打算通过降低其移动速度来弥补的话,则其建造的性能会受到影响(移动到建筑地点要花费太长时间),采集方式的不同问题则不大。我之前的设计将其移动和采集方式做了大幅度的变更,会产生相当大目前无法预料的问题,比如农民由于不能攻击而前期受到骚扰时没有反击手段等等。

考虑到这些问题,我产生了一个新的设计思路。之前的设计中,农民采集不用向基地中送矿这一设计是最重要的核心,比其飞行移动方式更为重要。这一设计方案来自于《魔兽争霸3》的侍僧采金子以及暗夜采木头,已经得到过验证,不容易产生没有预料到的问题,同时玩家易于理解。目前我打算作出如下改变:

  • 取消相当于其他种族农民的单位。
  • 主基地改为飞行建筑,移动缓慢。
  • 建造功能由主基地完成。
  • 建造方式为向一定射程内投掷建筑物的卵,经过一段时间后孵化为对应建筑。(十分类似于人族主基地扔矿螺,但矿骡射程是无限的。这么一说更类似于感染虫扔枪兵蛋,或神族向能量场中折跃单位)
  • 新的主基地由老的主基地建造而来,造价和建造时间同其他种族。
  • 自动采矿机也由主基地建造而来。
  • 主基地能够升2本、3本。
  • 主基地有一定的战斗能力,1本战斗力约等于2个虫族皇后,2本战斗力约等于神族大炮台,3本战斗力约等于人族行星要塞。
  • 主基地可能会拥有一些升级,如共享空军的攻防等级,或研发新的能力等等。