作者：Kimberly Unger & Jeannie Novak

主要问题：

* 第三方工作室 & 独立开发者的利弊？

* 开发团队的核心成员？

* 如何防止项目变得过于庞大，难以驾驭？

* 独立作品平均上市所需时间？

* 独立制作会给设计决定带来什么影响？

各手机游戏都有其独特之处，制作过程有时需要重新调整，以配合手边资源和人员。新手设计师常随身携带记录众多游戏构思的笔记本——有些令人怀疑，有些颇具潜力，其中的某个构思也许能够颠覆当前的游戏世界。

将游戏构思付诸实践有时有些令人胆战心惊，尤其是对那些刚担任制作人的人士而言。游戏制作涉及管理实际操作和整个开发过程，要鼓励、诱哄及偶尔呵斥团队成员，确保项目最终得以完成。独立开发者也需要知晓团队成员的需求。独立项目有时是利用下班时间完成。由于存在上述种种情况，手机游戏开发者需注意下述若干方面。

开发阶段

手机游戏的制作过程同掌机和电脑平台的“常规”视频游戏不同。传统游戏开发遵循特定“指令”，确保作品在发行前的完美和完整性——但手机游戏的开发具有很高的灵活性。开发者可以在作品推出几个月或有时几年后继续添加和扩充内容。陈述技术细节的上千页技术文稿在此不复存在。相反，手机游戏制作团队所使用的设计文稿内容有限，具有高度灵活性，能够经常进行调整。传统掌机游戏需要花费几年时间完成，但手机游戏的整个制作流程只需几个月。

前制作阶段

不论开发者是单人工作室，还是有内部制作团队，前期制作都主要决定游戏的制作内容。需融入什么元素和功能，游戏要何时发行？前期制作包含设定“进攻计划”。记住在手机游戏领域，此总体规划需保持灵活性——不是构建整个制作计划，而是要瞄准单个功能，将项目分解成若干能够完成任务清单。

制作阶段

制作阶段的目标是建构游戏，以某种方式快速运作项目；这是解决看不见的设计问题的关键要素。在理想情境中，此阶段的目标是每1-2周设计些许游戏功能；这意味着整个作品会不断塑造模型，而非仅在某特定阶段进行。

Alpha & Beta

一般来说，到了Alpha阶段，游戏就已完成所有编码，玩家能够从头体验至尾，所有美工元素都已置于恰当位置。不是所有要素都需要最终确定；各处也许仍有需要完善的小地方。此时团队就需要从游戏创造切换到游戏完善。这个阶段编码已最终确定，此时主要侧重优化和完善游戏内容。这是手机游戏制作同传统游戏设计的一大差异所在。搭载掌机的作品需要更长的开发周期，Alpha和Beta阶段的区分更明确——但在手机项目中，这些阶段通常混为一体。手机内容的最终目标是推出可行作品，确保开发者能够在发行后通过更新内容进行必要完善。

Gold

若你应对的是掌机风格的设备，Gold依然是标准尺度：开发商呈现的需是完整的、吸引眼球的成形作品；发行后就鲜有机会进行调整。但手机内容不再设有明确的Gold阶段。将产品投放至应用商店是主要任务——所以若作品依然存在些许问题，我们依然有机会进行更新和调整，完成相应的修复和升级工作。

后制作阶段

即便作品已发行，开发商依然需要进行一定的调整。通过检验参数（游戏邦注：有关用户行为和营收的信息），设计团队能够获悉用户在哪些地方遇到麻烦，在哪些地方卡住，或玩家体验多久才退出游戏。这些内容促使开发者做出调整，以推出更新内容的形式呈现。

敏捷开发阶段

游戏的制作阶段持续进化。源自制造业和产品开发的传统制作过程无法匹敌手机内容制作的高速度。致力掌机和PC内容的游戏开发者重新改造这些方式。对手机游戏开发而言，这些过程依然过于缓慢，若要保证顺利运作，需要进行调整。游戏行业向来都会对任何无法实现预期目标的制作过程进行调整——手机游戏领域亦是如此。

采用敏捷开发模式（游戏邦注：涉及增量和迭代组件的软件开发方式，更多着眼于应对变化和团队成员，而非工具和计划）的手机游戏会取得更突出的表现。由于团队规模相对较小，迭代之类的敏捷开发过程能够更快、更轻松地实现。开发者不是以相同速度推进整个项目，而是将其分解成小区块。开发者根据任务清单列表将游戏要素投入制作，进行单个元素的建模——这会带来持续不断的建模过程。

Scrum

Scrum是更受关注的敏捷开发过程。简单来说，这是个预定框架，旨在确保跨学科的单个团队能够积极进取，在开发过程中制作多个版本的作品。作品被分解成系列“故事”，这些故事的制作过程又进一步分解成“小冲刺”——团队成员逐步完成各要素，然后回到故事堆，继续分解剩下的任务，选择下个“冲刺”的要素。

诸如Scrum的敏捷开发过程旨在保证产品开发过程的灵活性，确保能够进行轻松修改，这样开发者就能够满足用户预期，迎合快速变更的市场。

Scrum是个可以教授的开发模式——工作室可以雇用持有Scrum Master Certificate证书的制作人，或聘请外部专家教制作团队如何在Scrum框架下进行操作。虽然Scrum在大型团队中获得顺利运作，但他们依然难以达到手机开发的高速度。许多工作室都进行一步调整Scrum，将其整合至其他模式，创造符合自身需求和目标的混合制作方法。

Kanban

这是JIT制作过程的组成部分（游戏邦注：此技术由日本商人大野耐一开发，Kanban是排程系统，能够生成更大部件，呈现各相关要素）。在多数敏捷系统中，这些组件都具有完整功能；开发者能够转向任务清单开始下个要素，而非以相关步调推进整个项目的进展。Kanban起初的运作方式同Scrum类似，客户的需求和欲望由系列“故事”的组织方式决定；它还能让功能由面板的左边移到右边。但和Scrum不同，Kanban允许要素在需要更多时间的情况下重新回到左边，不论在制作过程，还是在其他开发过程；它还腾出空间给紧急要素——这些要素能够排在优先名单中，优先进行制作。

和其他杰出的制作方法一样，上述敏捷开发过程依然具有一定的灵活性，可进行调试，更好配合团队。记住敏捷是种制作理念，而非固定不变的系列规则。

开发团队角色

虽然创建开发团队取决于许多要素，但在手机内容领域，这些要素在早期阶段并不那么重要。但有许多游戏设计要素依然非常重要，只是由于设备局限，这些内容得到相应简化。制作手机内容的一大吸引之处是公司无需配备大型团队——这是因为内容的制作速度相对较快，相对较简单。其实一个完整的项目可以凭借一个人、一台电脑和一个追梦信念完成。但即便是一个人，他也需要区分不同制作角色，清楚如何进行组合，方能呈现合理的进攻计划。

管理

开发工作室的核心管理职位是制作人，他负责运作项目，确保所有内容都能够按期完成。在手机游戏中，制作人可以是团队领导（游戏邦注：包含设计、美工和编程），也可以是营销总监。就小型独立工作室而言，制作人通常是最早提出构思之人（通常是设计师）。这很难定义——但在2-3人工作室中，这不可或缺。

在大型工作室，特别是当各项目需要共享资源时，制作人的角色就不可或缺。即使如此，我们依然很难确保总是设有特别小组——尤其是在开发周期较短的手机项目中，有时单个项目也许需要同时投放上千个设备。

设计

在小型工作室中，游戏设计通常还涵盖另一角色。姑且不论工作室规模，游戏设计的主要角色不仅涉及架构游戏的最初构思，还包括同其余团队一同开发内容，无缝隙地将修复、变更和新探索内容融入游戏设计中。

编程

在完整的游戏中，编程任务总是分解成不同科目（例如，图像、声音、AI、引擎、工具和网络）。在手机领域，编程人员通常最多两个人，更多时候只有一个人。例外情况是，团队出于授权目的编辑引擎。

美术

在完整的游戏开发中，美术内容通常进行专门划分（例如，概念、架构、建模、动画、角色和环境）。行业如今开始逐步跳脱原先的少数多面手负责所有美术内容的局面，变得更加专门化。相反，手机领域的美工需要将自己培养成“多面手”。在手机领域，一个美工通常需要处理概念图和所有游戏美术设计——从游戏屏幕和背景到影视艺术和影片剪辑。

声音

遗憾的是，手机内容的声音制作依然处于初级阶段。由于预算和时间限制，声音部分常归到其他内容。在发行商支撑的大型项目中，包括既有掌机游戏的分解版本，如《刺客信条》，游戏通常都会制作音效，必要时还会进一步细分任务。好消息是，越来越多声音制作的专业人士开始加入手机领域，独立开发者开始意识到高质量音乐、声音设计和对话的重要性。

测试 & 质量保证

手机游戏也有测试和质量保证（QA）。即便单人小型工作室也会向若干好友呈现作品，让他们进行体验，以发现其中存在的糟糕漏洞。发行商支持的工作室通常能够接触到更广泛、更正式的测试QA。缺乏此强大阵容，QA的主要任务就需要由既有团队成员完成。手机开发商能够无线发布iOS应用，进行“特别”测试，接收者能够轻松安装这些预发布内容。TestFlight通过允许开发者自己邀请测试者（游戏邦注：通过邮件），查看测试对象，进一步优化此过程。Android开发者可以将他们的Beta内容放到Android Market，或向用户发送APK，这样他们就能够将内容装载到自己的系统。采用此方式时最好在游戏中创建机制，这样测试者就能够轻松提供反馈信息。

规模 & 范围

手机游戏需要保持小规模和小范围。在传统游戏开发中，常有“越多越好”的说法——很多开发商都从较大构思着手，然后进行调整，配合限制条件。与之相反，许多手机开发商倾向“保持简单”；通过首先专注机制（游戏邦注：即玩法具体细节），设计过程就会自然呈现限制条件。

功能累赘

功能累赘，有时也称作范围蔓延，是指出现更多意料之外的游戏构思。制作人和游戏设计师需要花时间参与范围控制——控制范围蔓延，确保团队着眼于游戏的核心要素，将附加功能放置于独立的“功能列表”中，后期也许还有时间和预算添加这些内容。开发者需通过下述两个问题评估所有新功能或设计元素：

* 融入此元素是否给玩法带来积极影响？

* 去除此要素是否会损及游戏？

若新功能会给游戏带来消极影响或并非必要元素，那么就不应将此元素添加至功能列表中。

上市时间

手机游戏的概念化和开发过程更简单、更迅速——它们也更快现身市场，发光发热，然后烟消云散。软件开发领域众所周知的事实是10个人挖洞无法比一个人挖洞快10倍。项目融入越多人，就越容易放缓进度，主要缘于大家对项目的支持。团队越复杂，就越容易打破某些东西。单手机游戏的上市时间就使得更小、更快、更敏捷的团队结构必不可少——即便是对大型发行公司而言。

独立开发

现在是凌晨2点，最后一块内容顺利完成。无需告知老板，无需迎合什么时间表。整个过程只有你，还有你的代码文库和咖啡。听起来像是理想工作？随着应用商店（游戏邦注：这主要针对智能手机）的出现，个人和独立开发者的市场更加细分化。

个人目标

从理论上讲，独立开发者在手机游戏领域的发挥空间不受限制。但就回报来看——应该至少抵消开发过程的咖啡和糖包费用，开发商选择自己的战场非常重要。快速、利落地开发，不断制作内容。制作、开发和发行游戏不是人人都能做到的，第二款作品更难以完成。获得收益的单人开发者或小型工作室通常不会只开发一款作品。首先，判定开发游戏的原因非常重要。是出于热爱游戏？还是你有很棒的构思，有相应的编程技能支撑？还是将此当作你进入更广阔游戏开发世界的跳板？名声，还是荣耀？还是金钱？吹嘘权利？还是当你将自己的作品下载到自己刚买的iPhone上时，父亲的表情？

真正的原因并不重要，重要的是弄清原因。你的游戏项目需要理清这些内容，否则坎坷的开发过程会让你停滞不前。

设计选择

采取独立开发意味着只能运用自己的能力。若你有全职工作，只在业余时间开发游戏，需确保“保持简单”，制作自己能够驾驭的内容。记住复杂内容并不一定会更好。玩法、平台适合度、简短娱乐体验都是杰出手机游戏的特征。益智和物理游戏通常是入门者的最佳选择，这类内容已有许多典范，它们都由简单规则构成。

平台

Android、iPhone、Windows Phone和黑莓平台都非常适合独立和小型开发团队。这主要是因为在这些平台发行和推广内容相对容易。PSVita和3DS之类手持设备的游戏环境对于独立或小型团队更为不利——部分归咎于授权和开发工具的成本。

iPhone

投身iPhone平台首先要注册成为iPhone开发者。这让开发者得以接触iPhone开发者论坛、开发游戏所需的软件、抽样代码、指导资料——几乎所有除游戏构思以外的必备要素。锁定iPhone平台的一大好处是开发者所需处理的设备有限。

Android

Android是个新平台。此操作系统由谷歌研发，出现在各种不同的设备上。问题是：虽然Android是个相当开放的系统，Android Market的审判流程相当迅速和简单，但游戏需运作于各种不同设备（游戏邦注：每个设备都有截然不同的配置）。

Windows Phone

Windows Phone与Android操作系统情形类似。当前市场上存在许多不同的Windows Phone设备——但由于Windows Phone OS的相对封闭性，设备的变化并不大。

黑莓

由于市场上的黑莓设备有限，它和iPhone存在些许共同之处。和苹果一样，这些设备的差异主要体现在年代上，而非特定运营商的硬件标准——所以我们完全能够只锁定1-2个设备开发和测试内容，无需瞄准10多个设备。

发行

所有开发平台都包含呈现游戏或应用的独特发行过程。待到更广泛地采用基于平台的商店，如Android Market和苹果App Store，手机游戏的推广就能够通过锁定运营商的手机商店（通常被称作运营商平台，手机运营商通过自己的购买选择宣传和推广游戏）完成。Verizon的“Get It Now”就是典型的例子。

由于大多运营商都要求开发者支持他们的设备，而这些设备通常采用不同操作系统和配置，这就限制个人或小型团队开发者的发挥。若干制造商纷纷发行自己的智能手机商店，旨在促使开发商瞄准自己的设备设计应用（例如黑莓的App World）。有些制造商无法促使开发者瞄准自己的设备开发应用；用户就依然需要通过运营商平台、网页或其他资源去发现和下载他们相应的程序。那里没有手机到制造商的直接链接。

独立手机开发者依然面临着在何处发行的问题。目前依然还有很多网站出售瞄准某设备的游戏和应用，但这些缺乏质量控制；在某些情况下，网站运营商甚至都不会检查应用在所宣传智能手机的下载和运作情况。这些内容集合网站还融入大型发行商发行的掉出运营商平台的游戏，运营商平台放弃这些游戏或由于他们无法带来足够收益，或由于已超过生命周期。

游戏要获得展露机会，需搭载瞄准OS的应用商店：Apple App Store（苹果）、App World（黑莓）、Android Marketplace（Android）和Windows Phone Marketplace（微软）。这些销售渠道都有单独的发行过程，所有提交的内容都要经过某种形式的审核。这些操作系统的注册用户能够获悉相关应用商店的发行要求和过程——他们需了解最新的限制条件。例如，苹果持续基于用户反馈和Apple App Store滥用情况完善和修改自己的发行限制条件。常触及iPhone和iPad限制界限的开发者，其作品就有被撤下的风险，若这些规定变得更加保守。

工作室开发

成立自己的工作室会带来相应的问题，这些问题不仅仅涉及融资。新手开发者存在的普遍误解是同发行商签订合约就足以运作工作室——但多数时候，组建正式的工作室需要有预备资金，以现金融资或人力资产形式。

毋庸置疑，凭借资金雄厚创建工作室要比自我奋斗简单得多。虽然有许多热心的新手开发者愿意冒此资金风险，但所有问题的关键点还是维持运作；这意味着全职、兼职工作同游戏开发时间冲突将导致团队成员流失。许多工作室承诺同成员分享将发行游戏的权益股，但开发者也只有待到作品发行几个月后才能从中受益。

手机游戏的一个优势在于开发速度。开发手机游戏所用的时间通常少于6个月，根据游戏的复杂程度，有些作品的开发周期常短至几星期。这意味着我们能够运用其他成员的业余时间制作出一款作品，但这不代表所有游戏都以同样方式完成。

与掌机和电脑游戏领域（游戏邦注：即便是高质量的游戏也难以获得长久生命）一样，手机游戏领域也常出现昙花一现。

办公地点 & 虚拟团队建设

租赁办公地点，摆脱在家办公，分布各地的局面有其利弊。一方面，组建虚拟团队意味着你无需支付日常开支；所有团队成员都是独立合约人，持有自己的设备，负责自己的项目任务。会议可以通过各种多方或多地点会议软件和系统（例如，Skype、WebEx和Google+ Hangouts）每周或者甚至是每日举行。虚拟团队设置需要更多自律性，团队成员需要承担更多责任（游戏邦注：他们要能够在较少监督的情况下完成任务）。若出现差错时，他们拒绝回复电话或从虚拟空间中消失，要如何处理？驱车到他家，在他家前面的草坪搭棚等待？若创建虚拟团队，我们就需要相应的控制措施——包括每天固定检验美术和编码内容。若团队成员遭遇个人突变，项目遭受的损失就会降到最低。若设有集中办公地点，约束就来自外部世界。所有资源和材料都放在同个地方——若某人未出现，大家就会发现。

记住独立合约人和雇员存在区别。确保自己知晓其中规则，即便你和两位挚友目前达成口头共识，同意共同“冒险”。例如，加利福尼亚工人若每天得在公司的办公地点工作固定时间，他们就是雇员。虽然工作室成立时大家都是“好朋友”，但这会随时间发生改变——一个涉及雇佣问题的法律诉讼会摧毁一家挣扎中的初创公司。

利润分成 & 工资

当以利润分成的形式雇佣开发者时，有两个问题需要注意。

1. 回报也许会非常渺小。所谓的可持续开发者并不是指推出一款轰动巨作，而是指开发系列颇成功的作品或是系列持续创造些许收入的低产作品。这意味着单个团队成员的投资回报率（ROI）将非常低——尤其是当工作室有若干成员，每人每次只投身一个项目。虽然长久回报能够抵消开发成本，但获得回报的持续时间过于漫长，此时团队成员也许早就离开。

2. 若团队成员共享所有收入，公司就所剩无几。持续性意味着暂时付给员工酬劳，即便现在没有新工作。这种持续性意味着开发者在没有同发行商合作第三方项目时，可以发行原生作品。发行合约存在“潮起潮落”；不论你认识谁，你在业内拥有多少好友，时机也许不复存在——公司需要有运营资本应对差额情形。若你已做出承诺，你就需要想办法维持，或者选择关闭公司。游戏开发世界存在许多倒闭的工作室，这些工作室的创始人都是携手发行商开发游戏，但最终无法快速推出第二款作品，维持发展势头。

融资

融资是创建公司最棘手的问题。尤其是在游戏领域，这片市场真正可销售的资产非常有限：许多电脑未来将遭到弃置，所有已购买的devkit工具和大量优秀游戏构思。

投资者

知识产权只有在得到开发的情况才变得有价值——所以除非原型已创建，否则公司需提供更多内容，证明项目值得投资。我们常听到此公司或彼公司获得1000万美元或超过3000万风险资本。多数时候，这些公司都已成立——项目制作已准备待续，配有曾在知名公司推出系列成功作品的经验丰富管理团队，或存在某些业绩，能够带给投资者信心。

天使投资者是初创公司的首选；所谓的“天使人”通常是指在小公司中投资5万、10万，或者甚至是50万美元（游戏邦注：通常低于100万美元）的个人，期望几年后获得更大回馈。同天使投资者碰面的最佳方式是通过介绍——最好是通过某个同他做过生意的人士。当然还有投资峰会和会议，这些也能够创造遇见小投资者的机会。寻找投资项目的天使人通常非常愿意同有梦想的企业家面谈。

现金支出

多数小型的正式工作室最初都是以现金融资创建公司。也许是你自己积累这些项目制作的资金，也许你是之前某被收购初创公司的合伙人，也许你有个刚过世的富翁叔叔，留给你他的维多利亚痰盂收藏；反正你是通过手边现金启动项目。这咋看之下好像完全自由——但你的投资资金会很快耗尽。考虑获得合约，继续运作所需的时间非常重要。初期应只招聘少量员工；手机游戏所需的人员很少，所以不妨从单个程序员着手，然后再慢慢扩大。

自力更生

自力更生在单人工作室情形中最常见；我们很难集聚到4-5个充满激情且经济稳定的开发者共同着手某缺乏资金的项目。但若投资者和现金融资尚未到位，不妨考虑单独制作1-2个小型项目积累资金，直到能够独立发展公司。此时，其他融资机会也许就会出现！

组建团队，发展游戏工作室后，就到了做决定的时候。你是要维持“生活风格”状态，还是要将公司出售给大型公司，争取更多收入？在手机游戏开发领域，二者都是可行选择——但若你引入外部投资者，那么获得更多收入将是你的目标。

快速 & 灵活性

在制作阶段，相比传统掌机或PC游戏，手机游戏进展更快，需要更大的灵活性。关键角色和要素依然不变，但处理的方式截然不同。最重要的是手机制作过程具有高度灵活性。由于手机游戏继续基于用户反馈和参数信息发生变化，一款手机作品也许会在其生命周期中经历多次制作过程。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Excerpt: Mobile Game Development – Going Into Production

By Kimberly Unger and Jeannie Novak

[This extract from Game Development Essentials: Mobile Game Development offers an in-depth overview of the production processes, team roles, funding, and platforms involved in mobile game creation.]

Key Chapter Questions

* What are the pros and cons of being a third-party studio vs. independent developer?

* What are the key members of a development team?

* How can you keep a game from getting too big to finish?

* What is the average time to market for an indie game?

* How can going solo affect design choices?

Every mobile game is different, and the production process is sometimes reinvented to fit the resources and staff on hand. Budding game designers often carry notebooks full of ideas-some questionable, some with potential, and perhaps one that might change the world of games as we know it.

Putting an idea into action can get a little scary sometimes, especially for those who are experiencing their “first runs” at being producers. Game production involves managing the hands-on, moment-to-moment development process and working with a team-encouraging, cajoling, and occasionally shouting (but hopefully not too often) to bring a project to fruition. Even an indie developer must understand the needs of the team members. Indie projects are sometimes developed after hours-in the dim time between the day job and before the alarm screams again. Due to this reality, there are special considerations and precautions that should be taken.

Development Phases

The production process for mobile games is different from what is seen in “formal” video game development for console and computer platforms. In traditional game development, there is a “mandate” to make sure the entire product is perfect and complete before it ships-but in mobile games, there is a much greater degree of flexibility. Game elements can be added and expanded upon for months or sometimes even years after a product is released into the market. Gone are the thousand-page design documents with reams of technical detail. Instead, mobile teams use limited documentation that is flexible and changes dynamically on a regular basis. While traditional console games might take years to complete, the entire mobile game production cycle might take place within just a few months.

Pre-Production

Whether the developer is a single-person studio or an in-house team, pre-production is the phase in which what game will be produced and how are both decided. What elements and functions need to be included and at what point can the game be released? The pre-production phase involves setting a “plan of attack.” Keep in mind that for mobile, this master plan must stay flexible-so rather than building out an entire production plan (which is often done for a console title), focus instead on individual functionalities and break the project down into small chunks that can be completed and checked off the ‘to do’ list.

Production

During the production phase, the goal is to get the game up and running as quickly as possible in one form or another; this is a key component to solving unseen design issues. In an ideal situation, the goal is to have a working build of the game functions every week or two; this means that the product as a whole is constantly being prototyped, rather than having a single distinct phase for the process.

Alpha & Beta

Traditionally, by the alpha phase, the game is code complete-playable from start to finish, with all art assets in place. Not everything is necessarily final; there may still be a few bits and pieces here and there that need improvement. This is where the team makes a shift from game creation to game refinement. Code is locked, and the majority of time is spent making the game as polished and complete as possible. This is one of the major divergent points from more traditional game design. With a console-based product (3DS or PSVita) with a longer development cycle, the Alpha and Beta stages are more clearly defined-but with mobile projects, these stages tend to get mashed together. The end goal for mobile is a viable, shippable product that can be polished as needed through updates after it has been released.

Gold

Goooooooooooooooooooooooooold! If you’re working with console style handhelds, Gold is still the standard: A complete, finished, shiny product is needed for delivery; once it goes out the door, there are only very limited opportunities to change it. However, the Gold stage has become indistinct in mobile releases. Getting a product into the app store is paramount-so if it ships with a few issues, there is still an opportunity to push updates and changes that allow for fixes and upgrades.

Post-Production

Wait-there’s more? Even after a mobile product is pushed out the door, there are still changes to be made. By reviewing the metrics (information collected about player habits and monetization), the design team can see where players have issues with the product, where they might be getting stuck, or how long they play before the put the game down. These elements drive changes to the design that can then be iterated upon and pushed back out as updates (the mobile version of “patches”) to an installed user base.

Agile Development

The production process for games is constantly evolving. Traditional processes derived from manufacturing and product development just can’t keep up with the ultra-high-speed pace of mobile development. These methods were reinvented by game developers working with console and PC products. For mobile game development, these processes are still a bit on the slow side and need some modification if they are going to work. The game industry has a long history of reinventing any process that gets in the way of the intended result-and the mobile game industry is no different.

Games for mobile tend to work better when utilizing an Agile development process-a type of software development methodology that involves incremental and iterative components, focusing more on response to change and team members rather than tools and plans. Due to the relatively small team sizes, Agile processes such as iteration become much quicker and simpler to manage. Instead of being pushed forward at the same rate, the entire product is instead broken down into smaller pieces. As each game element is taken from the list of “to-do” items and put into production, the prototyping of that individual element is handled-which results in the occurrence of some sort of prototyping process on an ongoing basis.

Scrum

Scrum is one of the more broadly known of the Agile development processes. In a nutshell, it is a predefined framework designed to allow a single, cross-disciplinary team to be able to work aggressively and iteratively-producing many versions of a product during its development cycle. The product is broken down into “stories,” and the development of those stories is further broken down into “sprints”-with team members pushing one element forward to completion, then returning to the backlog of stories to reassess the remaining tasks and choosing the next element to “sprint” on.

Agile development processes such as Scrum aim to keep the product development process flexible and easy to modify in order to keep up with client expectations and a rapidly changing marketplace.

Scrum is a teachable process-and a studio might hire a producer who holds a Scrum Master Certificate or bring in an outside expert to teach an entire production team how to work within a Scrum framework. However, while Scrum works well for large studio teams, it is still a bit unwieldy for the speed at which mobile development operates. Many studios have adapted the Scrum methodology by integrating it with other models to create hybridized production methods that suit their own needs and ideals.

Kanban

Part of JIT (just in time) production-developed by Japanese businessman, Taiichi Ohno-Kanban is a scheduling system that yields larger pieces reflecting several interrelated elements. In most Agile systems, these pieces are pushed to full functionality; the developers then return to the “to-do” list to start on another piece, rather than trying to push production on the entire piece of software forward at the same pace. Kanban begins like Scrum, with the needs and wants of the client determined by assembling a list of “stories”; it also allows features to move from the left of the board (where they are essentially still ideas or stories) to the right (where they are declared completed). However, unlike Scrum, Kanban allows elements to move back toward the left if more time is needed, whether during production or another part of the development process; it also makes room for urgent components-elements that can be fast-tracked to rise to the top of the queue and pass through production on a high-priority basis.

Just like any good production methodology, even the “named” forms of Agile development (there are a great many ways to develop using an Agile process, but not all of them are common enough to be given names or be taught in a formal setting) maintain some flexibility and can be adjusted to better fit the team in question. Keep in mind that Agile is a production philosophy, rather than a hard and fast set of rules.

Development Team Roles

Although setting up a development team depends on a number of factors, mobile-specific issues are surprisingly not that relevant early on. Most game design elements are still important, but they’re just abbreviated due to device constraints. One of the attractions in developing for a mobile title is that it’s unnecessary to have a large team-due to the relative speed of development and simplicity of design. In fact, an entire game can be developed with just a single individual, one laptop, and a dream. However even a single developer must be able to distinguish between different production team roles and how they all fit together in order to lay out a proper plan of attack.

Management

The key management position in a development studio is often the producer, who is responsible for making things happen and ensuring that everything ships on schedule. In the case of a mobile title, the producer could also be anyone from a team lead (design, art, programming) to the marketing director. For very small and indie studios, the producer often ends up being the person who initially developed the concept (often the designer). This can be a difficult job to juggle-but in the case of a two- or three-person team, it becomes a necessity.

Within a larger studio, particularly when sharing resources across multiple projects, the producer position becomes an absolute essential. Even then, it is not always possible to have a wholly dedicated team-particularly in mobile where development times are short, and a single product may need to be pushed out across several thousand devices simultaneously.

Design

In a smaller studio, game design is almost always doubled up with another role. The primary role of the game designer, regardless of the studio’s size, is to not only create the initial concept of the game but to work with the rest of the team to develop and incorporate any fixes, changes, and new discoveries into the game design as seamlessly as possible.

Programming

In full-scale games, programming tasks are broken down across multiple disciplines (e.g., graphics, audio, artificial intelligence, engine, tools, network). In mobile, programming teams usually max out at two and more commonly involve just a single programmer. The exception to the rule is when teams program engines for licensing purposes (e.g., GameSalad, Unity).

Art

In full-scale game development, art involves specializations (e.g., concept, texturing, modeling, animation, character, environment). The industry has rapidly moved away from a few generalists handling all aspects of art production into massive specialization. In contrast, a mobile artist needs to have a “jack of all trades” mentality. In mobile, a single artist often handles concept art and all aspects of the in-game art-from the title screen and backgrounds to cinematics and cut-scenes.

Audio

Regrettably, audio in mobile games is still in its infancy. With small budgets and tight time constraints, audio is sometimes “kludged” together by a team member. In larger, publisher-backed titles-including stripped-down versions of existing console titles such as Assassin’s Creed-the audio has already been produced for the larger game and can be re-tasked as needed. The good news is that more audio professionals are getting involved in mobile games-and indie developers are beginning to understand the importance of high-quality music, sound design, and dialogue in their games.

Testing & Quality Assurance

Testing and quality assurance (QA) (whether internal or external) does exist in mobile games. Even single-person micro studios hand the game around to a group of friends and let them bang on it for a while to be sure the worst of the bugs are found. Publisher-backed studios often have access to a more extensive and formalized QA group for testing. Without this luxury, the primary QA tasks need to be handled by the existing team members. Mobile developers can distribute iOS apps wirelessly for “ad hoc” testing purposes-and recipients are easily able to install these pre-releases. TestFlight has further refined this process by letting developers invite testers via email and see who has tested which builds. Android developers can put their Beta builds on the Android Market or send the APK to any number of people who can then side load it onto their systems. When using this method, it’s a good idea to build a mechanism within the game so that the testers can easily provide feedback.

Scale & Scope

Mobile games need to be smaller in both scale and scope. In traditional game development, it is often said that “more is better”-and many developers begin with a larger, grander idea that is trimmed to fit within constraints. In contrast, many mobile developers prefer to “keep it simple”; by initially focusing on mechanics-the nuts and bolts of gameplay-the design process naturally provides constraints than help to keep the game on task.

Feature Creep

Feature creep, sometimes called scope creep or “featuritis,” has been the death of more great game concepts than anyone is willing to reveal. The producer and game designer need to spend time engaging in scope control-reining in scope creep and ensuring that the team focuses on the core elements of the game-with additional features kept on a separate “feature list” in case there is time and budget to add them later. Any new feature or design element must be carefully evaluated with two questions in mind:

* Will including it positively affect the gameplay?

* Will omitting it hurt the game?

If the new feature will negatively affect the game or will not be absolutely essential to it, then it should not be added to the feature list.

Time to Market

Mobile games are quick to conceptualize and develop-and they’re also fast to hit the market, bloom, and fade away. It’s a known fact in software development that 10 people cannot dig a hole 10 times faster than a single person. The more people that are added to any given project, the more it will slow down simply due to supporting the project (e.g., everyone plays well together, all the ducks are in a row, Programmer A delivers code that works well with Programmer B’s interface, artists deliver assets that fit with the overall visual style). The more complex the team, the easier it is to break something. Time to market alone in mobile games necessitates smaller, faster, more Agile team structures-even within the confines of large publishing houses.

Going Solo

It’s 2:00 A.M., and the very last build complies without a hitch. There’s no boss to call, and no milestones to meet. It’s just you, with your trusty code library and all the coffee you can drink. Sound like a dream job? With the advent of app stores that are specific to a single smartphone, the market for individual and independent developers has broken wide open.

Individual Scope

In theory, there is no limit to what can be done with mobile games as a lone developer. However, to see a return-which should at least cover the costs of coffee and sugar packets consumed during development-it’s important for lone developers to pick and choose their battles. Develop quickly and cleanly-and keep developing. Producing, developing, and publishing a single game is an achievement that not just anyone can match-and the second game is even more difficult to finish. Single developers or even very small teams who earn incomes doing this often push beyond that single title. First, it’s important to decide just why you’re doing this. Is it because you love games? Do you have the coolest idea ever and the programming skills to back it up? Are you looking at this as your entré into the larger world of game development? Fame and glory? Money? Bragging rights? The look on your dad’s face when you download your game onto his new iPhone?

The exact reasons don’t matter, but it’s important to know what they are. Your games will need to address these reasons, or the great swampy middle of the development process will bring you to a standstill.

Design Choices

Going solo means working within your own capabilities. If you have a full-time job and are building games as a hobby in your spare time, make sure to “keep it simple” by first creating a game you know you can finish. Keep in mind that a complex game isn’t necessarily going to be better. Elements such as gameplay, platform suitability, short entertaining play sessions are the hallmarks of great mobile games. Puzzle and physics games are often perfect starting choices, since there are so many great examples available that can be created using a very simple set of rules.

Platforms

The Android, iPhone, Windows Phone, and BlackBerry hardware platforms are best suited for individual or small-team developers. This is due primarily to the relative ease of publication and distribution on these platforms. With handheld devices such as the PSVita and 3DS, the environment is much more hostile to individual or small-team developers-in part due to the licensing and development kit costs involved.

iPhone

Developing for the iPhone requires registering as an iPhone developer. This allows access to iPhone developer forums, software needed to develop titles, sample code, instructional materials-almost everything needed outside of the original game concept itself. One of the greatest benefits of developing for the iPhone is the limited number of devices that the developer needs to address.

Android

Android is the new kid on the block. The operating system was developed by Google and is available on devices from a number of different manufacturers. And therein lies the rub: While the Android is an extremely open system, and the Android Market approval process is swift and straightforward, the game must be run on several different devices-each with slightly different configurations.

Windows Phone

Developing for Windows Phone is similar to developing for the Android operating system. There are many different Windows Phone devices on the market-but due to the relatively closed nature of the Windows Phone OS, there may be less variation among them.

BlackBerry

With a limited set of devices available on the market, the BlackBerry has something in common with the iPhone. Much like Apple, the differences in these devices are largely generational rather than related to hardware customization for specific carriers-so it’s possible to develop and test on just one or two devices rather than a dozen or more.

Publishing

For each development platform, there is an individual publishing process required to make the game or application available for all to see. Until the broader adoption of platform-specific stores such as the Android Market and Apple App Store, distribution for mobile titles was primarily handled through a carrier-specific mobile store referred to as a carrier deck-and a rotating list of titles was promoted and distributed by a mobile carrier through its own purchasing option. Verizon’s “Get It Now” is one of the widest known examples.

Since many carriers require developers to support a large number of their devices, often all with different operating systems and requirements, this process becomes prohibitive for individual or small-team developers. In an attempt to push applications designed specifically for their own devices, several manufacturers launched their own, smartphone-specific stores (e.g., BlackBerry’s App World-which could be found through the associated web site, but not directly through the phone). The manufacturers didn’t have as much ability to push applications developed for their devices; consumers still needed to either go through the carrier’s deck, the web or other sources to find and download the programs they wanted. The direct link from the phone to the manufacturer wasn’t there.

Independent mobile developers are faced with the question of just where to publish. There have been a number of smaller web sites that will allow sales of games and applications designed for a single device, but these sites also have no quality control; in some cases, site operators don’t even check to be sure an application downloads and plays on the advertised smartphones. These content aggregation sites also contain games by larger publishers that have slipped off the carrier decks because they either weren’t generating enough revenue to be worth the associated fees or had outlived their life cycles.

For a game to have a chance, it needs to be available through OS-specific app stores: Apple App Store (Apple), App World (BlackBerry), Android Marketplace (Android), and Windows Phone Marketplace (Microsoft). Each of these outlets has a separate publication process, and all submitted games will undergo a review in some form or another. Registered developers for any of these operating systems have access to the associated app store publication requirements and processes-and they should read and understand the most current set of restrictions. For example, Apple is continually refining and modifying its restrictions for publication based on consumer feedback and Apple App Store abuses. Developers interested in pushing the acceptable boundaries of the iPhone and iPad run the risk of getting an app pulled if these rules shift to the more conservative.

Studio Development

Starting a development studio comes with its own set of problems, not the least of which is funding. It is a common misconception among new developers that having a contract in hand with a publisher is enough to get up and running-but most of the time, putting together a formal development studio requires upfront capital in the form of cash funding or sweat equity (working for free for the first game or two until capital increases enough to allow for a more formal salary arrangement).

Needless to say, starting a studio with a fat wad of cash is a lot easier than bootstrapping (discussed in the Financing section). Although there are many enthusiastic new developers who are willing to take financial risks, one of the biggest sticking points across the board is the need to eat; this means getting or keeping a day job, freelance work or other opportunities that will interfere with game development time and may result in the loss of team members at some point during production. Many studios launch with the promise of an equity share in the games expected to be released, but this also means that developers aren’t paid until months after products ship.

One advantage of mobile games is the speed of development. The time commitment to develop a game is usually less than six months and can often drop into weeks depending on the simplicity of the title. This means it’s possible to develop a game using the good graces and spare time of the other team members, but it doesn’t mean that a whole catalogue of games should be developed the same way!

One-hit wonders are as common in mobile games as they are in traditional console and computer games-and even high-quality games aren’t always enough to ensure long-term sustainability (Pictured: Marroni’s iBailout!! and BurstStudio’s Kitten Cannon).

Office Space vs. Virtual Team Building

There are advantages and disadvantages to leasing office space and working out of a home office with a distributed (or “virtual”) team. On one hand, having a virtual team means you don’t have to pay the overhead; all team members function as independent contractors, maintaining their own equipment and holding responsibility for their own piece of the project. Meetings can be held on a weekly or even daily basis via various types of multi-party or multi-location conference software and systems (e.g., Skype, WebEx, Google+ Hangouts). A virtual setup requires more discipline and greater personal responsibility on the part of the team members-who must be relied upon to do the work with only limited oversight. If something goes wrong and they stop returning phone calls or vanish from the virtual space, how will you handle this? Drive to their house and camp out on the front lawn? When building a virtual team, it’s necessary to have controls in place-including checking art and code assets in and out each day from a common location (whether online through version-control software such as Assembla or Google Docs, or on a private company server). If a team member suffers a personal tragedy (or if the programmer goes to Burning Man and comes back having eschewed all technology), the damage to the project will be minimal. If there’s a centralized office space where everyone physically puts in their time-even if it’s the basement of your grandmother’s house-the discipline is imposed from the outside. All the resources and materials are in one place-and when someone fails to show up for work, everyone else will notice.

Keep in mind that there is a difference between an independent contractor and an employee. Be sure you know the rules, even if you and two of your best buddies have all agreed verbally to work “on spec” for the time being. For example, California workers are classified as employees when they’re required to work in the company’s office space (even if it’s in a private home) at set hours each day on company equipment. Although everyone might be “best friends” when the studio starts up, this might change as time goes on-and one employment-related lawsuit can break a struggling startup.

Profit Share vs. Salary

There are two key issues to consider when bringing on developers to work for profit share, rather than cash or a salary.

1. The return is likely to be very small. Becoming a sustainable mobile game developer isn’t so much about having one hit title but developing a long string of moderately successful or even low producing titles that continue to trickle in cash over a long period of time. This means that the return on investment (ROI) for any individual team member may be fairly low-especially if there are several different people each working on just one game each. While the return over time may cover development costs, the length of time it takes to see a return can simply be just too long for your team members to stick around.

2. If all the revenue is divided up among the team members, it’s not going back into the company. Sustainability means continuing to pay employees for a while even if there is no new work coming in. This type of sustainability means that a developer can publish original games when it isn’t working with a publisher on a third-party title. There’s an “ebb and flow” associated with publishing contracts; no matter who you know or how many friends you might have in the industry, the timing might just be off-and your company must have the working capital to survive the shortfall. If you’ve promised it all away, then it will be necessary to come up with a plan to survive or close your doors. The world of game development is littered with the corpses of studios whose founders came together to develop a game for a publisher but were unable to land a second title quickly enough to keep the momentum going.

Financing

Financing is the great sticky wicket of forming any company. In games in particular, actual saleable assets (tangible and intangible items an investor might guarantee against in case of failure) are extremely limited: A handful of computers that will be obsolete in a year, any devkits that have been purchased, and lots of great ideas. (Don’t be fooled: There are countless great ideas out there-and having one or even 100 in the company’s portfolio doesn’t mean it has any value!)

Investors

Intellectual property only becomes valuable after it’s been developed-so unless a prototype has already been created, a company must have something more to offer that’s worth the investment. Every so often, this company or that company is reported to have secured $10 million or upwards of $30 million in venture capital financing. Most of the time, these companies are already established-with products and processes in place, a management team with years of successful shipped games at well-known companies, or some sort of track record that gives investors confidence.

An angel investor is the first choice for companies that are just starting out; “angels” are usually individuals who invest $50,000, $100,000 or even $500,000 (usually under $1 million) in a small company for a big fat return in a few years. The best way to meet an angel investor is through an introduction-preferably by someone that has already done business with them. There are also investment summits and conferences that provide opportunities to network with small investors. Angels actively looking for investments are often willing to talk directly with visionary entrepreneurs who are willing to shake things up.

Out-of-Pocket

The majority of small, formal studios get started with out-of-pocket funding. Perhaps either you’ve saved up the funding to begin production on a game, you’ve been a part of a previous startup that was bought out, or you have a wealthy uncle who passed away and left you his prize collection of Victorian-era spittoons; for one reason or another, the cash is in hand to get the process started. This might look at first like total freedom-but your investment could run dry very quickly. It’s important to consider the time it will take to secure contracts to continue doing business. Staff lightly at the outset; mobile games in particular take far fewer people to build, so start out with a single programmer and move up from there as the contracts get lined up.

Bootstrapping

Bootstrapping is most common in single developer situations; it’s difficult to get four or five passionate people together who are financially secure enough to work on an unfunded project. However, if investors and out-of-pocket funding are not options, consider bootstrapping one or two very small projects as a single developer until enough cash can be saved to grow the company through self-funding. At that point, other financing options might be on the table-if they’re still needed!

After assembling a team and growing a game development studio, it will be time to make a decision. Will you sustain a “lifestyle” business (one intended to support the founders/employees for as long as possible)-or will you make a play for bigger money by selling to a larger firm? In mobile development, both of these are equally viable options-but if you have pulled in an outside investor, then the bigger play is where you want to be looking.

The Fast & the Flexible

When it comes to production, mobile games move faster and require a lot more flexibility during the development process than more traditional console or PC games. The same key roles and elements are there, but they’re handled in significantly different ways. Especially important is the overall flexibility of the mobile production process. Due to the way mobile games continue to evolve based on player feedback and metrics gathering processes, a single game may go through the production process multiple times over the course of its life. （Source：gamecareerguide）