游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

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

发布时间:2013-05-01 09:48:18 Tags:,,,,

简介

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

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

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

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

投放到设备上

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

marmalade system deployment tool(from gamedev.net)

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)

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)

big mistake(from gamedev.net)

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

农民的生活状况如何,是贫穷还是富裕?

他的婚姻状况如何,是和睦还是紧张?

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

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

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

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

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

1)为什么猴子会来到田里?(为什么是现在而不是一年前,或者一年后?)

2)玩家该如何阻止猴子的入侵?

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

dialog(from gamedev.net)

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)

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

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

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

LevelAI(from gamedev.net)

LevelAI(from gamedev.net)

游戏平衡补救功能

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

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

Paper Bag(from gamedev.net)

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(from gamedev)

现在的paper bag便非常棒了!

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

功能:知道何时以及如何说不!

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

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

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

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

我们需要更多音效

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

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

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

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

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

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

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

删除一种猴子类型

删除两种道具

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

watergun(from gamedev.net)

watergun(from gamedev.net)

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

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

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

结论

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

测试,发行和市场营销

简介

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

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

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

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

civilization 1(from gamedev.net)

civilization 1(from gamedev.net)

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

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

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

first iteration of tutorials(from gamedev.net)

first iteration of tutorials(from gamedev.net)

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

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

final version 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(from gamedev.net)

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

基于非玩家进行测试

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

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

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

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

touchscreen(from gamedev.net)

touchscreen(from gamedev.net)

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

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

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

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

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

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

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

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

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

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

gasp(from gamedev.net)

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(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 Stores(from gamedev.net)

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

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

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

最初的市场营销

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

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

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编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Part 3: Balancing and Polishing

Intro

At this point we had a working game, around 90% feature complete. The player could start a new game, play each level, interact with all 7 monkeys, use all 10 tools, save up stars, buy 28 upgrades in the store, use all 4 star powers, and save/resume their game. We declared ourselves feature complete. If we had created a more detailed design document we would have realized how untrue that statement actually was!

The Last 10% takes 90% of the Time

We didn’t know how long it would take to establish a publisher relationship, so we started showing an early prototype to some publishing agents. One commented that the game core was good, we definitely have a quality AAA title here, but we still have a lot of work left for polishing. We thought that was a rather silly statement, and proceeded to finishing off the loose ends and game
balance figuring we would be in the store in about 2 weeks.

This is where games are vastly different than business software. In business software, when we are feature complete with all unit testing completed, 80%-90% of the work really has been done.

Integration testing reveals its issues, but they are generally just misunderstandings between developers and spec that need to be resolved. A real-time game integration testing is about 50% of the work because of the layered interactivity/dependencies of the game elements to each other.

Getting it on a Device

Up until this point, the game could only be played in the Marmalade PC simulator. We still had no idea if performance would be an issue (memory or FPS) on real devices. It also severely hampered unit testing as the artist couldn’t test the game at all. It was time to deploy to a device.

Marmalade Deployment Tool for making the IPA file

Apple is extremely careful of what can be put onto their devices. This is good as it cuts down on piracy, but it also creates a whole series of hoops you must jump through to sign your code and get device ids and certificates for deploying test builds to a device.

If you are using xCode on a mac (especially the latest version of xCode), it is a relatively straight forward process, where xCode takes care of most of it for you. All of apple’s documentation
tells you step by step how to do it with xCode. If you are on PC, well prepare for some hassle.

There are two things you must do: 1) Setup your machine for iOS deployments and 2) Setup your project for iOS distribution. Fortunately, the documentation in Marmalade 5.2 for how to create distribution builds is much improved over previous versions. There is a walk through that explains you to create a certificate, which you then upload to Apple, and download the Apple certificate(s) and where to put them.

With the PC setup, the project must be setup and signed for distribution. The Apple dev portal is used to assign UDIDs of devices allowable to an application. Apple provides a provisioning certificate used to sign your project. Marmalade has a deployment tool that appears when making a release ARM build of the project. You enter in provisioning and OS specific options into this tool (it saves the settings to the custom MKB file) and it does the magic of making you an IPA that can be deployed through iTunes to your iOS device.

All in I was able to get the game on my iPod in about 10 hours. This was a vital step, because we needed the touch screen to test our gestures.

Getting Jiggy with Gestures

If you recall, our core design was a player using their finger to tickle a monkey through swiping. After some prototyping, we needed other tools to break up the monotony of constantly swiping back and forth. One of our early influences was a GameLoft game Bailout Wars. The player flicks bankers to their doom, but you also have to make other motions as well.

We studied numerous games and came up with this list:

Tap

Tap & hold

Swipe Horizontal

Swipe Down

Flick Up

Circle (clockwise or counter clockwise)

We chose Tap, Swipe Horizontal, Swipe Down, and Flick Up. (We also had Tap & Hold, but cut it later.) We tied these gestures to tools that we felt made sense: the paper bag, for instance, is placed on a monkey’s head, so the player swipes the bag down onto the head.

iOS and Android support multi-touch (up to 10 points) but we decided to stick to just single touch. A touch is nothing more than a click event, so we inspect the s3ePointerEvent in Marmalade to capture it into a global touch variable like this:

While it is all nice to know where a finger currently is, how do you know if they are making a gesture or not? The answer is you have to do that yourself.

A gesture begins when the finger touches the screen. From then on, the current position of that touch must be tracked at a regular interval until it is released (finger is lifted). The difference
in origin, progression across the points, and exit must be analyzed to determine what kind of gesture was made. I used the Strategy Pattern in a generic Tool class with the child class for each
tool implementing their own unique gesture recognition.

So while this explains the technical on how to do gestures, there was a lot of refinement necessary to get it to “feel” right. It is amazing how different each person performs a simple left/right
swipe. Some people do very gentle little swipes of 10 pixels, while others go all the way across the screen. Some do it straight across, others on a diagonal. Some do it so slow it didn’t register, and some do it so fast it didn’t register (we found the “right” granularity for the timing interval of each point is 50ms). At the end of the day, we went from a very strict gesture system where a horizontal swipe couldn’t have more than 20 pixels of vertical movement, to a very loose one where just about anything goes!

Saving the Story To Last

Catch the Monkey is an action game. While we need some sort of story to set the context for the player’s actions, we knew we didn’t need Crime and Punishment here. From the very beginning, we had a rough story outline:

A farmer in South Africa has a potato farm. As he sits down to lunch with his wife, a monkey is spotted in the field. He goes outside to take care of the monkey, but more and more keep coming.

Eventually he overcomes all the monkeys and returns to a cold lunch. Fin.

Ok, so we aren’t winning any Oscars for screenplay writing, but it was enough to get going so we focused on building the game and then would circle back to the story.

BIG MISTAKE!

When it came time to do the story sequences, I decided to involve my friend Rob for help. We sat down one evening to hash out the story. He started asking basic background questions for which I had no answer:

How well does the farmer do, is he poor or rich?

How’s his marriage, good or strained?

What’s his demeanor: happy or surly?

How long have they lived in this location?

This may seem like silly fluffy stuff, but it isn’t. I knew from research in how to write fiction that before you have a story, you have to have a character. It is the characters that drive the story and we didn’t have characters. So Rob and I had to define the characters first.

Throughout the game the player unlocks new tools. How are these communicated to the player? We decided it was by the farmer’s wife “finding” them and making them available to the farmer in his tool shed. We chose to use a dialog sequence to put the tool arrival into some context. Well, you cannot write effective dialog (even simple monkey catching dialog) without knowing the characters voice. So these “fluffy” questions had to be answered before we could write a single line of dialog.

We then had to answer the two big questions:

1) Why are the monkeys coming to the farm in the first place? (Why now and not a year ago, or why not a year from now?)

2) How is it that the player stops the monkeys from coming (by resolving #1)?

We went through a lot of ideas that night, but everything good we came up with changed the flow of the game, or introduced new characters (like a boss monkey), and we just couldn’t afford to do all those changes this late in the game development. It was overwhelmingly evident we should have had this meeting in the first week of the game, not the last.

We wrote the best story we could without changing the game or requiring a lot of new art assets. The first rule of writing is “write what you know”. In the end, I based the farmer and wife on
myself and my wife. The problem the farmer faces of trying to get rid of the monkeys, which seems so simple from the beginning, becomes overwhelming and takes over his whole life. This is actually a metaphor for what the monkey game became to me. When the farmer bemoans the monkeys never ending, that’s how I felt about the amount of work the game kept requiring. But in the background, unfazed, is the wife. Helping where she can, encouraging when needed. Many of the lines in the game are verbatim what my wife said. When the farmer’s wife goes away on a girl’s trip in the middle of it all, this also happened in real life.

Of course, all this is probably far too sophisticated for a simple action monkey catching game, but it is in there none the less.

Levels and the Game Master

I’ll admit this up front: sometimes I’m just plain lazy. But sometimes laziness is the mother of invention.

When we built the second prototype each level had scripted events: when a monkey is to be released down a tree, the type of monkey, the size of a wave of monkeys at one time. Most of these events were time driven. This is how classic action games, like Capcom’s 1942, are made. Each play through is the same.

It was a lot of work scripting each level with all the events, and frankly I didn’t want to do it again in the real game. There are also problems with scripting: how do you know if the player is
bored or sufficiently challenged? Releasing a monkey every 10 seconds may be fun for me, but too easy/hard for you.

So we tried to think of an alternative: what if we had a Game Master (to borrow the RPG term) that determines when, where, and type of monkey to release based on how well the player is doing. If a player is doing poorly it won’t become ridiculously intense, and if they are doing well it won’t get boring. We will define rules for the GM to behave by, and vary those rules from level to level. For instance, some levels the GM will be fast and furious, in others a slow build up. Even better, the GM can monitor things in real time, like the players energy level, and make smart decisions at the time of knowledge rather than guessing with scripting.

This seemed like a radical idea to us, so we weren’t sure what the negatives would be to building this dynamic AI “level designer” just so I didn’t have to do all that scripting.

I don’t remember why, but for some reason I felt I should play Valve’s Left for Dead FPS zombie game. I generally don’t like zombie shooters so I had never played it before. I got it off steam
and noticed somewhere in the description about “The Director”, which is essentially a level AI that responds in real-time to the players to give different experiences each play through. Once I
saw Valve did it, I knew we were on the right path!

If Valve did it, so can we!

It took a few days to build the Level GM, but once it was done it was a total win. No scripting required, all we had to do was define for the GM the resources it has (types of monkeys, total number of each monkey allowed at a time) and the level of intensity we want (earlier levels are easier than later ones).

In the book Andrew Rollings and Ernest Adams on Game Design (some of it is free on google ebooks) they explain how it is more fun to have waves of intensity followed by relief followed by intensity rather than constant intensity. Plants vs Zombies follows this formula perfectly by providing big waves of zombies followed by few zombies so you can rebuild. We implemented this concept by adding “moods” to the GM. Based on many factors, the GM will “go evil” on you and break the rules of intensity we set out. But at other times it will “go nice” and give you a chance to catch your breath.

We’ve detailed plenty of our mistakes in these articles, so we’re proud to say this is one where we nailed it! We’ll be using this approach in our future titles.

Game Balancing: Redeeming Features

Game balancing is tough stuff! There are no strict rules as to what makes something fun, especially in combinations. In the end we had to go with our personal play experience, and then test on
others.

It took 6 weeks to make the core game, and another 10 weeks to balance it. As I look over my work logs, up until the last day we were changing cooldowns, upgrade costs, and energy costs. I could give many examples from our time of play balancing, but I believe the most valuable lesson I can share is how we took something that wasn’t good and made it great. This at the core is what the balancing phase entails. So here is the brief story of the Paper Bag:

In reading a book on fiction writing it stated every character thinks they are the hero of the story, so give them a chance to shine. Think of how in Lord of the Rings Sam, a tag along character
for much of the story, gets to be the hero when he carries Mr. Frodo up Mount Doom. I think this applies to game features, in our case every tool should get to be the hero and legitimate chance of being a player’s favorite.

Each tool has its own purpose. Some are for taking out individual monkeys, some are for dealing with groups. Some are to prevent them from coming in, some are for dealing with them as they come in.

Some require the player’s attention and dexterity, some are great because they don’t require any attention.

The paper bag is a high cost high impact tool that completely paralyzes one monkey (intended for a high threat monkey) for a long period of time. It also has an Area of Effect (AOE) which causes other monkeys to be distracted and laugh at the silly monkey stumbling around.

In the first iteration, once the bag was placed onto a monkey’s head it immediately made all monkeys in range laugh. Play testing revealed players preferring other tools over the bag. It’s not
that it was bad, but it wasn’t good.

We played around with the cost, cool down, and range. At one point it made all the monkeys in the field laugh. But still the other tools were better.

Then we thought: what if instead of a onetime AOE effect it had a continual AOE? For the entire time the target monkey stumbled around any monkeys in range would be influenced. This changed the best time to use a paperbag from where a lot of monkeys are currently, to where a lot of monkeys WOULD BE. By making this AOE effect continuous we now had a very effective crowd control AOE tool while incapacitating one target monkey.

Now the paper bag is fantastic!

During game balancing some diamonds are in the rough. Some are rougher than others. It requires determination to cut into them to let the inner brilliance shine forth.

Features: Knowing when and how to say NO!

A game can be built forever. Should I even mention the obvious example of Duke Nukem Forever? When the goal is to create a rich enjoyable play experience, the temptation is to keep adding more and more features, because more = better, right?

Sometimes no. In our case we had to ship the game, not just for financial reasons but for psychological ones. After 2 years it is hard to keep up the enthusiasm. As we played and balanced, many ideas would come up. For instance:

We needed to add an easy (casual) mode for non-gamers or younger children

We needed a visual and audio warning to the player that they just lost a plant (seems obvious now, but it wasn’t added until the second last day)

We needed more sound effects

We changed the “level complete” requirement from reaching a certain number of monkeys, to reaching a certain number AND clearing the whole field

All of the above were implemented, but they were unscheduled tasks and our release date kept being pushed further and further out.

To decide what HAD to be done we asked ourselves these two simple questions:

1) Is the game broken without it? Meaning it is too hard to play, or doesn’t make sense to the average player, or boring/repetitive

2) Would we be embarrassed to release without it? Meaning it is obvious we cut a corner.

The second question may sound a little strange. Personal pride and brand reputation are at stake writing a game. If we tried our best and failed, that is ok. Sometimes that is life. But if we cut
corners, therefore reducing chance of success, and we failed, that is just being lazy or foolish.

To reach our timeline some things had to give:

Cut a type of monkey

Cut two tools

We wanted level ranking and gamecenter integration, but we had to cut it

Watergun didn’t make the cut. Maybe there will be a sequel we can put it into!

Finally, the hardest thing we had to do was what I’ll call “compress” the game. Our goal had always been to have 50 levels, each of about 3 minutes (earlier ones are shorter, later ones are longer) for 150 minutes of perfect play.

Upon play balancing we saw there were fun levels and not as fun levels. Fun levels generally had the player getting something new (a new tool, star power, monkey type). So we decided to compress the game by removing the low fun content; 13 levels. It hurt to see all that work go away. But in the end what the player now experiences is peak to peak fun with no valleys.

Conclusion

After spending twice as much time polishing the game as it took to build it, we had a game that was truly feature complete. It was fun, it flowed well, and we are proud of it. It takes some going,
but once you hit the sweet spot mid way through the game it is a ton of fun. We were finally ready for testing with others.

Part 4: Testing, Release, Marketing

Intro

We had a game! Hurray! It worked, it played well, it has a beginning, middle, and ending. We were ready to get the sucker out the door. But before release, we had to go through the final stage of development: testing. Wow, what an eye opener!

No one Knows How to Play Your Game, and They Don’t Care to Learn!

I submit I may be the strangest person alive.

I grew up in the 80’s and early 90’s. This is where many of my early gaming habits formed. Back then when I bought a new computer game, such as Civilization, Ultima, or Wing Commander, I would sit down and read the entire manual cover to cover before attempting to play the game. And this was when manuals were works of art: the civilization manual was over 100 pages and filled with fascinating sidebar historical facts. I continued this practice, though I’ve stopped now that the manuals are nothing more than epilepsy warnings and telling me where the square button is on my controller. (Fortunately board games still have amazing manuals, so I can enjoy those  )

The good old days when games were hard and manuals were thicker than your arm!

Apparently no one else read manuals so the gaming industry moved away from them altogether. Players want to play, not learn how to play. I sort of knew this, I read about it in game design books, but I didn’t have the experiential knowledge of it. It quickly came.

At our pre-release party (unfortunately 3 months before the actual release, but who’s counting) we had several iOS devices with a 4 level demo version of Catch the Monkey installed on them for people to play. We watched people pick up the game and play it for the first time. We learned two things: people enjoyed playing with the monkeys, but they had no clue how to do it. So while they had fun, they were frustrated not knowing how to use the various tools.

It seems obvious as I write this, but we discovered our need for tutorials built into the game. All I can say is that when you work on something closely for 2 years you lose track of what is “intuitive” and what isn’t. Observe strangers and reality will come crashing in. So, we used our character dialog system to retrofit in a tutorial system.

First Iteration of Tutorials. Nobody reads em.

Weeks before release, we tested with a focus group of teenage girls (our demographic) to see how they enjoyed the game. I squirmed in my seat as I watched them tap “next, next, next” and
completely bypass the tutorial to get on to the game. Once there, they didn’t know how to use certain features, started losing, and became frustrated.

Final version of tutorials. If you can’t follow that, there’s no helping you!!!

We learned valuable lessons as we went through three iterations of tutorials:

People assume they already know how to play your game. I can’t for the life of me figure out why they come with this belief, but they do. Work with it, not against it.

People don’t want to learn (because of the above), they want to play. So teach them one basic thing and set them off playing

When teaching, we observed the average player’s patience is two: Two screens of slides, two steps of interaction, two dialog boxes, then they don’t care anymore and want to skip forward

After playing, people want to learn. There is a correlation between how long they play and how interested they are in learning to play. In the first 2 minutes, they have 0% interest, at 5 minutes they have 10% interest, at 10 minutes they have 50% interest. You have to space your lessons appropriately

Remove all flowery “in character” text from the tutorial, they want to learn as quickly and efficiently as possible and could care less if a character starts each sentence with “<gwok>”

They don’t want to read, they want to do. Make the tutorial visual and interactive

Pre-plan your tutorials into the main story/progression of the game. Don’t do what we did and try to retrofit it in, it was a lot of work after the fact

Testing with Testflight

As previously mentioned, iOS locks down the devices to which you can install a binary. This requires the unique UDID of each device, registering it through the apple portal, including the provisioning profile at compile time into the binary, and then copying a provisioning profile to the device through iTunes (which provides zero feedback if it was done successfully) and finally
copying the binary to the device through iTunes. I can’t think of a process more antithetical to the apple “it just works” mantra. So, you can do all that OR you can use testflightapp.com.

Testflight for build distribution during testing; epic win!

With testflight, you send testers (family, friends, enemies) an email link and they go to it on their device. Testflight takes care of finding the device UDID, os version, make/model of device, and
sending it to you the developer, installing the provisioning certificate. As a developer, all you need to do is register the device id to your binary. Now you can upload a build (with release notes) to testflight, and everyone you autohrize is sent an email a link to download it. It bypasses all the silly itunes file copying. Testflight’s reporting allows you to see who has what installed. Valuable when they start reporting problems as you can definitively say “Oh, that’s because you’re on a build that was so yesterday! That build was terrible! Install the NEW build, it’s wonderful.”

Testing with Non-Gamers

Would you rather know about an issue during development, or once it’s released? Of course during development!

Testing with people who play similar games as the one you are making is very helpful. You can be sure you are meeting your demographics’ demands and they can often make suggestions or give articulate feedback on issues as they have a frame of reference.

However, we found great value in testing with people who have never ever played an electronic game in their life. You know who I’m talking about: your mother-in-law whose only game experience is yahtzee on the dining room table; the friend who didn’t know brick breaker was pre-installed on his blackberry.

The official term is blackbox testing. These people can confirm if your tutorials work, but more importantly they do things you never in a million years would do. But make sure you watch them closely, they won’t be able to tell you what they did or did not do. Here is an example:

We finished our final bug free never crashes build Dec 15. Over the Christmas holidays I showed a non-gamer friend the finished game. Within 2 minutes of playing he crashed it.

How? He never once lifted his finger from the screen. If you recall from part 3 about our gesture system, it tracks the current finger position every 50ms. Well if the player never ever lifts their
finger from the screen, it becomes one giant gesture of 2,400 points after 2 minutes (affecting performance). Even worse, the initial target object of the gesture may be destroyed while waiting for the gesture to finish, resulting in a NULL reference and therefore a crash.

It was relatively easy to replicate and fix once I saw what he did, but I have to admit I never imagined someone not lifting their finger!

How Do You Know When You are Done Testing?

This may seem like a silly question, especially coming from a business software background. In business software you would already have all your test cases written before hand (Right?) and execute them. When they all pass, you know you are good to release. Typically we would then get the customer to test the application in a pilot project, and that is the “real world” test. If it’s good, we release.

Well in games, it’s different. There is no “customer” to sign off and take responsibility that the application is good, you just have to decide at some point: it’s done.

Release too early, and the game will crash or misbehave for customers. Release too late, and you’ve squandered valuable effort that could have gone into another title.

I was listening to the MIT Open Courseware on Game Design and they asked this very question: how do you know testing is done?

Their answer: When you are out of time.

When you can’t take another step forward, you might be done testing.

That seemed like a cheeky answer, but having now lived it, I agree. Now, of course, we made certain all features worked, it was as fun as we could make it, and it didn’t crash. (Of course now as I
write this we’ve heard reports of a bug in one of our tutorials, oops!). The game will never be perfect, there is always more to add, more to test. There comes a point where you have to draw a
line in the sand and ship it. For perfectionists, this is a very difficult thing to do. I am fortunate that I’m not working solo on this project, both the artist and I together were able to agree the game was ready to go out. That gave me confidence I wasn’t deluding myself or just fed up. J For those soloing it, I recommend you ask a friend to be your “quality control” and help give you the thumbs up for releasing.

Judging the Difficulty

I read in the book Level Up: Guide to Great Game Design that the game makers are the worst people for judging the difficulty. So, I knew this going in, but it is still difficult in practice.

Obviously the first people that need to be happy are the ones making the game, that is your first quality control gate.

We also tested on young children (3, 8, and 9). Why? Because they’ll test for free all day long and they have nothing better to do.  (And they are the artist’s children). We found that young kids

love to play Catch the Monkey, but the mid game was too hard for them. So thinking this was a secondary market, we created an Easy mode that gives the player more energy and reduces the maximum number of monkeys in the field at a single time. The kids loved the easy mode and were able to finish the game, so we were happy.

Later, when doing focus group testing, two of the teenage girls couldn’t get past a certain level and were getting frustrated. We recommended they restart the game in easy mode. As soon as they started playing in easy mode they said “Oh wow, this is much more fun.”

At this point we had a dilemma: do we make easy mode normal mode, and normal mode hard mode? We did and made all the code changes to reflect this.

Then, a few days later, we fixed a bug in the Level GM AI and found it was working much better than previously. So we flipped it all back to Easy and Normal rather than Normal and Hard.

Big mistake.

Now that we have released and friends/family have been buying it, the most common complaint we hear from casual gamers is that it is too hard. When we tell them through facebook to try it on easy mode, they always come back with “Oh wow, this is much more fun.” Even post release we’re still learning things the hard way!

Here are the key lessons we’ve learned:

Make the game too easy, rather than too hard. Too easy can still be enjoyable, too hard never is.

Casual gamers are not looking for a challenge, they are looking to pass the time. Easy fits within this expectation.

Don’t make the game hard with the ability for the player to opt into easy. Make it easy with the ability to opt into hard.

Releasing to the App Store

After making it through the arduous testing phase, we were ready to release this sucker. This has several steps:

1) Making a build signed for App Store, as opposed to ad-hoc provisioning build

2) Uploading the binary to Apple

3) Waiting for approval

It was time to fire up Visual Studio one last time and create an app store build. It was relatively easy to do, I simply copied the deployment options from my test flight build in Marmalade and off I went. Now here’s the thing: you cannot test your app store build before you upload it. Why? Because it can only be installed on a device through the app store. So better get it right!

And we didn’t.

iTunes Connect is how you control your app in the app store

I made two blunders when doing the final build. The first was somehow I didn’t copy the proper icon image settings from the internal build to the final build, so it went to the app store with the
default app icon. Doh! The second was far, far worse.

We knew our game didn’t work on anything below iPhone 3GS or iPod 3. I saw other games show this requirement in the app store along the left column. I didn’t see any way to set this through
marmalade deployment, so I assumed it was done in the app store itself.

Well when you upload an app, especially your first, iTunes Connect walks you through a wizard. The answers you provide can never be changed, you got one shot to do it right. These we did right.

Again, I didn’t see anywhere I could set the requirements, so I figured it was after I uploaded the binary. I uploaded the binary and it went into the queue for review and approval.

Well, 8 days later, it was approved. But still no way to set the system requirements. It wasn’t until later that I found out you need to modify the plist.info file to include the OpenGL ES version
to 2.0 to target the devices we wanted.

No biggie, I modified the plist.info file and proceeded to upload the new binary.

ERROR!

Apple does not allow a developer to set more narrow restrictions on an application update than the app first had. So in short: if your initial version says it will run on iPod 2, you can’t later
do an update that makes it no longer run on iPod 2. We screwed up the one thing you cannot correct through an app update. After much back and forth with apple support we had to resort to putting the requirement right into the app description. We already know people don’t read, but it’s the best we can do at this point.

And one final thing to know about releasing to the app store when you make your app on a PC: you REQUIRE a mac to upload the binary to apple.

ITunes Connect used to allow you to upload through http, but no longer. There is a binary uploader program in the iOS SDK that checks and uploads your binary to apple. That uploader program only works on a mac. So while you can build and test the entire app on a PC, you need a mac for 10 minutes to upload your final binary. I’ve seen someone suggest just going to an apple store and using a demo mac to upload. In my case I already had the mac mini, so it wasn’t terribly inconvenient, but it was a real surprise.

Releasing to the World

By default, all apps uploaded to apple are released to every itunes store in the world, unless you specifically turn a store off.

There be a lot of iTunes Stores. Fortunately you only need 6 translations to cover them all.

We had always intended to release to multiple countries, so we tried to minimize the amount of text in game and use symbols where we could (the monkey story sequences use icons rather than text for this reason, although it actually made more sense conceptually too: how do you write “monkey speak” anyway?!).

The key is to get your app description translated from your native language into the various app store languages. It costs about $100 per language to use a translation service to translate our app description. Of course, the difficulty is we have no way to judge how good the translation is!

Initial Marketing

As I write this fourth part, our game has been out in the world for 22 days. Sales haven’t skyrocketed, so we’re in no position to advise on how to market a game. However, there are two things we can share.

First, Apple controls the app store. They make their decisions based on volume. The sections like “What’s Hot” and “New and Noteworthy” are driven by volume. The more volume you can drive in the initial days, the more likely you are to appear in those sections. Obviously the key is to get into the “Top 100 Free” or “Top 100 Paid”. The only way you get there is through volume.

We’ve made it to #45 in the Family What’s Hot. Go little monkey! Go!

Secondly, we knew review sites are important to get initial buzz going, but how do you find all the review sites out there? A google search will return some of the biggies, but also blogs that haven’t been updated in 2 years. So we devised a clever way to make a short list of review sites: most games put their reviews or quotes from review sites in the top part of their app description.

By clicking through about 20 apps we were able to compile a list of 41 respectable mobile game review sites.

Most if not all review sites work from a backlog of about 3-4 weeks. And they all want a promo code to get the game for free, they won’t pay money for your app. Apple allows you 50 promo codes per release. Once you make a new release, the unused promo codes are invalidated.

In the 3 weeks we’ve been waiting, we’ve had 1 review come back. Fortunately it was a good one.

For our next title we’ll be doing more on the pre-release marketing side to get the game buzz out before release. As we were taking so long on Catch the Monkey and we didn’t really know if or when we would be done, we had to forgo pre-release marketing.

Conclusion

Well, there you have it: a summary of our ups and downs over roughly 2 years trying to make an iphone game.

We set a goal, and despite great difficulties, achieved it. Beyond this, three things have brought great satisfaction:

1. Our first review came in:

We received 4/5 stars and an editor’s choice award from the family mobile gaming site famigo.com. It’s nice to know someone objective thinks what we made is good!

2. A review someone wrote on the US store:

How fun can catching monkeys be? Hours of fun! I love this game because it’s something for my kids to do that’s different from princess games and phonics—and it’s something that I can do when I’m commuting, waiting for my next appointment, or just to relax. This has got to be one of the best non-violent games I’ve ever seen. Great graphics, good story, and entertaining for everyone.

3. The popularity of these articles.

When we first set out to talk about our experience, we didn’t know who would be interested. Over 3,000 reads and counting on the first article makes all this writing effort worthwhile! Thanks!

What’s next for Mirthwerx?

We’re currently working on a few things:

Playbook version (taking full advantage of having used Marmalade)

Android version (dido)

Free version (different from a lite version, it’s a different but similar game)

And our second title which is a puzzle game for the masses (remember, turn based!)

I’ve enjoyed writing these articles, I hope they’ve been of benefit. I have some ideas for maybe doing an “encore” 5th article next week, but I’d be looking for questions or comments from
people before I decide to do it.(source:gamedev)


上一篇:

下一篇: