The Problem

If I owned a game development studio right now, I might not be able to sleep at night.

I’d lay awake thinking about how much money it cost to run my studio per day. My typical project has over 60 people working on it at any one time. That’s about $50,000 per day per project. That’s a lot of money. If that project takes two years it will cost well over $10 million dollars. Add the publishers cost of marketing and distributing the game and that project would have to sell over a million units to break even. How many games sell over a million units?! Not many.

Game development has never been the model of efficiency. It requires a lot of very talented people with creative ideas working closely together and staying continually focused. Under these conditions it’s certainly not the place to set up a factory where you hope to roll out hit after hit. A great game emerges like magic, and creating a great game is not a predictable process.

Since the beginning of the video game industry, we’ve been driven by hits. We waste a lot of money making bad games and make it all back (& lots more) when we manage to make a hit game.

These days the stakes are different for each game. The “hit or miss” model no longer works because the numbers don’t work the same. A decade ago, the million dollar budget was rare, because the teams were small and technology was far more limited. Take a look at Figure 1. It shows that although the video game market has grown steadily the past decade, the cost of developing games has skyrocketed at a far higher rate. Ten years ago, a single hit could finance ten failures. We are rapidly approaching the day when each game must make a profit. We may already be there.

But let’s go back to that $50,000 dollars a day. That’s what is keeping me awake. Did we add $50,000 worth of game today? Will we tomorrow? Today wasn’t such a great day. The build has been very unreliable for a week now…ever since we got that latest version of the engine. We’re bleeding money.

The last ten years has seen a number of improvements in how we make games. The tools for making games such as Maya and Visual Studios are an order of magnitude better than previous versions that ran under Windows 95. However, with all the progress it still seems as though we’re losing ground. This has to do with the ever-increasing demands of the hardware and the consumer market. While 5000 polygon scenes and 2 megs of texture memory were the norm in the mid nineties, we’re two orders of magnitude beyond that today. Today’s market demands a high level of detail in games.

These details have driven up the effort of making games. Today, teams of over 100 are common where a decade ago, a team of 20 was large. It’s clear that the cost of so many people on a project is much larger, but unfortunately we have come to learn what other industries have already known: Teams don’t scale in effectiveness as they scale in size. A team of 100 people aren’t five times as effective as a team of 20.

Why is that? Part of the answer is that it’s human nature. We’ve spent hundreds of thousands of years organized in small families of about 10 people and larger tribes of about 30-50. Our brains are wired for working differently for each group size. You can see this reflected in one of the oldest human organizations, the military, which has learned the lessons of how people work best in various sized groups. The military organizes at different size groups based on how well people work within those groups. For example, the “Squad” consists of about 8-16 soldiers that can communicate at the highest levels of efficiency. The next higher group size is the “Platoon” which consists of about 30 soldiers. You can still know all the other people in a Platoon and be able to communicate directly with them, but not as effectively as on a Squad. Above this is the “Company” of about 200. At the Company level we find that we need more of a hierarchical organization to start handling the communication that needs to happen between various members of the Company. Each higher level comes with a reduction of communication efficiency because of the overhead involved.

The other part of the answer is the complexity of communication that needs to occur between people on the same team. Team communication complexity is referred to as an “N-Squared Problem”. This means that the complexity of communication goes up exponentially as the team size increases. For example, a team of 20 people has a communication complexity (190 lines of communication) which is four times greater than a team of 10 (45 lines of communication). This is illustrated in Figure 2.

The other part of the problem with creating large projects that require large teams is the attempt to create huge plans that are meant to manage the risks of the project. We create huge plans to try to predict how we will address the complexity of large projects. Unfortunately these plans give us a false sense of security when we rely on them too much.

When General Dwight Eisenhower was asked about the plan for D-Day, he was reported to say that “The Plan is useless, but planning is essential”. Eisenhower knew that over one hundred thousand soldiers, thousands of missions and hundreds of individual battles were never going to follow any plan exactly, even from the start. However the knowledge gained from the extensive planning exercises leading up to the invasion were absolutely necessary to allow the plan to evolve as the reality of the war emerged.

While game development has not yet reached the scale of the Normandy invasion (it’s projected that it will by the time the Playstation 6 is out), our plans for developing current generation games has reached the same level of fragility. Plans go wrong from the start, but being prepared with knowledge is absolutely essential.

One particular problem we have with game development is the fuzzy definition of our major project aim: to create “fun”. I’ve never seen a 300 page plan for a game that clearly communicated to me how the game was going to be fun.

The problem we see with big plans for games is that we inadequately handle the problems associated with reality departing from the plan. Large plans take a large investment in time, but we never properly invest the time needed to maintain those plans as the game emerges. When reality significantly diverges from the upfront plan we are essentially flying blind. We need to find a way to spend less time on the plan and more time on planning.

A Solution