黑暗中的小步前进（上）

---持续性原型构造理念

By-solin 2016.4.22

关于这篇文章其实我已经酝酿了很久了，为什么选择在这个时候把它写下来，其实是最近在做一款新产品原型的过程中，又对之前的一些已知的理论进行了实践和整理。有了不少体会，所以正好趁着这个机会把之前想整理的内容梳理一下写下来。

为什么谈“原型制作”这个话题？

最近看一系列游戏设计及行业内的文章，大家无非在谈“抄袭”“山寨”“创新”等话题。案例也无非是对一些山寨游戏的唾骂和大成功的“皇室争霸”等等成功原因的剖析。这些现象的背后，我自认为作为一个开发者，需要精进的就是关于“如何进行原创设计”这一开发技巧的提升，而不是仅从现象去感慨芬兰寒冷的天气，漫长的夜和高福利带来的原创环境，而最近上海北京高涨的房价似乎又变成了另一个原创乏力的理由了。原创一定离不开一个科学的高质量的“原型制作“方法和理念。所以我想就我自己的一些认知和别人总结的一些理论和出发，谈一谈”原型制作“的一些技巧和方法。

大家如果读过《精益创业》这本书的话，应该对fail fast， MVP（minimum viable product）最小可执行产品这些理念不陌生。所有创新产品（不仅指游戏），快速面对用户，进行迭代，永远是提高原创成功率的重要法则。Supercell的cell团队理念也正印证着这个fail fast的理念。

而“持续性原型构造”就是把原型作为一个信息收集器，增加上图这个循环的次数，把每次循环作为一个信息收集的过程，从而在下次循环中更好地进行迭代。

在这个过程中，know unknown（知道自己不知道什么）是很重要的，设计永远是一个模糊到清晰的过程。没有任何一个设计师在一开始做产品的时候，就清楚知道这个产品的最终形态。所以明确自己想要的，明确自己不知道什么东西，不想要什么是原型构造中非常重要的环节。而我偏执地认为，只有将“原型构造”的技巧和方法磨练到了一定程度，我们作为一个开发者的原创能力才能真正意义上的进行提高。通过我自己从业的一些经历，我认为国内开发者，特别是一些大厂的顶尖开发者，在制作一款“高质量”游戏的技术和美术上，和国外没有太大差距，但是在原创能力上，其实距离还很远。这也是我愿意以自己的一些浅薄之见来谈论一下这个挺大的话题的主要动力和原因。

如何进行“原型制作”

关于Idea的生长

所有原创产品，我相信在设计之初，总会有一个种子。之前看过的两本书中对这一点印象非常深。一本是《皮克斯：关于童心，勇气，创意和传奇》一书中，关于皮克斯是如何让大家保持童心，敏感和好奇的方法，比如制造宽松的环境，及时的review讨论，对于故事本身的执着等等。另外一本是《盗梦空间》的剧本中，诺兰对于这个剧本十年前的这个idea的坚持。我相信所有游戏开发者，内心都充满着无数的关于一个新游戏的idea。这个idea的萌发有可能是被一部电影，一本书，一张图，一个游戏等等启发的。这个时候，这个种子就已经埋下了，但是大多时候，这个种子很快就会被淹没掉，也会被自我否定掉，就算不被自我否定掉，可能你写下来之后和别人讨论下也很容易被否定了。这种时候，千万记得保护一个idea的生长。方法有很多，比如：先把它记下来，然后每过一段时间，拿出来丰富它。拷问自己，为什么我会有这个想法， 它好在哪里？有没有更吸引我的idea? 多数时候，太多的想法会被自我否定掉，而那些留下来的，我认为就是所有游戏原型，属于你的最初的种子。一定记得时不时去浇灌下它，在合适的时候，它一定可以发芽。

下面就直接聊一下我认为可以直接实践的几种原型方法。

实践方法一：视频原型和美术先行原则

这句话我记得很多人都说过“graphic is gameplay”。没错，人就是视觉动物，任何脱离了视觉抽象出来的gameplay,要达到视觉原型一样的效果，费的力气永远是最大的。所以在你的团队有不错的美术同事的情况下，一定不要忽略他们，认为原型制作就是一个程序员和一个策划的事情，很多时候，视觉原型要有效的多得多。

举个很实际的例子。策划这么描述“A玩家武器在脚上，翻身踢腿，停留3秒，分别向前方，右方，后发发射一颗子弹，将BCD敌人击飞1.5米。“ 这个其实每个人都有自己脑海中的画面，并且还有很多人想，这个有什么好玩的？这个游戏是什么呢？

哈哈。分享一段这个游戏在原型开发阶段的视频：

大家感觉是不是和最终版本的味道有接近了呢？

其实这种方法在电影动画行业中已经是非常成熟的了。Storyboard这个事情就是为了这个事情而存在的，有兴趣的可以看这个视频：

在观看所有由storyboard组成的视频中，已经能将整个电影的节奏给表达出来了。后面的拍摄和表演，都是在这个架构的基础上，继续润色和升华。

实际应用中，之前的项目中，曾经使用过flash去进行动画演示战斗片段和操作演示，用AE去模拟战斗场面，用引擎自带的UE的Matinee或者CE的Trackview去演示关卡流程等。

视频原型本身有很多好处和限制。最大的好处就是传达性相当强，大家看了演示视频基本上都能认知到将来游戏大概的形态，这对提升团队继续开发及完善原型的动力是大有好处的。其次，你可以解放程序啦，程序哥哥们可以抽烟喝酒打dota+评论视频原型了。最后，视频原型其实制作的速度相比代码开发，还是会快不少的，这非常符合持续性原型构建的理念。

当然这么好的方法也同样也有不少限制。第一，你要有一群理解游戏，快速构建美术素材和视频剪辑能力的小伙伴，美术同学不怎么玩游戏的话，可能构建这种原型就比较困难了。第二，这种方法对游戏类型限制较大，题材驱动，故事驱动，情感驱动的游戏可能比较合适，但是机制驱动，或者操作性即时性较强的，可能视频原型的意义就不是那么大了。第三，原型信息折损较大，视频毕竟是视频，实际玩家操作，交互的感受还是有很大区别的。

实践方法二：纸面原型

顾名思义，就是不借助电脑编程或者软件制作进行游戏原型的制作。这本是以前的开发者们非常常用的学院派原型制作方法，只不过在这个抄袭拷贝层出不穷的时代，慢慢被人遗忘和放弃了。

作为美国游戏设计教科书的Tracy Fullerton写的《Game design workshop》中的第七章关于原型制作中，提到最多的就是关于纸面原型的部分了。另外安利一下目前摩点网众筹这本书的中文版已经完成了，5月应该可以正式发售了。

纸面原型的基础是基于规则的，这个和桌游设计很像，这边我觉得有一张桌游设计的流程图能省却我的很多废话。请看下图（来自狗头人系列之-桌游设计指南）：

从我自己出发，我的常用方法是主题先行，然后进行核心冲突和循环确认。这其实是桌游中经典的美式和德式之风。你是希望一个战斗的？资源收集的？冒险的？交易谈判的？领主争夺的？确认了这些之后，就开始脑洞各种规则。一开始的规则不用特别在意好不好，觉得符合初衷的就留下来，然后尽快运作起来第一个版本。通常来说，第一个版本自己和自己打数盘之后就能有很明确的是否有继续细化的动力了。而第二个版本相当关键，因为第二个版本是需要和别人（最好是游戏开发者）玩的，所以你会使上120%的劲让这个原型看起来和玩起来一样“带劲”，这时候找一些素材图和精美的棋子和彩色打印的地图，会让这个原型吸引力倍增。这个也是进入进一步迭代的重要前提。

当然纸面原型其实最重要的环节还是在playtest环节。为什么第二个版本最好要找游戏开发者过来，其实主要是为了排除其中的一些干扰因素，开发者会过滤掉一些不完善的规则，简陋的地图卡片棋子小人等等。每个人对playtest的环节使用方法不同，我就按照自己的方法简单描述下。

1:自己1v1测试：最好找到你最熟悉的一个同事（无所谓工种），熟悉程度是能对你直言不讳不客气的那种。然后自己和他对局，在对局和解释规则的过程中发现问题。

2：观察1v1测试：找两个同事（最好是避免是此类游戏的狂热用户，且不认识），然后解释规则，让他们对局，观察-记录-访谈-总结。

3：继续观察1v1测试：找两个同事或朋友（此类游戏狂热用户，两人互相认识），然后解释规则，对局。对局之后让他们两个进行讨论。观察-记录-访谈-总结。

一般来说，经过上面3个阶段的测试，你应该对自己的这个纸面原型有了一定的认知了。这时候是时候判断这个原型是否有继续深入的价值了。

然后我推荐几个快速做纸面原型的工具：裁纸刀（台式的那种，工具提升效率，真心的）。然后软件的话Photoshop, 如果做卡牌的话，MSE(magic set editor)绝对是不二之选。如果做版图类桌游的话，可以用一个兵棋推演软件ZunTzu，这个软件会让你以上的playtest流程远程进行且多次发生。

当然，纸面原型一样有着诸多限制和不足。

1：类型限制，操作性强，空间性强的即时性强的都比较勉强。但是做回合制，战棋类，战略类的都非常合适。

2：测试演示繁琐，还是只能局限在一个很小的范围内进行个别人数的playtest。无法像一个正常电子游戏一样快速交给很多人进行playtest（毕竟你没有一家印刷厂）。

3：不直观，对规则迷恋的设计师们往往会写一本厚厚的规则书。很多非桌游爱好者往往见到一堆牌和一本规则书已经头痛了，然后你再反复去追求一个晕乎乎的玩家“怎么样？到底感觉怎样啊？”

实践方法三：暴力原型

其实这个词是我生造出来的，在以上两种常规原型方法之外，我觉得最适合大家去做的，应该就是这个方法。何谓暴力原型？就是采用一些已知的技术和方法，在“快”这个唯一原则下，进行原型开发。

Prototype≠PreProduction。在这个原则下，一切hardcode，一切不正规的开发方法都是可以被接受的。忘记数据表，忘记架构问题，忘记pipeline，忘记性能消耗，把脑海中和文档中描述的机制，竟可能快地实现出来进行游戏。Gamejam是一种很好的进行暴力原型的训练场。

游戏原型很多程度上被复杂化了，其实“原型”这个词在很多互联网企业中都会被理解为“交互原型”。而手机游戏的设计很多情况下用一个“交互原型”其实蛮能说明问题了。一般大家常用的axue,justinmind这些我就不另外详细描述了。可以搜索“15款优秀移动APP产品原型设计工具”。

如果你是一个程序哥哥，那就用你最熟悉的语言，最熟悉的引擎，最简陋的模型和贴图，去快速coding实现它。

如果你是一个美术妹妹，你除了可以使用实践方法一的视频原型之外，那你还可以快速魅惑一个程序哥哥，鼓励他去快速代码实现出来。

如果你是一个策划屌丝，那你什么都干不了了。你还是回到你的纸面原型看着自己的小兵人互相打架吧（笑）。

多说一句，在这个连小学生都在玩Minecraft的时代，工具的易用性达到了一个前所未有的高度，如果你没有冲动去尝试一两个，何苦做游戏？关于这个我会继续写下一篇关于如果使用一些可视化编程工具进行原型构造的具体方法。

这里简单罗列下之前用过的一些可以制作原型的引擎及小工具的利弊，供挑选。

Scratch:一个7岁以上小朋友就能用的2D可视化编程工具，虽然看上去幼稚，但是定义变量，控制，移动等都很全面，近两年貌似台湾那边小朋友电脑课就学这个了。

Kodu: 是微软的一个小工具，用很简单的一些事件命令可以写一些小游戏。听说以前维塔士笔试策划就是用Kodu做一个小游戏原型。

Rpgmaker&橙光游戏：不得不佩服橙光，从一个同好社区如今已经成为一个平台，做AVG和Rpg的可以直接用，很好用简单，关注故事和表现本身就可以了。

Gamemaker: 2D游戏原型的福音，7.0开始就很稳定了，编辑一些基本逻辑都没问题，目前资源和案例都很多。

Unity+playmaker:playmaker本是unity的一个状态机插件，但目前看来这个插件的逻辑能力还是空间很大的，很多简单逻辑都可以通过这个实现。

UDK+kismet, UE4+blueprint,之前对kismet接触较多，用UE去实现原型其实看起来好像是一个顶级引擎会很困难，其实相当易用。但是性能么就不好说啦，不过原型嘛，谁关心性能呢。

CE+flowgraph, 由于之前项目的关系，对这个应该是使用最多的，只能说又爱有恨吧，有兴趣了解的可以看我之前录过的入门视频：

不过目前CE被amazon收了之后我连打都没打开过，所以大家权当了解就好，感觉深入的必要性很小。

其实，以上那么多，原则只有一个“哪个你熟悉，哪个快，用哪个”。有一个数值策划的好基友，之前自己VBA和excel用得比较熟，就直接用VBA写了一个新游戏的战斗模拟器，可以配装，可以配技能。在我看来这也是很典型的“暴力原型“的一种。

暴力原型当然也会有一些问题。就是原型本身和最终成品之间差距的问题，由于要快，所以很多情况下质量上面会忽略很多。这里有一些取舍原则：

1：找到确定自己不知道什么（know unknown）

原型很重要一个作用就是信息收集器，所以肯定有很多模糊和未知的东西。未知不可怕，但是不知道自己什么不知道就很可怕了，所以原型中要留下的东西，一定是能让自己确定有哪些还不知道。

2：只制作核心规则，不做上层规则

这个其实说起来容易做起来难，感觉又可能讲好久，大家慢慢体会就好，是不是核心，很多情况下只有你自己判断了。

3：不要放弃和过度简化视觉传达

很多人认为，既然要快，那美术上能简则简。其实猎天使魔女那个原型视频很能说明问题

虽然在美术上的极简传达，但是基本关键帧，镜头，节奏，人物剪影和最终成本差距不大。所以视觉上还是要把结构，剪影这些最好能做出来，毕竟一堆方块人对打很难让人想象最终游戏画面。

感觉洋洋洒洒又写了好多，非常感谢看到最后的同学们。写此文的目的非常简单，就是希望拿自己实践的方法和看到的方法和各位开发者进行探讨和批判。最后安利一部被别人安利的番《白箱》，相信唯有精进游戏开发的方法和技术，国人们才会对游戏开发这个职业多些尊重和理解吧。

“failure is an option, but fear is not”-James Cameron

参考资料及推荐书籍：

游戏设计的艺术-The art of game design

游戏设计梦工厂-Game Design Workshop

狗头人系列之桌游设计指南

推荐关注作者的微信公众号，会分享一些他们游戏的开发日志，搜索Solingames即可