Blue Fang Game谈传统游戏公司业务转型经历
游戏邦注：本文作者是独立游戏开发商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、掌机游戏玩家纷纷转移阵地，开始玩起了在线游戏、网页游戏。
在加入BFG团队之前，我是Tabula Digita工作室的产品管理总监，负责教育题材的PC和在线休闲游戏业务；在此之前还是Mind Control Software工作室的主管，负责监管所有的游戏开发和工作室运营事务。
BFG所有的团队共用一个QA经理里克·贝克（Rick Baker），他很擅长摆平掌机游戏、手机游戏和在线游戏这些不同项目的需求，但他的一些想法跟我们还是颇有差异。我们曾经在BFG首款社交游戏《动物园王国》（Zoo Kingdom）的上线时间有过不同的意见。
我们团队的设计总监是亚当·莱维斯克（Adam Levesque），美术总监是罗·卡坦扎罗（Lou Catanzaro），这些精英人物的加盟使团队得以快速做出决策，同时又能灵活适应变化。亚当可以迅速对游戏细节作出设计说明，而罗创建视觉艺术的功底相当深厚，这种组合让团队得以高效达成目标，就算是失败也能够迅速调整方向重新开始。
我们的第一款Facebook游戏《动物园王国》原先被视为与《Dofus》、《Club Penguin》差不多的MMO网页游戏（游戏邦注：它还被称为《Zoo Online》），并没有多少人当它是Facebook游戏。在项目启动前，我们制定了开发计划，着手准备融资，又招聘了一些在线游戏和网页游戏开发者。
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）