Friday, December 3, 2010

Steambirds: Survival: Goodbye Handcrafted Levels

Steambirds: Survival, the sequel to our original steampunk airplane strategy game was just released today.   You can go play it right now at

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.
  • Removing handcraft levels as a method of finding deeper fun
  • Create game modes, not levels 
  • Corollary: Focusing on static levels decreases the depth of your game.

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 too 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:
    1. 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
    2. 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.


      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. 
      • Always evergreen: Deeper, more meaningful systems yield lifelong hobbies, not disposable media.
      • New games: Design from the root using iterative, exploratory design to create unique, differentiated products.  Clones are projects for wage cogs and poor designers. 
      • Small teams: Leverage the immense creativity, flexibility and productivity of small teams of co-creators.  Large teams destroy efficiency. 
      • Robust play spaces: Create broad landscapes of possibility that can easily withstand both player and designer induced variation.  Avoid brittle structures.
      • Lean Content: Unchain our ability to iterate on design by reducing our debilitating dependency on puzzles, levels and other static content.
      • 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 designed based on a passionately held ideals. 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.

      take care,


      1. Congratulations on another masterpiece of evergreen strategy goodness. Keep up the fantastic work - and as always, your insights into the design process are extremely valuable to your indie game dev peers. Thanks for sharing your wisdom!

      2. It seems to me that your post (and in fact, basically all the conversation about procedural content) miss a very important and unexplored middle ground:

        Procedurally specified static content.

        Considering your example of changing the player's jump height after 20 levels have been made. What if instead of geometry being statically placed a certain distance apart, which makes a gap, instead there was a 'gap object' that was tuned to the current jump height? Adjusting the jump height would adjust the size of the gap, and the rest of the level content would close in or expand around it.

        Of course, this is not something that could just be added to current engines and processes. Building worlds and games in this way would likely have to start out from a more 'fully procedural' approach, and be adapted from there to introduce more level design and game design control over the picture.


        I honestly don't think that any of the three approaches (static, procedural, and procedurally static) is any better than the other, but rather, we have the opportunity to make choices that are right for our game.

        For example, Steambirds was already a fairly procedural game, relying more heavily on the mechanical interactions between the airplanes than on any static level designs or scripted elements. So it makes sense that procedural content would turn up as a strong fit. But this doesn't apply to all games.

      3. A couple thoughts:

        1) Your process of design changes the type of game you make. If you start prototyping with random maps and procedural generation, you'll end up at a different point with more robust systems than if you start out with handcrafted content. This is due to how polishing occurs and how the fun is found. The game you want to make is one ingredient. How you make it has an equal impact on the end result.

        2) Procedural content is not for every game design. That is also the point of this have a choice as a designer. By choosing designs that are not amendable to procedural content, you put yourself into a production rut that deemphasizes the impact of meaningful design. So yes...make whatever game you want. Just realize that there are immense trade offs and it certainly isn't efficient game design.

        take care

      4. I've played four or five planes in SB:S today. Are the wave spawns varied by your type of plane?

        Good work, by the way.

      5. I did something similar with my game, Word War vi. All the "levels" are procedurally generated with a bunch of knobs that can be turned (at compile time) to influence how each level turns out. Not sure it's really quite the same as what you describe, except in the fact that I did it that way to save myself the work of having to make static levels. And I can get practically infinite variations by just changing the initial random number seed.

        Some info about it here:

        and more here:

        -- steve

      6. @John

        Glad you are enjoying the game. Wave spawns do vary based on the type of plane you play. I'm basically using it as a pacing mechanism. Some planes are more powerful, but the spawn rates ramp up faster. That can lead to either a more frantic survival game or a kill fest against low powered hordes.

        take care,

      7. Another fantastic read, and excellent advice for indie game designers. Content can be a devil, locking you into design choices that are contrary to actually having fun.

        When people complain about how most franchise based games are horrible, I point to exactly these principles. The design insights formed are killed even earlier and more often, as an existing franchise imposes its design on a game. The few franchise games that are actually any good either have an incredibly wide franchise base to draw off of, so more concepts are on the table (Batman: Arkham Asylum), or foresake some of the most fundamental aspects of the franchise that it's drawing on itself (NBA Jam).

        Steambirds succeeds in part because it isn't restrained to any franchise or any *history* - you can make up as many planes as you want, color them however you see fit, and add as many nonsensical mechanics (historically) as you please. By completely forsaking that narrative and striking a new one that explains it all without question (alternate history woo), Steambirds leaves the door open to every possible design choice - and that's the first critical step.

      8. Rock on, danc! I am going to get S:S this weekend (when I'm not coding maniacally on my own title). :)

      9. This comment has been removed by the author.

      10. Please make this game full screen, this can change everything!

      11. I agree with an awful lot of what you're saying here, Dan - but then, I think your production observations are almost always really insightful and a great antidote to what normally happens in the AAA industry.

        I used some amount of procedural content generation for both the Flash games "Sparks and Dust" and "Magnesium Gardens" (though it was in the frozen variety, mostly for level shape + entity allocation), for many of the reasons you talk about. The main lesson I took away from doing so is that it's very hard to know what ought to go into your procedural algorithms if you haven't spent some time making good levels by hand first - and it's still really hard to know even if you have.

        I have this vague but pressing sense that procedural content generation in games is in a state similar to where procedural art generation was prior to Perlin noise - we need better ideas, tools, primitives, and probably even mathematical paradigms for this stuff, I think. I have no idea if you've run into anything similar, but it's slowly turning into one of my great white whales =)

      12. Nice article and all...
        But I have really enjoyed steam birds 1. The second installment not so much.
        Levels really gave the first game a story - I remember I was really looking forward to what kind of scenario have the authors thought of for the next level. It is like when you are reading a book - you read it because the author is good in story telling/putting thoughts on paper. If you were provided with random (yet tuned up) text it would be of lower value.
        Sadly I must say that Steambirds: Survival does not spark same enthusiasm as first one. It feels much more arcade, much less involving, much less interesting - just fly around and see how many planes you can down. And when they kill you, you start from the beginning.

      13. I've always hunted for games (since I started caring about games and playing them much--when I entered my teenage years) that present limitless possibilities for interesting decisions. I always felt that games with static content were cheating me. I wanted emergent gameplay that generated novel situations, not the same regurgitated, scripted activity. Though I have come to accept static content more, I still feel as if game designers are cheating players by hardwiring high-level content into their games when they could otherwise only hardwire the low-level stuff and allow its procedurally-generated recombination to provide the interesting decisions. I want to say to certain developers "you could have actually thought this out and given me a game I could keep playing for months, if not years. Instead, you gave me this preconfigured blob of uncaring, uninteractive shininess."

        I'm very much on your side here, Danc. I want games to explore the recombination of smaller static design elements to produce as much fun as possible, instead of the game putting quickly explored and discarded large static design elements before the player.

      14. As an earlier commenter said, I think there's a middle ground here.

        There are types of games which simply can't be done with generated content; story driven games, unless you make the content dynamic and drive the story with cutscenes, but I think history has demonstrated pretty well that story based games have more impact when the story is told through gameplay as well as cinematics. It would be hard to do, say, the X-Wing / TIE Fighter games with dynamically-generated levels; so much of the excitement of those came from the story. To take an even more obvious example, a dynamically generated adventure game would be a terrible, terrible idea. =)

        There's also the case where level design is so good it becomes the strength of the game. The game mechanics of Super Mario, say, are not intrinsically super-interesting. They're carefully designed and tweaked and it is kinda fun to just run around with Mario doing different types of jumps...but only for a few minutes. I think a Super Mario Galaxy which consisted of dynamically generated levels drawn from a set of platform blocks and enemies etc would simply be nowhere near as great a game as SMG actually is, because the design team is so strong at designing inventive and interesting experiences.

        But most interestingly there is the middle ground. I think an interesting example here is Doom. Doom's an all-time great game, that uses set level designs. Some of the level designs are really, really amazing. What's interesting is that someone once wrote a random level generator for Doom which works much as you describe, and playing those levels is *also* fun. It can be better than a really bad human-designed level.

        So I think the trick Doom manages is that its mechanics are intrinsically great: it's a design that's capable of being fun with randomized levels because the parameters of movement, weapon selection and strengths, and enemy behaviour is so well-balanced and interesting. If you set up a level generator with a few parameters to make sure the game balance works as the design intends, you come up with consistently enjoyable levels. But a skilled designer can *also* bring a great setpiece level design into the mix and it will elevate the experience even more.

        I think I'd say the point to be mindful of here is that you should make sure the fundamental properties of your game design are sufficiently well constructed that they're interesting and fun in and of themselves, and restricting yourself to dynamically generated content and making sure the game's fun to play that way is a great way to make sure you don't screw that up. But once you've done that, I think with most designs, a skilled handcrafter of levels can come up with an experience that's still going to be superior to the dynamically generated levels.

      15. First off, good write-up. Very insightful and articulate. And now to a point of difference!

        "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."

        While I agree with you, as a designer and a game player, I think you have only lightly touched on the artistic ramifications of this statement, namely the time it takes to carefully craft a game environment to AAA quality. Steambirds, and nearly all indie games, are game design constructs illustrated with a particular lo-fi look that maximizes flexibility at the cost of verisimilitude.

        The impact of that tradeoff is felt most keenly at the mainstream level of AAA titles. If God of War was just a series of challenges with its basic control scheme, it would not be... well... God of War.

      16. "By choosing designs that are not amendable to procedural content, you put yourself into a production rut that deemphasizes the impact of meaningful design. So yes...make whatever game you want. Just realize that there are immense trade offs and it certainly isn't efficient game design."

        Would you consider Zelda OoT or Mario Galaxy 2 games that deemphasize the impact of meaningful design. No procedural creation could produce levels of polish and creativity as Galaxy 2. An adventure, or story, or exploration game benefits from levels and a world created and crafted with focus from a designer.

        Perhaps such games deemphasize the design of the mechanics, but to suggest they deemphasize design in general is using a very narrow definition of design.

        Thousands of hours perfecting the mechanics of Minecraft will provide a different experience than thousands of hours crafting the world of Zelda. I don't see the validity in the claim that Miyamoto's masterwork had less "efficient" design than a procedurally created game.

        Entirely procedural games can never provide the same sort of experience as a game like Metroid. Or at least, we haven't gotten there yet.

        Great article, with a lot of insight. I just think its a bit unfair when comparing the two design styles.

      17. Great article, many great comments.
        My addition is to note the inherent conflicts between the two poles of game design.
        Challenge presentation: Complete Control
        Challenge resolution: complete control
        Story presentation: complete control. Focus is on the NPC story.
        Player Control: Minimal to Some
        Replay: Only per pre-defined branching points such as story and class choices.

        Challenge presentation: Loose Control
        Challenge resolution: Player control
        Story presentation: Some + Player control. Focus is on Player's story of how they played the game.
        Player Control: Some to Maximum
        Replay: Virtually unlimited.

        or so I see it. The two approaches are equally valid, they are just going to be really different experiences for players. This is GREAT, as it expands the potential for "What is a game?".

      18. As an indie game developer, what you say makes a lot of sense.

        However, I have to disagree with your dismissal of the static game. I love a good story. Take a powerful writer in charge of a games story and you get to play the main character in a book. That kind of story can not be built using a dynamic system.

        You can build A story using dynamic content. Which is what I think Peter Molyneux is eventually trying to do with something like Fable. But it's an entirely different experience.

        Now, as AI gets sufficiently advanced, we can have that dynamic story. But for now we have to survive with static levels.

      19. I think your view of the validity of procedurally generated content is also limited by the scope of your experience of it. As someone who worked at Maxis on both the Sims and Spore, and being on the periphery of the SimCity projects, some of the most 'procedural' AAA titles out there, I can tell you that your ability to experiment is limited by the weight of work that's been done before, regardless of the type of that work.

        Imagine if you had 50 people working on Steambirds for a year - even if it's still all procedurally generated, small 'discovered' changes are going to have dramatic impact. Rather than throwing away content, however, you throw away all the work on tuning and understanding what is now a monstrously complex procedural environment.

        I also think working in a flash environment on an already fairly well understood game, mechanically, is not a good test case for proposing that AAA titles move to your form of design strategy.

        While Steambirds:Survival is really fun, and I applaud the game, you haven't really made anything unique here - adding a horde mode, purchaseable unlocks, and powerups isn't exactly novel.

        No offense, they're good design choices, but you haven't really stumbled on new territory that many, many, many other flash titles haven't been chasing down for the last year or two - so it's a bit strange to hear that you believe this system has allowed you to experiment grandiously when the results are very similar to the additions most other flash games are adding to promote replayability.

      20. Hey Dan,

        I just want to mention that this lines up exactly with what I discovered, but had neither the courage nor budget to correct on a game I finished a while ago. While creating static levels for a puzzle-action game, I found that the endless mode, full of randomly spawned elements with knobs associated, wound up being more entertaining both to iterate on and to play. The transition away from an explicitly authored experience was intimidating, and ultimately both modes suffered due to my indecision.

        It was good to read this and certainly I'm taking it to heart.

      21. Loving the game, but I am wondering - is there any kind of timescale on getting Steambirds: Survival on mobile devices? I was pondering getting the original on my iPhone but having tried both on my PC via Flash I do definitely agree that Survival is more fun and has more replay potential.

      22. As I understand it, design changes were the main factor responsible for the decade-long lack of Duke Nukem Forever. They got a good engine, developed characters, wrote the story's plot and made levels, but by then engine design had moved on, so they got a new engine, redeveloped characters, rehashed plot points, made new levels...

        And with the money DN3D made during those heady days before Internet piracy became every game publisher's worst nightmare, they could afford to revamp and revamp and revamp.

      23. Can the same approach be used with competitive multi-player games ... or is the risk of unbalanced and exploitable systems too great leading to griefing etc?

      24. This is an excitingly thought provoking article!

        Personally, as a game player the idea of playing procedurally generated levels does not appeal to me at all. I think the main reason is that I specifically want games with endings, and preferably that ending isn't too far away from the beginning. There are simply too many wonderful games (and films, and books, and albums, and things to learn, and places to go) for me to invest dozens or hundreds of hours in just one. Short, dense games that, in the words of Jonathan Blow, treat my time and attention as precious, are what I look for and cherish these days.

        Wearing my other hat, though, as a game developer the idea of using methodical processes to develop mechanics and random generation to get inspiration for level design appeals to me a great deal. I want us to treat the results of those as raw material, though, and use our judgement as game designers to curate and develop it down to the cream of the crop down for the players. Of course, that's the process you described for coming up with the plane design parameters, but why not do the same for the levels as well? I want to be able to say to my players, "I tried 10,000 different variations so that you don't have to. Here are the 50 out of those that are really worth your time."

        Anyway, thank you for explaining your ideas and processes so well in this post. I'm kicking myself that I won't have time to make use of some of these ideas in the game that I'm finishing now, but there's always the next one!

      25. Hello Dan,

        First time posting here :) A lovely, quotable article as usual.

        I don't think 'static v. procedural' is a fundamental opposition in game design. Both are useful modes for realizing a world or concept. And they work well together; most games are a mixture of the two.

        Few games are purely static -- a linear point-and-click, perhaps. And none is purely procedural -- even the Game of Life or Powder Game XXI have static rules at their core, however simple.

        AI's and randomized environments are usually procedural; item types, drop rates, boundaries, physics, planes/NPCs are usually static. There are some nice explicit mixtures of the two modes; Nethack springs to mind.

        It might be helpful to describe a game world in terms of which of its aspects are fixed, and which can be organically parameterized from simple rules. This is independent from whether it also has hand-made elements by people good at making that type of design.

        (and 'levels' aren't unique here: elegant clothing, balanced weapons or planes, tricky levels, and entire balanced rulesets, are all things that can be designed... or generated by organic rules designed... etc.)

        Some people are born level designers. Asking Edmund McMillen to stop what he does would be criminal.

        Personally, I find that a few carefully designed, elegant levels in an organic game help frame a great story and help players discover various meta-games.

      26. Dan: Really enjoyed this. I haven't really had a chance to swing by and say hi for a while and this article is another great angle on procedural content generation that I hadn't really considered before.

        Nathan, others: There is a significant amount of academic work investigating procedural content generation at the moment, which is opening up some really exciting opportunities for game development. I'm going to summarize some of this on my blog this weekend, and the PCG wiki (, but in the mean time, if you Google Julian Togelius and look for his and his co-authors' paper on Search Based Procedural Content Generation, you'll find a useful primer on the direction being taken.

      27. I'm currently working on an AI director based on a PDF I found floating around about Valve's Left 4 Dead. The idea being that in my level editor I add zombie and ammo cache spawnpoints, but the game determines which ones should actually be active based on player skill level, and short break points. I guess its like semi-hand crafted levels... Anyway, nice post!

      28. I see this as a much deeper issue than just procedural vs static content. I'm reminded of a theory I had years ago about the balance of units in Total Annihilation vs Starcraft, a theory I called Internal Balance vs External Balance.

        TA is an internally balanced game. Each unit is balanced individually on its own merits and some unifying guidelines. Say you need to design an artillery unit to complete an army, you have many factors available: maximum range, minimum range, damage, vehicle speed, cost, and so on. A common tactic in TA balance seems to be erring on the unit being more powerful, but raising the cost of it. Magic the Gathering is also balanced kind of like this.

        Starcraft, on the other hand, has each unit balanced by external factors. A zergling fill a basic role in its army, but there are hard counters to them in the other armies. Blizzard has evolved this complex interlayered balance between units into an artform by SC2. You don't just consider a unit's costs or abilities, but also what hard counters exist, what hard synergies are built in, and so on.

        Obviously, any real game has a blend of both methods. TA and MtG require some considering to how different units will synergize together, and SC needs some benefit vs drawback analysis per unit to set baselines before tweaking to match the counters. But my point is that each is more of a philosophy that can drive how you design and balance the system.

        The consequences of that focus stretch through the entire design. I compared TA to a card game and I think that's apt. You can go through the TA unit list selectively disabling and enabling units without destroying the game's balance. Other units can be used to fill in gaps, or used together to open up new strategies.

        Starcraft is not the same beast. If you disabled even one unit from a side, you'd leave a gaping tactical weak point in that army. High level play exploits this kind of thing where a tactical flaw is found due to designer oversight, and is exploited until a bug fix or a counter-exploit is introduced.

        There are further consequences as well. The single player game for TA or Supreme Commander may not be very thrilling, but its very easy to make scenarios because you just set up a tactical puzzle, remove some pieces, and let the player work it out. SC2 shows the result of the external approach: a single player game that is very unlike the multiplayer one, with additional units that severely alter the balance of play, and a heavy reliance on scripted scenarios.

        I'm not trying to say one way is better than the other, but to me, the internal balance creates a more modular game design that's easier to build additional content around. Instead of a preset list of counters and tactics, you create a sandbox of potential strategies that the players are free to explore.

      29. Great article. Dynamically-generated content definitely has the benefits you've outlined here -- infinite variation, and easier ability to change game mechanics completely.

        But what about story? RPGs are an extreme case; what about games with less story, but still a significant portion -- how do you integrate that if everything is dynamic?

      30. I agree with those that are saying that the procedural content is not necessarily better. I LOVED Steambirds 1, and was really anticipating the release of SB2. Unfortunately, I was disappointed with the implementation and lost interest after only a few missions. For me, the issue is one of motivation and progress. With the completely open-ended nature of the survival mode style, I feel like there is no goal for me to accomplish. I mean...there's no way to win the game even, which I would argue is pretty central to gameplay in general, and to the psychology of reward systems/schedules in general. As a result, I felt no motivation to push forward, little sense of progress (yes, you there are unlockables, maybe some people feel progress by working up leaderboards, but I am and introvert, and will never have enough time to invest in a game to make any impact on the leaderboards), and ultimately no sense of accomplishment. It's just how far can you get through a meaningless horde of recyclable enemy encounters. I felt like Bart Simpson when Principal Skinner made him lick envelopes as a punishment after school. "This doesn't have to be boring; you can make a game of it. See how many envelopes you can lick in an hour, then try to break that record!" Bart's response is what you might imagine. For me, the truly wonderful mechanics of the game are just not enough to keep me motivated.

        I understand your point about how procedural content is more efficient of a way to create game content, but I would argue that that's a business model point and not a game design point. The idea that procedural content makes hand-crafted content obsolete is a pretty one-sided view. Hand-crafted content can still do plenty of things that procedural simply can't do, and as long as many of those things create worthwhile experiences, there will be a niche for them.

      31. The type of static content you describe is the worst case because it is strongly coupled with the game tunables.

        I think there is a ton of value in procedural/systemic gameplay (especially multiplayer) but fictional meaning is still really important, and there is a big market for well-made static content.

        The key to getting the benefits of both are robust systems, robust levels, and loose coupling between systems and levels. If all your levels completely break when you reduce your jump range by 20%, you're coupling too hard. For some games some content-systems coupling is unavoidable (platformers, I think), but for many it is perfectly avoidable.

        For example, consider DOOM. You could rebalance all the weapons, movement speeds, enemy characteristics, and the game would still work well in its existing levels for a pretty wide range of values on these variables. This is a robust systems-to-content relationship.

        In modern times, you can look to a game like BioShock. The game is very story heavy, and it's combat doesn't exactly sing like a really good combat FPS, but I think it could still sustain changes to game systems pretty well. This is part of the design because there are lots of character and weapon development choices in the game and the designers couldn't count on any specific loadout when the player entered many areas.

      32. this is one of the worst things I have ever read. I'm going to go out of my way to bash your game and tell others not to play it.

      33. I'm with Danc on this one... maybe not 100% but well over 50.

        Just remember that classic games from the 90s rarely had "content" in the sense of the rollercoaster ride we see in the latest consoler games (e.g. Duke Nukem).

        For example, X-COM (2) had many random elements. At the world level, you had different subs going to different underwater bases. At the mission level, it depended on whether you've downed the sub or you caught the aliens off guard. Then research depended on what aliens you've captured. No two games were ever the same, though some missions were scripted.

      34. "Treat production as a form of waste that should be stripped from your development process..."

        As a programmer, I have noticed the importance of modularity, high cohesion with loose coupling. It is true that the design will be locked when the coding implementation starts, no matter how flexible it is. However, without locking the design at root, it may lead to feature creeps, the larger the changes in features, the greater the effect.
        With this approach, how can we avoid this issues?

      35. The smaller the codebase, the less expensive the inevitable rewrite. :-)

        A game like Triple Town has been written officially at least 5 times from scratch (if you don't include the half dozen unofficial clones and weekend projects)

        Reducing scope in all areas tends to miraculously improve a surprising number of complex issues.