开发者分享在PC上制作iOS游戏的经验（下）

开发者分享在PC上制作iOS游戏的经验（下）

发布时间：2013-05-01 09:48:18  Tags： AI, 市场营销, 手势, 测试, 游戏平衡

简介

这时候我们已经创造了一款可行的游戏，即拥有90%完整的功能。玩家可以开始玩一款新游戏，经历每个关卡，与所有的7只猴子展开互动，使用10种工具，储存星星，在商店中购买28种升级道具，使用4种星星能力并保存/重新开始游戏。我们宣称已经完成了功能创造。但是如果我们创造了更加详细的设计文件，便能够意识到事实并非如此！

最后10%的开发工作占据了90%的时间

我们不知道与发行商建立关系需要多长时间，所以我们开始将早期原型呈现在一些发行商面前。有个评论表示我们的游戏核心非常棒，肯定了其AAA级游戏质量，但是我们却仍需要进行多方面完善。我们认为那是个相当愚蠢的声明，并在接下来2周时间内继续致力于未知的结局与游戏平衡上。

这时候的游戏与商业软件有很大的区别。在商业软件中，如果我们已经完成了大部分功能创造并进行了单位测试，那便算完成了80%至90%的工作。虽然综合测试能够揭示问题所在，但却也是开发者与需要解决的细则之间的误区。由于分层互动/游戏元素之间的依赖，实时游戏综合测试需要花费50%的时间。

投放到设备上

在此之前，我们的游戏只能在Marmalade PC模拟器上使用。我们仍然不知道它在实际设备上的性能是否是问题所在（内存或FPS）。它同样也阻碍了单位测试的进行。不过现在我们是时候将其用于真正的设备上了。

marmalade system deployment tool(from gamedev.net)

苹果对于其设备上的应用筛选总是非常严格。虽然这能够降低盗版率，但同样也为我们设下了一环环挑战，即我们必须签订代码，并获得使用测试建造的设备ID和认证。

如果你正在mac上使用xCode（特别是最新版本的xCode），这便是一个较直接的过程，因为xCode能够帮助你完成这些任务。所有的苹果文件都将告诉你如何一步一步地使用xCode。但是如果你面对的是PC，你就需要做好应对烦的准备。

你必须做到两点：1）为你的机器设置iOS部署，2）为你的项目设置iOS分布。幸运的是，Marmalade 5.2关于如何创造分布构建的文件在之前的版本中已经得到了证实。如此你变能够轻松地创造认证，然后上传到苹果上，然后下载苹果的认证。

如果是基于PC，那么你就必须明确项目的设置并签订分布。苹果的开发门户便是用于分配适合应用的设备UDID。苹果提供了配置证书去签订你的项目。Marmalade拥有调度工具，能够用于项目的ARM构建中。你可以通过配置和OS特定选项而进入这一工具，它能够帮你创造一个IPA而有效地部署于你的iOS设备的iTunes上。

如此我便只需花费10个小时便能够将游戏带到iPod上了。这是非常重要的一步，因为我们需要触屏去测试手势。

基于手势变得更活跃

你是否还记得我们的核心设计是玩家通过手指滑动去控制猴子。在创建一些原型后，我们需要使用其它工具去解决反复滑动的单调。Gameloft的《Bailout Wars》便在早期影响着我们的游戏。但除此之外我们还需要其它的动作。

Bailout Wars(from gamedev.net)

我们参考了许多游戏并最终得到了以下列表：

轻打

轻打和控制

水平滑动

向下滑动

摇动

绕圈

我们最后选择了轻打，水平滑动，向下滑动以及摇动。我们将这些手势与合适的工具整合在一起：如纸袋子便被放置在猴子的头上，所以玩家可以向下滑动带子而套在猴子头上。

iOS和Android都支持多点碰触（最多可达10个点），但是我们仍决定只检查单点碰触。碰触无非就是一个点击事件，所以我们检查了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;
}

尽管能够知道手指在哪里就已经很棒了，但是你又该如何搞清楚它们是否正在做手势？答案是你必须亲自尝试看看。

当手指碰触到屏幕时，手势便开始行动了。从那时开始，我们必须定期追踪碰触的当前位置，直到手指离开屏幕。我们必须分析最初点，跨越每个点的进程以及离开点的差异，以此决定手势类型的设定。我使用的是策略模式，即在一般道具类中基于子类去执行独特的手势识别。

尽管这解释了设定手势的技巧，但是还有很多方法能够让它显得更加“自然”。让人惊讶的是每个人执行简单的左/右滑动的方法都不同。有的人只会轻轻地滑动屏幕的一小块位置，有些人则覆盖了整个屏幕。有些人是垂直滑动，有些人是沿着对角线进行滑动。有些人缓慢地滑动，有些人快速滑动。最终我们遵循了一个较为严格的手势系统，即水平滑动比垂直滑动所碰触的位置低了20像素，所以更加合理！

把游戏留到最后

《Catch the Monkey》是一款动作类游戏。尽管我们需要创造一些故事去丰富玩家的行动，但是我们也知道这里并不需要犯错与惩罚。从一开始我们便设定了一个较为粗糙的故事线：

在南非有个农民拥有一个土豆农场。当某一天他坐下来与妻子共进午餐时，一只猴子出现在田里。他赶紧冲进田里抓猴子，但是紧接着却出现了更多猴子。经过一番辛苦的对抗，他终于赶走了所有猴子并回到餐桌吃那凉掉的午餐。

从编剧上来看我们并不可能获得奥斯卡奖，但是对于一款游戏来说这便足够了，所以我们便决定先专注于游戏，然后再去完善故事。

大错误！

big mistake(from gamedev.net)

当开始创造故事时，我决定邀请好友Rob前来帮忙。我们花了一个晚上的时间想出了一个故事。他开始问一些我从未想过的背景问题：

农民的生活状况如何，是贫穷还是富裕？

他的婚姻状况如何，是和睦还是紧张？

他的举止行为如何：是面带微笑还是摆着一张臭脸？

他们在这片领域生活了多久？

一开始我认为这都是些非常愚蠢的问题，但事实上却不是这样。通过调查，我知道在写出一个故事前我们必须先构思出角色。因为是角色推动着故事的发展。所以我和Rob便决定先明确角色。

贯穿这款游戏玩家将打开全新的工具。而我们将如何把这些内容传达给玩家呢？我们决定让农民的妻子“找到”这些工具，并将其放到农民的工具箱中。我们使用了对话框序列将工具出现的信息整合到游戏环境中。当然了，如果不知道角色的声音我们便不能写下有效的对话。所以我们必须在写下一行对话前找出这些问题的答案。

然后我们必须回答两个主要问题：

1）为什么猴子会来到田里？（为什么是现在而不是一年前，或者一年后？）

2）玩家该如何阻止猴子的入侵？

我们想出了很多办法，但是所有有效的想法都需要改变游戏的流量，或者引进新角色（例如猴子boss），而我们也没有足够的资本在游戏开发后期做出所有的这些改变。显然我们必须在游戏开发的第一周便进行讨论，而不是推到最后。

dialog(from gamedev.net)

最后我们在尽可能不改变游戏或添加任何新资产的前提下创造出了非常棒的故事。对此我们所遵循的第一个写作原理便是“写下你所知道的内容。”所以我便以我自己和妻子为原型去构造农民和他的妻子。农民尝试着去摆脱猴子的问题在开始会看起来简单些，但是在之后将变得更加困难。这也是在指代这款猴子游戏所带给我的挑战。农民感叹猴子源源不绝便是暗指我对无数游戏要求的埋怨。而妻子则在背后帮助并鼓励着农民（和我）。游戏中的许多内容都是曾经出现在我的生活中的事。

当然了，这些对于一款简单的抓猴子动作类游戏来说都太复杂了，但是它们却依然适合这款游戏。

关卡和游戏管理员（GM）

我不得不承认：有时候我真的很懒。但有时候懒惰却是创造的源泉。

当我们创造了第二个原型时，每个关卡都拥有基于脚本的事件：猴子是何时被放下树，是什么类型的猴子，一波猴子的规模有多大。大多数事件都是受到时间的驱动。这也是《Capcom’s 1942》等经典的动作类游戏所遵循的。每个游戏过程都是相同的。

如此我们便需要投入大量时间为每个关卡撰写事件，说实话我并不想在真正的游戏中再做这些事。关于脚本也存在许多问题：你该如何判断玩家是否感到无聊或者面临了足够挑战？每隔10秒释放一只猴子对你来说也许很有趣，但是对别人来说可能会太简单/太难。

所以我们便努力想出替代方法：如果我们拥有游戏管理员能够基于玩家的表现决定何时，在哪里释放何种类型的猴子会是怎样的情况？如此，即使玩家表现不好的话也不会感到紧张，并且如果他们做得很好的时候也不会感到无聊。我们将为GM设定规则，并且这些规则将根据不同关卡而发生改变。举个例子来说吧，GM在有些关卡中会变得更快速，但是在其它关卡中可能会较为缓慢。除此之外，GM还可以实时监控事物，如玩家的能量级别，并在适当的时候做出明智的决定而不是基于脚本进行猜测。

对我来说这是一种较为激进的想法，所以我们不能确定在创建这种动态AI“关卡设计师”时会出现怎样的负面影响。

出于某些原因，我认为自己应该玩Valve的FPS僵尸游戏《求生之路》。因为之前我并不喜欢玩僵尸射击游戏，所以我从未碰过这款游戏。我是在Steam上看到它，并注意到在游戏描述中出现了“Director”的字眼，这是一个关卡AI，即将在每个游戏过程实时提供给玩家不同的体验。当我看到Valve这么做时，我便知道自己所选择的方向是对的！

left 4 dead 2-gameplay(from gamedev.net)

我们花了几天的时间去创造游戏管理员，而当我们完成了这一创造时便知道自己的付出都没白费。这里并不需要任何脚本，我们所要做的便是明确GM所拥有的资源（游戏邦注：猴子的类型，每次能够出现几只猴子）以及我们理想中的关卡密度（越早的关卡越简单）。

《Andrew Rollings and Ernest Adams on Game Design》这本书解释了如何通过减轻或增强每一波的强度去创造乐趣，而不是通过恒定的强度设置。《植物大战僵尸》便是有效地遵循这一原理，即先提供了较大波的僵尸，然后再提供少量的僵尸，让玩家拥有时间去恢复能量。而我们则是通过在GM上添加“情绪”去执行这一原理。基于各种元素，GM将变得更加邪恶，并打破我们所设置的强度规则。但是其它时候它将“非常体贴”，并提供给你喘息的机会。

LevelAI(from gamedev.net)

游戏平衡补救功能

保持游戏平衡真的很困难！对于创造出任何有趣的内容并不存在严格的规则，特别是在结合中。最后我们必须基于自己的游戏体验去测试其它游戏。

我们花了6周的时间创造了核心游戏，又花了10周时间去平衡它。当我在检查工作日志时发现，直到最后一天我们仍在修改升级成本和能量成本。关于游戏平衡，我认为最有价值且最值得分享的经验便是我们如何处理那些糟糕的内容并完善它们。这便是平衡阶段的核心。以下是关于“Paper Bag”的故事：

Paper Bag(from gamedev.net)

我在一本讲述小说编写的书籍中看到一句话，每个角色都会认为自己是故事中的英雄，所以请给予他们发光的机会吧。就像在《指环王》中，当Sam带着Mr. Frodo朝着Mount Doom走去时，他便被冠上了英雄的标签。我认为这也适用于游戏功能中，在我们的例子中，每种工具都有可能成为英雄，并变成玩家最喜欢的工具。

每种工具都具有其自身存在的目的。有些是用于应对落单的猴子，有些则是用于对付群体猴子。有些能够阻止猴子进入田里，有些则是用于对付已经进入田里的猴子。有些要求玩家集中注意力并足够敏捷，有些则因为无需玩家集中注意而显得更加厉害。

“paper bag”是一种高成本且高冲击力的道具，能够完全制服一只猴子，让其长时间动弹不得。它也带有影响范围，即将分散其它猴子并让它们嘲笑这只被制服的猴子。

在首次迭代时，当带子出现在猴子的头上时其它猴子便会开始嘲笑它。而经过测试我们发现比起paper bag，玩家更喜欢其它道具。并不是说它有什么不好，而是因为它并没有很好。

对此我们进行了适当修改，并调整了它引起其它猴子嘲笑的时刻。但最终还是证明其它工具更棒。

然后我们便开始思考：如果取代了从前的AOE效果它是否还会具有持续的AOE？从整体来看，让目标猴子绊倒范围内人其它猴子将很有效果。这将改变使用paper bag的最佳时间，即从当下的猴子变成将出出现大量猴子。通过创造这种持续AOE效果，我们既拥有有效的群体控制AOE工具，同时也能够制服一只目标猴子。

paper bag(from gamedev)

现在的paper bag便非常棒了！

在游戏平衡过程中有些内容还是非常粗糙。有些甚至比其它内容更加粗糙。而我们需要做的便是不断完善它们，将其闪光点逼出来。

功能：知道何时以及如何说不！

我们必须持续地创造游戏。最典型的例子便是《永远的毁灭公爵》。当我们的目标是创造出有趣的游戏体验时，我们所面对的诱惑便是继续添加更多功能，因为更多=更好，对吧？

但是有时候却不是如此。就像在我们的例子中，我们必须适时发行游戏，这不只是是出于利益原型，同时也是基于心理元素。经历了2年的开发，我们很难在继续保持着最初的热情。随着不断地游戏与平衡，我们会想出许多理念。例如：

我们需要为非游戏玩家或年轻玩家添加较简单的模式

我们需要添加视觉或音频提示去告诉玩家他们丢失了庄稼

我们需要更多音效

我们将“关卡完成”要求从抓住一定量猴子改成抓住一定量猴子并将其从田里清除出去

最终我们执行了上述这些理念，但它们却都是计划外的任务，所以我们的发行日期便不得不往后推。

为了决定HAD该做什么，我们需要问自己这两个简单的问题：

1）没有它的话游戏是否会崩塌？如果它太过困难的话对于平均玩家来说是否会失去意义，或者变得更加枯燥

2）没有它的话我们是否就不能发行游戏？这便意味着它能够帮助我们抄近路。

第二个问题听起来好像有点奇怪。个人的自尊和品牌名誉攸关一款游戏的编写。如果我们尽了最大努力但却失败了，这便没关系。但是如果我们选择抄近路，从而降低了成功几率，并最终遭遇了失败，这便只能怪自己愚蠢了。

为了符合时间表的安排，我们必须做到：

删除一种猴子类型

删除两种道具

我们想要设置关卡排名和游戏中心，但是不得已也要将其删除

watergun(from gamedev.net)

最后，也是最复杂的便是游戏“压缩”。我们的目标是设置50个关卡，每个关卡大约拥有3分钟的时间（游戏邦注：越前面时间越短，越往后越长），而整体游戏时间为150分钟。

在确保游戏平衡时我们发现了一些有趣的关卡以及一些无趣的关卡。有趣的关卡能够提供给玩家一些全新的内容（如新工具，能量或猴子类型）。所以我们决定通过删除较无趣的内容而压缩游戏；将其变成只剩下13个关卡。

当然了，删除自己辛辛苦苦所创造的内容会很难受。但是如果能够带给玩家最棒的体验，这种难受又算得了什么呢。

结论

在花了比创造游戏多了2倍的时间去优化游戏后，我们的游戏已经拥有真正完整的功能了。它不仅很有趣，也很顺畅，我们真的对此感到非常骄傲。接下来我们要开始测试其它内容了。

测试，发行和市场营销

简介

万岁！我们已经拥有一款有趣的游戏了！但是在最终发行前我们需要经历开发的最后阶段，也就是测试。

没人知道如何玩你的游戏，他们也不会愿意去学习！

我承认自己可能是一个非常奇怪的人。

我成长在80年代和90年代初期，并在那时候养成了自己的早期游戏习惯。那时候，每当我购买了一款新计算机游戏，如《文明》，《创世纪》或《Wing Commander》后，我便会先坐下来仔细阅读游戏指南封面内容。因为那时候的游戏指南简直就是件艺术品：就像《文明》的游戏指南有100多页，并包含了各种吸引人的史实。不过现在我却不得不改掉这一习惯，因为现在我们所看到的指南只是提供着无聊的警示以及陈述一些显而易见的内容。（幸运现在的桌面游戏还有很棒的指南。）

civilization 1(from gamedev.net)

显然是因为现在很少人愿意阅读指南，游戏开发者才会忽视它们。玩家想要游戏，但却不想学习如何游戏。我曾在游戏设计书籍中有所了解，但是对此却未拥有经验知识。

在预发行时期，我们拥有一些安装了《Catch the Monkey》4个关卡演示版本的iOS设备。我们在旁边观看玩家是如何首次体验游戏。从中我们学到了两点：人们喜欢与猴子一起游戏，但是他们却不知道该如何做。所以尽管他们感受到了乐趣，但却因为不知道如何使用各种道具而沮丧不已。

所以我们需要创造一些教程并整合到游戏中。我想说的便是，当你致力于某一项目2年多时间，你便会遗忘什么是“直觉”，什么不是。而观察陌生人和现实情境能够帮你找回这种直觉。所以我们便使用了角色对话系统去完善教程系统。

first iteration of tutorials(from gamedev.net)

(首次教程迭代。没人愿意阅读。)

在发行几周前，我们邀请了一群十几岁的少女（也是我们的目标群体）作为焦点小组，帮助我们测试游戏。当看到她们不断地拍击“下一步，下一步，下一步”并完全绕开教程而直接进入游戏时，我真的要抓狂了。但是当真正进入游戏时，它们并不知道如何使用特定的功能，然后便遭遇各种失败，并逐渐感到沮丧。

final version of tutorials(from gamedev.net)

(最后的教程版本。如果你不能仔细阅读这一内容，那就没人能帮助你了！)

在经历了3次教程迭代后我们吸取了更有价值的教训：

玩家会假装自己已经知道如何玩游戏了。我想不出为什么他们会产生这种想法。但是事实上他们便是如此。请利用它而不是抵抗它。

人们不想要学习，他们只想玩游戏。所以只要教授他们一些基本的内容便可以放任他们游戏了。

在教授过程中，我们观察到平均每个玩家的容忍度只到2：也就是最多不能超过2个屏幕内容，2个互动步骤以及2个对话盒子，否则他们便会不顾一切地略过去。

玩家总是会在游戏后才想要学习。玩了多长时间游戏与他们在学习过程中感受到的乐趣是相关联的。在前面2分钟他们的兴趣度为0%，在第5分钟他们的兴趣度为10%，而在第10分钟他们的兴趣度便会高达50%了。

删除教程中所有华丽的文本，玩家想要尽可能快速且有效地学习，而不会在乎有关角色的具体描述。

他们不想阅读，只想实践。确保教程觉有视觉效果和互动性。

预先规划你的教程，并将其整合到游戏的主要故事/进程中。不要模仿我们的做法并尝试着去改善它，这反而更费时。

基于Testflight进行测试

就像之前所提到的，iOS锁定的是能够安装二进制内容的设备。这便要求每个设备具有独特的UDID，并在苹果的门户网站上注册，在编译时将配置概要文件整合到二进制中，然后将一份配置概要文件通过iTunes复制到设备上（即使成功完成的话也只能提供零反馈），并最终通过iTunes将二进制内容复制到设备上。我想象不出与苹果的“正常运行”咒语相违背的过程。所以你只需要落实行动便可，或者你也可以使用testflightapp.com。

TestFlight(from gamedev.net)

基于testflight，你可以向测试者发送一个邮件链接，他们便能够在自己的设备上登录该链接。testflight负责寻找设备UDID，操作系统版本，设备模式，并将其发送给开发者，然后安装配置证书。作为开发者，你需要做的便是为二进制内容注册设备ID。现在你便可以上传架构（带有发行说明）到testflight，而你所授权的人便会受到电子邮件链接从而能够下载这一架构。这便能够避免那些愚蠢的iTunes文件复制。testflight的报告机制能够告诉你谁安装了你的架构。如此当人们开始反映问题时你便可以说“那是因为你所面对的是昨天的架构。请安装新内容吧，这就没有问题了。”

基于非玩家进行测试

你更想在开发过程中察觉到问题还是在发行后？当然是在开发过程中了！

让那些玩过你之前创造的类似游戏的玩家进行测试便很有帮助。你可以确保满足目标群体的需求，而他们也可以以之前游戏为参照而给出适当的反馈与建议。

但是我们也发现与那些从未玩过电子游戏的人进行测试也很有价值。就像你那只玩过掷骰子游戏的岳母；甚至不知道预先安装于自己黑莓手机上的打砖块游戏。

关于这种测试的官方术语是黑箱测试。这些人可以帮你明确教程是否有效，但是更重要的是他们会做一些你从未尝试过的事。但是你必须认真地观察他们游戏，因为他们不会告诉你自己做了什么或没做什么。让我们举个例子来说：

touchscreen(from gamedev.net)

我们在12月15日完成了最后的无漏洞碰撞架构。在圣诞假期时我将完成后的游戏呈现在一个非玩家好友面前。而在玩了2分钟游戏后游戏便崩溃了。

为什么？因为他一直都将手指死死地压在屏幕上。如果你还记得我在第三部份所提到的手势系统，你便知道当前手指位置的变化为50毫秒一次。而如果玩家从未将手指离开屏幕，那么2分钟的时间便会创造出2400个点的巨大手势。更糟糕的是，在等待手势完成的过程中，手持的最初目标对象也会被破坏，并创造出一个空引用而导致游戏的崩溃。

当然了，看着他游戏我便能够更轻松地解决这一问题，但是我真的没想过有人会在游戏过程中会从未抬起手指。

如何判断测试已经完成了？

这个问题很愚蠢，特别是基于商业软件背景中。在商业软件中，你可能在执行前便已经写下了所有测试案例。当它们都通过测试时，你便知道能够发行了。一般情况下我们会让用户在试点项目中进行测试，这便是“现实世界”测试。如果得到的是好结果，我们便会决定发布。

但是在游戏中情况却不同。没有一个“用户”能够保证应用是否出色，而你只需要在测试完成后做出决定便可。

太早发行的话游戏将很容易崩溃。而太晚发行的话，你便会浪费许多宝贵的精力（本来可以投入在其它游戏身上）。

我曾经听过麻省理工关于游戏设计的公开课程，他们问了一个问题：你是如何判断测试已经完成了？

而他们给出的答案便是：当你已经没有时间时。

当你不能再继续往下走时，你便完成了测试。

gasp(from gamedev.net)

也许这个答案听起来很荒谬，但是在真正面对测试时，我也是这么想的。而现在我们已经确保了所有功能都能有效运行，并且足够有趣，也不会崩溃了。（而在我写这篇文章的时候却又听到有人说我们的其中一个教程带有漏洞！）游戏永远达不到完美，我们需要一直添加更多新内容，并一直进行测试。不过你必须选择在适当时刻划出一条界线，并在这时候推出游戏。对于完美主义者来说，做到这点真的非常困难。幸运的是我并不是独自在项目中奋斗着，设计师和我能够共同决定游戏何时能够发行。如此我便会更有自信了。而对于那些独立开发项目的人，我会建议你去请求朋友进行“质量控制”，并帮助你决定何时发行游戏。

判断难度

《Level Up: Guide to Great Game Design》这本书告诉我们，游戏制作人是最不会判断难度的人。虽然我知道这点，但在实践中还是发现做到这点很难。显然，你最先需要取悦的便是创造游戏的自己，这便是你的第一道质量控制门槛。

我们也会选择小孩进行测试。为什么？因为他们没有其它事可做，可以一整天帮你进行测试。（当然也包括我们设计师的孩子）。我们发现小孩都很喜欢玩《Catch the Monkey》，但是中间游戏内容对于他们来说却太难了。

所以我们会将他们当成第二市场，即创造简单模式，提供给玩家更多能量并减少每一次出现在田里的猴子的最大数量。结果孩子们都很喜欢这一简单模式，并能够轻松且愉快地完成游戏。

后来当我们在进行焦点小组测试时，发现两名少女不能通过一个特定的关卡并因此感到十分沮丧。我们便建议她们重新从简单模式开始。而当她们开始玩简单模式时便惊呼：“哇，这真的有趣多了。”

这时候我们遇到了一个难题，即我们是否应该让简单模式更倾向于一般模式，而让一般模式更倾向于复杂模式？我们便调整了所有代码去做出回应。

几天后，我们修正了Level GM AI中的漏洞，并发现它比之前更有效了。所以我们便决定回到简单和一般模式而不是一般和复杂模式。

大错误。

现在我们已经发行了游戏，而亲朋好友们也已经购买了游戏，我们从休闲玩家身上所听到的最多抱怨便是游戏太过复杂了。当我们通过反馈告诉他们去尝试简单模式时，他们所给出的反应都是“哇，这真的有趣多了。”即使是游戏发行后我们也仍然在辛苦地学习着。

以下便是我们所获得的一些经验教训：

确保游戏足够简单，而不是足够复杂。简单仍会带来乐趣，但是复杂永远都不会。

休闲玩家并不想追求挑战，他们只想消磨时间。而简单模式能够满足他们的这一要求。

不要创造出会让玩家主动选择简单模式的复杂游戏。而是创造出能够推动玩家挑战复杂模式的简单游戏。

面向App Store发行

在经历艰难的测试阶段后，我们将开始准备游戏的发行了。这需要经历几个步骤：

1）创建一个与App Store达成协议的架构，而不是特别配置架构

2）上传二进制内容到苹果

3）等待审批

是时候最后一次启动Visual Studio并创造一个应用商店架构了。这并不难，我只要从Marmalade的testflight架构中复制部署选择便可。但这里却出现了一个问题：即在上传前你并不能测试应用商店架构。为什么？因为它只能经由应用商店而安装到设备上。你最好弄清楚这一点。

iTunes Connect(from gamedev.net)

（iTunes Connect是关于你如何在应用商店中控制应用。）

在创造最后架构时我犯了两个大错误。第一个错误便是我并未将适当的图标图像设置从网络架构复制到最后的架构上，所以在应用商店中显示的便是默认应用图标。而第二个错误则更加糟糕。

我们知道，我们的游戏并不能运行于iPhone 3GS或iPod 3以下的设备。我发现其它游戏也会在应用商店中列出这一要求。因为我并未在Marmalade的部署中找到设置方法，所以我便认为应用商店会帮助我做到这一点。

当你上传一个应用，特别是第一次上传时，iTunes Connect便会引导你如何做。你不能改变提出的问题，并只有一次设置机会。到这时候我们做得都没错。但是因为我找不到能够设置要求的地方，所以我便认为在上传二进制内容后它便能够自动进行设置。但是当我上传了二进制内容后，它却进入审核批准队列。

8天后，我们的游戏通过了审批。但是那时候我还是找不到能够设置系统要求的方法。直到最后我才发现必须修改plist.info文件去包含OpenGL ES版本并瞄准我们的目标设备。

不要紧，我修改了plist.info文件并继续上传新的二进制内容。

错误！

苹果并不允许开发者在应用更新时设置比最初应用更低的限制。也就是，如果你最初的版本能够运行于iPod 2上，你就必须确保之后的更新还能继续运行于iPod 2上。我们便搞砸了应用更新。最终在苹果的支持下，我们将要求添加到了应用描述上。我们当然知道很少有人回去阅读描述，但这却是我们唯一能够补救的方法。

如果你是在PC上制作应用，那么在面向应用商店发行游戏时你就必须找到一台mac去上传二进制内容，

过去iTunes Connect允许你通过http进行上传，但是现在却不可以了。在iOS SDK中还有一个二进制上传程序能够帮助你检查并上传二进制内容到苹果上。不过该上传程序只能用于mac。所以当你是在PC上制作并测试整款应用时，你便需要花10分钟时间在mac上上传你的最终二进制内容。曾经有人建议可以直接到苹果使用演示mac进行上传。不过因为我自己拥有mac mini，所以便不需要担心这一问题。

面向世界发行游戏

所有上传至苹果上的应用都将默认发行到世界各地的iTunes Store中，除非你特别删除了哪些商店。

iTunes Stores(from gamedev.net)

（世界上具有无数iTunes Store。幸运的是你只需要通过6次翻译便能够覆盖所有的这些商店。）

我们总是希望能够面向更多国家发行游戏，所以我们便尝试着减少游戏中的文本内容，并尽可能使用符号（如猴子故事系列便是使用图标而不是文本）。

而真正的关键在于我们该如何将应用描述从本国语言翻译成各种应用商店所要求的语言。对于每种语言，我们花费了100多美元去使用翻译服务。当然了，最大的难度还是在于我们不能判断最终翻译的质量。

最初的市场营销

当我在写这第四部分内容时，我们的游戏已经出现在大家面前22天了。因为销量并未取得巨大的飞跃，所以我便没有立场去告诉别人如何进行市场营销。但是我们却可以分享两点内容。

App Store-What’s Hot(from gamedev.net)

第一，苹果控制着应用商店。他们是基于销量做出决定。就像“热门游戏”和“值得推荐的新游戏”等列表都是受到销量的推动。如果你能在一开始取得更大的销量，你便越有可能出现在这些列表上。而进入“前100名免费游戏”或“前100名付费游戏”最重要。而只能销量能够帮助你做到这一点。

第二，评论网站能够帮助你在一开始吸引更多玩家的注意，但是你该如何找到这些评论网站呢？谷歌搜索只能找到一些大型网站，还有一些博客在近两年中也都未做出更新了。所以我们便想出一个好方法，即创造一个较短的评论网站列表：即根据大多数游戏都会将来自评论网站上的评论和引用放在应用描述的最上方。而我们只需要点击20几款应用便能够找到41个可靠的手机游戏评论网站。

这些评论网站都希望拥有优惠码能够免费获得你的游戏，他们不希望花钱去买你的应用。苹果允许你在每次发行时派发50个优惠码。而当你发行了新应用时，之前未使用过的优惠码也会作废。

等了3周时间，我们终于获得了一条评论。幸好这是条积极的评论。

我们也决定在今后的游戏中将更加注重发行前的市场营销，从而让我们能在游戏发行前获得更大的曝光率。而因为我们在《Catch the Monkey》上投入了太多时间，并且不清楚何时才能真正完成游戏，所以我们便放弃了预发行市场营销。

结论

我们为自己设定了目标，尽管经历了种种困难，但最终还是走到了终点。除此之外，我们还在三种情况下获得了满足感：

1.获得首次评论：

我们获得了4.5颗星的评级以及来自家庭手机游戏网站famigo.com的编者选择奖。当知道有人如此肯定我们的作品时，这种感觉真的很棒！

2.当看到有人在美国应用商店做给予评论时：

抓猴子真的是太有趣了！我非常喜欢这款游戏，因为这不同于公主游戏或升学应用，既能带给我的小孩乐趣，也能让我在空闲的时候进行游玩。可以说这是我看过的最不具备暴力性的游戏。它具有非常棒的图像和有趣的故事，能够带给所有人乐趣体验。

3.这系列文章的普及：

当我们第一次开始分享创造经验时，我们并不知道谁会对这些内容感兴趣。但是在得知第一篇文章的阅读量超过3000人时，我们便知道自己的付出是有回报的！多谢大家！（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）