Game Design is Iterative

Dice for game designIn my side job of game design, I’ve learned a lot about how games are made. Games can have a strong mathematical component to them, and you can apply game theory to any interaction. But when designing a game to be played, the process is highly iterative and experimental. In tabletop games, there’s usually an underlying mechanic, like “roll a d6 and move that many spaces” for a roll-and-move game like Monopoly, and a theme, which is what the game looks and feels like– “building a real estate empire” for Monopoly, for example. Zombies was a hot theme a few years ago, and cats seems to be the theme-of-the-year for 2017.

When I design a game, I start with some idea of what I think would be fun. I’m a “theme first” designer, so I start with “this game is…. (escaping from a space station, or fighting monsters in space, or being a walking, talking toy). I usually keep going, and play a solo improv game of “yes, and/no, but.” That’s where I may discard the first idea so that I come up with something more interesting, or I add to the starter idea (” a walking, talking toy” had “in a post-apocalyptic, broken world” added to make a much more interesting theme and therefore game).

Side note: Other designers are “mechanics first,” where they design a clever or new way to play a game, and then put a theme over it. You can usually identify these designers because they have clever mechanics but either very little theme, or no theme at all (abstract games). An abstract game is something like Go, where there is almost no theme at all, but there’s deep strategy involved in where one places the stones.

 

After I’ve played this game of “yes and,” in which I run through a lot of different ways to explore an idea or theme, then I start thinking about mechanics. If I were building a backlog of “make a game,” I’d have the following items in it:

  1. Decide on a theme.
  2. Flesh out the theme– make it more interesting!
  3. Pick a game mechanic.
  4. Flesh out the game mechanic– give it a twist!
  5. Write the first draft of the rules.
  6. Get some components and players and Playtest.
  7. Revise the rules.
  8. Repeat from step 6 until it’s either ready to ship or you run out of time, money, or patience.
  9. Release the game.

The repetitions between 6 and 7 are, of course, where the bulk of the work comes in; they are the inspect-and-adapt portions of creating a good game.

I’ve written several games, sometimes using this method, sometimes with less playtesting, and I can honestly say that iterative playtesting is the cornerstone of good game design. I even playtested my Improve Drawing Game before posting it.

Written by

Stephanie Bryant is a Certified Scrum Professional (CSP) with a technical documentation background from Las Vegas, Nevada. She helped a 100% remote defense contractor team transition to Scrum in 2016, bringing them to be more functional and productive thanks to improved communication and teamwork. Before falling in love with Scrum, Stephanie was a technical writer for 20 years and has written several books, including Videoblogging for Dummies. As an entrepreneur, she wrote and published a 4-issue comic book for knitters and has written or contributed to several tabletop games. Stephanie is an accomplished public speaker and trainer, having presented at professional conferences and user groups for the Society for Technical Communication, WebWorks, and the Madrona Fiber Arts Retreat. She has both online and in-classroom experience as a teacher and trainer, having taught technical writing courses online and Freshman composition in the classroom at San Jose State University. She's also led teams, both professionally (as a Scrum Master and entrepreneur) and on a volunteer basis in her tenure as an officer of a local Toastmasters group, the Society for Technical Communication, and the National Writers Union, where she served as the national chair for the book authors' division. Stephanie is now turning her unique set of leadership, training, and Agile skills to a career in helping other teams learn to love Scrum and improve their teams and processes.