ios教程，用pc开发ios游戏

原文是Thomas Henshell对手机游戏Catch the Monkey的开发总结，由Lyra翻译。

传智播客今年6月开始ios培训（http://ios.itcast.cn）的课程；相对于一些应用，我本人对ios游戏开发更感兴趣，这些开发总结并不拘泥于技术，更多的探讨了开发过程。过程很重要，过程正确才能保证结果正确，没有正确的过程，一切方法都是纸上谈兵。

听听Thomas Henshell的总结：

许多人都想做游戏，特别是移动游戏。好吧，我们是你们中的一员。本文就是为想进入这个行业自己动手做游戏的朋友们写的。我们的目标有两个： 

1、告诉你这是可能的。

2、分享一些经验教训，或许能够帮助到你。 

我们这个叫Mirthwerx的团队其实只有两人：Thomas是自学成材的程序员，Alex则是毕业于Sheridan学院传统动漫专业的美术师。我们是高中同学，20年前就认识，从那会儿开始便试着一起开发游戏。 

在着手这个项目之前，我在微软干了15年，写一些web和移动终端的商业软件。因为有这样的背景，我们知道怎么样才能妥善地开发软件[面向对象的编程(OOP)、设计规格、易用性考量]。但后面你会看到，心里明白和实际做到是两码事。 

策划和原型 

技术 

从第一天，我们就知道自己想要两个东西： 

1、安卓是未来，但iPhone是当下。两个版本我们都会开发。

2、我们想用windows平台上我们熟悉的环境和工具来做开发。 

我买了台mac-mini来研究Mac平台和XCode。用了一天ObjectiveC后，我知道自己一点儿也不想用这种语言来工作，它会把我逼疯的。幸运的是，我们可以用一个办法同时解决这两个问题：Marmalade让使用者能在Visual Studio C++里写代码，却可以在任何平台运行(包括iOS，安卓，黑莓，Windows Phone，Bada和其他平台)。模拟器很棒，想要的性能监控应有尽有。对于独立开发者来说，价格也很合适。 

策划 

考虑到这是我们的第一个项目，我们想让app的设计简单些。最初的概念是这样的：农场里有些猴子，玩家划动手指来挠它们痒痒。每过一关，猴子会来得更快更多。就这么简单。 

在那时，它看起来太容易不过了，因为就俩人，我们觉得没必要做什么开发规范。我们用了Xmind来画思维导图，并把“策划案”放在那上面。这个游戏最初美术的工作量比较大，所以我们的美术就全职扑到项目上，而我只在下班和周末的时候抽点时间捣鼓一下。 

原型 

在商业软件开发里，最初的原型对用户来说至关重要。它把对文字描述的揣摩和猜测都撇尽了。 

我们并没有真的去做个原型，而是用了GameMaker 8，一个很强大却不算贵的游戏制作工具。它让我们可以把画好的图形和一些玩法机制凑到一起，来看看是不是已经弄出点好玩的东西来了。我估计我们的首个原型总共就花了20小时。因为它是在windows屏幕上跑的，所以没法测试真实的触摸/划动机制，于是我们就借助点击，每次点击模拟一个指划动作。这样，最大的问题就变成了：它好玩么？ 

不，不好玩。我们改了一些数值(猴子的速度、戳戳它们让它们发笑，一次来多少个猴子)，但还是太简单了。能做的事情太少，连2分钟都玩不到。我们不是要做一个“搞笑游戏”，所以又重头开始。 

头脑风暴过程中，我们想到了一个用不同工具让猴子们动作的主意。挠痒痒是最初级的工具，一根羽毛，后来你能得到其它工具。这下看起来有点儿戏了。我们于是构思了一些工具类型，删减到方便放到原型里去的几种，然后做了第二个原型。在这个版本中，玩家有了一个仓库来储藏各种工具。当一种用完时，农夫可以叫他太太来装满，每次装满之间要隔几分钟。这让玩家会去考虑什么时候用哪种工具。我们也把对农夫的控制交给玩家，他们可以指挥农夫到特定区域把猴子抱回来。最后我们还加入了捕捉星星的概念。每过一段时间，会跳出星星来，玩家需要通过点击来捕捉它。星星后面对升级会有用，尽管我们从来没有把它放到原型里去过。那么：这下它好玩了么？ 

是，也不是。似乎已经有了一个好玩的内核，但一些迷障始终把它困在里头。我们知道选择工具(作为策略)很好玩，捕捉星星(它是自然产生的，不同于核心玩法，并且很难)也很有意思。我们去掉了农夫的控制权(太费劲)，和补充工具的概念(太复杂也太随意)。我们需要一个让玩家能制定策略和管理资源的游戏机制。 

必须指出的是，做原型的时候，我们不只是闭门造车，而是听取了项目以外其他人的诚恳意见。自己在项目中的太容易对测试的结果心存偏见了。你们后面就会看到我们是怎么在这上面载跟头的。 

在第一部分中，我们介绍了Catch the Monkey从最初简单的概念，到技术选择，直至原型的过程。到原型完成时，我们已经有了一个进步很大的策划案。但因为没有经验，当时并没有把它们完整地记录下来。我们知道有12个工具要开发，有10种不同的猴子，和对商店的不甚清晰的想法。我们想让商店的购买可以升级，但到底升多少级，以及升级后能干嘛在那时都还不确定。该动手写代码了！ 

我们要不要做？！ 

正如上文提过，美术同学全职扑在这个项目上，而我作为程序员却还要干点儿别的，只能兼职写代码。项目于是被拖累了，最后到了因为没有进度项目要被砍掉的地步。所以，我计算了一下继续做这个游戏需要的时间。6周(50小时x6=300小时)貌似够了。我做了个艰难的决定：申请了6周的休假，回到自己的小屋子，专心一意搞这个游戏。我太太并没有大惊小怪，她支持我把游戏完成。是时候“全力以赴”了。回过头去看，继续项目的选择是对的。 

最大的失误 

没有一个合适的策划文档看起来成了我们最大的失误。我只做了个非常简陋的文本。 

如果你研究过《植物大战僵尸》会发现它有很多类型的僵尸，但他们是由几个图形(头、身体、胳膊、腿)和一些可选的饰物(假肢、头盔、报纸)组成的。如果把这些部件重新组合的话，你可以得到很多不同类型的僵尸，而只需要很小的存储空间。我们想要一个类似的做法来画猴子，使它们拥有各自的能力和缺陷。 

然而后来我们痛苦地认识到，如果你想要做到这种重复利用的话，其实需要为每个角色写下来非常周详的规则，哪些它们能做哪些不能。请注意，在《植物大战僵尸》里，僵尸永远面朝摄像机(就好像2D的《南方公园》动画)。无论做什么，它们都不会转过去给你看一个侧脸。 

可早在我们制作动画和原型的时候，我们就已经定下来，当一只猴子到达植物时，是一屁股栽下来的，转过去，开始挖掘。当它挖到土豆后，又会转身开始吃土豆。发现这个问题之前，我们已经完成了所有普通猴子的美术工作工。当我们想做一个戴帽子的猴子时，以为只要做一个单独的帽子把它按在猴子头上就可以了。我们开动了。真的完成后，我们发现，如果猴子从摄像机镜头前转身，帽子(或者背心，或者太阳镜)也得跟着转。这就要求每个猴子帧必须对应一个饰物帧以及像素精调，意味着每一帧都要大量苦哈哈的坐标分析，才能让它看起来比较正常。工作量太大了，我们又不想重画挖掘的动画，所以做了一个实验性的决定：把帽子粘在猴子身上，把普通猴复制到戴帽猴。美术同学就这么干了，如法炮制出另外6种猴子。 

这个问题的数学公式如下： 

1种猴子有一套行动精灵表(恐惧、愉悦、大笑、走路、攀爬，等等)，需要大概20mb的VRAM空间。 

7种猴子x 20mb=140mb VRAM 

在iPhone 3GS(iPod 3+)上只有约55mbVRAM(15mb的堆阵)以下的才不会崩溃。 

我们最初还考虑过iPod Touch 2+的，可它只有30mb的VRAM，所以没可能了。因此我们慌忙调整VRAM，使之符合iPod 3+的要求。我们在下文会更多涉及这部分。 

因此，教训是：永远都要在策划阶段就考虑内存要求，得在你写代码之前，而不是事发时，或者干脆事后才发现。我们要早知道猴子转身会带来的后果的话，早就在美术上调转方向了，游戏也不会做得那么辛苦。 

最后的10%用了90%的时间 

我们不知道建立一个发行商关系需要多久，所以开始把一个早期的原型拿给运营代理看。其中有一个说，游戏内核很好，有AAA游戏的潜质，但还需要做大量润色工作。当时我们觉得这个说法很蠢，认为平衡性教调和其他一些细枝末节的工作大概再2周时间能完成，然后就可以上线了。 

这便是游戏和商业软件的极大不同。商业软件的特性完成、所有单元测试完毕后，真的算是已经完成了80-90%的工作。集成测试会发现一些问题，但一般只是开发者和开发规范之间需要解决的误解。即时游戏集成测试占了全部工作量的大约一半，因为这关系到游戏元素各层之间的相互影响和依存性。 

移植到设备 

到目前为止，游戏只能在Marmalade的PC模拟器上玩。我们对它在真机上的表现(内存或帧率)心里没有底。而且因为美术同学完全没法测试游戏，所以单元测试也颇为受阻。该部署到真机上去了。 

苹果对于什么能放到它们设备上去非常谨慎。这有助于减少盗版，但也因此给开发者带了紧箍咒，你不得不签署你的代码，获取设备ids码和证书，才能部署测试到设备上去。 

如果你是在mac用XCode(尤其是最新版本)开发，过程就会比较简捷，XCode会帮你料理好。所有的苹果文件都会告诉你用XCode每个步骤该怎么做。而如果你是在PC上开发，就等着麻烦来找你吧。 

有两个必须做的事情：1)把你的机器设置成可部署iOS状态，和2)把你的项目设置成iOS发行状态。幸运的是，Marmalage 5.2版本里关于如何创建发行的文件比以往的版本要好得多。它包含了从如何创建证书的示范：上传到苹果，再下载苹果的证书，以及把它放在什么地方。 

设置PC的时候，项目必须设置和签署为发行状态。苹果的开发者门户会向应用签发设备许可的UDID。苹果提供一个签署项目用的配置证书。Marmalade有个部署工具，在发布时ARM就会出现。你把配置和OS具体选项输进这个工具(它会保存自定义的MKB文档)，它就会神奇地帮你搞定IPA，这样你就可以通过iTunes部署到你的iOS设备上去。 

前前后后，我大概花了10小时才把游戏弄进我的iPod。这是个极其重要的步骤，因为我们需要触屏来测试手势。 

让手势酷起来 

如果你还记得的话，我们的策划核心是玩家用手指划动来挠猴子痒痒。几个原型之后，我们需要一些其他工具来区分千篇一律的划来划去。最初对我们产生影响的是GameLoft的游戏“财政大战(Bailout Wars)”。玩家轻点银行家来干掉他们，但你还可以做其他的动作。 

我们研究了许多游戏，最后理出下面这个清单： 

点 
点了以后长按 
水平划动 
向下划 
向上轻划 
画圈(顺时针或逆时针) 
我们选择点、水平划动、向下划动和向上轻划。(我们一开始也采用了点后长按，但后来去掉了。)我们为不同工具设计了相应的手势：比如纸袋要放到猴子头上去，所以玩家要把袋子往下划到猴子的脑袋上。 

iOS和安卓支持多点触控(最多10点)，但我们决定只用一个点。一个触摸点就好像一次点击，为此我们审视了Marmalade里的s3ePointerEvent，用下面的代码行捕捉，放到通用的触摸变化上： 

void SingleTouchButtonCB(s3ePointerEvent* event) { g_Touches[0].active = event->m_Pressed != 0; g_Touches[0].x = event->m_x; g_Touches[0].y = event->m_y; g_Touches[0].when = (int32)s3eTimerGetMs(); g_Touches[0].handled = false; } 

现在我们知道手指在哪里了，这很好，但你怎么知道是在做一个手势呢？答案是，你得自己来编程。 

手指触摸屏幕时，手势开始。从这时开始，在它放开(手指提起)之前必须每隔一定区间就检测一遍目前的触摸点，必须分析其相对于原点的变化、点的进程和终止来确定所做的是什么手势。我用通用工具类别及其子类里的战略模式来实施每个手势识别。 

我解释了创建手势的原理，但要让它感觉“顺手”还得做许多优化。一样是简单的左右划动，每个人的手势都会不同，真夸张。有的人只是轻巧地划动10个像素点，而另一些则会霸气地横贯全屏。有人水平地划，而有些人则喜欢对角划。有些人划得太慢，机子记录不下来，有的人又划太快记录不下来(我们发现最“准确”的时间间隔单位是每个点50毫秒)。那天结束后，我们得出了一个非常严格的手势系统，水平划的像素比垂直多不超过20，已经足够宽松了。 

把剧情放在最后 

Catching the Monkey是一个动作游戏。我们要为玩家的动作设定一些故事背景，当然不需要写个《罪与罚》的小说。最初，我们的故事框架如下： 

南非的一个农夫拥有一片土豆田。当他和太太一起坐下来用午餐的时候，有只小猴闯进了田里。他跑过去看住那只猴子，但来的猴子越来越多。最后他赶跑了所有的猴子，回去吃他已经冷掉的午餐。结束。 

行了，我们可不是要去获奥斯卡最佳剧本奖的，对于游戏来说这已经可以让我们开始了。所以我们把重心放在游戏开发本身上，然后再回头来看故事剧情。 

大错特错！ 

当需要处理剧情逻辑的时候，我叫我的朋友Rob来帮忙。某个晚上，我们坐下来讨论故事。他开始问一些基础问题，而我却答不上来： 




这位农夫同学有钱么？ 
他跟他老婆的关系好么？ 
他的行为模式怎样：是没头脑型还是不高兴型？ 
他们在那儿住多久了 



这些问题看起来无聊到死，愚不可及！但事实上它们不是。从研究中我学习到，写小说之前，你得先有个角色。于是Rob和我开始定义角色。 

整个游戏过程中，玩家可以不停解锁新工具。怎么来告诉玩家呢？我们决定让农夫的太太“发现”它们，并把工具放到他的工棚里。我们选择连续的对话框来介绍工具。然而你不知道角色的说话习惯就没法写对话(哪怕是抓小猴的简单对话)。所以，写对话之前，我们还真得回答这些无聊的问题。 

接下来我们要回答的是两个大问题： 

1)猴儿们为什么会来？(为什么现在，而不是一年前或一年后？) 

2)玩家阻止了猴儿们以后会怎样(在解决了上一个问题之后)？ 

那个晚上我们想了很多点子，但每个好点子都会改变游戏走向，或者引入新的角色(比如猴王)，而游戏已经进入开发尾声了，我们不可能做这样的改变。我们绝对应该在第一周就开这么个会的！ 

我们在不改动游戏和添加大量新美术资源的前提下写出了最好的剧情。写作的第一条军规是“写你熟悉的”。最后，我以自己和太太为原型创作了农夫和他太太。赶跑猴子对于农夫而言，开始时很简单，后来却越来越难，成为了他的全部人生。这是我的人生隐喻。当农夫为没玩没了的猴子痛哭时，正是我为没完没了的游戏开发任务抓狂时。而背后，是一位淡定的太太。在她力所能及的地方搭把手，在必要的时候给予鼓励。游戏里的一些对话其实就是我太太说的。游戏里农夫太太外出参加“女生旅行”的时候，其实是现实中我太太跑出去玩了。

当然，对于一个简单的捕猴动作游戏，故事有点复杂了，但我还是把它放在了游戏里。 

等级和Game Master 

我必须先承认：有时候我实在是很懒。但有时懒惰却是发明之母。 

当我们开发第二个原型的时候，每一等级都有自己的脚本了：猴子什么时候从树上掉下来，猴子的类别，一次来多少猴子，大部分都是时间驱动的。这是个典型的动作游戏，就像Capcom的“1942”。每个过关都是这样。 

希望文章能给你带来一些帮助。

--------------------编程问答-------------------- 沙发，学习了

补充：移动开发 ,  非技术区