Search

Saturday, September 01, 2007

A Case for Small Teams and Longer Development Cycles

Great Games are Hard to Make

We were having a discussion the other day about how it seems that most great games which come out go through some form of crisis or independence from deadlines. One development story was about MechWarrior 2. The team had struggled to find the gameplay to allow funding to continue, but at one point the game was canceled by an executive on a Friday. The team struggled to finish a pass at gameplay over the weekend and fortunately succeeded in overturning the decision Monday morning.

It seems that every breakthrough game had a similar chaotic history or had a commitment by the developers to “release it when it’s ‘done’” (which was longer than the publisher or public liked).

No publisher in the world is going to sign up for a “release it when it’s ‘done’” development deal with anyone besides an Id Software or some other similar developer who can share the risk and who has a proven track record. It’s reasonable considering the risk, but what potential great titles like MW2 didn’t make it?

The Publisher Business Model Rules All

Publishers are like any other large business. They have shareholders that expect returns on their investment and a board of directors that directly answer to those shareholders. The board demands a business plan from their executives that show perhaps a five year plan with lots of promise of profit. To create this plan, the executives develop a portfolio of game products with an estimated profit/loss (P&L) statement for each. Obviously each future game in the portfolio has a positive P&L or it wouldn’t in the portfolio. Unfortunately a large portion of games released do not make a profit. We are still a hit driven industry, but hits can be a bit difficult to predict. Hit franchises give you the best chance (Madden, WoW, etc), but many franchises fade over time.

The portfolio should show a good mix of proven franchise titles and riskier titles that are potential new franchises (new licenses or new intellectual properties (IP)). The problem is that riskier titles won’t get a big financial bet. In order to get a positive P&L you have to compare the predicted sales with the cost of development (and marketing, etc). No one in their right mind would predict huge sales for a brand new license or IP. So to keep the P&L positive, the dev cost has to be low.

Developing the Riskier New Franchises

So there are a number of new riskier titles in every publisher’s portfolio. Unfortunately they can often be cast in the same date driven mold as the proven franchise development projects. They needed to be treated differently.

Risky new titles should be developed with the P&L in mind, not the portfolio. The portfolio is a wish list used to predict the market and the marketing flow. It’s a poor tool to apply to new titles. Like Design Documents, if anyone takes the time to look back a few years at original portfolio plans; they bears little resemblance to what really happened.

To maximize the units sold and minimize the cost of development, development of these titles needs to pursue an effort that maximizes efficiency, is quality focused and minimize risk to the publisher.

Maximizing Efficiency

Research has shown that there is a “sweet spot” in the number of people working on a task; fewer or more people than this sweet spot and the cost of development rises. This is the basis of the Mythical Man Month and Scrum practices of what team sizes should be. Brooke’s Law is especially true of the game development industry where adding more people to a game development project in pre-production not only has little effect on the ship date but can actually slow down the team with communication overhead and loss of focus.

There are many ways to minimize production time (outsourcing, reuse, etc) by improving efficiency and partitioning, but pre-production is a highly creative and iterative process that can slowed down by applying the same “fixes”.

Better games can be made by having small creative (inexpensive) teams iterating over the possible gameplay mechanics.

Maximizing Quality

The first factor in quality is the team. Talent and teamwork is the key to success. How do you know whether the team can deliver? Iterate. Have the team demonstrate their progress every few weeks. Participate in the direction that the game is taking. Marketing should spend time in reviews and planning as well.

Reducing Risk

This approach fits well with the kill gates approach to seeding many ideas and allowing only the best to fully grow. This sounds harsh to some, but it’s better to kill a bad game early than to spend years working on it to see it fail in the market. Also, impeding cancellation of your project can have a great motivation for the team to prove the games value, as with MechWarrior 2.

Incentive to Take Risks

Based on the current business model, it's difficult for the developer and the publisher to adopt a pre-production model that allows for quick cancellation if the game is going nowhere. Developers want predictable, long-term cash flow. Publishers want to keep the portfolio flow going and want a sense of security from a big plan.

However examples for this models exist (see below). The important thing is to preserve the relationship and pursue ideas with a talented team.

Where does Schedule fit in?

At some point in time, it should be apparent what the core game is and what it is going to take to finish it. At this point the production side of the project can ramp up and a low-risk gold date can be predicted.

Production can’t be ramped up overnight. So every release should have an evaluation of the project in terms of the conditions for production that remain to be met. The team should be able to give a release or two advance notice (~ 3-6 months) of when production can begin. Longer notice can be given with less certainty.

Where games took 2 years to develop, they now might take longer. Teams may save some of the time by entering production with truly shippable mechanics rather than wasting time reworking assets in light of changing mechanics. It should be a lot less expensive and produce better results.

The main risk of this approach is rushing the production trigger. It’s hard enough not to fix a launch date two years in advance. Asking for a year or less commitment to the launch date may be impossible for marketing up front, but it’s what is often done in light of project delays.

Not a New Idea

None of this is new. This approach dovetails with agile very well though. As more developers adopt agile practices it will make more sense to develop games with this approach.

As a member of the Nintendo Ultra-64 Dream Team, Angel Studios was exposed to this model in the mid-90s. Nintendo would discuss a game idea with us and ask us to "find the fun". They'd give us enough money to operate for three months and then come back at the end of that time to see what we found (occasionally Miyamoto would visit!). Usually we discussed the results and the high level direction for the next three months. Occasionally, if we couldn't "find the fun", the game would be canceled and an entirely new game would be started. If the game lived long enough Nintendo would tell us to finish it in six months! Unfortunately we weren't very iterative in our development approach at Angel, so it wasn't an ideal fit.


2 comments:

Hayden said...

This is a good read having worked in small teams myself and had set deadlines I totally understand what it can be like. Your blog seems to full of useful information to So ill keep checking back when I can.

Clinton Keith said...

Thanks Hayden!