G.A.M.E Reports: Rules and Setup
The future of this blog is admittedly mostly a giant question mark to me, but there are a few things I know I’m excited to do. One project that I plan on regularly creating will be game design reports. I’ve had a blast making dozens of silly games and play-centric events over the years, and I’ve learned a lot about the process of crafting positive experiences for players/guests along the way. Game projects and party design have always been delightful challenges to me, especially when constraints like a specific audience, a tight budget, or requested themes add to the puzzle.
I’ve always enjoyed reading other people’s game design blogs and post-mortem reports (you should go check out the boardgamegeek forums for an endless supply, from amateurs and experts alike.) I’m excited to share some of my own stories of success, failure, and hilarity along the way and I hope that you can find my experiences useful, or at least mildly interesting.
Before I get down to any one project, though, I want to lay down how I’ll go about dissecting the process in all future reports.
There are countless ways to tackle the question of ‘how to design things’, but when it comes to games, at least, there are a few fundamental areas that you need to consider. It’s possible to deconstruct a lot of game design into a few non-intersecting component parts, and so my plan of attack will be to use a slightly altered version of the “MDA” (Mechanics-Dynamics-Aesthetics) approach to game design developed by Hunicke, Leblanc, & Zubek (2004), with the addition of a post-mortem analysis on how the game went. And hey, it was a pleasant surprise to notice that I could make the ‘GAME” acronym fit, so how could I resist!
Anyway, enough of the backstory: here it is, the anatomy of my G.A.M.E reports!
1. Goals: Why did I make this game? What was I aiming to achieve, and what was the intended audience and/or environment? What sort of experience was I hoping people would have, and how could I sculpt the game in order to help achieve the desired effect on the event? This section also covers the ‘Dynamics’ portion of the MDA model, but in a broader way.
Game dynamics are described as the experiential patterns of play that emerge from whatever the final rules are of a game. For example there may be a rule (aka mechanic) that allows players to trade resources, but that doesn’t describe what actual play styles will emerge: will players cooperate and form teams, or backstab and lie? Will players be incentivized to share information freely or try to guard their secrets while keeping mental notes of others’ holdings? It probably goes without saying, but this is also the domain of the very common and utmost important goal, “will this actually be fun?”
2. Aesthetics: What’s the ‘flavor’ of the game? What’s the genre and the backstory? These questions will determine how I present and entice the game to the players. What can they gather about the experience at a glance? You can think of a game’s aesthetic as being what’s on the box, what’s in the trailer, or even what is the venue. It’s important to note that a given aesthetic could rely on any number of different sets of rules, and likewise a single mechanic could be used in any style game.
For example, an apocalyptic zombie survival game could be based on dice rolling, tile exploration, or running a marathon. Similarly, a game relying on a deck-building mechanic could just as easily be centered around space warfare, railroad economy or a magical bakeshop simulator. Both sides are important! A large number of games I’ve made have been for specific events or holidays, so I often end up thinking about aesthetics before mechanics – though it is totally fine to go in the other direction as well!
3. Mechanics: The nitty-gritty, the meat-and-potatoes. Simply put, what are the rules? How is the game won or lost? A little more in-depth, how are things accomplished, and how are these indicators of progress/gamestate quantified and represented within the game? Also, what’s the game’s scope – what are the components, when and with whom is it played, and what are the boundaries? Potentially significant actions such as rolling doubles, gaining gold coins, or tagging a tree are only defined by the specific rule(s) that accompany them.
Mechanics are the trickiest part of game design in my opinion, mainly because they really make or break the overall experience. Designers need to be ready to continually revise their rules, often through the exhausting process of iterative rounds of playtesting, analyzing and tweaking. Putting the effort into polishing the rules and making sure that everything is functioning as intended, though, is precisely what it takes to make sure you have a good game on your hands.
Unfortunately it’s basically impossible to playtest one-shot games or events; the best you can do is to try and simulate the experience and talk through possible scenarios with friends, etc. Plan as best you can, and then be ready to learn from the results the next time around…which brings us to part 4.
4. Execution: How’d it go? What went wrong, or right? How accurately did the experience match your expectations? What surprised you? Being able to learn from experience and adapt your design is critical to making good games. This section will vary wildly based on the specific scenario, but there are two important steps that I always make sure to consider. The first is to have a few concrete metrics of success laid out before the game. Instead of asking vague questions like, “was this successful? Did people like it?” try asking, “did at least half the party participate? Did people decide to play again?” Mainly I think this helps make sure you’re being both objective and constructive with your self-assessment. Otherwise, it can be easy to end up judging yourself unfairly in either direction.
The second part is to really step back and listen to people’s feedback – trust the players’ experiences, usually more than your own. They’re the ones who you built this for, and I think designers do themselves a huge disservice by ignoring some types of feedback (again, this could mean positive or negative.) I find this is the hardest thing to do for me personally, because it’s just so easy to become attached to your design. They’re just ‘playing it wrong’! They just don’t get it! But no, remember it’s your job to have your mechanics lead to the intended dynamics (fun included), and it’s important to take note when that doesn’t occur. At the same time, expect people to sugarcoat their critiques – whenever possible, try to find objective playtesters and invite them to be critical. The best feedback I’ve ever gotten was a man at the Game Makers Guild (hosted at Emerson!) who bluntly said, “I hated this game, and here’s why…”
So there it is, a brief overview of the most important core components of game design! Phew, I realize that was a lot at once. I could devote multiple articles to any one of these categories individually, and in fact I’d love to do just that in the future. For now, though, keep your eyes peeled for my first GAME Report: Sneks & Ladders!