如何做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

《死亡空间》大佬的分享

我看到了一个youtube上的视频:

How Dead Space’s Scariest Scene Almost Killed the Game | War Stories | Ars Technica

国内没有翻墙所以看不到视频的小伙伴们也不用担心,你有2个选择:

  1. 买一个Chrome翻墙插件,网址:xiyou.io,谁用谁知道;
  2. 跳过上面的一步,看我下面的哔哔。

这位大佬叫做Glen Schofield,他的第一部游戏是1991年创作的,因此从业经历可以说是非常丰富了,关于他的具体介绍就看这里就好了:

https://en.wikipedia.org/wiki/Glen_Schofield

这里不展开说了因为说实在的我对这位大佬也并不了解,我想分享的是这位大佬在做《死亡空间》的时候思路是非常清晰的,请看下面的图片:

这张图上就是大佬在做《死亡空间》之前就定下的5个规则,并且后面分别为每个规则的重要性打上了分数:

  • 无UI(2500)
  • 角色从不说话(1000)
  • 分尸系统(7000)
  • 所有时刻都可互动(9500)
  • 任何东西都要创新一点(15000)

无UI这一条,大佬只给了2500分我觉得是给少了,因为《死亡空间》对于3D游戏的UI设计可以说是革命性的,他把所有的非叙事性3DUI都转化成了叙事性的3DUI,这难度可以说相当高。以前我专门看过一篇文章分析2D/3DUI以及叙事性与非叙事性UI的,想看的可以点击下面的链接:

http://gamerboom.com/archives/45431

或者如果你的英文很好想要看原文的话点这下面的:

https://www.gamasutra.com/blogs/AnthonyStonehouse/20140227/211823/User_interface_design_in_video_games.php

大佬还讲了他是从哪里获得的无UI的灵感的,答案是……潜水员,潜水员们的设备都是穿戴在身上然后一低头就能看见面板上显示的数值的。

永远不说话,大佬说的很直接,想要增强角色的代入感,因此主角从来不说话。大佬也说了这个设计的灵感是来自于《半条命》的Freeman博士的。当年我玩《半条命2》的时候因为主角从来不说话所以玩的过程中还是挺紧张的,因为《半条命2》的整体氛围还是很吓人的。阀门后来的FPS后续的《传送门》系列也延续了主角从来不说话的设计。

分尸系统,这东西就很有B级恐怖片的味道了,大佬决定为了角色设计了被各种怪物攻击各种地方死掉的各种方式,在分尸动画中主角的整个身体被分成了十几个部分,这有点像当年的《命运战士》。因为玩家总是死,所以观赏死亡动画反而成了一种奖励。

所有时刻都可以互动,指的是当进行CG叙事的时候,玩家的角色依然是可以操作的。这个其实也不算特别新鲜的设计了,很多游戏都有。这么做的好处自然也是为了增强代入感,你是很难在玩着玩着突然就被打断了强制你去看动画的情况下保持沉浸感的。

任何东西都做一点创新,但注意是一点创新,不是特别大的创新,比如刷怪模式稍微增加了一些随机性,比如主角的跺地板攻击,比如奇葩的等离子切割枪。这些都是在传统的第三人称动作射击框架内,但是只是一点点的改进就让整个游戏有了大不同。更何况视频中花了大量篇幅说的触手怪,大佬为了解决这个触手怪的问题,不惜让团队重做了游戏的射击机制,并且每种武器的设计动画都要加倍(因为要支持角色躺在地上开枪) 。事后大佬说最重要的还是通过制作触手怪,大佬的团队们学会了拆解任务,一次性做出来搞不定的就拆成一小步一小步的去做,确保每一步做出来的都OK。

大佬的分享精神非常好,他能明确的说出来自己想要的某一部分设计是来自于哪部作品的,比如场景设计受到了1997年惊悚科幻片《黑洞表面》的启发,前面说的主角从来不说话则是学的《半条命》,而没有UI则是来自和游戏完全没关系的潜水员。这说明了积累丰富的生活经验和广泛阅读大量优秀作品是非常重要的,但更重要的还是要有解决问题的方法,大佬之所以是大佬,不是因为大佬看过《黑洞表面》,也不是因为大佬玩过《半条命》,更不是因为大佬潜过水,而是大佬在游戏制作的开始就定下了5条规则,并且当团队遇到了困难的时候能够通过逐步分解的方式带领团队解决问题,并且为了达到一个目的而要花很大代价的时候有拍板的果断,这才是大佬之所以是大佬的原因。

主属性脑洞

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

为了做到这一点,我决定首先分析一下其他游戏是怎么做的,那么第一款应该拿出来说的,也是我产生我想要设计一款前面提到的游戏的根本原因,还是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这种经历了几年的更新后已经趋近于没啥新东西可做的游戏来说,开一个新的维度也许是一个让游戏能再续上好多年的好手段。

一场撕逼:UGC游戏平台是否可行?

前几天在QQ上和策划无双展开了一场关于UGC平台的撕逼大战,最终没啥结论,但在撕逼的过程中形成了一些思路,整理出来遂成此文。

一切都是从Roblox开始撕的

《Roblox》,据说国内有一款山寨的产品叫
《源码部落》

Roblox是个啥?是个向玩家提供开发游戏的简易工具,并让玩家可以把自己开发的游戏发布至Roblox平台供其他玩家一起游戏的面向低龄用户平台(主要是小学生)。在这个游戏中凡是大于13岁的玩家年龄统一会显示成13+,并且年龄是和玩家名一样重要的元素并列进行显示,因此可以看出官方对于打造其小学生定位所付出的努力。

能自己做游戏然后上传的平台?很耳熟是吧?

没错,听起来就跟当年《魔兽争霸3》的各种对战平台差不多(当然了现在已经有了官方的魔兽对战平台),或者说像是《星际争霸2》的“地图大厅”、《DOTA2》的“游廊”:一个内容消耗平台或者说社区,大量的内容消耗者消耗着一波创作者所提供的内容,因此本质是一个内容消耗型的UGC平台或者说是社区。

所以从性质上来说,Roblox和橙光、抖音是一样的,但是为啥Roblox上线了这么多年没人听说过呢?

或者说为啥《魔兽争霸3》的对战平台,《星际争霸2》的地图大厅还有《DOTA2》的游廊都凉了呢?

我觉得,这就不得不面对内容消耗型UGC的平台的三个致命问题了:

  1. 创作者为什么来你这个平台?
  2. 用户为什么来你这个平台?
  3. 平台的极限在哪里,或者说盘子有多大?

先有鸡还是先有蛋

先回答问题1还是先回答问题2,这是个特别难以回答的问题,这说白了是个先有鸡还是先有蛋的问题,即到底根本性的服务对象是创作者还是用户。

按我个人的理解,这种UGC平台根本性的服务对象是创作者,其次才是用户。在这种平台的早期,核心用户肯定是创作者社群,并且这个群体中会有很多的大神会成为意见领袖拥有众多粉丝,只有抓住了这一批创作者用户,平台才能有足够优秀的UGC内容,有了内容才有运营的基础,才会存在引爆的可能性。到了平台的后期如果已经进入稳定阶段了,服务对象更是创作者了,甚至可以从创作者这里进行牟利,比如渣浪微博,你懂的。

按这个逻辑来说,B站服务的是up主,《星际争霸2》和《DOTA2》服务的是MODDER,橙光服务的是AVG作者,抖音服务的是……抱歉我不玩抖音所以不知道抖音里面发视频的叫啥,但道理都是一样的。

如果我们把这种平台比喻成一片农场的话,那么创作者群体就是在里面辛勤耕作的农民,而消费者群体则是来消耗农产品的客户。假如我们即不对创作者群体收费,也不向消费者群体收费,那么这一部分成本就必然会转嫁给第三方,比如广告商。假如我们对消费者进行严格的收费,那么就会变成一个订阅制或者说会员制的平台,就像Netflix。假如我们对创作者进行投资,对消费者进行收费,那就变成了传统的出版业。假如我们对创作者进行投资,同时对消费者即允许免费也允许氪金的话,就变成了直播平台和大部分网文平台的模式。各种模式哪个好用,以我个人的水平还是很难判断的,但无论如何,要求客户花钱的模式在中国估计是行不通的,给免费用户解锁大部分的内容是最常见的。

这就是为啥《星际争霸2》凉了的原因,因为他是个付费游戏,不管是创作者还是消费者都需要先掏钱买门票,注定凉凉。

如何吸引创作者,我觉得分两个方面,即这个UGC平台的下限与上限。下限,我指的是参与UGC平台进行创作的门槛有多低;上限指的是UGC平台所能产出的最高品质的内容是在什么水平。下限越低起步越容易,创作者群体数量越多;上限越高平台的质量越高,能吸引来的用户越多,平台的极限越大。

再说回《魔兽争霸3》的例子,其下限并不低,因为学习其编辑器是很难的,没有任何程序基础的人想要入门要花少不少的功夫去学习;其上限在当时来说是很高的,因为可以诞生《DOTA》这种级别的作品,但随着时间的推移,其画面的过时让其上限不断贬低,《DOTA2》出了之后就已经沦为非常小众的平台和工具了。

然而橙光就不一样了,其下限非常低——AVG类型的游戏不需要任何代码知识,平台提供了大量的背景、音乐、人物素材,所以随便是谁都可以参与创作。其上限又非常高,因为AVG类型的上限并不依赖于硬技术,美术、音乐,以及最重要的剧本水平都是软实力,因此其存在不断产生爆款的可能性。我个人认为这也是为什么66rpg要从RPGmaker转型去做AVG的原因,正是因为他们看中了其超低的下限和超高的上限,从而放弃了在技术上落后的RPGmaker,完全避开了这一类的短板。

类似的,从这个角度来看抖音的话,其下限非常低,因为只有十几秒的短视频随随便便谁都可以参与创作(微信的视频只有10秒我认为也是这个原因,一旦视频是几十秒甚至几分钟,那么对于一般人来说是很难创作出品质尚可的视频的,会大大打消其创作积极性,提高下限);其上限非常高,因为抖音并不提供专业的视频编辑功能,上面发的视频可以用现有的专业视频创作软件进行创建与发布。这是抖音成功的一个基础条件。

然而,橙光和抖音的区别也是十分明显的,就是橙光受制于AVG这一种游戏类型,因此其平台的极限必然是比不上抖音这种全民级产品的。短视频是目前在移动设备上能够体验的最佳的媒体形式了,受众极其广泛;而AVG这种几十年都没怎么变化过的形式,受众十分有限。橙光目前的做法应该是在想方设法拉网文的用户,但目前结果如何我还不太清楚,但短时间内应该还是没法撼动或者说代替网文这一形式的,因此其平台的极限,可预见的未来内都看不到明显的爆发点或者说突破口。

再说回Robolox

再说回Robolox,其定位为什么是小学生,这个答案就呼之欲出了。他们的创作工具非常简单,因此小学生都能入手,这是其最大的卖点。市面上总是会蹦出来宣称不会写代码也能顺利开发游戏的各种轻量级引擎和编辑器,他们都是在打这一个卖点,而Robolox所更进一步的是它不满足于自己的工具属性,而是想要做平台。

但是,UGC内容的下限和上限在游戏开发这个领域中往往是矛盾的,越易于掌握的工具为了降低其理解难度,其模块化越强,但泛用性或者说专业性也就越差。打个比方,如果说专业的游戏开发引擎Unity可以类比于视频编辑领域的AE或者PR这种软件,那么Robolox大概相当于爱剪辑这种水平的货色。美图秀秀也是一样,作为一款为没有P图技能的人提供快捷P图的工具,其上限必然是低于PS的,因此如果在它的工具属性上想要转成UGC平台就必然面临着所有的内容没有一个能打的情况,甚至像直播平台一样,三俗网红脸满地都是,这是其下限低而上限又不够高的特性所必然导致的结果。

Robolox自己也明白上限太低了,没法跟专业的开发工具所开发出来的内容打,因此他们降低了目标群体的年龄为小学生,这部分用户都没有什么大型游戏的经验,因此对画面烂体验差的游戏的包容度更高,而且比较简单的玩法只要还可以也能够玩的津津有味,因此Robolox在这一块上是非常聪明的。

但是,也因为其限定了群体就在小学生之中,因此永远无法和专业的游戏开发工具相提并论。

那么为什么Unity不搞UGC平台呢?

如果我们按这这个思路继续往下推进,就变成了这样一个问题:为什么Unity不搞这种UGC平台呢?我做个Unity Store上面都是用我Unity开发的游戏,不好吗?Steam上、AppStore上、Google Play上充斥着大量用我Unity做出来的游戏,我为什么不直接把这些玩家都直接攥在手里呢?

答案很简单,因为Unity的下限太高了,不是专业的开发人士压根没法驾驭这种工具。游戏开发是一种下限极高的生产活动,这就导致了游戏开发行业和用户的距离是很远的,很多的游戏玩家压根不知道游戏引擎个啥,什么是网游什么是单机也分不清,更不用说知道不知道Unity是啥了。

因此Unity的做法就是服务好开发者群体,提供针对开发者群体的教程、社区、各种工具、各种演讲各种活动,这就行了,它们是基本完全不在乎更下游的游戏玩家群体的。

我们可以想一想还有哪些是下限极低上限极高的活动,有可能做成UGC平台。

做饭算一个,下限低上限高盘子又大,下限低到了人人都可以做的地步,但上限高到了米其林三星餐厅那呢。但是这种产品已经有了,比如下厨房,抖音上也不乏这种东西。但是这种产品有一个问题就是你只能看别人做,又吃不到,因此其教人做饭的工具性过强,大家就不怎么在乎其他人的UGC内容了,我只看菜谱不看菜这是最大的问题。

唱歌算一个,下限低上限高盘子又大,人人都能唱歌,上限在帕瓦罗蒂那呢。但这个产品也有了,全民K歌什么的。但这种产品难做在大家唱的歌都不是原创的,而是唱的市面上的歌,市面上的歌你要搞到自己的app或者网站里面就会面临版权问题,那么这种app除了业内几家有音乐版权的大厂子以外也都不用想了。

那就不存在下限低上限高盘子又大的游戏UGC平台吗?

我觉得不存在,原因前面已经说过了,在游戏开发这种高技术生产活动中,下限低与上限高是矛盾的,能走的只有一条路,就是专精服务某一部分用户。橙光选择了开发下限低上限高的AVG品类与对应的用户,Robolox在上限不足的情况下则通过年龄来筛选用户。

被66rpg所抛弃的RPGmaker在日本也是有着固定的一小撮Free Game群体,这我还基本都是从岚少那里看的,日本有个也算不大不小的用RPGmaker做恐怖游戏的圈子,但这个群体还是太小了。Mugen是一个专门做格斗游戏的UGC圈子,同样也是下限很高,圈子太小。和橙光相比,这些都太小太小了。

另外,游戏UGC还存在一个问题就是大部分玩家并没有游戏设计技能,因此就算他们有开发能力,制作出来的游戏的可玩性也不一定有保障,不管是《魔兽争霸3》的地图还是Mugen里面的各种格斗角色,都有相当一部分是胡high性质的,这也是一个问题,不管下限是低是高都是如此,在这种情况下上限要足够高就显得更重要了。

能否产生一个下限极低上限极高盘子又足够大的游戏UGC平台呢?这是一个我还没想明白的问题,大家如果有什么看法的话欢迎留言交流。