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.

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:

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.

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:

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.

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:

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.

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!