如何做TODO LIST?

首先为什么要做TODO LIST?

很简单,为了让你成为一个靠谱的策划。

怎么才能成为一个靠谱的策划?

最基本的就是把该干的活都干完。

那么如果你连自己该干的活都有什么都不知道的话,就根本靠谱不了。

至于实际的工作能力如何都是之后的话题了。

好记性不如烂笔头,每天面对这么多工作和信息,要做什么靠脑子根本记不住,所以需要工具来辅助我们的工作,确保我们做到以下几点:

  1. 时刻知道自己还有哪些东西要做。
  2. 时刻知道暂时没法做的东西是因为什么原因,是被其他人卡进度,还是什么原因。
  3. 时刻知道经过自己手已经移交出去的作业现在是什么情况,而不是移交出去就变成撒手掌柜了。你是策划,是一个功能的最终负责人,必须从头跟到尾。

基本概念

  • 所有工作内容分为三个状态,TODO,DOING,DONE
  • 工具的具体形式无所谓,用本子手写也行,用纯文本txt也行,用专门的工具也行,看个人习惯,下面是几个我推荐的工具:
    • TIM(我个人习惯用TIM的待办事项)
    • 钉钉
    • QQ邮箱
    • 手机备忘录
    • mubi.io
    • trello
  • 随便你用哪个都行,因为要记住,工具毕竟只是工具,只是手段不是目的,目的是提高工作素养,管理好自己的时间,时刻知道自己要做什么,还有多少东西没做完。

一个TODO LIST的范例


TODO

  • aaaaaaaaaaa
  • bbbbbbbbbbbb
  • ccccccccccccccccc
  • dddddddddddddd

DOING

  • @AT 1220 eeeeeeeeeeeeeeeee
  • @AT 1220 功能A
    • @张三 1216 模块1
    • @李四 1217 模块1
    • @王五 1218 模块1
    • @赵六 1219 综合测试
  • @AT 1220 eeeeeeeeeeeeeeeee
  • @AT 1220 eeeeeeeeeeeeeeeee
  • @AT 1220 eeeeeeeeeeeeeeeee
  • @AT 1220 eeeeeeeeeeeeeeeee
  • @AT 1220 eeeeeeeeeeeeeeeee

DONE 1218

  • aaaaaaaaaaa
  • bbbbbbbbbbbb
  • ccccccccccccccccc
  • dddddddddddddd

DONE 1217

  • aaaaaaaaaaa
  • bbbbbbbbbbbb
  • ccccccccccccccccc
  • dddddddddddddd

LIST中每一个条目需要的元素都有什么?

  • 状态:当前是处于啥状态,TODO,DOING,还是DONE
  • DEADLINE:什么时候之前要做完
  • 进度:以百分比的形式写明白进度
  • 担当:谁来做这一个工作
  • 优先级:就是优先级

不同管理工具的复杂程度不同,有的会非常复杂,但管理个人作业的话就是最上面的3条就够用了:状态,进度,DEADLINE

但是你仅仅把要做的整理下来了还没用,这是个开始。如果你不能保证持续使用TODO LIST的话,整理完了并没有任何意义。

接下来你要进行漫长的、重复的持续的一直到死的、不断关注和更新自己TODO LIST的操作,这个操作将打磨你的灵魂,让你从一个不靠谱的人变成一个靠谱的人:

打磨灵魂的操作:

  1. 有哪些TODO部分的需要挪到DOING部分的?
  2. 有哪些DOING部分是自己的部分已经做完了,要等其他人协助的?
  3. 之前已经处于需要协助状态的DOING的内容怎么样了?
    1. 不是说交出去就完了,要持续跟进
  4. 有哪些DOING部分的内容延期了?延期的原因是啥?之后怎么做能避免延期?
    1. 重点是如何避免再次出现类似问题
  5. 有哪些DOING部分的内容过于复杂,需要拆分成多个子条目来推进的?
    1. 分解任务是解决问题的核心能力
  6. 有哪些DOING部分的内容必须开会讨论后才能继续推进?
    1. 菠菜原则:报告,联络,商谈
  7. 已经完成了的挪到DONE,做好归档(比如按照日期)
    1. 这样可以定期复盘自己的工作做的如何
  8. 以上操作至少每天醒了做一次,睡之前做一次

不要追求花哨

选一个适合你自己的TODO LIST的工具,并坚持下去,直到你的工作素养提高到不需要TODO LIST也时刻知道要干什么的地步。

不要因为追求花哨,就整天花时间在挑选工具上,一会儿试试这个一会儿试试那个,感觉好像自己花了不少时间在管理自己的作业上,但其实全都是废操作。

不要追求花哨,选定一个,坚持下去,才是提升能力的最快途径。

必学部分

策划流程进度可视化

  • 【0%】只有原始反馈,或者是空单
  • 【10%】确认用户需求,从原始反馈整理出真实需求
  • 【20%】敲定解决思路或策划草案完成,但尚未讨论(含线框图)
  • 【40%】策划草案通过,等待美术UI案完成(高保真UI示意图)
  • 【60%】美术UI案完成(高保真UI示意图),但尚未讨论
  • 【80%】美术草案通过
  • 【90%】策划验收测试项草案完成
  • 【100%】策划验收测试项通过——到这里算完成了一个完整的策划案
  • 【CLOSE】按照测试项验收完成,迁移至【策划验收完成】状态,交付QA进行测试

需求 -> 思路 -> 策划案

任何一个策划案诞生的过程都应该经过以上三个步骤,能够清楚地区分这三个步骤对增加沟通效率非常有帮助。

  • 需求:指的是我要做什么
  • 思路:指的是我用什么方式做
  • 策划案:指的是这个方式具体表现在游戏中是什么规则

比较简单的需求解决思路一般也很简单,直接改就行了。比较复杂的需求往往要花时间调查、讨论各种思路,最终才能确定。

例1

  • 需求:粉丝发来的垃圾信息过多
  • 思路1:增加一键已读功能
  • 策划案1:在消息界面增加一键已读按钮,点击后如果粉丝消息存在红点,则会消除所有红点(即将所有粉丝消息视为已读)。点击后若没有粉丝消息,则飘字提示“已经全部读过啦”。

然而思路1就是好的吗?

  • 思路2:为什么粉丝发来的垃圾信息过多?因为我们不支持向陌生人发送消息,因此凡是会产生消息的都要求必须先关注对方。如果不要求也能发送呢?这样一来我们要追加不接受陌生人消息之类的功能,也可以解决问题。
  • 思路3:如果增加粉丝关注的成本呢?因为粉丝关注我没有任何成本,然后关注了就能发消息,因此会产生大量垃圾消息。如果其他玩家关注我的时候发现我要求送礼,或者要求其达到一定指标,是不是也可以减少垃圾信息数量?

例2

  • 需求:游戏太卡。
  • 思路1:降低分辨率,从1080p降低到540p
  • 思路2:降低帧率,锁帧30fps
  • 思路3:更新引擎,提升效能
  • 思路4:自己魔改引擎,解决问题
  • 思路5:压缩图片,减少内存占用
  • ……
  • ……
  • 思路X:是不是应该先调查一下到底因为什么卡,然后在决定用上面的哪个方式推进?

思路不一样,往往解决方案完全不同。在【需求单策划流程进度可视化】这个系统里面,定下来思路策划案只完成了10%,但是这10%非常关键,否则整个策划案都是无根之木。策划的功力主要体现在这10%,剩下的都是基本功和体力活了,因此新人策划往往在做从10%到100%的工作,做好了这些基础性的工作,才有机会负责重大功能的前面10%的工作。

如何写游戏策划文档?

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

不过如果你翻不了墙也没关系,接下来我会把每一页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君能意识到这一点,并且尝试设计一个能达到同样设计结果的更优秀、更好玩的模式,那才是靠谱的策划,脱离了玄学的策划,一个有益于所有人的策划。

脱离“自high”是策划入门的必经之路

大家好,好久没写博客了,今天趁着周日写一篇稍短一些的,只是一些想法,不是很有条理,但是AT君还是决定先记录下来。

AT君是一个没有师父带入门,一切都靠在工作中坑队友以及自己学习来提高能力的小策划,因此在策划成长的路上踩过不少坑。我不太清楚大公司或者大团队传说中师父带徒弟或是参加策划培训班儿而成长起来的策划经历和我有什么不同,但AT君最近越来越觉得,在新人策划成长的道路中,非常容易深陷其中而又非常有害的两种非常坏的习惯是“自high”“玄学”。这篇文章主要说“自high”,“玄学”放在之后再说。

“自high”是啥呢?就是一个设计自己觉得美得很,但团队其他人根本不服。如果两个“自high型策划”碰到了一起,会互相觉得对方是傻逼,而事实上他们每个人的水平都不一定高到哪里去。AT君曾经听说过有两个策划为了一个NPC的名字应该是两个字还是三个字争得面红耳赤,甚至整个办公室的人都陪着来争,这种情况会出现说明了这两个策划要么是有其他恩怨,要么就都是非常不成熟的——他们很有可能都是“自high型策划”。站在更高的视野上来看,实际上一个不是主要人物的NPC的名字只要不太出格,具体是啥根本无所谓的,争这个完全是在浪费策划自己的生命和团队的开发资源。

“自high型策划”的一大问题就是自我感觉良好,觉得自己想出来的点子是天下无双的,容不得批评,看不起美术和程序因为觉得他们不懂,然后又看不起其他策划因为觉得自己最牛逼。“自high型策划”在接收到任务的时候,往往会搞出来画蛇添足的东西,无视更上层的需求,任性的按照自己的感觉走——而最后往往都证明了感觉是不靠谱的,一般案子都会被打回来重做,而“自high型策划”由于觉得自己才是对的,往往会觉得主策划或者制作人是啥都不懂的傻逼,而不会站在对方的视角上来考虑对方为什么给自己这样的任务。

实际上,“自high型”策划在新人策划中所占的比例非常非常大,AT君觉得这是因为,如果不是这种对于游戏设计特别有热情的人,往往不会选择这个行业,而会有如此高热情的人往往都是有自high倾向的,再加上阿宅特别多,出现这种性格的人就特别的常见了。他们对无数金牌制作人的故事耳熟能详,对各个游戏大厂的梗烂熟于胸,受到诸如《东京玩具箱》一类作品的影响,觉得一个游戏就是靠一个天才的点子做出来的,觉得自己对产业十分了解,但实际上这一切都只是从玩家视角上看到的业界,而不是真正的从业者所接触到的东西。“自high型策划”如果真的是绝世天才,会成为乔布斯一样的人物,然而事实情况是99%的“自high型策划”是眼高手低的一般人,这也是为啥“不要相信策划”成为了一个最常见的的梗的原因。

但如上面所说,好的策划往往也是从这个群体中培养出来的,因为这种人有着很丰富的玩游戏的经验,以及有着相对较高的自我要求。“自high型策划”如何才能成长呢?

  • 换位思考。
  • 换位思考。
  • 换位思考。

这是第一点,也是交流的基本。“自high型策划”在与人交流的时候自己的杯子是满的,根本听不进去对方的意见,只顾着说自己的,最后只会吵起来,因此对“自high型策划”来说,换位思考是交流的基本,也是最欠缺的能力。能够换位思考意味着要放下自己的执念,认真的考虑对方为什么会有这样的想法,真正的做到一个倾听者。听到别人与自己不同的意见时,先仔细的考虑一下,对方的意见有什么好处,对方为什么会觉得有些地方不妥,而不是一口否定对方的意见和抱怨。即使确实你自己的主意更好,也要在充分理解和肯定对方的想法的前提下,再向对方解释为什么你不能采纳对方的意见。AT君自己在这方面做得也不是很好,之后还需要进一步提高。这只是心法,需要在实践中不断的去做,才能慢慢做好。

  • 用客观需求代替主观偏见

当意见产生冲突时,评估双方意见的标准绝对不是个人喜好,而是应该先商量一个双方公认的客观标准,否则就会像上文的两个策划一样为了一个NPC的名字吵个没完没了。做到这一点不容易,因为要做到这一点不能情绪化,要保持冷静克制和足够强的逻辑性,这样才能做到求同存异。AT君性子比较急,因此在这方面做得也不够好。

主观偏见不一定是自己的好恶,也可能是团队其他人,甚至领导的好恶。比如“你们不就是想要一个大胸妹子特别多的游戏吗”这种心态,实际上也是在用主观偏见代替客观需求,在这种情况下做出来的东西往往是怨气丛生,就算一次两次能压下去,最后爆发的时候也会导致一切工作的根本都站不住脚的。因此策划在给程序和美术提意见的时候,因为自己不是专业人员,往往自己的发言都是建立在自己的主观偏见上的,要明白自己只是提意见的,不要把自己的偏见强加于人,这也是很重要的。

  • 拒绝为了争执而争执

“自high型策划”如果能够意识到嘴炮是在浪费生命,也会获得巨大的进步。很多“自high型策划”把自我价值建立在了与其他策划打嘴架后获得的胜利带来的满足感上了,而这其实一点用也没有,只是廉价的自我安慰。发展到比较严重的阶段时,甚至会为了一切东西故意唱反调,以刷存在感,如果到了这种地步就有些可悲了。

因此我们要以结果为导向来代替为了胜利而争执,不要为了口舌之快而主动挑起争端,不要为了显示优越感而刻薄的批评,只在有必要统一意见的时候,按照上面两点来与其他人进行交流。但这并不意味这做一个和事老,当问题出生的时候必须要交流时,也往往需要主动来组织讨论,及时解决问题。

可见,以上三点实际上都是在针对与人交流而说的,这是因为“自high型”策划比起能力不足,更严重的是心态和认知层面的问题,只要心态能够摆正,有能力的人自然会进步神速的。而容易对一个新人策划提高能力产生负面影响的,是文首提到的“玄学型策划”,这个在之后的文章中再探讨。

今天就到这里了!

战斗数值框架搭建入门

设计一个游戏DEMO的时候要干的第一件事是什么呢?是搭建数值框架,而如果是一个打打杀杀的游戏,第一步要搭建的就是战斗数值的框架了。

AT君最近在自己尝试着做一些塔防的DEMO,并且获得了一些搭建数值框架的经验,在这篇文章中直接以实例的方式总结一下,如何着手从零搭建一个游戏的数值框架。

打打杀杀的游戏第一步要确认的是攻防关系,以及游戏的基本节奏。AT君所做的是一个塔防游戏,简单来说就是玩家的化身是一个塔,不断的攻击从四面八方向塔逼近的一波一波的怪物,直到击败一关中的所有波次,或被怪物打败——也就是说是一个有些类似于《抢滩登陆战》的游戏,只不过塔是自动攻击的。

AT君第一件确认的是单关的长度。由于是为手机游戏设计DEMO,因此单关长度要在3分钟以内。接下来就是3分钟的时间,要让玩家感受多少波次比较合适呢?这是一个比较个人化的体验所带来的决定:15秒一波,既不会密到喘不过来气,也不会松到觉得无聊。经过6波普通波次的战斗后,迎来30秒的BOSS波次,这样一来一关是120秒的时间,符合3分钟以内的标准,而且为以后扩充留下了一定空间——8波甚至9波也是可以做的,但由于目前要做最小化的DEMO,因此AT君认为这个波次6+1,一共120秒的设计是OK的。

这样我们得出了数值框架的第一部分:一波15秒,一关120秒。

一波15秒,所发生的事情是什么呢?最基本的事情是怪物冲向玩家,玩家把怪物们打死。那么一个标准的无伤模型就是最后一只怪物冲到玩家面前的时候,正好全部被玩家打死,接下来立刻就刷新了下一波。由于玩家的英雄站在地图中间,那么我们能够得出:

【结论2】假设标准怪物的移动速度是1,那么地图的半径就是15,英雄的攻击半径也是15。

接下来要定的是一个标准波次有多少怪物,每个需要玩家的英雄攻击几下来打死。这是在奠定游戏的基本节奏,因此非常关键。AT君想要的是偏“无双”风格的游戏,怪越来越多,被玩家的英雄哗哗的干死,非常爽快的游戏,因此标准怪物要很多。AT君一拍大腿,决定标准波次要有15个怪物,之后的每一波都比前一波多5个怪物,游戏一共有7波,那么分布就是这样的:

  • 15个标准怪物
  • 20个标准怪物
  • 25个标准怪物
  • 30个标准怪物
  • 35个标准怪物
  • 40个标准怪物
  • 1个标准BOSS

我们可以看到,怪物数量增加的速度非常快,最后一波标准怪物是第一波的两倍还要多,因此一定可以达到非常爽快的目的。当玩家用标准英雄去玩这个关卡的时候,得到的就是一个标准模型了。

我们假设一个标准怪物是40血,那么第一波共15个怪就是有600血,玩家的英雄要在15秒内造成600点伤害,因此我们得出:一个标准英雄的秒伤是40。那么标准英雄打一个标准怪物要打几下呢?至少要是2下,因为一定会存在血比标准怪物少的怪或单下伤害比标准英雄高的英雄。那么我们就得出了:

【结论3】假设一个标准怪物的生命值是40,则标准英雄的单体伤害为20,攻击间隔为0.5秒。

我们确定了英雄攻击力和怪物生命值的关系,接下来需要确定的是怪物攻击力和英雄生命值的关系。标准怪物都是近战的,那么我们以什么为标准呢?由于第一波怪是一定会被标准英雄无伤打死的,因此英雄的死亡时间一定是在15秒至120秒内。玩家纯挂机必须是不能见到BOSS波次的,因此死亡时间可以缩短至15秒至90秒内。AT君一拍大腿,认为标准英雄的死亡时间应该是在60秒,也就是第四波怪刷出来的时候。由于怪物攻击英雄会不断随着数量的减少而减少DPS,再加上AT君的高等数学已经全都忘光了,因此经过连算带测,得出的结论是:

【结论4】假设英雄的生命值为1000,那么标准怪物的秒伤为5。

接下来是BOSS,AT君将标准BOSS的生命值设定为了45个标准怪物的生命值,即1800(相当于第七波的总生命值),在移动速度与普通怪物相同的前提下,可见其近身至英雄身边会损失600生命值。玩家如果在BOSS波什么都不干,只靠平A挂机,是一定会被BOSS打死的,由于我们已经设计好BOSS波次要在30秒之内完成,因此BOSS的秒伤要至少是1000/15=66.6666,AT君一拍大腿将其定成了100,这样一来假设玩家的英雄满血进入BOSS波次,之后什么都不干纯挂机,会在25后结束游戏,BOSS剩余800血。这样我们就得出了:

【结论5】标准BOSS的生命值是1800,移动速度为1(即等于标准怪物的速度),秒伤为100。

若我们从另外一个思路来考虑:如果我们要求BOSS波25秒结束游戏,且前提是BOSS移动速度为1,那么如果我们要求BOSS打死玩家的时候还剩一半血,就可以得出BOSS的血量=25秒*英雄秒伤/1/2=25*40*2=2000血,秒伤=英雄血量/(25秒-BOSS移动速度*地图半径)=1000/(25-1*10)=100。我们只定了要求BOSS波纯挂机25秒结束,BOSS剩余一半血,移动速度为1,就能够得出BOSS的血量和秒伤啦,并且是能够得出理论上的极值的。

到了这里我们可以总结一下我们得到的数据:

标准怪物:

  • 生命值:40
  • 移动速度:1
  • 射程:0.1(即近战)
  • 攻击力:5
  • 攻击间隔:1

标准BOSS:

  • 生命值:1800
  • 移动速度:1
  • 射程:0.1(即近战)
  • 攻击力:100
  • 攻击间隔:1

标准英雄:

  • 生命值:1000
  • 不能移动
  • 射程:15(或无限)
  • 攻击力:20
  • 攻击间隔:0.5

标准关卡:

  • 怪物刷新点至英雄距离:15
  • 刷怪间隔:15秒
  • 第1波:15个标准怪物
  • 第2波:20个标准怪物
  • 第3波:25个标准怪物
  • 第4波:30个标准怪物
  • 第5波:35个标准怪物
  • 第6波:40个标准怪物
  • BOSS波:1个标准BOSS

这样我们就得出了一套最最最基本的数据,游戏已经可以玩啦。回顾一下我们是如何得出这些内容的,经历了几个步骤:

  1. 根据单局时长和想要的游戏节奏 => 得出移动速度、地图大小、波次间隔;
  2. 根据撸怪风格和标准怪物生命值 => 得出怪物数量、英雄秒伤;
  3. 根据我们认为合适的英雄死亡节奏 => 得出怪物的秒伤;
  4. 根据我们认为合适的BOSS波节奏 => 得出BOSS的属性;

这样一来,我们只要改变以下几个最基本的值,其他的值都会跟着联动:

  • 标准单局时间:120秒
  • 标准波次结构:6普通波+1BOSS波
  • 标准波次的间隔:15秒
  • 准怪物移动速度:1单位/秒
  • 标准怪物生命值:40
  • 标准英雄打标准怪物几下打死:2
  • 标准怪物在标准波次的个数:15个
  • 英雄挂机死亡时间:60秒
  • 标准英雄生命值:1000
  • 标准BOSS的移动速度:1单位/秒
  • 英雄BOSS波挂机死亡时间:25秒
  • 英雄BOSS波挂机死亡剩余生命值:44.4444%

我们会发现,虽然是在搭建战斗数值框架,但实际上和攻击力啊,攻击速度啊,生命值啊直接相关的数值非常少——只有一个我们假设的标准怪物生命值和标准英雄的生命值作为基础单位而已。一切都是在游戏的基本节奏定了之下推算出来的数值,我们会发现,单局时间,单波波次,挂机死亡时间,这些都是时间,也就是节奏,这些是我们需要确定的数据,这些是我们想要产生的体验,而最终得到的攻防数值都是为这些服务的。当我们看到别人的游戏的时候往往看到的是这些果,经常有人连篇累牍的分析别人的游戏数值是什么样的,这个单位的攻击力是多少,但不能掌握那个“为什么这些数值要这么定”的因的话,是在做本末倒置的无用功,直白点说就是还停留在门外汉的级别啦,外行看热闹而已。因此,对于一个战斗数值框架来说,最优先的是定基本的“节奏”,这是由空间上和时间上两方面来决定的,其他的一切数值基本都是水到渠成,定了一个就能推算出来其他的。

总之,最重要的是方法论,要做到每个数值维度的设计都是有道理有基础的,而不是凭感觉拍脑袋拍出来的,这样之后我们调整的时候才会有方向,出了问题可以不断的对这套数值框架进行验证与调整,避免像AT君一样陷入曾经的“傻媳妇和面”窘境——一切凭感觉拍脑袋,最终只能面多了兑水,水多了兑面,然后是无尽的测试地狱。平衡不可能全都是纸上谈兵,一定会需要依靠测试来调整,但那些没有理论依据,只靠测试来调平衡的绝对是愚蠢的不靠谱做法,等着程序员、测试员和老板骂死你吧。

说了这么多,相信很多人已经开始早就怀疑一个问题了:目前这个模型是玩不下去的,英雄只能普通攻击,到了60秒的时候就死了!怎么才能获得最终的胜利呢?

这里亮点登场——锵锵锵,AT君设计的这个游戏,是一款TCG游戏!玩家要配一套牌组,带进游戏中去施放,和传统的TCG一样,每张牌都需要支付一定的费用才能打出,不足的这部分能力就要靠卡牌来实现了。那么接下来我们就需要解决一个问题了:

1费值多少?

每个问题都要有一个基本的原点,我们假设1费值1条标准怪物的命,那么我们就可以得出:

【结论6】假设1费值1条标准怪物的命,那么1点费用用于攻击时,价值是40点伤害。

游戏中一共有15+20+25+30+35+40个标准怪,以及一个生命值相当于45个标准怪的BOSS,生命值总计210*40=8400。游戏时间120秒,普通英雄一共造成了120*40=4800点伤害,剩下的3600伤害要从卡牌里出,我们就能得出,一局游戏如果想无伤通关,需要3600/40=90点费用,一局游戏120秒,那么得出了下一个结论:

【结论7】每1.3333333秒产生1点费用。

也就是说,如果玩家带的都是10费的卡,平均每13.3333秒能够打出1张。我们可以根据玩家的卡组平均费用的出玩家平均多久打出一张牌,由于AT君并不想要让游戏的强度太高,一场游戏下来操作次数不要超过30次为妙,平均每4秒出一次牌,平均费用为4*1.33333=5.3333333,这就是我们的标准卡组平均费用啦。

以从结论6为标准,我们可以得出其他一系列其他的卡牌设计标准。比如,伤害提高100%的卡牌,1费值持续多久?按照标准英雄计算,值1秒,英雄的秒伤为40,这个效果只要持续1秒就提供了40点伤害。只要是以各种方式增加伤害的,我们都可以用标准英雄为模板来计算其收益。

另外一种则是与英雄生命相关的,比如1张X费的牌效果是为英雄恢复100点生命值,X应该是多少?一张0费的牌,效果是对英雄造成100点伤害,产生X点费用,X是多少比较合适?由于英雄生命值是另外一套独立的价值标准,因此也需要一个基础。

我们有一个原则就是,玩家如果只带恢复生命值的卡,必然是会输的。我们知道BOSS的秒伤是100,那么每1点费用恢复的生命值应该是小于133.333333的,否则玩家可以只靠治疗卡牌磨死BOSS,因此我们可以粗略的拍大腿——

【结论8】用于恢复英雄生命值时,每1点费用应该恢复100点生命值(且不可高于133.3333)。

接下来会有越来越多的复杂情况,让我们难以预估,1点费用应该产生多强的效果,比如召唤防御塔的平衡标准是什么样的?召唤一个改变路径的墙的平衡标准是什么样的?控制法术的平衡标准应该是什么样的?一局游戏内永久性的提高英雄的能力的平衡标准是什么样的?但只要我们能够找到一个方法论,就可以先得出一个我们认为是正确的平衡标准,然后再通过不断的测试来反复检验我们的平衡标准,这样一来我们就可以通过反复迭代最终得出一个游戏最终的全部数值了,整个框架是一个从最基础的原则一点一点搭建起来的牵一发动全身的动态框架,而不是四处都是拍脑袋拍出来的数值。

关键还是在于方法论,即便错误,也是可以验证的。而没有方法论,连对错都不知道,就没有验证的基础了。游戏中的最终数值,不一定所有东西都是绝对平衡的,但有框架能保证数值不会崩——比如假设我们一拍脑袋设计了一张1费恢复200生命值的牌,数值就已经崩了,而如果我们没有框架,只靠测,就算经历九九八十一难确定了导致游戏崩的就是这张牌,也不知道应该改到133.3333以下才会不崩,还是只能靠调完了再去无尽的测试,简直是地狱。而框架能让我们逃离这个地狱,这就是框架的价值,地基打得牢,以后填的坑就少,不然就是害人害己害团队害老板了。

好啦,AT君的经验就分享到这里了,终于在2016年的1月的最后一天的23点多完成了这篇博客,不至于让2016年的1月份只有1篇文章了!过几天就过年啦,AT君提前祝大家新年快乐,年终奖炒鸡多!