Design Doc 1.2: Core Mechanics

Design Doc is a series where I design a tabletop RPG from scratch, in public.

I guess the idea is to get myself thinking about how I work and codify some design principles - hopefully into useful tidbits that you can take away and glean something from for your own design and/or GMing :)

*

Last time, we made a mood board. Now we have a solid stylistic foundation from which to make creative decisions going forward.

This time: We're coming up with core mechanics by first asking Big Questions about what mechanics are, why we need them, and what this game even is.

Before we start, I'll reiterate some things I've implicitly or outright said so far:
- this is just one way to make a game
- it's not even the way I always make games, but it's how I'm doing this one
- I don't really know what I'm doing and neither should you
- all creative decisions are ultimately down to my own arbitrary whim

We good? Good.

Let's make a game!

FATE dice?! In my OSR? It's more likely than you think... More on that story, after this.

What's a Core Mechanic?

I mean... simple question, simple answer. There are mechanics that make up the game - these are the core ones. These, along with the fiction, help define the system.

What are mechanics? "The Rules" is certainly a term for it, but in tabletop they're more like tools that are at the GM's and group's disposal. We talked last time about how these can be numbers and things to do with dice, but also words and fictional concepts.

What are these tools used for, then? Well, they're "for" whatever the players want them to be for, in the same way a hammer can be "for" carpentry or setting up a tent or blood sport. I'm just writing a recipe - it's up to the hypothetical chef to adjust to taste, incorporate their own ideas, and entertain their guests.

Having said that, of course a hammer has an implied use - bashing in nails. Different games "want" you to use their mechanics in different ways: storygames want you to use them to give structure to a piece of collaborative fiction; crunchy tactical combat games want you to learn and master them to gain advantage in battle.

This game, in the tradition of the OSR/DIY circuit and the original TRPGs before them, wants the GM to use the rules to help govern decisions - and often make those decisions outright, by consulting the dice as an oracle - as they interpret the outcomes of player character actions within a fictional space. These are the kinds of games I most often tend to play and make, and the best fit for our current ideas.

some of the best RPG mechanics I know

Note: Mechanics on their own don't actually do anything. We're not *actually* making a game after all, that's the job of the people who end up running the system, but we're equipping them with things to make their game out of. Mechanics are the tools we give them, the game-bits.

So, making those tools. Where do we start? I mean, we've confined ourselves to the aesthetic bounds of our mood board so the options aren't completely limitless, but there's a lot of scope. Dice, cards, tokens, dominoes? Let's say dice - ah, but which kinds of dice, used in what way - do we add numbers or make pools or use different die types or put them in a tower and dance around the table?

All solid options. I don't really have an answer here - I just go with whatever feels right. Don't forget your mood board if you need reference for what "feels right" means in the context of your game.

Also don't be shy about iterating: nothing will be right first try, guaranteed. Stick with an idea for now, then change it when you inevitably come up with a better one. Your game is the sum of its parts - scrapping something, even something big like a core mechanic, is totally fine and normal.

making lil baby dice mechanics 

General Overview of ~The Process~ (This Time)

I mentioned I already had a skeleton of a system to work from. The process of coming up with something like that is boring and not useful info for you guys imo so I'll run through it quickly:

- Idea: dice pool where you add dice to be more likely to succeed but also more likely to incur negative side effects
- let's say d6, keep it simple
- putting more effort or energy into something and therefore succeeding but feeling the backlash is a good theme
- let's say the players are psychics, and adding more dice is like using more power/focus
- vague idea of them being psychic because of wi-fi and fighting computer viruses or something
- I'm bored of this game and don't know what to do with it
- work on other projects for several months
- oh yeah that thing
- change around some basic concepts (d3 now, cyberpunk setting)
- remember I can't do maths so check google to see if the probability works ok
- yeah sure, looks good, I guess, I mean what do I want a medal
- iterate, iterate, test, wing it, test
- core mechanic

The main question at every stage is never mathematical for me, I'm writing a book not assembling a machine. The only question that matters is "does it feel right?". Again, no one answer here. Use your mood board for guidance. Play games, enjoy them (or not) and think about why, study them, hack them, take them apart and look at the pieces.

If you've GM'd an RPG before, you're already a game designer and have all the necessary skills to make your own. Trust those instincts.

The Players, here represented by the cast of everyone's favourite d&d show, "talky white friends"

Big Picture Stuff

So, our mechanic. I'll get to it. First we're going to zoom out a bit.

The dice roll or whatever being a "core mechanic" is actually a bit of a misnomer, I think - the true core mechanic of any tabletop RPG is the group playing it. Their brains, their imaginations, their interpretations. Their interpersonal relationships and collective communication skills.

The book is just a set of language tools you give them to use. Whatever mechanics we end up with will be just another tool in the arsenal of the actual engine driving the play experience: people. RPGs are people games. Don't lose sight of that.

So before we go further, let's address the real core of the game: the players. Who are the players in your game? How do they play? Why do they play this game?

For most RPGs, the answers to these questions are very similar. If we get specific and look at traditional, challenge-based RPGs (the genre we're working in - remember the mood board), the answers will be almost identical across all games.

Who are the players? A group of friends. (I'm not just writing this for my own group, so I'll specify - not necessarily my friends. I don't know them, but they should know each other.)

How do they play? They have a conversation. One person describes a fictional reality, and the others each control a character within that world. They act, the GM reacts, and the situation progresses.

Why do they play this game? To have fun imagining and solving problems using creative thinking, within the confines of a fictional world.

This is super conceptual shit, I know! Basically, all I'm doing is asking "why" to everything and going with the answer that I like best, until I get a model in my head of how I reckon these games function. That model is then a useful reference for making my own.

Ask yourself these questions if you want. Form your own opinions and you'll have your own model to work from.

Let's talk characters. Like this guy, from 5e D&D

From Players to PCs

Ok, we're really zoomed out right now. That was some fairly umbrella-level Game Design stuff.

Let's ask some more game-genre-specific questions about our players. Two questions in particular actually, and the most important things to know when designing this kind of game.

Q1: What do the player characters do?

Not being able to answer this question was actually why I lost interest in the system initially. It's such an obvious, big thing - all of this stuff should be pretty obvious - but if you don't have answers to these questions then neither will anyone else, and your game won't work.

Q2: How do they do it?

Both these questions are inextricably tied to your game's fiction. If you don't have that mood board nailed down, your answers are going to be vague, noncommittal and incoherent, and, again - your game won't work.

Make sure you're in a position to answer these questions, and by and large stick to your answers throughout development, before continuing.

Our hypothetical player character. What's he up to?

Core Gameplay

Let's answer those questions then.

What do the player characters do? As I said - this was a struggle for a while. I settled on a tried and true classic - they're skilled mercenaries, looking to survive. This was touched on in the fluff on the ol' mood board - it's standard RPG fare.

Player characters have unique talents and abilities that make them valuable in solving many of the dangerous problems the world around them presents, and so - by choice or no - they take it upon themselves to do so.

Basically, they "adventure".

How do they do it? The fun bit. This is the behaviour we're going to be expecting (and therefore should try encouraging) from our players as they act through their PCs.

First, I'll introduce you to a fictional concept that sprang from the mood board. As I've said, what order the ideas come in - fiction, mechanics - doesn't matter, and the lines are blurred. Mechanics came first here. I just think it'll be easier to explain it fiction first.

This needs its own section actually. More after the jump.

it's-a me, a legacy of ingenious game design

Recall our fluff. Everything is connected wirelessly, and so by logic - at least by movie logic, my favourite kind - everything can be hacked. I mean... cyberpunk. The method most commonly at our PCs disposal, as well as special class abilities, is the Troubleshooter. Basically it's a fictional excuse to use two of my favourite mechanic types, Hit Points and attack rolls - albeit in a new context, with some significant changes.

So, uh, these are guns that shoot... "bullets of hack". Like, you need to learn how to use them in-fiction, tune them up in the manner one toys with a sonic screwdriver or taps panels on the Star Trek bridge, to align them with the tech you're aiming at. Then you shoot, and on a hit, you overload its wireless receiver, kinda DDOSing the chip and forcing shutdown while it waits for reboot. You use Pantheon's method of control - wireless signal - against them.

Why?

I like the idea, and it's fun. It's also hugely gameable. This is the meat of our recipe.

Sidebar: "gameable"? Qu'est-ce que c'est? A favourite vocab nugget of the DIY contingent. Here's a crash course if you're unfamiliar: consider Mario. Mario can walk, or run, or jump. Basically, he can move. That's the mechanic - the only mechanic, actually.

Is Mario's movement a "gameable" mechanic? Yes - incredibly so. His movement can get him across the level towards the goal. His movement is how he avoids obstacles. His movement can get him into specific spot to grab collectables and powerups. His movement gets him on top of enemies, which are designed to be defeated from above.

So, the Troubleshooter then. Gameable? Well, I'm no Nintendo, but I like to think this is a good idea. A cyberpunk city, full of tech including its residents, with everything wirelessly connected. The primary mechanical interaction being a gun that shuts down tech? That's pretty darn gameable:

- Door's locked! Shoot it.
- Laser grid! Find the control panel, shoot it.
- Armed guards! People all have neural chips, remember? Shoot 'em. (It's like a stun gun - they drop unconscious while the tech part of their brain restores its backups.)

That's not even getting into class abilities - but I'll save those for later. The bell's about to go. You've been good and sat quietly throughout class, so here's that mechanic you wanted. It's our "attack roll" for the Troubleshooter, and a unified skill check too, because I love you and want your life to be easy.

Look at me. Reduced to memes.

"When a player character attempts an action that has a chance of both success and failure, and either would develop the current situation in a way the group finds interesting, the GM calls for a roll. Roll a pool of d3 (1-3, based on skill level in task). Any number of 3s is a success - a roll without 3s is a failure. Players can add additional dice based on class abilities - but when doing so, any 1s cause Overload. The player notes accumulated Overload points on their sheet - break the character's threshold and they shut down."

See? Pretty boring in the end. Roll some dice, they do a thing. The fun bit is all that work we did to get here - and that's what will come across in play.

So, yeah - next time, more mechanics: Class Design.