分类
未分类

如何做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君能意识到这一点,并且尝试设计一个能达到同样设计结果的更优秀、更好玩的模式,那才是靠谱的策划,脱离了玄学的策划,一个有益于所有人的策划。