For quite a few years now, I’ve been giving a presentation as various conventions titled “Golden Guidelines for Good Game Design,” which I’ve described as a set of rules of thumb that can be used to determine why a poor game isn’t better, and how to improve it. I’ve been asked many times if there’s a printed version, or some online deal, and the answer’s always been “not yet,” mostly because every time I gave the presentation, it would change. It was clearly still evolving.
Now, that’s still true, but along the way, parts of it have leaked out. So, I thought I’d collect some of the parts that have made it into print so that people could see some of what I’ve been working on.
It all started at the 2002 World Science Fiction convention in San Jose. I was on a panel about game design (with Bill Fawcett, Phil Foglio, and Julie Haehn), and somebody in the audience made some comment about a particular game, and how they didn’t really like it as much as they thought they ought to, and I replied along the lines of “Oh, yeah, I’m not surprised you feel that way. That game breaks one of my golden rules of game design: don’t kick a player out before the game is over.” Everybody immediately wanted to know what the other rules were. I’d never actually written them down; every now and then I’d look at a game and think “now, see, this game is doing that thing that the other game did, and it’s not a good thing for a game to do,” and that would become a Golden Rule in my head, but I’d never tried to think of all of them at the same time.
So I told the other panelists to carry on without me, and I’d try to figure out what those rules were and tell them in a few minutes. Which I did. I believe there were five of them at the time.
Now there are nearly thirty Golden Guidelines (at some point I decided calling them ‘Golden Rules’ was a bit pretentious), and rather a lot of game design theory behind them. The whole thing is (at the moment), two presentations, one of which takes 90 minutes and the other which takes 60, but will probably be more than 90 before the end of 2013 because it’s the part that’s still being developed at the moment.
I tried to write the Guidelines up as an article, but it was when I was halfway through the project that I realized there was a whole lot more still waiting to be thunk up, so I shelved it until I was closer to having actually finished developing all the ideas. Sorry.
However, that first half isn’t hiding in my drawer any more. Mike Selinker asked me to contribute an essay to “The Kobold’s Guide to Board Game Design,“ and what he got was, in a nutshell, the first six Golden Guidelines. The essay is entitled “Stealing the Fun” because the first six Guidelines are all instantiations of what James Ernest calls “Howell’s Law” and I call Axiom 1:
A game is not fun unless a player believes they have some reasonable chance to win until the moment the game ends.
Some of the ideas that needed to be developed for the original article developed themselves further when I wrote a white paper for Blizzard discussing how StarCraft could have been even better than it was without needing a bigger processor, and with what would have been only a few extra pages of program code. Although I wrote the paper before StarCraft II came out, I didn’t end up showing it to anybody until after SCII was released, and it was interesting to see a couple of the ideas in the white paper appear in SCII, but in a fairly tentative and weak form.
The white paper talks about Axiom 2, and how it explains what it is that makes a game fun in the first place. It was this idea that I realized was incomplete. What was Axiom 2 has become one of five new axioms for the second part of the overall theory. You can see how that idea has developed in the next white paper....
Most recently, I was one of a horde of people who backed a Kickstarter project for a computer game called “Faster Than Light.” Given that it came from what appears to have been more or less a two-person team, the game is remarkably well-designed. I take it for granted that it’s modeled on some other game with which I am unfamiliar, because a lot of what’s in FTL is smoothly balanced in a way that usually takes a lot of iterations to home in on.
Almost every computer game I’ve ever played (and this absolutely includes Blizzard’s games) shows a distinct ‘fingerprint’ to me; the game is as good (or as bad) as it is because the programmers developed it mostly by figuring out there was something about the game that wasn’t working, thinking up a solution, playtesting it, and then deciding if whatever the change had been had fixed the problem or not. The result, at least to my eyes, is a game where I’ll find myself saying “why on earth did they do that? Oh, I see, because that odd behavior or strange quirk fixes (or mitigates) this game design flaw.” or I’ll go “why didn’t they implement this feature in this other way? It would have been much more interesting, and more fun.” The answer, I have to believe, is because they didn’t actually understand why the design change that they made had made the game better, they just could tell that it had. Since they didn’t actually understand what the revision had done, they couldn’t use logic or reason to refine the design. They would have had to have just tried other options more or less at random to see if anything else was better, and at some point, you just can’t take the time to keep stumbling around in the dark trying to improve something that isn’t really broken.
That’s why I think FTL must have some fairly similar precursors. If the guys at Subset Games were good enough to have designed FTL just on general principles, they would have been good enough to avoid many of the fairly significant and easily fixed flaws the game has. Don’t get me wrong, I think FTL is a really outstanding game. Based on how much fun I’ve had and how much I’ve played it, it’s worth at least $60, but it only costs $10. Interestingly, I’ve found that it’s easiest to show how the Guidelines can improve a game when I apply them to a game that’s already very good. I guess bad games have such obvious problems, you don’t need anything as subtle as the Guidelines to fix them.
But anyway, the other important thing about my Faster Than Light analysis is that’s it is the first time I’ve written down material that directly discusses the second half of my overall philosophy of game design, which has to do with what makes a game fun in the first place. You can clearly see (I hope) how the idea that was Axiom 2 in the previous document has developed into something much bigger, and much more useful.