The general question for this thread is I guess what the order of decisions is when designing an RPG?

I have my own current thoughts on this, which I guess follow on from The Traveller's "Rules As Tools" thread awhile back where he suggested thinking about how rules had 'dependencies' between them, to use as a place to start.
I've tried drawing a map of the common links between chunks in an RPG to see how each of these things interacts with the others, which I guess is a clue on where to start.

The 'arrow' means that a choice before the arrow limits what choices are available after the arrow (dependency). (Even though when building a game, someone might start after the arrow and work back to find what works).
In theory what the hardest bits to design should be where lots of arrows are pointing e.g. Hit Points, although I'm not sure that passes a basic sanity check  :confused:





Some terms here:

*By attribute/derived attribute/skill based I mean whether the game mainly uses mainly stat checks (like Warhammer 1E/2E, Tunnels and Trolls, Amazing Engine), OR mainly skill checks (BRP or White Wolf) or probably-level-based numbers adjusted by stat (AD&D, Gamma World 4E).

*By 'safety valve' I usually means if characters get luck points, hero points, willpower, any sort of bennie point to boost a roll or resist damage....you could think of Resurrections or whatnot as serving a similar job in some games, though.

"effect" means the rules for how successful a task is. "Damage" is often a particular form of effect, it could also mean how long a spell lasts or how far the character could throw something or whatever. It could be determined via counting successes or rolling on a table or whatever.

The line marked 1. is an unusual connection between core system and skill list you get in some games. If all rolls have to be [stat+skill] for instance (One Roll Engine), or if a stat roll is much more likely to succeed than a skill roll (BRP i.e. Runequest), then the core system demands a number of skills be invented to fill in those holes and so is directly affecting the skill list.

I've also colour coded rules modules based off how they affect the gameplay, primarily. IMHO damage system/ HP system affect lethality, advancement and effect influence how competent PCs are, and 'safety valve' or major decisions affect both.

Its missing decisions about scale, such as movement, weapon ranges and the like. Which I have always found pretty major.

The diagram is missing an important starting point.

Ultimate Objective of Play.

What is the purpose of the game? What core activity is the game representing?  ALL further decisions should be in service to this core objective.

Is the game primarily about roleplaying a character in a fictional environment?

Is the game primarily a vehicle for creating shared fiction?

Is the game primarily about replicating the kinds of adventures found in particular source material? Ex: action movies, comics, pulp, etc.

Is the game going to be focused on gaining power and influence or will these be merely a side effect of ongoing play?

These questions, once answered, will provide the large scale vision to build the particulars on. You will know from these answers if your game will include
narrative mechanics or not, give you a rough idea of the the role of the GM, and tell you if rules that enforce genre tropes in general, will factor into the design of the game.

The mechanics themselves will fall into place a bit easier if these questions are decided upon first. After all, why worry too much over design elements that are peripheral at best to your goals and objectives for the game?

Just some food for thought.

Yep that all makes sense, thanks.

I'm bad at noticing those sorts of considerations since my answers to all of them are pretty fixed regardless of what I'm designing (I would never set out to build a "shared narrative GMless game"). I guess it can be useful to realize others start from different places though.

I think you first need to decide what type of setting you're designing for.  While it might be possible to create a set of flexible rules that can easily be adapted to a variety of settings, it's easiest to start with a clear sense of what you're building for.  If you want a Tolkien-esque fantasy setting, you've already got a sense of the type of actions you need to model.  

Even when you know what you're aiming for, you need to have a sense of the 'action scale'.  In D&D and similar systems, each roll corresponds to roughly a single action; you attack (make a roll).  It's absolutely possible to abstract action much much more generally - you fight an enemy (make a roll).  

If you're looking at a type of fantasy game with a scope of action like D&D (where people will say 'I swing my sword' as an action type) you're going to get a lot closer to knowing how to proceed.  

There are a lot of additional considerations to make, but a lot of things you're going to decide will stem from that.  For example, if you abstract all combat to a single roll (rather than attack rolls and damage rolls), you're not going to have to deal with fiddly things like specific weapon damage.  

Perhaps before (or simultaneous) to these decisions will involve what kinds of things you want to happen.  If you want people to get stabbed with swords in gory detail, you're probably going to want blow-by-blow combat.  If you're trying to create a system that can do anything people in the real world do, you'll need lots of realistic type rules.

Sorry for the double-post.  I've just been reading your post and links on the Cover Art thread, so this is probably relating to Deep Blue?  

One of the first questions I'd ask myself if I were designing the game is how I see characters interacting with the world.  You mention submarine combat - ship based combat is hard to involve every player.  Imagine what you'd like players to be doing during the game, and that'll answer a lot of your design questions.

Quote from: deadDMwalking;716286Sorry for the double-post.  I've just been reading your post and links on the Cover Art thread, so this is probably relating to Deep Blue?  

One of the first questions I'd ask myself if I were designing the game is how I see characters interacting with the world.  You mention submarine combat - ship based combat is hard to involve every player.  Imagine what you'd like players to be doing during the game, and that'll answer a lot of your design questions.

I think you may be getting me and The Traveller confused - I think Deep Blue is his game? I did refer to some things he'd brought up in the OP.
Myself, I'm not working on anything entirely particularly tangible myself at the moment. Typically I'd be working on some sort of fantasy RPG, though I did design a  superhero RPG ages back.

Quote from: deadDMwalking;716284I think you first need to decide what type of setting you're designing for.  While it might be possible to create a set of flexible rules that can easily be adapted to a variety of settings, it's easiest to start with a clear sense of what you're building for.  If you want a Tolkien-esque fantasy setting, you've already got a sense of the type of actions you need to model.  

Even when you know what you're aiming for, you need to have a sense of the 'action scale'.  In D&D and similar systems, each roll corresponds to roughly a single action; you attack (make a roll).  It's absolutely possible to abstract action much much more generally - you fight an enemy (make a roll).  

If you're looking at a type of fantasy game with a scope of action like D&D (where people will say 'I swing my sword' as an action type) you're going to get a lot closer to knowing how to proceed.  

There are a lot of additional considerations to make, but a lot of things you're going to decide will stem from that.  For example, if you abstract all combat to a single roll (rather than attack rolls and damage rolls), you're not going to have to deal with fiddly things like specific weapon damage.  

Perhaps before (or simultaneous) to these decisions will involve what kinds of things you want to happen.  If you want people to get stabbed with swords in gory detail, you're probably going to want blow-by-blow combat.  If you're trying to create a system that can do anything people in the real world do, you'll need lots of realistic type rules.

On the main point..using one roll for fighting would be pretty unusual since it makes fighting someone a save-or-die situation unless characters can spend resources to boost rolls, or death isn't the outcome of losing a fight. If its a design objective that the PCs try to avoid combat, maybe.
I do get your general point that there's a range of different levels of abstraction possible. Wish I could jam it into my diagram but it seems to be a consideration that reappears over and over at each point.

Ever seen the episode of Red Dwarf where Rimmer needs to study for his Astronavigational exam and spends so much time coming up with colour-coded charts and organizers for the most effective way of studying that he never actually gets around to studying?

Quote from: Bloody Stupid Johnson;716290I think you may be getting me and The Traveller confused - I think Deep Blue is his game?

Yep.  It was late, and your avatars (while looking nothing alike) both have a lot of yellow in them.  The excuse is weak-sauce, but that's all I got.  

Quote from: Bloody Stupid Johnson;716290I did refer to some things he'd brought up in the OP.
Myself, I'm not working on anything entirely particularly tangible myself at the moment. Typically I'd be working on some sort of fantasy RPG, though I did design a  superhero RPG ages back.

Good to know.  In a fantasy type situation, we generally expect that characters will interact with the world directly - their actions and abilities are used to directly resolve obstacles.  Unlike, for example, a starship RPG where the technological abilities of the starship are usually used to solve problems and each player needs to interact with the ship in a tactically interesting way.  

Quote from: Bloody Stupid Johnson;716293On the main point..using one roll for fighting would be pretty unusual since it makes fighting someone a save-or-die situation unless characters can spend resources to boost rolls, or death isn't the outcome of losing a fight. If its a design objective that the PCs try to avoid combat, maybe.

I'm not at all recommending it as a resolution mechanic, but if fighting is minimally important, you can reduce the scope. Presumably if you went that way you'd not have 'death' as the main result of a lost fight.  You've identified that hit-points will flow from a number of design considerations.  Since it sounds like you're looking at someone taking multiple individual sword swings to resolve combat, you're going to be looking at hit points that scale with how many sword-blows a person can take.  If you want a very deadly game, you wouldn't even necessarily need scaling hit points.  

The issue that comes up at this point is really 'tactical complexity'.  Do you want people to say 'I swing with my sword' and figure the character will attack in the most optimal manner or do you want the player to say 'I stab toward his head, but quickly reverse into a feint.  I lunge forward striking low and stabbing at his gut'.  

Quote from: Bloody Stupid Johnson;716293I do get your general point that there's a range of different levels of abstraction possible. Wish I could jam it into my diagram but it seems to be a consideration that reappears over and over at each point.

Absolutely!  Different games abstract different parts of the games in a different way.  For example, D&D only minimally abstracts tactical combat, but it greatly abstracts hit points and healing.  D&D usually abstracts overland movement to a fair degree, but movement within a dungeon is much more concrete.  

All of these kinds of considerations will influence the game.  Areas of high abstraction are usually less interesting, but quicker to resolve.  If you add too much concrete detail to an area of the game that was never interesting to begin with, it will become tedious.  Nobody wants detailed rules about how difficult it is to get out of bed on a cold day.  

Personally, I think it's not a bad idea to say 'I really want a game like X but with a lot more of Y and Z'.  For example, 'I really want a game like D&D, but I want a lot more cinematic combat and dramatic stunts'.  That can give a useful comparison for your design decisions.  If your proposed mechanic is worse than your proposed system or is worse at what you want more of, you can quickly identify it as 'bad'.

1. Is it for beginners or pros? What play styles will it support?

2. How long will the game take? How is it structured (adventures, hexes, levels/tiers, scenes, combat/non-combat, intime days...)

3. Is there a player/GM split? If so, how does it work in detail? Are there assumed roles (tank, damage dealer...) or responsibilities (Lab GM, Shadowguide).

4. What themes and patterns do you want to have in the game and which do you turn into mechanics? For example, if honor is important in your game, you can make an Honor stat. But you can certainly make honor important in your game without doing so. In the same way you can have a game without a Strength stat, even though people smash bad guys and carry away loot.

5. If you are sure what kind of things should have rules, determine what stats you need (if any). This is not the same as the last question because you might encode a single concept with several stats or a function of several stats. What do you call the parts? Is it Honor or Fides? Strength, Brawn or Earth Affinity? You can set the tone of your game here.

6. Where do you want to use random elements, if at all?

7. What props will be used? Dice? Maps? Character sheets? Beeds for counting resources? Custom designed playing cards? Stupid hats?

8. What are the keys and slots, like if you have stats some effects can modify them. Which kind of effect modifies what stat? If you have a dice pool system, you can change number and size of the dice. Which do you use? If both, what does each represent? Are there re-rolls? What about stacking?

9. If there numeric stats in your game, what are the scales? What do they represent?

Quote from: Exploderwizard;716221The diagram is missing an important starting point.

Ultimate Objective of Play.

Yeah.  That's what I was going to say, but Exploderwizard beat me to it.

One thing that I often find useful, and have used in video game design, is to create a sample transcript of play, noting decisions the players are making (and the factors going into them) but *not* the specific mechanics or numbers.  It's a good way to get a feel for what you want the game to "feel like" before you get bogged down in specific mechanics choices.

This can then serve as a guide towards if your mechanics are generating the type of gameplay you're interested in.

Another thing that's worth thinking about is who you're making the game for.  Many decisions may be made one way vs. another depending on the intended audience of your game.

Thanks for all the answers guys.
Duly noted and I'm definitely learning some stuff.

Whoa, just spotted this thread now. Absolutely awesome! This is pretty much exactly what I had in mind with "Rules as Tools", and it illustrates the difference in mechanics between what you're doing BSJ and what I'd normally do.

Most enlightening, for example I don't derive hit points from attributes so there's no connection there for me, and I'd normally start out with the core mechanic (as a baseline physics engine) and build everything from there, so it wouldn't be dependent on anything.

Fascinating, but I think people might be taking this as a complete guide to designing a game, which it wasn't meant to be, at least as originally put forward. It's more like a blueprint of the mechanics, so a designer can see at a glance which cogs and gears fit together, and how. This is purely mechanical.

From the GM's perspective it's an invaluable tool to help guide modding and houseruling, you can quickly tell what else down the line is going to be affected if you change rule X. In a hobby where houseruling is a common feature, it's quite handy.

Quote from: deadDMwalking;716284Sorry for the double-post. I've just been reading your post and links on the Cover Art thread, so this is probably relating to Deep Blue?

One of the first questions I'd ask myself if I were designing the game is how I see characters interacting with the world. You mention submarine combat - ship based combat is hard to involve every player. Imagine what you'd like players to be doing during the game, and that'll answer a lot of your design questions.

Yeah parties got a bit muddled up there. I typically embrace the open ended nature of RPG activities by trying to represent reality as much as possible, then bolting on genre emulation mechanics afterwards.

If I was going to do a horror game I'd include a sanity mechanic. If I wanted pulp, I'd double or triple the hit points. Adding on or taking away skills and benefits is a very easy way to emulate genres or themes, since nothing is dependent on them.

I find that starting out with rulesets built around one genre can be fun but it breaks down if the players want to explore other elements of the game world, or do things in a way the game designer hasn't foreseen, whether the designer wasn't aware of that aspect of the genre or didn't care.

This is what I call the humansize problem. It's really easy to design a neat balanced game that only features humans, your variables aren't going to swing much one way or the other, you're only operating within a very tight band of probabilities. This is a humansize (genre or theme-specific from the ground up) game, and it mostly works by ignoring or eliminating options for character activity.

It's much more difficult to build a game where outsized monsters need to be accounted for, or humans versus cars or whatever. The more options you provide, the more that can go wrong. D&D deals with the problem via levels, which are a hack intended to make humans as powerful or more powerful than even tremendous monsters, which to my mind is a stand-in for player and character ingenuity. But, it works in that context.

My general philosophy is that one should focus on letting players and GMs do anything, because that is exactly what they're going to do anyway, and they can narrow it down themselves then if they like.

Providing the tools to help narrow it down in as easy and straightforward a manner as possible is therefore very desireable.

Quote from: The Traveller;716533Whoa, just spotted this thread now. Absolutely awesome! This is pretty much exactly what I had in mind with "Rules as Tools", and it illustrates the difference in mechanics between what you're doing BSJ and what I'd normally do.

Most enlightening, for example I don't derive hit points from attributes so there's no connection there for me, and I'd normally start out with the core mechanic (as a baseline physics engine) and build everything from there, so it wouldn't be dependent on anything.

Fascinating, but I think people might be taking this as a complete guide to designing a game, which it wasn't meant to be, at least as originally put forward. It's more like a blueprint of the mechanics, so a designer can see at a glance which cogs and gears fit together, and how. This is purely mechanical.

Yep!  
Actually drawing it out like this turned out to be a big help - helped me find one spot where I was trying to make gears turn in opposite directions simultaneously. Part of my issue was trying to pick the best core mechanic, based off various goals in all sorts of weird places through the system, so it helped me pick best fits for other things as well. I'll maybe start some sort of thread on my new project soon.

When I drew it I was trying to do a map for any RPG, though it probably does show a few of my mechanical idiosyncracies (wanting effect measurements when many RPGs don't have any real system for these, liking systems where damage comes straight off CON). You might be right in having attribute scale depend on core mechanic rather than vice-versa, to explain when I did it was thinking about (for instance) how games likely to be massive in scale probably shouldn't use dice pools. Most core mechanics could be fitted to most attribute scales via changing how modifiers are calculated though.