Modes, not Levels

I think a lot about game design. This is partly because I've always wanted to be a game designer of some sort -- I made my first board game at I think the age of ten or twelve -- and partly because it's such a rich method of engaging with the interactions of human beings and systems that you can't help but learn when you explore it. Sometimes when I read or think about game design I can extract lessons for my writing, for managing people, for cooperating with others, or other things like that, and sometimes it's just fascinating in and of itself.

So this article by Daniel Cook about the power of creating gameplay modes instead of levels is pretty exciting to me. I've noticed this as a trend in game design generally for some time now. flOw (yes, I know, we all hate the title) is the earliest example I can think of in terms of infinitely playable games in this hardware generation, though there are doubtless other important games. Tim Rogers has written a lot about this sort of thing as well, in regards to small games like Canabalt, a game where your guy runs and you make him jump until he dies, as well as larger franchises like the new PacMan games. The Halo series now features an endless horde mode, which I believe descends from a similar mode in the Gears of War series. The mode seems to be a critical favorite and is certainly the only reason I would take an interest in Halo at this point, and the concept's presence in these two major franchises seems to have led to a resurgence of interest in the concept more generally.

The idea is basically that you create a rich game mode with many interesting little hooks, barbs, and systems for the player to explore rather than creating specific levels with pre-planned experiences that often wear thin after one play-through.

Cook argues that the two primary advantages of this approach are as follows (quoting his post):

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

In other words, by forcing themselves to create a game engaging enough to work without their plotting specific experiences for the player, they can create a richer experience that is both more demanding and more rewarding. Instead of figuring out how the designers think, you can focus on figuring out how the game works. This is cool stuff.

To borrow a bit more from Cook, here's how this worked in the development of his specific game:

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

This seems like a sharp process for designing pretty much anything. It occurs to me, particularly in light of my post about the necessity of continuously making rules for oneself in writing, that this is also a good way to design your own voice as a writer: we often learn to do our best work by exploring the extremes of a particular aesthetic, style, or strategy, tweaking the results (often over a series of stories, most of which will never be seen) until we understand how best to make the reading experience fun for the reader. As we grow more experienced, we better understand where the "Goldilocks zone" lies, and grow more skilled in intuitively finding it even in totally new styles. But it's still essential to occasionally go back to square one and screw with your variables, pushing them to the extremes, refining the results, and culling all but the best.

A game with procedurally generated levels (in other words, a game where the focus isn't on level design, but on the creation of a computer program that can generate fun levels according to rules selected by humans) can be continuously redesigned throughout the development process, whereas a game developed according to traditional means is often required to lock down its mechanics prematurely:

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. 

... 

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. 

I don't actually agree re: Uncharted, because while I agree there's a limiting focus on feeding the player pre-planned content, I think that in the case of the second game there's a surprisingly robust series of tactical choices to be made within the levels, which are often brilliantly designed in order to interact with the player and game mechanics in really interesting ways. I've played through Uncharted 2 more times than I'd like to admit, and I was discovering new approaches to familiar situations right up to the end. In other words, I think it's a good example of how you design a scripted game, which is and will continue to be an entirely valid style of game.

I think though that the idea of procedural games as a money-saver may turn out to be a red herring. In the iPhone app market, where Cook is developing, procedural games can indeed save money, but in the realm of triple-A games especially my guess is that competition will generally drive budgets sky high whenever a new method is adopted, regardless of how theoretically efficient that method may be.

For instance, if we begin to procedurally generate more of our levels, we'll inevitably find ourselves looking for more sophisticated ways for the game to build content. This will quickly become costly to develop -- artists probably won't make any less art, but rather will end up providing the computer with more flexible resources to deploy, for instance.

I'm still excited about the idea, though, because of the potential for additional depth Cook discusses, and because advanced procedural design might lead to really rich, surprising experiences in unexpected ways. What if instead of randomly dropping in certain gameplay elements (certain types of enemies and power-ups, features of the terrain) the computer could generate narrative? Not language, necessarily -- that's still well into the future, at least in terms of good language -- but events with narrative heft. Story. What if the computer could be trained to generate a community procedurally? A society? An ecosystem? These are the sorts of things I'd like to see explored, and where I suspect one important piece of the future of game design may lie.