Steambirds: Survival takes place on a grim fall morning at the start of the Battle of London. The British forces are taken by surprise as thousands of Axis steam-planes descend upon the doomed city. Outnumbered and outgunned, your heroic mission is to delay the invaders long enough that a handful of civilians might escape the genocidal gas attacks. You have one plane. How long can you last?

David has a great post about how we integrated microtransactions, but today I wanted to focus on a couple of design lessons that came up while building Steambirds: Survivial.

Find deeper fun by killing levels

Steambirds: Survival started with the observation that the core mechanic of maneuvering planes was fun independent of the level design. When we were building the first game, we'd toss in enemy planes nearly at random and interesting combat scenarios would emerge. My personal design process is highly exploratory: I examine a working prototype, identify whiffs of an opportunity and then attempt to amplify those desirable moments in the next iteration. The lack of levels was one such opportunity.

What if we built a version of Steambirds that relied entirely on randomly generated levels where planes came at you in ever increasing waves? In essence, create the Steambirds version of Gears of War 'Horde mode'. This path harkens back to the escalating arcade mode found in Asteroids, Space Invaders or most traditional arcade games.

At first, we randomly spawned planes and saw how the game played out. Then we polished the systems until the game was fun to play every single time. I observed several higher level attributes of this design process.

No preferred perspective: We were forced experience the gameplay from a variety of perspectives. When I create static levels, it is easy to quickly fall into a rut where I start polishing the experience for one or two 'correct' paths. If a specific scenario is too powerful, I might simply adjust the health of an individual enemy instance so the player has less difficulty. The result is localized polish that translates into shallow gameplay. With random levels, this class of tweaking is impossible.

Fig 1: Polishing a single scenario and a single success path leads to polishing only a narrow portion of the playspace

System-level iteration: In order to polish the experience, we instead needed to iterate and polish at the system-level, not the content level. Most changes occurred in the planes, powerups and scoring. These are systems that affected the entire player experience. In the end, a much broader playspace ends up being polished.

Fig 2: Polishing a variety of scenarios leads to polishing a broad set of systems that yields a deep playspace

Depth through new systems: When the game wasn't engaging, we added new systems such as having downed planes drop powerups. A more traditional approach might be to manually create more detailed scenarios with surprise plot points where a pack of planes pop out of a hidden cloud when you collide with a pre-determined trigger. However, by instead focusing on new general systems, we created an entire universe of fascinating tactical possibilities. Do you head for the heal powerup or do you turn to face the Dart at 6 o'clock? That's a meaningful decision driven by systems, not a cheap authored thrill.

The self imposed constraint of avoiding the creation of static content in the form of hand crafted levels resulted in a game that is in my humble opinion, more enjoyable than the original Steambirds. Personally, I'm going to continue using this philosophy of limiting static levels in future games because I see the following benefits

More game for less overall effort: You can play Steambirds: Survival for dozens (if not hundreds) of delightful hours. Yet development time was considerably less than if we had handcrafted an equivalent number of puzzle levels. .

Deeper gameplay with a longer mastery curve. I've played a lot of Steambirds: Survival and I still find new skills and tricks that keep me coming back. At a certain level of depth, a game transcends being a disposible blip and turns into a life-long hobby. We aren't quite yet at a hobby-class activity with Steambirds, but this design process inevitably leads us there. As a designer, I feel like I'm wasting my life when I create a disposable game. I feel like I've contributed in a meaningful way if I can create an evergreen activity that attracts a community that last far into the future.

Create game modes, not levels

As designers, we have access to a much broader exploration of the space created by a set of game rules than is available to the player. During development, it is common to run crazy experiments where speed is doubled or health knocked down to nothing. Most of these variations are unplayable, so we chop them from the final product.

Yet a handful of tweaks end up being fascinating. I think of these areas much like the Goldilocks zone for planets. In order for life to exist, a planet must be close enough to the sun to be warm and far enough away so that it isn't boiled. These two factors create a thin band around a sun in which a habitable planet may exist. The same thing happens with games. You push a particular variable to far and the game stops being enjoyable. But within a certain range, the possibility for fun exists. This experimentation helps use define the valid playspace for a particular set of mechanics.

For Steambirds Survival, we took some time to discover the limits of the combat system. We spent hours tweaking various variables, and testing to see if they were fun. The goals was to build a multi-dimensional map of where the fun lurked in the Steambirds mechanics. In the end, we took snapshot of the various gameplay variables in 24 initial states and saved these out as unique planes that you can play. The long range sniping Aught Nine plays quite differently from a delicately swooping Chickadee-S518 The result is really 24 game modes, each of which is infinitely playable.

Level design vs initial conditions

How is this different from level design?

Instead of creating content that can be enjoyed only a handful of times, we are setting up game modes that can be played a very large number of times.

How each mode unfolds is primarily determined by game mechanics, not a set of scripted events. As a result there is a very wide range of possible scenarios, not a single predetermined outcome.

Modes are modular, robust and loosely coupled so that tweaking critical values is rarely damaging to the mode's fun. Level design is fragile because you are trying to squeeze fun out of a very narrow playspace. One tiny mistake and the experience is broken. However, when you have a big broad playspace and you've plunked the player smack in the middle of a wide Goldilocks zone, you have a lot of room to push variables about without harming the rich pleasures of the game.

Mapping the playspace

Here's the process I used to map the playspace and create the various play modes.

Identify: Identify the variables. Many of the important variables in the original Steambirds were hidden away in code. Andy surfaced these in an XML file so they could be readily tweaked.

Explore: Methodically explore the space. I created a matrix of planes, each with one variable pushed to the extreme. Then I played them. The majority were unplayable and I'm not sure a single one made it into the final game. However, through the process of testing concrete variations, I gained a sense for what worked and what didn't. I was mapping out the Goldilocks zone.

Theorize: Now that I had some data, I created theories for fun planes. "I think that a slow, short range plane that needed to trap enemies in webs of poison trails would result in interesting tactics"

Test: Then I would change a few variables and try it out. Did the theory yield a new way of playing the game?

Refine: At this point, we'd iterate on the plane many, many times to get the feel just right.

Cull: We made a lot of planes. Some were more fun than others so those got chopped and the good ones stayed. This follows the philosophy of designing from a position of plenty, where you are overflowing with good content and can choose to put forth only the best.

Static levels decreases the depth of your game

Let's take a step back and look more broadly at what this simple observation means for the industry at large. There is a very real opportunity cost associated with creating static level content. In fact, it is baked into the pre-production and production stages suggested by the popular Cerny method of game development. During preproduction, you test and finalize your game mechanics. By locking down your game systems early on, you reduce your production risk when building large amounts of static content. Heaven forbid you change the jump distance on your main character after you've built 20 expensive levels based off that value.

At first glance this staged approach seems like a sane and rational practice. In fact, it originally came about as a way of giving design a place to iterate within the increasingly rigid development schedule. However, it also requires that you limit your iteration upon your mechanics at some point in your schedule. Yet such a design lock down conflicts with how design actually occurs in the real world.

Consider the common scenario: a designer, after playing the game for several months, finally groks a fundamental relationship in the system that will make the game immensely more enjoyable. This actually happens all the time...designs often need to sit for a while before they reveal their true nature. We are closer to mathematicians exploring a new class of equations than we are authors banging out another variation of the Hero's Journey. And like mathematicians, insight rarely occurs on a predictable schedule.

In a procedural game, a new design insight translates into a quick experiment that tests the idea. Many of our big design changes in Steambirds: Survival took minutes. The largest, a new progression system, took a week. In a game with a heavy production burden, a new design insight instead provokes immediate push back. Almost all other disciplines have something to lose since almost any mechanics change occurring in the middle of production has two follow-on effects:

Design changes during production threaten to invalidate many man years of labor. The producer sees a threatened schedule. The level designers see destroyed levels. The gameplay programmers see destroyed scripts. The narrative designers see altered plot lines and discarded cinematics. The reality of modern development is that any design change in production has a large political cost.

If the change is accepted, large amounts of new content needs to be implemented. Even if the design change is the right thing to do for the player, it is often economically not feasible.

As a result, polishing and improvement on the game design is almost always locked down prematurely. It is not random chance that nearly every postmortem wishes they had a longer preproduction phase. The entire Cerny method creates logistical constraints that unwittingly damage the team's ability to build and iterate on deep and meaningful systems.

Agile methods help here by allowing teams to lock down content on a more modular level, but this is a patch, not a solution. Ultimately static content is inherently difficult to refactor. The marginal cost to change content is often equal to original cost of creation. The reliance of the design on structurally brittle content like levels and narrative lies at the root of the problem of premature design lock-down.

After many years of living this reality, modern AAA development teams have retreated from most meaningful exploration of deep game systems. Over time, economics and production logistics shape design as surely as the currents in the ocean shape the rocky shoreline. If you look at games like God of War or Uncharted, you see the end result: Mechanically safe and simplistic games heavily larded up with a constant streams of static content. There is no meaningful systems to learn nor choices for the player to make. Instead, players submit themselves to a constant stream of pretty pictures whilst bashing buttons to advance. By following the siren's call of 'evocative' static content, most AAA teams have managed to suffocate the playspaces that make games great.

As a movie-trained consumer looking for mindless escape, I understand the appeal. As a game designer, I find this direction repugnant. We have a unique medium capable of immersing players in a rich systematic understanding of complex models of the universe. It is time for a very different philosophy of design that minimizes static content and level design and maximizes the impact of game mechanics and meaningful systems.

With Steambirds: Survival, we were able to create relatively major changes to the gameplay late in development. What little static content existed was highly modular, contained few dependencies on other systems and was therefore quite robust in the face of changes.

I highly recommend that you distance yourself from handcrafted static levels. Cull linear structures and content dependencies. Treat production as a form of waste that should be stripped from your development process. These elements destroy your ability to iterate on your design and suck you into a mediocre and limited vision of what games can become.

Conclusion

When I look at back at the origins of electronic games with their infinite arcade modes and their procedural levels, I see the seed of something great. Somewhere along the way we took a wrong turn, away from interesting interactive systems and towards static disposable content. For decades we've been investing outrageous sums of money in production activities that actively diminish the key value proposition of our interactive craft.

My goal with the games I work on is to shift the balance back toward gameplay. Throwaway bits of plot and puzzle are still useful as training that gets players into the game. They are great as the occasional dash of spicy emotional seasoning. We have such things in Steambirds, modularized and tucked in the background where they belong. But they are not, nor should they ever be, the meaty center of the experience.

What I've been describing with my last few posts is a philosophy of how I prefer to design games...a school of efficient game design, if you will. The pillars I've discussed to far are simple stated:

Use design to lower costs: By following efficient design practices, we can build world changing games at low cost. Escalating cost curves are a symptom of broken design practices.

Leverage Players: Our designed systems seed value structures that empower players to create stories, community and culture. The deepest dramas happen in the players' heads, not in our labored delivery.

The existence of a school of game design does not mean that all games need to follow these constraints and processes. If anything we need passionate variety more than we need a theocracy of design. Instead, a school of design acts as one (hopefully of many) beacons for thinking designers. We look to the past and call out our long history of mistakes and successes. We look to the future by building concrete works of art that boldly promote the lessons learned.

Design is first and foremost a conscious act and we should take an educated and thoughtful stance on what styles of design we pursue and what ones we reject. Steambirds: Survival is a simple game, but it is one that is design with intent. To make games due to habit, fads, instinct or pursuit of a mundane paycheck means that you are wasting not only your life but the lives of all your players. A thing blindly created is always a thing blindly consumed. What is your stated philosophy of game design? What are the beliefs that drive your creation?

Give Steambirds: Survival a try. There is still so much more work to do, but this should give a small taste of where we are heading.