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.