Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
From Two Years to Two Months: Transforming a Studio
View All     RSS
January 25, 2020
arrowPress Releases
January 25, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


From Two Years to Two Months: Transforming a Studio

April 15, 2010 Article Start Previous Page 3 of 4 Next

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:

  • 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.

Article Start Previous Page 3 of 4 Next

Related Jobs

Health Scholars
Health Scholars — Westminster, Colorado, United States

3D Artist
Health Scholars
Health Scholars — Westminster, Colorado, United States

3D Animator
Schell Games
Schell Games — Pittsburgh, Pennsylvania, United States

Community Marketing Specialist
Disbelief — Chicago, Illinois, United States

Junior Programmer, Chicago

Loading Comments

loader image