游戏邦注：本文作者是独立游戏开发商Blue Fang Games（简称BFG）工作室的负责人Eduardo Baraf，他在文中分享了带领传统游戏开发团队转向手机、社交游戏领域过程中的一些心得和体会。

关于Blue Fang Games及本人介绍

在进入正题之前，我得先给各位补充一些背景介绍：Blue Fang Games工作室的发展得益于PC游戏项目《动物园大亨》（Zoo Tycoon）。作为一家游戏工作室，我们致力于开发适用于所有玩家游戏，但在家庭游戏、女性游戏和非硬核游戏领域的表现最为突出。

在2007年之前，Blue Fang主要面向PC平台开发游戏，并于2009年向Wii平台推出了《动物园世界》（World of Zoo）。在2008年底，BFG开始发现传统游戏开发/发行业务已经面临窘境，大量的PC、掌机游戏玩家纷纷转移阵地，开始玩起了在线游戏、网页游戏。

因为《动物园世界》的发展空间受限，公司管理层指派我负责创建传统的Wii游戏原型，并挖掘在线游戏的发展潜力。当时我已经具备11年的游戏开发经验，涉及领域包括传统游戏、在线游戏，开发周期在2周至2年不等的游戏。

在加入BFG团队之前，我是Tabula Digita工作室的产品管理总监，负责教育题材的PC和在线休闲游戏业务；在此之前还是Mind Control Software工作室的主管，负责监管所有的游戏开发和工作室运营事务。

成立“国中国”小团队

我加入BFG是因为这个工作室支持我从中组建一个“国中国”的团队，快速开发和移植好玩的游戏原型，而且我还可以从BFG团队中挑选或对外招聘自己所需的成员，脱离BFG掌机游戏开发团队，实现高度独立的自主管理。

尽管我们这个新团队与原掌机团队同在一个屋檐下，但每个团队都有不同的文化理念、个性和工作流程，甚至工作时间也有差异。这种高度自治的管理方式，是我们团队得以立足的根本，也是BFG向在线游戏、手机游戏和社交游戏进军迈出的重要一步。

要实现这种团队分治却并不轻松，在BFG传统游戏团队已经面临巨大压力的情况下，又分割出一些零头资源来开拓新项目，难免会造成两个团队之间的磨擦。我的团队资源经常会被另一个团队挪用，还有不少人并不认同BFG的这种分治策略。

不得不承认，在这种情况下，新团队经常得顶着巨大的压力，证明自己正在不断进步，才有可能为自己的出身正名。在公司高层的支持下，我们在开发小型项目上不断取得进展，全力守住了我们的自治权。

这个团队的决策权在我，没有合作发行商，所以向股东证明团队的价值，就成了我每天的头等大事。我不得不克服重重困难，定期拿出一些上得了台面的成就，证明我们团队的确在进步。

并非所有的工作室都能如此大度，创造这么宽松的发展环境。但我还是要说，传统游戏团队与短期项目团队的文化异差确实不小。前者的项目开发周期都比较长，他们得创建长期的技术解决方案，反复优化产品，确认万无一失后才最终推向市场，整个流程有始有终，非常完整。

但开发这种传统游戏（尤其是掌机游戏），意味着产品进入市场后就划上了句号，所以开发团队之前就得准备一套合理的漏洞解决方案。如果是开发短期游戏项目，早期的开发过程与前者并没多大差别，但游戏正式生成之后，后期工作流程就有实质性的变化了。

开发者必须不断优化、修复漏洞、添加新功能，他们得及早做出决定并付诸行动，根据用户数据制定不同的产品开发计划，更重要的是计划不能过于脱离现实，同时还要推出一个合理的项目拓展或移植方案。

另外，掌机游戏开发过程进展比较缓慢，但发行却相对神速；短期游戏项目开发却具有长期的连贯性，所以必须制定一个合理的日程安排，高度重视产品质量，避免造成不必要的麻烦。

BFG所有的团队共用一个QA经理里克·贝克（Rick Baker），他很擅长摆平掌机游戏、手机游戏和在线游戏这些不同项目的需求，但他的一些想法跟我们还是颇有差异。我们曾经在BFG首款社交游戏《动物园王国》（Zoo Kingdom）的上线时间有过不同的意见。

当时我为这款游戏添加了一些新功能，也改变了一些视觉元素，但贝克却表示他们无法在今天测试游戏，明天就让它上线。但我却坚持认为，如果要赚钱确实不能这么仓促地测试，但还是得抓住时机，在明天把它推向市场，因为我们后面会经常对游戏进行修复和升级。但最终还是我妥协了，决定走保守路线，等游戏进一步测试后再作决定。

果断决策，高效执行

要在有限的时间内推出高质量的游戏，关键是要明确项目发展目标，并将其传达给团队成员，然后集中作出决策。许多人混淆了项目目标和项目延伸这两个概念，项目目标是指具体的发展目标，也就是射箭时瞄准的靶心，项目延伸则是指发展范围，它是你追赶目标过程中的一种灵活的变更策略。

需要指出的是，我们是小团队作战，所以成员之间的沟通和交流极为关键。团队所有成员不但要清楚地理解自己的任务是什么，而且还得了解他人处理的事情。另外我还认为，将决策权集中到同一人手中，是提高工作效率的重要因素，这个原则可能适用于长期游戏项目，但对我们这种短期项目来说，它是个必须选项，这样才能保证果断决策，立即行动。

我们团队的设计总监是亚当·莱维斯克（Adam Levesque），美术总监是罗·卡坦扎罗（Lou Catanzaro），这些精英人物的加盟使团队得以快速做出决策，同时又能灵活适应变化。亚当可以迅速对游戏细节作出设计说明，而罗创建视觉艺术的功底相当深厚，这种组合让团队得以高效达成目标，就算是失败也能够迅速调整方向重新开始。

重视用户反馈数据

在线游戏、手机游戏、社交游戏与掌机项目最根本的差别在于产品的发布特点。短期游戏项目要求开发者在产品发布之初，创建好最基本的游戏元素，然后再根据用户反馈和分析数据（游戏邦注：这里不是指玩家所表达的意见，而是他们在游戏中的实际活动）不断调整，提高玩家的游戏体验。

在传统的掌机游戏开发过程中，所有操作的终极目标都是“向钱进”，这就决定了产品开发之初就不能有任何纰漏。但短期游戏项目的要求则与此不同，最强大最有价值的是用户数据，必须善于搜集和分析这些信息。

举例说，在Facebook平台上，许多游戏初次访问的用户流失率都很高，《动物园王国》也遇到了这种情况，但我们想通过深入挖掘找出其中的原因。查看用户数据时，我们发现许多用户进入第二关时就走人了，可在我们看来，这个关卡是专为初级玩家设置的，并没有什么难度。于是我们打算从用户数据中分析出一些原因，重新调整游戏设置，然后再观察用户数据。经过一番周折，我们终于看到大量玩家顺利闯过这一关，但我们仍然得不断完善游戏，才能吸引回头客重新光顾。

这就是短期游戏项目的开发哲学，它是一种让开发者放低身段，密切关注用户反应，并快速开发和完善游戏的过程。

《动物园王国》的开发持续了10周（游戏邦注：这一点在下文中会详细阐述），上文所提到的这种开发哲学其实是多种游戏开发经历的一个合体，这种针对社交领域的开发特点，改变了更多“传统”开发者对游戏的定义和看法。

用户数据并不仅仅是玩家的操作方式、购买的道具种类，而是包括更广泛的内容，比如他们的身份特点，进入游戏的途径，玩过的其他游戏类型等等。所以必须针对不同用户群体，创建一个玩家档案，这样才能提高新增用户、留存率、病毒式传播效果、营收等游戏指标。如果还不知道何为用户档案的话，可以再仔细分析用户数据，对它们进行归类和比较，筛选出所需的数据并以此存档。

首先要查看用户调查数据的共同趋势，看看他们是不是都卡在第二关，为什么是在第二关，还是说只有一部分玩家遇到这种情况，他们的身份何特点。必须全天候追踪Facebook用户的游戏活动，反复观察和分析用户数据，最好要找一个专门负责人盯紧这项工作。

这种繁琐的事情可能很让传统游戏开发者抓狂，因为他们多数人都已经习惯在闭门造车的环境中开发游戏，从其他产品和个人经验的角度出发做出决策。但我们的《狂狮雄起》（Lion Pride）和《动物园王国》的玩法设置，却总因用户不得要领，或者他们被卡在某一环节，而删掉了不少好创意和强大的新功能。

如果你掌握了用户数据，就可以开始执行A|B测试，也即针对不同用户群体，测试游戏语言、色彩、功能等设置是否合理，这种测试可以是随机性的，也可以是针对性的。开发团队获得用户数据之后，还得善于根据这些内容对游戏进行完善。

在传统游戏开发过程中，游戏设计基本上由设计者本人的喜好而定，有些团队也会在开发后期推出用户测试，但往往收效甚微。而短期游戏的开发则必须注意以下要点：

·确定自己要调查的参数（游戏邦注：这一点可根据市场目标或原有数据而定）

·将所有相关数据考虑入列，并依此改变一些游戏特点

·设计一项专为改变游戏特点的新功能

·及早预测可能发生的结果。团队成员必须能够自我解释游戏特点或参数，并预测改进后的效果。要注意，这一点要与“X参数大幅提高了”这种空话相区别，我们的预期结果应该是具体的目标，比如说希望看到闯入第2关、第3关的30岁以上美国女性用户数量增长10%。

·对比预期目标与实际结果。添加新功能后，看看实际结果是否更接近预期目标，其他的参数是否发生了变化。

·从中汲取教训并继续改进。

不要制定过于脱离实际的计划

传统游戏开发与短期游戏项目开发的另一个区别体现在发展计划上。在传统掌机游戏领域，开发团队的整个产品研发过程可以排满一两年，而社交游戏开发过程则有两点明显的不同：

1.初期产品计划应该指向最初级的游戏功能，同时又要让游戏拿得出手，获得有效的用户反馈信息。这是快迅实现目标的一种方式，游戏上线后你就会从中发现初级开发过程中的许多问题。

这并不是说你就可以向市场推出一款垃圾游戏，或者说脱离整个系统来制定计划。你首先要了解自己的游戏，并判断出什么内容可以推向市场，反复推敲，并向朋友征求意见，然后再砍掉10%的内容，让整个产品看起来更加精悍。

2.产品正式上线后，要提前预测用户反应结果，制定三周内的应对方案。这个时候你已经可以查看用户数据，并依此做出更准确的判断。

如果不了解这些数据，你怎么可能制定剩下的开发计划？所以开发团队要善于预测并列出三周内的主要功能改进效果，大家必须全力以赴，根据用户反馈数据进行设计改良。

在早期开发阶段，用户反馈与预期效果的反差，很可能让开发团队措手不及，但随着项目的发展，用户反应会越来越接近预期效果，这个时候还得继续关注用户反馈。如果发现用户卡在某一点上时，就得及早推出新功能并解决这个问题。如果你原先认为他们会走X路线，结果却发现他们选择的是Y，那就得立即对游戏做出调整了。

亚当和我曾经就这个问题讨论了一整个下午。他认为有些功能的重新设计要一个月左右，在以前他会立即着手完成这些任务，但他这次却选择了把计划后延。他问，“为什么要现在就要浪费功夫？这些事情到后面又会有变化。”他说的没错。从那时候开始，我们就采用了更宽松的调整计划，筛选出一些主要的功能模块，等到发现更具体的反馈信息时才植入了这些内容。

设置自动化用户数据处理系统

迅速开发一个短期游戏项目时，要提前创建自动化的测试系统，根据之前的用户数据对游戏效果进行测试，这种方式其实就是自我检测。

值得反省的是，当时我们的项目进展得太快了，以至于大家都忘了创建这种数据处理系统。当时我们还缺一名工程师，我提出先让主要的游戏功能上线，但我们的首席技术官Jeff Kesselman认为不妥，所以把时间往后推迟了。后来游戏上线时又经历了好多次循环，我发现短期和长期的积累有助于选择正确的路线（尽管这个过程可能让你减速），总强过不考虑结果地急匆匆上线。

案例1：iPhone版《狂狮雄起》

《狂狮雄起》就是BFG的第一款手机游戏，从游戏开发到应用商店审核总共历时7个星期。这个项目组最初的三名成员是我、美术总监和工程师。这款游戏也属于短期开发项目，我们制定了发展目标和非常紧凑的日程安排。在游戏发行后，我们又在三个月内推出了六个更新版本。

以下是《狂狮雄起》快速投放iPhone的几个关键因素：

·富有经验的开发者、明确的发展目标和时间表；

·一开始就针对iPhone平台特点进行游戏设计和定位；

·工程/设计负责设置主要游戏机制，美工负责抓好游戏视觉效果；

·分工明确，美术、设计和工程各司其职，互不干涉；

·通过开发者和好友不断获取游戏反馈信息。

不幸的是，这款游戏并没有植入一个理想的分析系统，所以游戏的更新完全取决于用户反馈信息，我们通过各个游戏论坛与玩家进行互动和沟通，观察iTunes的用户评论，以此搜集到了不少数据。我们自己有许多内容更新的计划，但50%到75%的内容都是根据用户反馈进行调整。

在这个项目完善过程中，我们基本上是花一天时间制定计划，用几周进行开发，然后再经过几天的QA测试和应用审核，这是我们团队第一次体验这种持续性的游戏开发过程。

在《狂狮雄起》的开发过程中，我主要关注游戏的核心元素以及执行效果。我们的美术设计总监罗每天都会提出许多调整功能的建议，如果全盘采用他的提议，我们的日程表根本就排不完了。多数时候，他提出的功能设想和创意都很好，把它们全部集中到一块，有助于我们通过对比和考虑，在开发后期时再找时间加进去。

这款游戏开发过程中的另一个有意思的现象是，工程师Lajos Kamocsay和我们其他人的上班时间有时差，他一般都是从早上9点忙到凌晨4点。虽然为了便于沟通，我比较喜欢将所有成员召集到一块，但这种有时差的工作成效好像也不赖，它清晰地划分了我们的工作任务，让整个开发流程保持在时间上的连贯性。

案例2：Facebook游戏《动物园王国》

我们的第一款Facebook游戏《动物园王国》原先被视为与《Dofus》、《Club Penguin》差不多的MMO网页游戏（游戏邦注：它还被称为《Zoo Online》），并没有多少人当它是Facebook游戏。在项目启动前，我们制定了开发计划，着手准备融资，又招聘了一些在线游戏和网页游戏开发者。

这样我们的团队规模又扩大了，成了传统游戏、在线游戏、网页游戏等不同开发者混搭的组合。这些群体之间的分歧也非常有意思，经常会有传统游戏开发者想采用系统研究法，而网页游戏同行却说，“那是Flash，我们还是做一些不同的事情吧。”有时候我站在网页游戏开发者一边，有时候却又比较赞同传统游戏开发者的观点。

融资过程很漫长，但时间却很紧迫，我们在2009年11月底就得进军Facebook。

到了11月份，我们不得不召集原来的主要成员开会，为《动物园王国》设定了发展目标和时间表：

·成为Facebook最经典的动物园游戏；

·立足于《动物园大亨》，成为正宗的动物园游戏；

·利用Facebook病毒式营销渠道，具备虚拟商品和营收方案，植入用户分析系统，在1月15日上线。

明确了这些简单的目标后，项目正式开始运行了。

对我们团队和BFG来说，这是一个非凡的决定和时刻。当时我们已经决定放弃传统项目的发展计划，转战Facebook平台；另外，RockYou推出的《动物园世界》（Zoo World）也让我们备感压力，因为这意味着我们的新作刚出炉就遇上了劲敌。我们原先也公开讨论过是否要放弃动物园题材，但纠结到最后，还是觉得我们具有这方面的资本，这个主题才是我们的专长。

另外，Facebook平台总是充斥着大量山寨、克隆游戏，这一点也很让我们为难。Crowdstar当时也跟风推出了《动物园天堂》（Zoo Paradise）。

我们最重要的事情就是抛弃《Zoo Online》的设计，针对Facebook平台特点重新开发游戏。Facebook用户的特点和游戏体验方式从根本上有别于传统的MMO在线游戏玩家。在这款游戏的开发过程中，我们又列出了所有必备的要素：

·确定最基本、可上线的游戏功能

·快速创建高质量的游戏，果断取舍相关内容

·打造一个可由外包团队帮助开发的项目

·创建一个设计数据库，以便快速植入或替换游戏内容

·掌握Facebook API的使用方法

·创建自己的后端服务器框架，建设系统，部署模型

·选择和绑定合适的营收渠道

·选择和绑定正确的分析系统

转眼间1月份就过去了，我们终于在Facebook上发布了这款游戏。起先只有一小撮用户试玩我们的游戏，但因为病毒式传播的影响，这款游戏很快就引来了大量用户，场面甚至有点失控。

在前面一两周时间里，我们一直在马不停蹄地解决游戏运行效果、可运行时间、漏洞、功能优化等问题，同时也在不断搜集数据，查看分析结果。我们掌握了这些信息和用户反馈数据，就立即采用了那些有助于增加黏性、留存率、病毒式传播效果和营收成效的功能。

到此为止，我们的团队彻底实现了业务转型。后来我去参加GDC大会后，又掌握了更多新信息和新动向，提出了50%的项目发展计划。然后我们又开始了制定目标，观察用户数据，创建新功能，推出新游戏这个循环过程。

总结

在线游戏、社交游戏、手机游戏重塑了整游戏开发格局，2009年的游戏行业营收增长几乎都是来自这些领域，传统游戏发行商只能在后头奋力追赶。我认为掌机游戏开发迟早也会走上这条道路，只是个时间早晚的问题而已。如果你想赢得未来，那就成立一个小团队，制定明确的发展目标和时间表，掌握用户数据，开始行动吧！

Creating a Studio Within a Studio

Let me begin with a little background. Blue Fang Games (BFG) is an independent game developer that has funded its own growth through the commercial success of the Zoo Tycoon PC franchise. As a studio, we have always been committed to making games for “everyone else” and have been successful in creating games that appeal to families, women and non-core gamers.

Blue Fang had exclusively developed games for the PC up until 2007 and expanded to the Wii platform with the World of Zoo project which launched in October 2009. World of Zoo was a two year Wii/PC project that was Blue Fang’s first console experience and included a major game redesign in 2008 to make the game Wii-centric after the rapid collapse of the retail PC market.

Automate Game Builds with FinalBuilder

Toward the end of 2008, Blue Fang had become frustrated with the traditional dev/publisher business model, and recognized the need to expand beyond PC and console development as our audience had begun the migration to online and browser-based games.

The immediate demands of the World of Zoo project left no development bandwidth to pursue future opportunities, so I was brought on board to build a traditional Wii game prototype (for post-WoZ development) and pursue “something in the online space”.

I’ve spent the last 11 years at all levels of game development building teams and delivering packaged and live games that range from two week to two year development cycles.

Prior to joining Blue Fang Games, I was director of product management at Tabula Digita, responsible for their PC and Casual Online products in the educational game space. Prior to that I was studio head at Mind Control Software, where I oversaw all of Mind Control’s development efforts and day-to-day studio operations.

Separate for Success

While bringing someone on to drive future project development is not uncommon, the reason I decided to join the studio was BFG’s willingness to allow me to build a new “studio within a studio” to rapidly develop and deploy products and playable prototypes. I was given the ability to segment the group from the existing team, hire initial talent to drive development, and work with complete independence from the larger console development team.

Even though we were all under the same roof, each team had its own culture, identity, processes and even work hours. This independence and autonomy, more than anything, was critical to building the foundation of our group and preparing Blue Fang for the move to an online, mobile, and social world.

This separation was no small feat. Carving out additional resources to pursue new project development while a team is in a heavy push to complete a console project can create significant friction. This generally fluctuated with hefty milestones and crunches. There were regular “demands” for my resources and questions about the validity of BFG’s “split focus.”

I can’t stress this enough — in situations like this the second dev team needs to always be ready to demonstrate progress and overcome the gravitational pressure to be absorbed into mainline development. Along with upper management’s support, our ability to show constant progress through rapid small-scale development, was our greatest strength to help maintain autonomy.

We had centralized decision making (me) and no publisher. We could move quickly and we could impress our stakeholders with tangible results. Demonstrating our relevance and value was a daily priority for me. I staggered milestones and lined up deliverables to create regular, viable events to demonstrate progress.

Not every studio has this luxury or opportunity. Still, it is important to understand how culturally different package/extended-cycle product teams and live/short-cycle product teams are. When working on an extended-cycle project, the team has the opportunity to complete a proper pre-production phase, develop long term technical solutions, and polish to a final point.

The last point is worth extra emphasis. When working on a package product (especially console) everything that goes out is final and the team must enter a proper bug resolution phase. When working on a short-cycle project, the initial development may be similar, but once the project is moving to “live” the chemistry changes.

Developers need to constantly balance polish, bug fixes, and new features. They need to be able to decide and go, they need to respect their user data and take a different approach to product planning — making sure not to over-forecast or plan. Having a proper build and deployment plan becomes increasingly important with live product.

In addition, oftentimes console development is slow progress followed by a sprint, or extended sprint to ship. Short-cycle live development is on-going and constant. It is critical to have a well managed schedule and high development expectations to maintain quality development and avoid countless issues with a live user base.

Our groups used a shared QA manager, Rick Baker, and I must say he did a fantastic job balancing the different demands of console, mobile, and online. However, I distinctly remember a moment in his office where the differences came to a head. We were arguing about a live release we’d be making to Zoo Kingdom, BFG’s first Facebook product, which went live in February 2010.

I had added a few features between Code-Freeze and the Staging push and there had also been an art change which effectively touched every asset in the game. “Ed, man, we can’t properly test this and get it out tomorrow — there is just no way.” “Rick, you are right… we can’t test like this is for Gold Master, but we’re still pushing it out tomorrow. Let’s cover the critical items and we can always hot-fix if we need to.”

We did just that and it was the right call. The pendulum swung the other way on a different release where I was being conservative and wanted to hold up a build for further test, and I had to chuckle as Rick browbeat me into getting it out that evening — he was right.

Decide and Go

The key to delivering a high quality product in a limited amount of time is clearly defining the objectives of the project (this is not scope), dispersing this to the team, and having centralized decision making. Many people confuse project objectives with project scope. This is an important point. The objectives of a project are the concrete goals of development — the target you shoot the arrow at. The scope of a project are the parameters of development, which must be flexible and change to ensure you hit the target.

Furthermore, with small team development, there is no excuse for bad communication. All members should not only have a clear understanding of their tasks, but everyone else’s. Lastly, while I fully endorse lead and team collaboration, a single decision-maker is key to agile development. This philosophy can be applied to long term projects, but is a must for short cycle development. Decide and go.

This is an area where BFG’s long background in game development was so valuable. Working with Adam Levesque (design director) and Lou Catanzaro (art director) allowed us to not only make fast decisions, but bring clear rapid vision to these changes.

Adam’s ability to rapidly spec out all of the corner cases of a design and Lou’s ability to create strong visualization for the work was invaluable. We often hit the mark out the gate and if we didn’t, we failed fast and reoriented quickly.
Respect Your User Data

The key point where live online, mobile, and social development starts to divert from a console project is in the nature of the product launch. Live development requires that you develop the minimal components necessary for launch and then build and grow the experience based on community feedback and analytics (not what you community tells you, but what they are doing).

In traditional console development, everything needs to be perfect and final for Gold Master; a live game has no such requirements. Nothing is more powerful than your user data — it should be harvested and respected.

A quick example of how valuable this information can be: Because of the nature of Facebook, most games have a high loss of players after first use. We were seeing this with Zoo Kingdom, but wanted to dig in deeper to understand what was happening.

On review of our data, we saw players leaving before reaching level 2. Unfortunately, the game was set up for a first time player to hit this mark. We came up with a few theories, implemented them separately, and watched the results in data. With further tweaks, we now see a significantly higher number of users progressing through this level — though we always need to work on getting them to come back the next day.

This is a development philosophy, not necessarily “DNA.” This is NOT web development versus console development. This is low ego, rapid development that starts with intent and continues with following your community and your metrics.

Tracking Zoo Kingdom’s development to 10 weeks (which I detail later) was only possible with our team expertise across all disciplines. The development philosophy described above mixed with extensive development experience is an explosive combination. As more “traditional” developers come to understand this process, the quality and speed at which product is built and deployed in this social medium will redefine gaming as we know it.

User data is not simply how your players are playing the game and what they are buying. It starts with their demographic, how they come to your product, what other products they are playing etc. Creating a player profile for your different segments of users is essential for driving improvements in all major metrics: Acquisition, Retention, Virality, Monetization, etc. Don’t know what your user profiles are? Look at you data! Start sorting and comparing your data to create profiles of your players.

Look for common trends in your statistics. Did they all get stuck at level 2? Why? Are only certain types of players having this problem? What are their demos? Tracking, reviewing, and deciphering your analytics is absolutely a full-time job on Facebook. Someone should be devoted to this just like someone should be devoted to improving and extending your analytics. I can’t stress this enough, put someone in charge of your analytics.

This bit here can always be a struggle for traditional game developers. Most developers are used to developing in a vacuum and making decisions based on other products and personal experience. They’ve honed this skill over years of development. In both Lion Pride and Zoo Kingdom gameplay systems, well thought out and designed features were cut simply because casual users didn’t get it or the data suggested blockage.

Once you have a sense of your users and your data you can start A|B testing. This is trying out different language, images, colors, features to split groups of users. These tests can be blind (random split) or targeted at specific groups.

As soon as you have data, it is also important to drive your team to understand the metrics and how development improves these metrics. This process needs to be driven by a fundamental and actual understanding of your metrics and woven into game development.

In traditional game development, design is driven by what the game developer thinks will be fun and/or engaging. Some teams have user tests late in development, but these are often at a point of little return. In live development, a world of information is a available and should be used — the process looks like this:

* Define the metric you want to drive (based on market objectives or existing data)

* Consider all related data, and look to change a specific characteristic

* Design a feature specifically targeted to change the characteristic

* MAKE A PREDICTION! Your team should be required to explain the metric/characteristic and expected change they want to see. This should NOT be a blanket term like “a big increase in X.” This should be a targeted value. We expect to see user retention of our US, Female, over 30 group increase 10% between level 2 and level 3 based on this change.

* CHECK YOUR PREDICTION! After putting in the feature, check your prediction. See how close you were. See what else changes.

* Learn and improve

Don’t Over-Forecast or Over-Plan

Another different characteristic between extended-cycle and live short-cycle is planning. In traditional console development the production team is tasked with planning out an entire product over a one to two year development schedule. Even with highly iterative development, the expectation is the general game plan for the project is defined. This changes in two ways for social development:

1. The initial production plan should be targeted at the minimum feature set possible to deliver your product to your users and get user feedback and metrics. This is the quickest, smallest chunk of your project that can be delivered to meet your objectives and go live. You will learn 1000% more about your game and your development when it’s live than you knew during those initial stages of development.

Automate Game Builds with FinalBuilder

Now, this is not to say you need to deliver crap or you can’t plan out integrated systems for deployment. You know your game, you just need to evaluate what is necessary to launch, triple guess yourself, ask a friend, and then probably cut down another 10 percent to hit that minimum spec.

2. Once you product is live, trying to forecast and plan for more than three weeks (two weeks even) is wrought with peril. Again, you are now in a mode where you are looking at your data as it comes in and making decisions against your data.

How could you possibly plan the rest of development without knowing your data? That is like crossing a busy intersection with a snapshot of the cars from five minutes earlier (to paraphrase a recent TV ad). The development team should make predictions and outline major feature improvements for a three week period, but set the majority of team to data driven design.

Early on in development, this skews heavily towards reaction as you will likely be dealing with fires and the unexpected. As time progresses it can be a more even split between reaction and planning.. Still, have no ego. If there is a critical choke point with your users push a feature and address it. If players are doing Y when you thought they would being doing X, change your product.

Adam and I were discussing this at length one afternoon. He had some tasks to do detailed designs of features for development for a month or so down the road. Normally, Adam would jump all over these, but he was pushing back.

Essentially he was saying “Why spend the time developing this stuff now? It is just a wasted effort to do it now — everything is going to change.” He was right. Essentially from that point on we adopted a looser system for future designs. We detail out the main components of the feature, but wait until the horizon is closer for the detailed implementation specs.
Have an Automated Build Process WITH User Data

This last point is short, but is worth calling out. When developing rapidly on a live product, it is massively important to have an automated build system and a test deployment setup that allows you to test against old user data. Chase your tail in test, not out in the wild with your users.

Here I have to make a shout out to Jeff Kesselman (our CTO). We were developing so rapidly I actually drove the product without getting our build process set. We were short an engineer and I wanted to get our main gameplay features online. He pushed back hard, but it still took time to free up the resource. It was a lurch to get the system online and it used up a lot of cycles. In this case, I would say the short and long term gains are high enough to get this right from the get go (even if it does “slow” you down.)

Case Study — Lion Pride on iPhone

Blue Fang’s first mobile game was Lion Pride. This game was developed from kickoff meeting to Apple submission in seven weeks. Primary development came from three people: myself, my art director, and an engineer. This project followed the core principles of short cycle development. We set our objectives and had a very tight information loop. After launching the project, we delivered six updates over a three month period (this was back when Apple approvals were a two week affair).

Key factors to deploying Lion Pride quickly:

* Experienced developers with clear objectives and timeline.

* Platform specific design, well defined and vetted at the start of the project.

* Staggered development allowing Engineering / Design to implement and refine core gameplay while Art defined look/feel of the project.

* Distributed development allowing Art, Design, and Engineering to make progress independently.

* Constant game feedback from developers and friends.

Unfortunately, we did not integrate a good analytics system into Lion Pride and as such our live updates were all driven by community feedback. We were active on the forums talking to players and watching our review via iTunes. We always had more content planned, but 50 to 75 percent of our changes were initiated by user feedback.

Turning around regular builds in two week intervals essentially turns into one day of planning, one week of development, a few days of QA and resubmission. This was our team’s first taste of the non-stop live development of a Facebook title.

My focus during Lion Pride development was to drive to our core components and execute them. Beyond making fantastic art, I’d have to say Lou’s focus was daily suggestions of features, changes, and tweaks which together would blow our schedule. I’d get so many, we ended creating a Lou idea board in my office.

Here is the thing, in most cases (Lou would say “all”) the features and ideas being suggested would be awesome additions to the product. Having them all in one place allowed us to consider and contrast them late in development when we actually had time to add them.

Another neat dynamic of Lion Pride development was that our engineer, Lajos Kamocsay, was on a weird time split and essentially developed from 9pm to 4am each night. While I generally prefer the dynamic of being able to bring all developers into the same area for high communication — the off time was effective. It forced us to define our work clearly and allow uninterrupted development flow.

Case Study – Zoo Kingdom on Facebook

Our first Facebook game, Zoo Kingdom, was originally conceived as a browser-based MMO (codenamed Zoo Online) in the vein of Dofus or Club Penguin, not a Facebook game. We defined the experience and development plan, created pitch materials to secure funding, and recruited online and web talent for this initiative.

This was a larger increase in staff which allowed us to assemble an even broader mix of traditional, online, and web developers into the team. The dynamic created between these groups was interesting to watch unfold. There were often meetings were traditional development strived for a systematic approach while our web developers essentially said “It’s Flash, let’s just do as many different things as possible.” Sometimes I sided with web, other times with traditional.

Automate Game Builds with FinalBuilder

The funding process dragged on and as we watched the space, it became clear to us at the end of November 2009 that we needed to be developing on Facebook (frankly we were already behind the ball).

In December, we pulled our primaries together to define our objectives and timeline for Zoo Kingdom:

* Best in class Zoo game on Facebook

* Authentic Zoo and Zoo Tycoon roots

* Heavy leveraging FB virality, virtual goods monetization, integrated analytics, and live by Feburary 15th.

And with those simple objectives, development began.

This was a big decision and moment for our group and Blue Fang Games. We essentially jettisoned our longer term project plan and aimed at the Facebook space. Moreover, the growing success of Rockyou’s Zoo World meant we’d clearly launch our product against a myriad of competition in the space. We openly talked about moving away from the Zoo context for our first Facebook game, but ultimately decided there was too much heritage for us not to.

Also, watching the Facebook space it was easy to expect me-too, copy-cat product. I remember telling Hank Howie (president), “You know Hank, we are going to be up against at least one other Zoo game at launch, but I guarantee it will be just a slightly better rip-off of Zoo World. Zoo Kingdom will easily stand out as different and its own game.” Crowdstar obliged with Zoo Paradise.

First and foremost we had to scrap the original Zoo Online design and focus our efforts on the Facebook platform. A Facebook user’s profile and play pattern is fundamentally different than your typical online MMO gamer. While design worked on this problem, we leveraged industry experience to drive all other factors we knew had to be in place.

* Defining the minimum feature spec to go live.

* Creating quality fast — knowing when to build and when to hack.

* Developing a stylized look and feel for the project that could be outsourced for rapid development.

* Creating a design database for rapid integration and iteration of game content

* Learning how to use and leverage Facebook APIs!

* Building our backend server architecture, build system, and deployment model to scale.

* Choosing and integrating a monetization system.

* Choosing and integrating an analytics system.

In a blink, January came and went and we launched on Facebook. We started with a small group of users playing our game, but rapidly lost control of how many users were in the system (damn you virality!).

For the first week or two of development we were in constant firefighting mode. Addressing performance issues, up time, bugs, and feature improvements. We also began to collect and review our analytics.

As soon as we had a good hold on that information and our user feedback we began the process of reviewing our data and focusing on driving features that moved our major metrics: engagement, retention, virality, and monetization. Our focus now is a major feature per week with the requisite bugs, optimizations based on feedback and data.

At this point, the team is still moving at a blistering pace, but has fully made the transition to short-cycle development. After a week at GDC I came back with new information and direction, I threw out 50 percent of our existing plan and drove towards new metrics and new features. We set our objects, reviewed our data, developed features, and continue to push major releases to our users.
Get Moving and Start a Short Cycle, Live Project!

Online, Social, and Mobile gaming are redefining the game development landscape. All of the Game industry revenue growth for 2009 came from those sectors and traditional game publishers are playing catch up.

Sooner than later, even console development will go the way of social integrated live products — it is just a question of when. If you want to play for the future, carve out a small team, clearly define your objectives and timeline, understand your user data and get it done! （source:gamasutra）