Are you a Butt-Kicker, a Specialist, or a Story-Teller? There is a huge world of games out there to satisfy every player’s and group’s style. And while there are academic discussions in every corner of the internet, sometimes it’s best to start at level one. Join the Level One Wonk in exploring the possibilities that RPGs have to offer, from Aberrant to Zorcerer of Zo. Today we transcend playing, running and hacking games, going all the way to designing them! Prepare for a project and grab some graph paper, things are about to get real.
You’ve hacked, you’ve tweaked, and you’ve adjusted. You’ve gotten nearly every game in your shelf houseruled just so, and yet there’s something else itching in your brain. You have a new idea, something that no existing game does to your satisfaction. And you think you can make it fun. These ideas are the first inkling that you’re going to design a game. How can you make it work, though? In order for any design to reach a successful conclusion, you need to define your goals, and have a workable process. And before all that, you need to understand your broader intent, even less specific than any goal of the design. If you are a gamer who wants something specific for their group, I strongly recommend that you stop here and go read more games. The range of games that already exists is quite large, and if you want to play you should be playing. If you have an idea you really want to flesh out for its own sake, or are certain that what you want truly doesn’t exist, then we can continue.
Nothing New Under the Sun
Of course, if you thought you were going to get out of doing your reading, you were wrong. The best thing a designer can do (and indeed, the best thing any creative can do) is expand their knowledge of what already exists. A painter should go to galleries, a writer should read novels, and a game designer should read (and ideally play) games. Reading and playing games is the best way to understand what has already been done, as well as what’s been done that works. Read good games, and note your favorite things about them. Read bad games, and note what makes you cringe or shake your head. If there’s a popular game you can’t stand, read it and note what you don’t like about it. If there’s a game you love that’s the subject of derision (like, say, if the System Mastery podcast has done an episode about it), read it and note what you like and what others don’t. Read games that are nothing like what you typically play, and read recommendations that are rattled off in lists that also include your favorite games.
When reading broadly, you should see a range of mechanics, genres, and styles. Hopefully you will see rules and ideas that work as well as ones that don’t. This is by far the easiest way to avoid design pitfalls; by reading that which came before you should also see the mistakes that have already been made. Identifying mistakes is also a confidence booster: by finding mistakes that made it into published products, you can feel better that you are capable of making something publishable.
Not necessarily after your reading, but somewhere at the beginning of the process, you should have a goal for what you want to make. Start with one high level statement about the type of game you want to make, but then start breaking it down. If you are even a nominally experienced roleplayer, you should have a feel for the elements that you care about in a game. Where you must make a leap is by identifying what you are going to do differently than these other games. You don’t have to write the next Fiasco and throw away the playbook entirely, but buried in your design goals should be your game’s value proposition: the thing that makes your game different than others out there and is more fun for being that way. If we look at Apocalypse World as an example, “I want to write a post-apocalyptic RPG” is likely not a great design goal. That could have led the author to go out and buy The Morrow Project just as soon as write a new game. “I want to write a post-apocalyptic RPG about human relationships and intimacy” is way better. “I want to employ a dice mechanic with three results instead of two” is also quite interesting. Combine those two, and you could imagine a rough design document that could lead us towards what Apocalypse World ended up looking like.
Once you have a broad design goal or two (or three), start sketching out what you think the game should look like. If you think it would work best in an existing ruleset, note that here. If you want to build a ruleset from scratch, this is where you start thinking about the mechanics. Don’t worry about any actual math yet, the mechanics at this stage can be as simple as “d20 plus skill” or “d6 dice pool”. What you want to capture in this stage is how you think the game is going to look, and how you imagine it being played. Write down what you think the most important activities will be, how characters will be designed, and things you want the game to be able to do. When you’re done with this, you should have a few broad goals about the game as a whole and a number of specific goals about things you want the game to include or be able to do.
Now we get to the hard part. Take all those goals you wrote and start filling out a scaffold of a game. At a minimum, you’re going to want character creation and some form of resolution system. What’s important at this stage is to figure out how to best realize those goals you wrote down earlier. What I’m going to recommend here is a business school concept called the minimum testable product. Basically, write the smallest amount you can that gets you to something playable. The important thing to remember there is the middle word, “testable”. It doesn’t take that much work to write up some stats and a dice mechanic, but that’s not worth testing if it doesn’t advance your design goals in some way. So once you have a basic little prototype that highlights at least one of your design goals, grab some friends and roll dice for an hour or two. Hear about what works and what doesn’t. Note places where you can add things, there should be many at the beginning of the process. Return to your design goals, and see if you can make changes that bring the game closer to what you envision. Tweak it a bit, self-test, and then take it to your friends again. You will be testing many times during the process.
Once you have something that incorporates all of your design goals in some way (and is fun to play), you have an alpha. This is still probably fairly rough, and may still have some gaps in the rules, but it should be complete enough that you can play it like an RPG, and even write sessions or one-shots for it. You’ll probably test this with your friends some more, but you’re eventually going to get to a point where they like it. You’ve been tweaking the game with respect to their comments after all, and one would hope they want you to design a game they like. Once your friends like your game, you need to go test it with someone else. Find a game store group, or a group of local game designers, or maybe another friend’s gaming group you don’t know as well. The point is, get some new people to critique your game, ideally people with a different play style than your friends. You’re going to get different comments. You may get contradictory comments. Nonetheless, the feedback you get will help you shape your game further. Once you have something that looks like a complete game, you have a beta. Now it’s time to get some seats at a local con and test your game with complete strangers. As you go through this process, you should notice the critiques you get will become smaller and smaller. As your process shifts from reworking to editing to polishing, you can start thinking about how to make the game look like a final product. Art, layout, and publishing, though, are a whole other animal that are worth at least an entire article on their own.
You’ll notice I haven’t given much advice about the nitty-gritty of design. Two reasons for that: first, there are tons of blogs and articles about game design out there, and many get into the weeds on dice mechanics, play balance, meta-game rules, and so on. If you get into design, you’re going to want to read as many of these as possible (indeed, that’d fall under my first heading). But if you’re just thinking about design and starting at level one, you need to know what the process will look like. That process is an incremental one, with lots of testing, iteration, and re-testing. Second, enumerating game design is the easiest way to build a box around the potential game design space. Even the one structural point I offered (you’re going to want character creation and a resolution system) isn’t followed by every RPG (i.e. Microscope). I personally love those games which dramatically opposed the normal conventions of game design when they were released, including Fiasco and Apocalypse World. If you’re going to create a compelling design, there will be a lot more thinking about what games do not do than what they do already.
From here, the best advice I can give is to go and make that game! Our own Seamus Conneely is in the process of building a science fiction PbtA game called Transit (#TransitRPG on Twitter and Priority Transmissions here!- Ed.), which is in closed beta currently. Loads of active game designers are on Twitter or have blogs, which make for great reading and inspiration when things get tough. And of course, here at Cannibal Halfling we’ll both continue to keep our eyes out on the horizon, bringing news of intriguing games and gaming concepts to you.
Great game design Twitter accounts:
Vincent Baker: @lumpleygames
Jared Sorensen: @jaredsorensen
Fred Hicks: @fredhicks
One thought on “Level One Wonk: Game Design”
Lots to think about, lays it out quite neatly.