《Robot Bros.机器人兄弟》诞生始末

编者按：文章来自 CocoaChina 开发讨论区，《Robot Bros. 机器人兄弟》是 iPhone 上面一款比较热的 3D 创意休闲游戏，由 108K 工作室开发，本文讲述了开发这款游戏过程中的诸多细节，值得从事移动游戏开发的诸位学习和借鉴。

　　（一）

　　一开始我们想模仿三只小羊，做一个合作通关的小游戏，当时打算直接换种动物，三只小狗或者三只小猫什么的。我们把三只小羊的截图，迅速把游戏原型给做了，用的是 Unity 官方那个 3d 横版游戏的控制脚本，角色的行走，摄像机跟随什么都是现成的，转成c#就完事了。

　　后来看到一则新闻，说在 Android 上山寨三只小羊的开发者被告了，产品被强行下架。这则消息打消了我们直接山寨的念头，于是我们考虑换个差别大一些的主题。我们以前上架过一款《Robot Factory》，正好可以继续沿用机器人的主题，说不定以后可以形成系列。参考三只小羊的幼羊，瘦羊，肥羊的区别，我们最初也是考虑体积不同的机器人：一个弱小的，一个细长的，一个重型带坦克履带的。正讨论着，团队一哥们说了句“让机器人去跳弹簧床，玩跷跷板什么的，会不会太弱智了？”。大家集体沉默…..-_-!!! 然后我们想到了给机器人增加不同的技能：冰，火，飞行，护罩等等，利用各种技能的组合来解谜通关。大家都很认可这个设定，成了，那就记录下来。

　　然后，然后我们没有开始做。我们接了两个外包，都是火烧眉毛的活，价钱还可以，于是游戏搁一边，跑去做外包了。

　　然后貌似又过了三四个月，我们重新拿起这个案子。当时我们已经针对这个案子写了十几页简单的策划文档，其中还设计了七八关示范关卡。

　　仔细分析一下当时的整个案子：

　　- 策划/游戏性：合作通关这种游戏模式不错，目前 AppStore 上同类的还不多，貌似就记得有个巴比伦兄弟。关卡方面可以参考三只小羊，弄几十关应该没问题。

　　- 程序方面：基本都是现成的，直接参考 Unity 官方的例子就行了，技术风险几乎为0，还有比这更爽的事情么？

　　- 美术方面：2D or 3D? 我们犹豫了一会。2D 游戏的话貌似目前国内随便一个 iOS 团队都能做，我们做 2D 或者 3D，工作量其实没差多少。为了显示与众不同，不如就用 3D 吧，就这么定了。

　　我们觉得整合出这么一个案子实在太幸运了，风险绝对可控，实现时间应该很快，一切都是“应该没问题”。我们越讨论越兴奋，仿佛成功就在眼前。然而接下来的几个月证明，上述的想法有一半以上都是错误的。

　　（二）

　　正式开发了。

　　首先进入的是原型(Prototype)阶段。

　　对于版本的定义，我想要特别注明一下，一般情况下我们开发的阶段如下：

　　1. 原型 Prototype 阶段。实现游戏的必要技术验证；做出一个最简单的只有 1 关或者 1 个场景的的游戏原型。

　　2. Alpha 阶段。完善游戏角色的逻辑，定义完善的数据结构和关卡配置，制作游戏 UI，菜单 UI 等。产出一个能玩若干关卡的版本。

　　3. Beta 阶段。完善逻辑，批量制作美术，关卡或者其他游戏内容，细化 UI 等各方面。加 IAP, GameCenter 等。

　　4. Production 阶段。测试，修 Bug，图标，截图，多语言说明，多语言枪文，视频录制等等准备上线需要做的一切事情。提交上线。

　　按照上面规范，机器人兄弟原型阶段的任务为：

　　- 实现游戏的必要技术验证；

　　- 美术方面使用 1 个机器人，以及一些简单的场景物件。

　　- 做出一个最简单游戏原型，只有 1 关即可，能玩就行。

　　原型阶段的美术需求，交给外包美术团队去做。要求外包团队先出一个机器人样本，以及一些关卡的场景物件。我们也不能干等着停下来什么都不做，Unity 那个官方例子不是有一些美术资源么，我们就先拿来用吧。这个过程并没有什么问题，我们三下两下就搞定了。之后就是等美术原型出来，等了很久。这个项目我们没有让美术先行是个极大的错误。

　　这个阶段其实更多的时间我们还是在处理外包的项目，是一个 app，虽然号称已经完工，但客户仍有些边边角角的东西需要改，以及 bugfix 什么的还没彻底了结，所以游戏原型阶段折腾了近一个月。

　　（三）

　　原型阶段结束后就是 Alpha 版本阶段。

　　原型阶段和 Alpha 阶段其实没必要做太明确的区分，最大的区别就是美术效果。尤其我们团队核心成员都是程序员出身，在项目进程中往往是程序产出远远快于美术。

　　在项目的前期，把准备功夫做足了，后面会越做越轻松，否则在中后期把前面的活推倒重做，将会是团队最大的灾难。

　　项目前期最重要是产品策划。

　　一开始我们设定了 8 个机器人，各自有不同的技能。冰块，火球，飞行，传送门，变身，替身，穿墙，无敌护盾等等。我们以前玩过一些 flash 游戏，里面的主角有折叠空间、90度场景旋转这些技能，但考虑实现起来不容易，就放弃了。这个时候我们一味贪多，希望把能想到的都记下来。在图纸上画了几关示范关卡。关卡部件想到了十多种，尖刺，升降台，按钮开关，把手，断桥等等。

　　在操作控制方面，我们曾考虑像 chop chop ninja 那样，不使用虚拟按键，而是让玩家在屏幕上随便点，我们靠检测用户点击区域判断行走或者跳跃。可是这样对于飞行机器人不合适，另外机器人还要释放技能，必须给他们一个技能按钮，几番权衡，又用回了虚拟按键。

　　更详细一点的细节，一开始冰块机器人是可以无限释放冰块的，大家认为这样设定太无敌，还容易出 Bug。那么设定冰块的有效时间吧，冰块出现 10 秒后自动消失，但这样紧迫感太大，不休闲。最后我们权衡选择了限制冰块的个数的做法。那么冰块的个数在哪显示？在右上角画个小冰块图标然后显示数字？每次放冰块时候飘出一个数字？最后我们用了一种最简易的方法，就是直接在冰块技能按钮上面显示，每放一块冰数字-1。 后来让朋友试玩时，果然这个设定无需我们多余的解释。

　　冰块是如此，那么飞行机器人是否要限制飞行的时间？或者限制连续飞行的能量，也就是所谓的气力值？最后我们的决定是什么都不加。

　　…….

　　…….

　　大家看到了，这就是做原创游戏要遭的罪，以及它具有的魅力。每一个想法都可以扩展出无限种可能，但任一种可能也许会带来其它负面的影响。我们认为某款游戏某个设定非常棒，想把它纳入我们游戏里时，发现还必须连带加入更多。

　　在这个过程中，我们绝对不能对自己说“这样也行，那样也可以，或者另一个都 ok”，我们必须整理出一个整体的方案，它不一定是最佳，但必须是完整的。也就是在这个过程中，我们切身体验并学会了”减法“。知道什么东西可以不要，什么可以精简，什么一定要保留。我们现在下载 Top25 的游戏玩，看到游戏里的玩法，数值，UI 等各种设定，马上会联想到是否有改进的余地，这些都是在走原创的路上积累的经验，倘若一味山寨，是不可能有这些体会的，更永远不能感受到游戏设计的乐趣所在。

　　其次是程序方面。

　　项目初期架构要搭好，切忌做一点想一点。什么数据结构，模块接口什么的就不必多说了，最重要的是要为以后添加游戏内容提供便利。机器人兄弟这款游戏属于关卡型，将来版本的更新肯定是不断加关卡。同时我们也必须为将来添加新机器人提供便利的接口。

　　一开始我们打算搞一个独立的关卡编辑器，将关卡内容存成 xml 或者是 json，到玩的时候再导入解析，这样将来也许能让更多朋友参与关卡设计过程中，许多知名游戏都用过这招。但中途我们改变了想法，首先这样重复造轮子未免太费劲了，毕竟 Unity 的 IDE 本身就是一个极佳的编辑器；其次一些关卡物件需要特定的设置，譬如要用到多个 Joint 的连接等等，这些在独立编辑器里再实现一遍太困难了。于是我们决定先在场景里摆放好关卡物件，然后存成 prefab，以前我们做 Devil Golf 游戏时就是这么干的。无奈 Unity 的 prefab 实在是弱得让人蛋疼，用过 Flash 的都知道，跟 MovieClip 比，prefab 就是屎。不支持嵌套、自动更新又存在 bug 的 prefab 肯定不能应付复杂关卡摆放。最后我们无奈地用场景来保存关卡设定。这对于关卡数量多的休闲游戏简直是一个噩梦。

　　开发各个机器人的技能。这个其实没太多要说的，这些都是由我们团队的 Ken 一个人完成的（场景物件的逻辑也是，哦，菜单 UI 逻辑也是）。Unity 官方游戏的脚本仅仅提供了控制人物行走的范例，可以参考的东西极其有限，真正开发中，每个功能都必须从头一行一行写。

　　我们在原型阶段犯了个错误，因为我们比较懒，产品一直没有放到真机上跑。导致在 Alpha 阶段快结束时，放到真机上，才发现操控感非常糟糕，行走速度，跳跃高度都需要调整。但一旦调整，连带的代码，场景关卡都会受影响。Alpha 阶段尾声，开发任务已经比较重，当时我们做了少许的调整。好吧，这一系列操作感的不适，一直带到 Beta 版，上线前我们小修了一下，早已积重难返。现在产品上线快一个月，用户评价将近一半都是对操作有意见。所以大家务必要切记，产品一定要尽早上真机，越早越好！！！

　　最后说说美术方面。

　　传统游戏开发都是美术先行。在产品前期光有概念时，各种原画，人设就呼啦啦出来了。我们小团队可没有这么幸运，有一堆原画可以随意使唤。我们找原画可是要按件算钱的，这个价钱还虚高得厉害。我们不否认传统的作业流程，但对于各项资源都有限的中小团队，必须认真考虑把资源用在刀刃上。

　　游戏前期的技术验证除了程序验证以外，另外还要有美术效果验证。美术效果验证的目的就是要让团队里每一个人都能明确的看到，游戏做出来是什么样子的，要有最直观的影像，就好比搞房地产的开发楼盘之前，先请人喷几幅精美绝伦的效果图一样。

　　如果团队里有比较牛B的原画，就让他先出整个游戏的效果图，最好跟策划一起，把 UI 的草稿什么的都画上。对与 iOS 项目来说，别花太多时间去搞艺术创作，就算是画 CG 也得考虑将来游戏里用得上才去画。最重要的是，先把游戏运行时的画面描绘出来。

　　如果团队里没有原画，外包的原画多半又不靠谱，这时候怎么办？只能靠自己去抠图，去拼合。既然是出来创业，技能太单一的话肯定走不远，基本的 PS 抠图总得会一点吧。实在不行找个初级的美工也能做到这些。

　　（顺便说一下，如果是山寨的话，前期的策划和美术效果验证基本就可以免了，都是照抄）

　　上面这些我们都懂，也都会，可是还是犯错了。错在美术风格的选型上。

　　我们本来打算沿用 RobotFactory 里的卡通机器人，那几个机器人造型是我们原创的，朋友们对它的评价还挺高。本来这个游戏用 2D 来做就挺好的，但是当时我们中了一种”2D 谁都能做，用 3D 显得我们更牛B“的毒。然后跟外包美术那边商讨美术风格时，对方极力推荐写实的金属风格，像钢铁侠那样的。我们一下就联想到电影里那闪闪发亮的钢铁铠甲，不禁悠然神往，就这么定了，写实风格！！ 其实我们的决定也并非盲目，之前我们自己有试验过 3D 的高光贴图，法线贴图什么的，这种技术验证我们以前实践过，确保是可行的。

　　我们确定了写实风格的美术。

　　然后过了几天，美术给我们看机器人和场景的原画稿，是卡通风格的，非写实。对方说到时候画贴图弄上写实材质就好了。

　　又过了几天，第一个机器人出来，还是是偏卡通风格的。这个过程中外包美术那边问我引擎支持什么样的灯光，支持什么样的材质，什么样的渲染云云。我说只要一张基本的贴图，最多加一张法线贴图。把灯光烘焙到基本贴图即可。又问我什么是烘焙…….

　　又过了几天，美术那边说写实效果不好弄，跟背景很难搭，建议做半卡通半写实的风格。新的贴图拿过来，发现要令其显示效果最佳，在 Unity 里只能用 Unlit/Texture 的 Shader，好吧，法线贴图已经和我们无缘了。

　　我们错误地选择了写实风格，然后在整个 Alpha 阶段，跟美术团队的写作过程，都称不上是美术制作，充其量是美术效果验证，大量的时间花在沟通和返工上了。

　　我们选择用 3D，虽然游戏制作过程中积累的宝贵的经验，以后会用得上。但是针对这个项目来说，2D 就能解决的需求，偏要上 3D，这是一种愚蠢的行为。

　　（四）

　　Alpha 阶段结束了，接下来进入批量制作游戏内容的 Beta 阶段。

　　这里有个插曲，当时 Alpha 阶段的产品就是冰块，火球和飞行 3 个机器人，五六个关卡，可以玩。我们兴冲冲地把它 build 成 windows 版本，发给几个要好的朋友，让他们评价一下。结果收到的全是负面意见。有的说场景视角太小；有的说机器人不好看；有的说 Bug 好多；有的直接就说不好玩。这直接又给我们泼了一盘冷水。但好处还是收回来不少建议，对我们接下来 Beta 版本的改进有极大帮助。重要的是，后来有一位同学参与的建议，比专业的策划都有用。

　　结论就是，千万不要轻易把非成品的游戏发给人看。

　　Beta 阶段的主要工作是批量制作美术素材和关卡。 外包美术那边的产出严重跟不上，滞后性严重，直接导致了进度的悲剧。在 Beta 阶段进行了两三周以后，我们盘点了一下产出：

　　- 场景 3D 物件十几个，返工了 2 次，算是确定了；

　　- 场景背景图做好了两张。（本来定的是用 3D 模型，后来换成 2D 的背景图）。

　　- 机器人 3D 模型+动作完成了两个，而且还没有完全定稿；机器人的特效不适用或者是用不上；

　　- UI 还没开始画。

　　我们才想起过去两个半月里，对美术的验收非常不规范。一方面是我们的标杆没有十分明确，需求没有完全确认；其次是时间点没有抓紧，本来说这周末（周五晚）验收一次，结果很可能拖到下周一二，一不留神就是下周五了。

　　这个问题非常严重，中途去追究责任也不适合，那段时间我们跟美术之间光协调就耗费了大量时间。协调的结果是缩减美术量，进度向后延。由原先的不同角色模型变成换贴图方式，美术风格由写实变成类卡通，取消某些项目的返工要求等等…如此又是折腾了一个多月。

　　在这里说说游戏美术，这种工种也是属于技术型。我自己也画画，所以十分能体会，这绝对是一线的，底层的，费时费神的工种。跟程序不一样的是，美术的工作不好忽悠，画了多少，画得好不好，都是明摆在那里的，每个人都能看得见。哪怕经验再丰富，哪怕积累了再多的素材库，真正干活时，该做的一样不能少。

　　既然是技术工种，肯定具备技术工种的特征。大家都听说过“文人相轻，程序员更甚”吧？美工也是一样的。你指着一幅图问美工：“这个效果怎么样？ 能做么？”绝大多数的美工会回答：“不怎么样，能做，肯定没问题。” 当然真正做起来又是另一回事了。

　　美工还有一点，危机感很强。美工一般不会像程序那样把源文件看得很重， 他们始终认为自己是随时可替代的，换个人照样能做。这得多亏了近十多年来各大美院的疯狂扩招和数不清的培训机构。

　　传统游戏公司里的美工，其实也命苦，这个项目完了马上又被借调到另一个项目里。他们不像程序那样可以玩神秘，不像策划那样善于辩论，常常因为上头一句话，所有东西都得推到重做。在这种艰苦的生存环境下，美工兄弟们也找到了一些应付的策略。譬如制定了严格的验收流程，从原画到建模到贴图到动作，每一步都要明确验收通过了才继续；譬如相互抱团，让美术总监罩着，抵御来自策划和产品那边的敌人；譬如学会扯皮，推脱需求，真正干活时多扯个几个人进来，把责任分散，避免单独承担，在不断开会讨论中大活化小，小活化了。

　　然后就是关卡设计。我们的立项的时候认为，这种休闲游戏，设计个几十关简直是“易过食生菜”。事实情况是，我们设计到十来关的时候，就感到江郎才尽了。我们参考的原型，三只小羊，其实只有十五关，另外又找了森林冰火人等几个解谜的 flash 游戏，艰难地炮制了 30 关出来，离目标 48 关还有距离。

　　与此同时，有一个问题始终困扰着我们，就是整个游戏的视野范围。一位玩过 Alpha 版的朋友认为，我们游戏的视野太小了，最好能够像吃豆人那样，整个关卡都在一个屏幕上显示。于是我们增加了缩放视野的功能，很多玩家为了搜寻场景里的星星，可能一上来就把视野放到最大，这个时候在 iPhone 上机器人只有黄豆般大小了，那我们非老大力气搞 3D 模型有啥用？

　　如果让我们选这款游戏开发过程中最难的环节，毫无疑问是关卡设计这一块。引用一句老话：“我们自己做的游戏，必须自己也喜欢玩才行。” 设计关卡不能仅仅是把障碍重复地堆砌，不能令玩家在玩游戏时感觉自己被玩了。

　　我们尝试了各种办法，抽象模型法，穷举排列法，图表配对法，随机组合法等等，目的是试验出各种不同的谜题。这个过程大杀脑细胞，堪比读书时做奥数题，而且我们还是在创作奥数题。说实在的，这个过程中我们不断怀疑之前的决策。譬如为什么非要搞原创，为什么非要自己设计关卡，为什么非要挑苦的累的难的活来做，直接去抄别人的多好。

　　看着勉强炮制出来的 30 多关，我们自己也不太满意，就在这难熬的时刻，一位老同学的建议，让我们霎时间豁然开朗。

　　当时我们关卡的编排是参照愤怒的小鸟那样，前 10 关里先让各种技能的机器人都出场一遍，随后就是不同的机器人自由组合堆砌关卡，从而延伸游戏。这样一来在第三大关以后，关卡会变得复杂无比，很多地方都是为复杂而复杂。那位老同学是在群里下载了我们的试玩版本，玩了以后觉得太冗余，他提出了好几个建议，其中两点最突出：一是简化关卡，减少冗余。二是把不同技能的机器人进行一个系统的编排，分布在每个大关里面。

　　这两点改进一下子把我们从辛苦的关卡设计工作中解脱了。原本我们还想着要多设计十几关更复杂的重度关卡，现在发现换一下体系，原先设计好的完全就够用了，顶多再增加几个轻量级的过度型关卡。同时改进后使得整个游戏的体系清晰明了。这就是后来大家看到的每个大关都以一个机器人为主题的设定，将来我们增加游戏内容，增加机器人，也是按照这种系统延伸下去。就算以后继续增加关卡，大体思路就已经界定，再去想关卡细节，就不会感到那么辛苦了。

　　貌似写了太多的细节。以往看别人的游戏，看到成品可能觉得没什么，认为自己也能做，同时还能挑出不少毛病来。但自己亲身经历过，感觉完全不同。举个例子，如果现在让我们去设计愤怒的小鸟的新关卡，该怎么设计？很多人可能想都不用想就回答：“直接往上面堆木块不就行了么？一天就能弄几十关。”或者说“让用户自己去设计吧…” 但实际上真的是那样么？小鸟再出续作，难道会随随便便堆些垃圾关卡来忽悠用户？偶曾经碰到过几个信口雌黄的策划，嘴皮子厉害，真正做起事来啥都干不了。大家引以为戒吧。

　　（五）

　　产品提交上线。

　　这个过程也没太多说的，之前已经提交过几款，所以没什么障碍可言。

　　截图，视频录制，视频处理，英文说明，关键字设定，推广文等等等等，都是这个时候准备。外包的美工做不了这些，我们是自己来。

　　扯了这么多，该说重点了。就说一下大家关心的销量吧。

　　上线前几天，每天是二三十个，一周后降到个位数。那个时候我们的心都凉了。辛苦这么久，却换来这个结果。

　　我们用自己的方式做了一下推广，没花钱的。视频也终于弄好。又上升到二三十个每天。

　　当时我们讨论了一下要不要花点钱做推广。后来一再考虑，还是先算了，等1.1, 1.2 更完善的版本上线，再决定是否花钱吧。当前的版本我们自己都不是很满意。

　　然后我们咬牙决定，免费！！限免了几天，平均每天 6w 多下载。多个国家进入过 Free 前十。总榜到过 Free 48。免费榜比较不稳定，没几天就下降了，我们对比了一下同期冲上 TopFree25 的，感觉不太容易冲了，于是改成收费。

　　改成收费后到现在，每天是五六十个，周末偶尔冲到八十以上。

　　限免那几天收到不少二星三星的，几乎都是批评操作感不好。我们相当惭愧。再次改成收费后，Review 就是四星五星居多了，不少玩家是玩过以后回来由衷地称赞，还在 review 中提了不少建议，十分期待更新云云。这点最让我们团队欣慰，这些星星不是让朋友友情打的，不是拿钱刷的，是来自玩家真真切切的赞美。这种成就感也只有做游戏才能享受到。

　　游戏的 rank 一直在爬升，我们有信心1.1更新后能达到每天一百五的量。不过话说回来，按照这个量，根本收不回成本，连我们一个人的成本都收不回。主要是因为前期决策的错误，导致整个项目投入过大。但无论如何，这个过程中我们收获了许多。做下一款游戏，又有了更高的起点。

　　当下普遍的论调都是认为，现在的市场对个人或者小团队是越来越困难了。的确是这样的。好的 idea 自然能让你事半功倍，但“事半”里头包含的工作量，肯定比一两年前要高得多，你或者你的团队能搞定么？所以，想进入这一行的朋友，最好先考量一下自己之前的积累如何，真正全职去做的话，单位时间里能制造多少产出？如果不能确保产出是高于整个 Appstore 市场水平均线，那么请三思而后行。

　　今年一年以来，不断有小公司关门；不断有某些业内单干的牛人被招安去上班；曾经在 Appstore 上捞到钱的公司，有很多再也没出新作。但与此同时，也不断有新的公司和产品冒出来，不断有奇迹发生。那些被报导的，没被报导的奇迹，我们知道都不是忽悠，是明明确确的在排行榜上呆着的。坛子里某位朋友说得好，目前我们是找不到能比 Appstore 更公平，更能产生奇迹的平台了。

　　纸上得来终觉浅，绝知此事要躬行，想干的话就放手去干吧！！祝大家都能在 Appstore 上挖到金矿！！