Weird Pirates is the working title for a Powered by the Apocalypse game system I am currently developing. If you are unfamiliar with PbtA games and the general terms used to describe them, I recommend checking out Simple World as a primer. While the terms used in this article are specific to PbtA games, this design style can be utilized for any tabletop RPG or video game.

When I started working on Weird Pirates I started with only a few core concepts: play as outrageous pirates, involve fantasy races in new ways, and detail weird science and magic. These, I thought, were the distillation of the game I wanted to work on and play. If everything I added to the game directly supported one of these tenants, I believe I would end up with a solid game that delivered engaging experiences. I wanted to approach designing this game in a way that would allow me to follow these concepts without getting bogged down in writing all the underlying rules and mechanics. While completely necessary for a game to function, they are not the exciting parts, and I set out to design a game by focusing on the interesting first.

The most common approach to game design would be to pick one of those concepts and start fleshing it out. For example, I could focus on magic and write pages of notes about what kind it is, how someone taps into it, and what kind of effects it can produce. There is nothing wrong with this style of design, but by getting into the proverbial weeds, I think you can easily lose sight of your original concept. Instead of starting at the bottom and working my way up, I started at the top. I would only ask the highest-level question I could, one at a time, and design a focused answer.

Before we dive in, I wanted to give credit to Steve Gaynor of the Tone Control podcast. In his episode with Ken Levine, they discussed a method virtually identical to this approach. You can skip to that part around the 49-minute mark. I did some additional digging to see if this was a defined and well-known style, but I didn’t turn up any articles or books. If you know of a more official version of this design method, please let me know.

The First Question

You should put your immediate attention to asking the most important question first. Usually, this has nothing to do with mechanics but rather how you want the game to feel, or a very specific element of the experience. The first question I asked was “what kind of pirates are you?” I came up with a lot of ideas, but I finally landed on emulating the Pirates of the Caribbean movies. I wanted to play in a world where everyone has swagger to spare and the exploits are grand and over-the-top. This inadvertently led to the next question: “what would these pirates do?” I drew up some rough outlines of what it would feel like to employ a crew, sail the seas, and profit through piracy. These would eventually become the mechanics for Crew management, Ship Moves, and Jobs.

The next big question I asked was “how do pirates be pirates?” I started outlining a few playbooks to explore that. I wanted to capture a wide array of possibilities for the world, so I settled on fleshing out six playbooks that included martial combat, ranged weaponry, thievery, social skills, science, and magic. Going into this process, I had not detailed any mechanics for conflict resolution and I wouldn’t until I absolutely had to. For example, when I designed a brawler, someone who addresses every problem with his fists and strength, many of this playbook’s moves focused on improving and augmenting melee combat. In order to actually write these moves, I first needed to know how melee combat worked. Now that I had an explicit question and need, I designed the basic melee move.

Follow the Questions

Using this method, I would simply brainstorm and design features until I had a question. Sometimes that question would be about a mechanic that didn’t yet exist or a part of the fiction I hadn’t thought of. Only then would I spend the time thinking about that particular area and start to define it. In a way, I was less creating a world and instead discovering it. I was writing the game, but the world existed independently of me, and I was just trying to figure it all out.

If this seems completely backward to you, don’t worry, it very much is counterintuitive to traditional design styles. It makes more sense to start vague and create a base upon which to build the game. What I propose is that you should instead start with the specifics. The benefit of this style is twofold: first, you make sure to focus your immediate attention on the special and interesting aspects of your game, and second, it prevents you from ever boxing yourself in. The latter benefit is the biggest; there are a number of times in past designs when I would have an idea for a special or interesting mechanic, but it would break the foundation I had already designed. Instead of leaning into something exciting, I would often temper ideas to fit the existing framework, and this leads to mediocre game experiences.

Revisiting Questions

Sometimes you follow the questions down and down until you arrive at a place you don’t like. If all your high-level fiction and concepts have created a mechanic or function you fundamentally don’t like, I recommend backing up through the process one question at a time and try to answer it differently. If you back up a step and still don’t like the answers you’re coming up with, just go back another step. Eventually, you’ll find an answer that you like and can start down the same path of questions again. You might even find that the new answer prompts a different next question altogether; follow this one and don’t try to force the same path as before. Remember, you didn’t like where it led anyway.

You may also need to reorganize your work from time to time. The questions you ask may be winding and take you in unexpected directions from time to time. After writing a few answers down, take a step back and look at the whole. Ask yourself if everything still ladders up to the core concepts you started with. Identify sections that naturally go together and see if you can combine them, or at the very least put them near each other for easier browsing. This extra step of checking in on your concepts will further prevent getting boxed in down the road.

I hope this peek at my design process has been helpful. If you try out this method, I would love to hear your feedback.

Leave Comment

Your email address will not be published. Required fields are marked *