There is a complexity wall you hit during development. Even if you are on a small team, there is a point early in development where the complexity of the game makes it too cumbersome to add new systems. Either there are too many systems already there, or too much content built on those systems. What this means is that the initial period of development is a golden time. It’s the one time during the making of a game when it’s easy to change something.
It’s hard to understate how important this idea is toward making good games. Game design is more about process than theory, much like John Carmack would say it’s more about execution than the initial idea, and much like how Steve Jobs said product design was more about process than the initial idea.
Getting the right pieces in place before you pass beyond the complexity wall is what makes the difference between a good game and a bad one.
You have a choice on what to spend that early time on. You can spend it on making a new graphics engine. You can spend it on prototyping a fresh and exciting new core loop. Or, you can spend it on animation systems and cameras for narrative storytelling. Fairly quickly, you will pass the complexity wall and that thing you chose to work on at the beginning will be the de facto defining element of your game.
The foundation of the Cerny method was that, for action adventure games, you should spend that golden development time on the 3 C’s (camera, control, character). Mark formalized preproduction as a way for teams to stay outside the complexity wall until they had a good foundation based on those three elements. If you didn’t have a great “First Playable,” or “Vertical Slice,” you did not get greenlit and move on to production. Staying out of production meant staying on the cheap and flexible side of the complexity wall.
There are many studios who are repeatedly successful because they are good at focusing down on one thing early in development, one thing that is good to work on outside the complexity wall for their kind of game, like Bungie with its sandbox. I like to belive Bethesda Game Studios has this quality.
If you choose to focus poorly, you can end up stuck with a bad foundation, and then there’s no amount of time, money, or talent that can turn that project around incrementally. The inertial resistance to change beyond the complexity wall is too great. At the beginning of development your game is a small, nimble go-kart. Beyond the complexity wall, it’s a thousand ton train and you ain’t turning that thing around, even if you know it’s headed to shitville.
I’ve been on a few trains to shitville (not where I currently work), and it’s a terrifying, helpless situation.
If you scale up a team too soon, as is fairly common for teams up against a looming release date, you’ve taken a voluntary pass on the golden period outside the complexity wall.
Now, there is one way to tear down the complexity wall, and it’s relatively common thing to hear about from the best games ever made. Throw out the bathwater and start over.
Yep, just toss it out. Reboot. Halo started out as a Mac RTS and ended up as a console FPS. Large portions of the original game were thrown out and started from scratch. Half Life was famously thrown out and started over, as was Half Life 2.
The sunk costs fallacy (and budget politics in big companies) might lead you to believe that throwing out the current version of the game is an expensive idea. It is surely daunting, but it’s the only way to regain that ability to change your game significantly. If the current game sucks, it’s often cheaper to throw it out and start over with a smaller team with a smaller burn rate.
Luckily, throwing out the whole game and starting over is not necessary if you choose the right things to focus on early in development. Most great games don’t need to get made twice before they are released once. Usually, there’s a proven previous game that gets sequeled or made greater (Mario 64, Battlefield 1942, Uncharted 2). Or, there’s a great initial prototype or mod to build on (most indie games, most Valve games).
The complexity wall is important to recognize because it’s the most common downfall of producer-driven development. The fallacy of the producer-as-creative-director is the idea that he can steer the big ship, make directorial decisions mid-development that direct the team back on course towards success. Producer-driven development is the hallmark of big publisher owned teams, and it’s why you don’t often see innovation there.
People think creativity is inherently lacking at the big companies. That’s not the case. Creative risks get taken all the time on big teams. The problem is when the creative idea gets adopted on a big team, it needs to be shepherded by a producer. Guess where that producer lives? Behind the complexity wall. No matter the level of selflessness or skill that producer has, she will have a epic challenge opening a hole in that complex game to fit in the creative idea.
The complexity wall is why we can’t have teams assemble on the fly like hollywood movies. It’s why a stable tech foundation works to a team’s advantage. It’s why you have to have your core loop understood before anything else, and it’s why you need to understand the tone of your game before you grow your team.
The complexity wall is why game design is more process than theory.