The Rise and Fall and Rise Again of Game Design Rules

Game designers create rules.  It's practically the job description for what we do.  As game designers, we tend to see the entire world in rules, imagining how life can be better understood as a rules-based system, because rules-based systems are what we create.  In digital games in particular, these rules tend to be hard and fast - because a computer inherently only understands true and false, not shades of gray.  And since we spend our time thinking in rules, it's not surprising that many game designers attempt to apply the same rigor to the craft of making games that we do within the games themselves.  We want there to be rules about game design. 

The 400 Project

Over the years there have been many attempts to codify game design rules.  One of the more sustained efforts started with a talk Hal Barwood gave at GDC 2001 titled "Four of the Four Hundred."  In this session, Hal started off with the assumption that maybe there were "400 or so" rules of thumb that governed game design, and then proceeded to talk about four of them.  This was followed by another talk the next GDC, with Hal now joined by long time collaborator Noah Falstein.  Noah went on to continue adding entries with his column in Game Developer magazine, incorporating contributions from many other designers.  The collaborative effort was named the 400 Project.  Today, there's a spreadsheet that shows how far the project got - around 110 rules of this writing.

I always found this rule-cataloguing endeavor to be interesting because of what it implies about scope.   There are 400 rules?  And are those rules really universal to game design?  It's a bold statement, but also somewhat plausible.  When I asked Hal about his motives for starting the project, he said:  "There's an almost inexhaustible number of rough-and-ready maxims -- rules-of-thumb -- that reflect the bemused bafflement that threatens all creative endeavors (and life itself). They help to make sense of the vast and daunting possibilities. I believe that the very informality of rules-of-thumb is what allows them to hold real content -- actual wisdom."  But when I asked Hal how he felt about the project in retrospect, he was very aware of the limitations of such an exercise, and was concerned that game design rules are sometimes taken too literally:  "The kinds of rules I rebel against are those that imagine game design to resemble compiler design. A two-fold folly: on the one hand, a belief that following very precise rules can result in an engaging game; and on the other, a belief that what is engaging is driven by cool science and logic."  When I talked to Noah about the status of the project, he said that he had started work on further refining the list, categorizing it, but that it's a side project that he can only get to when his schedule allows.  Yet Noah was still bullish about the 400 Project, though he too advised caution in using the rules:  "I think the idea of rules is great - as long as you don't take them too seriously, Hal and I quoted Captain Barbossa 'The code is more like "guidelines" rather than actual rules.'"

The Problems with Rules

While still maintaining the value of the 400 Project, Noah and Hal both admit that creating a "definitive" set of rules can be problematic.  The use of the word "rule" itself may be the start of the trouble.  "Rule" implies something immutable, something one must follow if one does not want to be disqualified or thrown out of the game. 

Katie Salen and Eric Zimmerman's book Rules of Play has the word "rule" in its title, but reading the book one finds that it doesn't really cover game design rules per se - the rules it refers to are the rules in games themselves, and the book endeavors to create a framework for game analysis and thought more than a recipe for designers to follow.  Talking to Eric about it, I asked if this was intentional, and he confirmed that it was.  "Because game designers tend to be structural, analytic thinkers, coming up with grand sets of "rules" for good design is very seductive. Including for me! Over the years, I have tried to cultivate skepticism towards those kinds of systems."  Eric pointed out an additional problem with rules:  they can date you.  As in all art forms, creating strict parameters and rules for what art should and should not be is inevitably discarded by the next generation.  Eric again, "Any rules we might think of to define good design in a game will tomorrow become the Man that all the kids want to overthrow."

Daniel Cook, who has written extensively about game design on his blog www.lostgarden.com, finds game design rules more problematic than any of the other designers I spoke to.  As he put it, "They are highly context sensitive, rarely make interesting predictions for the project at hand and have very little analytical power."  Dan prefers functional models that are better suited to analysis and improvement of games in development, with these models helping designers find solutions to their here-and-now development problems.  But he concedes that functional models are not something one can easily explain in a blog post nor do they boil down to a catchy tweet.  As a result they tend to get less attention (though you can read a good write up of one such functional model on Dan's site).  He did say that designers can benefit from creating context-specific rules for themselves, whether for the long term or just for a specific project.  "Sometimes, you need to define a radically constrained black and white world as a creator to push yourself sharply in an interesting direction.  But that is an aesthetic goal, not some observable universal structure that is applicable most everywhere." 

How Design Rules Are Useful

I'm inclined to agree with all the disadvantages of game design rules that these designers pointed out to me.  So why am I still fascinated by them? 

First of all, for new designers I do think reading about game design rules can be an interesting entry point to the craft.  Rules tend to make bold statements that can spark questions in a curious novice designer.  If hearing about a rule is followed up with further reading in a particular area, that can be a great starting point for learning about game design.  But as discussed above, if the rule is taken at face value without further study, that rule may end up doing more harm than good. 

But beyond the novice, I know lots of experienced designers who swear by their personal rules.  This is certainly the case for me.  Specifically, when working with teams as a consultant or advisor, if I spot problems I tend to use past experience to help explain why I think there's an issue.  Usually I have distilled this past experience down into a rule, though typically I don't present it that way to the team.  Instead I focus on the details of my past project, show how a similar problem arose for that game, and then talk about what we did to fix it (if we were fortunate enough to fix it - of course failure is almost equally useful as a learning experience).  In these instances, the strict "text" of the rule is not my focus, but instead the larger context and framework it provides.  As Dan Cook put it, in this case the rule is functioning as a "Memetic for a hard won wisdom."  When we spell out these lessons in easily memorable sound bites, it can help as a way to plant a bookmark in our own experiences.  But we must remember that the rule itself is just a signpost.  To truly do the game design work we need to understand the larger game design problem, not just the catchy phrase we use to remember it. 

The Best Rules are Personal

As a designer, I find that some of the most intriguing rules are ones associated with a particular designer whose work I admire.  For example, I quite like this list of rules Warren Spector developed in collaboration with Harvey Smith for use on the original Deus Ex.  Sid Meier is probably one of the more famous creators of "rules of thumb" for game design - a good summary of some of those can be found in this fine article by Civilization III & IV designer Soren Johnson.  The game fan in me loves hearing the rules a creator set for themselves before working on a beloved game; dissecting their creative process can be fascinating in itself.  But as a designer, I don't necessarily see those rules and think "Aha! I must apply those rules directly to my own games and then they will be perfect!"  That would be foolish.  Those rules worked for Warren, Harvey, or Sid in the context of the games they were making at the time they were making them.  Extending them beyond that can be problematic.   

I think all game design rules are local - to a genre, to a project, to a particular designer.  When hearing about interesting sounding design rules, always remember to analyze the context.  What genres does this rule work in?  What effect would this rule have within that genre?  Is breaking this rule appropriate now that the audience and medium have matured?  In what type of project teams and development environments will this rule even work? 

On that last point, it's often important to think about how game design rules will work within a team environment.  When working with a team of designers, basic agreement on the design principles the project is operating under is crucial.  Often this will be established by the project's design leads, as we saw from the example from Harvey and Warren for Deus Ex.  Making such a set of mutually agreed on rules can be a tremendous tool for keeping a game design team moving in a focused direction. 

As a game designer working on a large project where another lead designer is calling the shots, one inevitably thinks the boss is sometimes wrong - they're designing by their own rules, not yours.  But at the same time, every designer is building their own rule book, whether they get to use it or not.  What are the things that matter most to them?  How would they do things differently than other designers?  In this way, design rules can become very personal. 

For many designers who have worked on large teams, independent development can hold that bewitching allure of finally getting to "design by my own rulebook."  I've been extremely fortunate in that I've gotten to play mostly by my own rules on some of my past projects (though certainly not all of them).  Other times, I have worked primarily as a consultant and advisor, where I was helping teams identify and strengthen their own "rules" and guiding principles to make their games stronger.   In the last half year I've started on a new independent project - right now I'm enjoying working within some of my own rules that will create a very different game.  Other designers wouldn't necessarily agree with my design choices, but isn't that the point?

A Design Rulebook of One's Own

Whether you're an indie flying solo or a designer on a tight-knit team at a bigger company or one of many designers on a giant team at a giant company, the way you work with design rules will be different.  As you read about the design rules in places like Gamasutra always use a filter.  Consider the source - who is the person stating this rule?  What have they worked on?   How is that game similar to the game you are working on and the problems you face?  Even if a designer is brilliant and you love their work, keep in mind that any rule they put forth will probably be a personal, aesthetic choice that governs that person as a creator.  Those rules can be fascinating and informative, but they are far from absolute.  Accept them or reject them for your own personal rulebook, remembering to add rules of your own creation that will define you as a game designer.

If you'd like to hear some interesting creators talking about their own personal game design rules, in two weeks come see my GDC session "Rules of the Game:  Five Tricks of Highly Effective Designers."