Complicated vs. Complex: Why Game Development is Hard

Developing a game is difficult, to put it mildly. And it never quite comes out the way you plan. Despite this, many developers and (especially) project managers — smart, talented, ferociously hard-working people — continue to believe that somehow this time they’ll make the right schedule and be able to predict months in advance when their game will launch.

This never works (okay, unless you’re just copying someone else’s game). And yet, project leaders continue to create Gantt charts of doom, or to try out one production methodology or another in hopes of making game development predictable. As one pervasive example, Agile/Scrum has long been touted as the way to successfully develop a game. Unfortunately, as some have long suspected and recent data has shown, using Agile isn’t a predictor of game development success (but see below). In fact it scores about as well as using a traditional (and long-reviled) Waterfall process!

Okay, so making a game is hard. Really hard. We all know that. But why? And what can we do about it?

Complicated vs. Complex
What is it that makes game development so difficult? It comes down to the difference between a problem being complicated vs. complex. (This distinction comes out of systems thinking, an area highly relevant to game development, and yet often all but ignored by practitioners.)

A complicated problem is one with many parts and many steps — lots of things can go wrong. But, the way the steps are used, the process, is itself predictable and repeatable. And, most important, there aren’t that many interactions between parts or phases of the process.

You can think of this like an assembly-line process: there’s a lot to putting together a car on an assembly line, but it’s not going to vary a whole lot from car to car of the same type. Sending a rocket to the moon is even more complicated: there’s a lot going on and no one would say it’s easy, but the different phases of the process don’t have disproportionate effects on each other. Once you get through launch and boost, they’re not going to have unpredictable effects on later phases like lunar orbital insertion. And, after you’ve sent a rocket to the moon once, there’s little variance in doing so a second time (at least until parts do interact and things go wrong, which is when the process veers into complex territory).

The key concept here is that in a complicated process there are relatively few interactions — and few if any feedback loops — between parts of the process. When something unexpected happens, it’s often possible to trace the problem from the effect back to a single cause and fix or replace the specific part that caused it.

A complex process also has many parts and steps. But in the complex case, these parts are highly inter-related: what happens in one phase has effects — often disproportionate, non-linear effects — on other parts or phases of the process. These interactions often create unforeseeable effects that change the entire process itself. As a result, serialized causal analysis of such problems won’t lead to a point-solution, though it may bring a false sense of security in having found a  cause but not the more systemic causes.

To put that another way, complex problems aren’t amenable to a strict step-by-step process unless great care is taken to separate the steps along their “natural” borders (where systemic interactions are minimized) and account for the relationships and feedback loops between them. In complex problems there are points where a careful effort to channel the output of one phase can prevent a much wider variance in behavior or result in a later phase, but this is rarely captured in a serial (e.g., Gantt charted) analysis of the process. In contrast to the difficult but “merely” complicated process of sending a rocket to the moon, creating and administering national financial policy is an incredibly complex process: immediate or “first order” effects may soon become swamped by deeper second (or more) order effects as internal interactions reinforce each other. In many ways effects arising out of complex systems are like rogue waves: all but impossible to predict and potentially devastating in their power.

Game development as a complex process
Any process where there are lots of interactions between different parts along the way, and where every decision and deliverable can have a significant and often unpredictable effects on later ones, is a complex process.

In the world of product development, there maybe none that are more complex (not just complicated) than game development.

The early construction of a game design has huge effects on its development later on — but the design itself can’t be fully understood until it’s played. And it can’t be played until it is to some degree developed. There are all sorts of feedback loops like this in the development of a game that must be managed, not ignored. And yet, game developers continue to plan out development along the lines of, “well, we’ll have one month for concepting and then another month for pre-production, and then we’ll go into production.” This sort of linearity completely ignores the fact that when you start out, you have no precise idea of what you’re building, and thus how long it will take. You may have an idea, a vision, for the game, but that conceptual thinking only becomes precise when it’s been implemented. Until then any degree of certainty your feel is from fooling yourself.

This inherent complexity and uncertainty are things the business side of creating games desperately wants to avoid — uncertainty and complexity are also inherently and unpredictably expensive, and therefore risky. Spending time in early concept work often looks like “wasting time” or “fooling around” to a more linear-process driven manager who really just wants the assurance of the development team getting on with it already.  The false certainty of cutting short concepting or pre-production and lurching into production has ended up killing many game projects that ran out of budget before they “found the fun” in the game they wanted to make.

So what can be done?
Apart from recognizing that game development will always be somewhat complex (that is, having non-linear effects emerging from difficult-to-predict feedback loops), developers can carefully remove or constrain some of the relationships between different aspects of development that create this complexity. How this is done isn’t a revelation, except that far too few teams embrace and work with, rather than against, the complexity.

Here are a few  key principles (not an exhaustive list!) that will help work with the complexity of a game development project:

• Fast early iteration is vital. Iteration on the game design must happen fast and early, with a small (and thus cheap) team. “Iteration” here means coming up with an idea, or modifying an existing one, and trying it out in prototype form. No game design idea can be tried out unless it’s implemented, however roughly. This may be a paper prototype, a fast 2D prototype, a prototype using other existing assets, or something else — just so long as the team doesn’t get stuck in “hey let’s make an engine” or “this has to look spiffy for management” or similar holes. Those will kill the fast improvement cycle of the early design quickly and doom the team to having to deal with unknowable consequences later on.
  A couple of temptations to avoid in early iteration: “let’s write a huge design document” and “let’s build an engine.” Both feel like lifeboats for those at sea in complexity, but both also distract from the actual task of figuring out what you really need to design and build. Writing a design-bible or creating a “this will let us to anything later on much faster” engine are two surefire ways to be overcome by unexpected complexity later on.
  Also, while iteration is necessary (I’ve worked with some game companies where it was explicitly avoided!), endless iteration isn’t good. How to know how to modify the early iteration process, or even when to cut it off, is as much a part of the art of game design as anything else. If the process is converging on what looks like a solid set of ideas, that’s great; but don’t let a single point measurement (i.e. a single creative review meeting) determine whether the ideas are worth pursuing or not. Every original idea goes through an ugly duckling phase — or more than one. Protect these ideas when they’re in this state, at least until whether you know the idea is worth carrying forward or not.
• Get to a clear, coherent, consistent, communicated design: Once you have your design worked out for the game, make sure it’s consistent and can hold up to what the product needs to be. This also means making sure that everyone concerned — the development team and management in particular — are solidly supportive of the design. Creating a culture of buy-in will help sustain the team through the long development process, and will help the team stay away from changing the direction of the game or its features mid-stream. Big changes during development raise the complexity of the process significantly, increase costs, and reduce the probability of actually creating a successful game.
• Keep iterating during development: Iteration continues to be key to converging on a valid, engaging, fun game design. Earlier I pointed out that Agile isn’t a magic bullet for successful game development. However, this methodology does embrace the need for rapid, adaptive, responsive development cycles that continually move toward a set of product goals.
• Regular evaluation and review are critical: The famous OODA or Boyd Loop has as its four steps: Observe, Orient, Decide,  Act. That first step, Observe, is how you evaluate the results of your prior actions. In Agile, this is typically done at the end of one Sprint and before the next one. Too many teams, however, move right from one to the next with little time spent analyzing their efforts and to what degree these remain consistent with the (potentially shifting) product goals. Taking the time to review progress at the end of a Sprint and plan effectively for the next will help you recognize and mitigate the complexities inevitable in the development.  This includes reviewing whether the design works (is fun and engaging) along with other potential changes to product goals. Resist the temptation to start the next iteration or Sprint by just taking the next few things off the backlog without first really understanding where you are in the complex process.

Those are my top points for understanding and not getting swept away by development process complexity. In a lot of ways, even just understanding that the process is complex (and not just complicated) is a big help. These points are also consistent with those found by the Game Outcomes Project.

So what do you do? What ways have you found to recognize, reduce, and mitigate the complexity of game development?

Explore posts in the same categories: games, industry

Tags: development, games, industry

Both comments and pings are currently closed.