Your TTRPG Design Principles?

[Lanefan]

@kenada

In your 12, should "#9" actually be "#11"?

And in your 14, should "#9" and "#10" actually be "#11" and "#12"?

I think (but could be wrong) kenada is saying that the unified mechanics of the system (#9) can be leaned on to help with generating a living world (#12) and reducing prep (#14); and that a rules-not-rulings principle (#10) helps limit the prep (#14) as the mechanics ideally help the game at least in part run itself.

I can see the reasoning behind the reducing-prep piece - if everything neatly slots into the unified mechanic, prep does become simpler - but I fail to see how the mechanics can help generate a living world unless that world is rather stilted.

 

[kenada]

@kenada

In your 12, should "#9" actually be "#11"?

And in your 14, should "#9" and "#10" actually be "#11" and "#12"?

Nice catch, thanks. I had added some items to the list but failed to adjust references when the numbers changed. It’s fixed now.

 

[kenada]

I think (but could be wrong) kenada is saying that the unified mechanics of the system (#9) can be leaned on to help with generating a living world (#12) and reducing prep (#14); and that a rules-not-rulings principle (#10) helps limit the prep (#14) as the mechanics ideally help the game at least in part run itself.

@pemerton had the right of it. I’d moved some stuff to the top of the list without adjusting references, which created a couple of off-by-2 errors.

I can see the reasoning behind the reducing-prep piece - if everything neatly slots into the unified mechanic, prep does become simpler - but I fail to see how the mechanics can help generate a living world unless that world is rather stilted.

One of the reasons why I post recaps in the 5-words commentary thread is to provide actual play examples of how the system works.

The event and factions stuff is still highly WIP, but I know it will lean on existing mechanics including progress clocks. The purpose of these mechanics is to manage discretion.

For example, when the raiders were looking for the PCs, there was a clock tracking when they were found. I created it as a consequence for the PCs’ actions. By having it put to system, it can be integrated with other mechanics, and it takes the decision away from the GM except as the discretion to incorporate it is managed.

What I want to avoid is my deciding that the raiders catch the PCs even though the PCs have taken steps to hide and lose their interest. The system will take care of that and indicate when decision-making is required.

The way “living world” will be realized is by having a lot of these processes (probably via clocks) going at a time. For example:

• A fire dragon has been sighted in the area. The PCs know it’s coming (via obtained intel) but not when.
• Natalia, a vampire friend, wants to create more vampires. Deirdre (the barbarian PC) is not happy about that and has killed one already.
• Natalia is investigating the death of one of her spawn. If that clock is filled, she learns the answer. If it is emptied, the trail goes cold, and she loses interest.
• A occult researcher (i.e., vampire hunter) is due to arrive in town soon. His investigation into the sightings will create many clocks involving Natalia.
• The PCs fought and defeated the raiding party that was pursuing them. The raiders (a larger group to which they belonged) will be attempting a different tactic to force a parlay.

Plus more as play requires (e.g., the threats in the PCs’ settlement’s hex should probably be a source of events or clocks). Dungeon factions would also fall under this framework as (probably) dungeon (re)stocking (e.g., you return to town for month or two, and a necromancer moves into the dungeon in the meantime).

Essentially, the world exists in a status quo until the PCs go out and start doing stuff. If there is some event that is already happening, it can be started off in the framework (but it should be something that will affect the PCs’ lives, or it’s just setting flavor). Putting it to system and managing discretion means I can play things as hard as they require when they come into play.

I expect the fire dragon situation to be potentially explosive. The Natalia situation is potentially very messy. The PCs have their own (individual and group) goals they are pursuing. All these things may come into conflict, and the PCs will have decide how to respond when that happens or accept the fallout when things happen outside of their control. It’s this dynamic that creates the sense of “living world”.

The PCs can also undertake large scale projects to change the setting. They’ve staked out a road to their settlement and have been working to build it up as a base of operations for an eventual foray into the fallen capital in the center-ish of the swamp to the north.

 

[Celebrim]

Wow. This one could generate multiple essays and I don't have the time. Very brief stream of consciousness here:

Character Generation - Class based is superior to point buy in most cases because it forces breadth on the character's being created, but classes should be "soft" in that within each class there is enough variety that you could have a party with every PC of the same class and not have a lot of overlap. Character Burners are fine provided they give sufficient choice over the character creation process. Randomization is fine as long as all resulting characters are interesting to play and you aren't just forcing a player to go through the ritual of making multiple characters before they have one that they want to play. The important thing is to give players choice within a system that constrains them to making characters that aren't Johnny One Trick hammers that treat all problems as nails. Despite restrictions created by the class system, the character generation system should reasonably provide for the creation of every character that could inhabit the shared reality, with the only limits on the player's imagination being how far that character has advanced in his skill or resources.

Character Advancement - Ideally, characters should get better at what they actually do. Levels or perks or skill increases however are all fine depending on what you are going for, but again, the leveling process should be constrained so that players are encouraged to gain broadly rather than focus on one specialization.

Wounds - Hit points are the superior model for tracking wounds in almost all cases, but it's also usually necessary to be able to inflict long term statuses on the player to represent hinderances. Hinderances should be removable or minor, or both, irrespective of whether that is realistic because in a social game being put out of play sucks. Exactly what statuses you need depends on the system and how much granularity you are going for in game. A light game might have all hinderances represented by blanket increases in difficulty whereas a heavy game might have tailored hinderances that represent specific wounds, ailments, poisons, etc.

Fortunes - Linear fortunes from a single dice are superior to dice pools in almost all cases because the math is more intuitive and less likely to go wrong. Regardless of whether you use dice pools or linear modifiers to represent skill you also need adjustable target difficulties to represent the degree of difficulty of a test. There should always be a point where a skilled character becomes reliable at doing what was once hard or even impossible for a less skilled character. Critical success or critical failure or partial success should never be assumed as a universally applicable outcome of a task. For the most part that does not help a game, but to the extent that it does it should be applied judiciously to those tests where such outcomes can be defined in a rigorous manner and are reasonable to test being tried. Fortune resolution should involve as few of steps as are necessary to achieve the intended result.

Skills - A skill system should be:
1) Space spanning - Does everything that a character would try to do have an obvious choice of a skill that would cover it? This is pretty obvious. Players should be able to tell from the skill list what sort of things they'll be called on to do, and whatever the players attempt should have some sort of skill that covers it.
2) Discrete - Does each skill represent a truly separate area of skill? Skills should not overlap, nor should a skill be built around something that can also be covered by a combination of other skills such that a person who has all the skills we would expect going into doing X find themselves unable to do X because it has its own skill. For example, if 'Knowledge of the Law' is a skill and 'Bargaining' is a skill and 'Oration' are skills, then Lawyering probably shouldn't be a skill. Lawyering should probably in such a situation be a 'Feat' or 'Trait', ei "Gain a bonus to skill use when you use them in in a professional legal situation." and not a replacement for the discrete skills themselves.
3) Independent - This is like discrete but is the additional test that advancing each skill is not connected to another one so that it makes sense that you could advance one without advancing any of the rest. For example, I very much dislike it when a system has a completely separate skill for using clubs, hammers, and maces as weapons. It doesn't feel to me sensible that I could get very good at using a baseball bat as weapon in combat and advancing that skill would not make me more comfortable with a mace than a person who had never held a swung bludgeoning weapon of any sort.
4) Balanced - Does each skill represent a reasonably broad area of knowledge that is likely to be a reoccurring test for the character? It's better to assume that broad knowledge exists even when that's barely reasonable than to silo off skills like "Use Parachute" and "Botany" and "Foward Observer" that might rarely be tests in your game. This of course depends on the intended gameplay. "Latin" might be perfectly reasonable in one game, "Dead Languages" in another, and just "Languages" in a third depending on how much testing speaking dead languages is part of the game. If your game is intended to be generic, then the skills should err on the side of being broad, and have perks to specialize and rules for dealing with when an character uses an unfamiliar tool. The more generic your system is, the fewer skills it should probably have.
5) Immersive - Skills are not actually completely congruent and interchangeable. Depending on how you select for skills some of them will be more pass/fail and some of them will be more degree of success. Some of them will be highly random and unpredictable and some of them will have much more predictable and reliable results constrained to a smaller range. Do not blindly assume you can have a single fortune mechanic represent all skills. This brings me to the last principle:

Modularity: An RPG is actually a collection of minigames. It's not possible to design an elegant system that covers all possible minigames. Wherever one system fails at a minigame, it should leave room for a different perhaps even completely different resolution system. For example you may decide that turn based combat simplifies the tactical skirmish minigame that is important to your intended gameplay, and that's fine but as soon as you do that then you have to consider how to handle a situation like a chase seen that needs you to simulate continuous motion. It's OK to have two completely different ways of tracking movement available in the toolbox for the GM if that would be simpler and more elegant in play than having one convoluted impulse or fractional movement system for simulating continuous simultaneous movement. Likewise, you don't need to treat artillery as just a bigger weapon. Characters can dodge character scale and non-characters scale weapons by completely different means and that's OK. The trick is in figuring out how to be elegant in both cases. However it is not acceptable to imply some intended minigame - say combat on the high seas in a Pirate RPG - and not actually have a fun and elegant minigame for doing that that is succeeds in all the other design principles I've mentioned. If you have important minigames missing from your base game, that should be a priority in future rules expansions.

There is no such thing as Rules Light: A rules light system is just a system that intends to fail or at best intends only to succeed as a casual game suitable for one shots or even just playing once. A game can either intend to be rules moderate or rules heavy, but if it is rules light it's just a rules moderate game that is trying to get its toe in the market.

 

[Breaking Star Games]

Beyond the overall goals of being fun, interesting and meaningful. I really like:

• Collaborative Storytelling is the focus. Whether that looks like your traditional sandbox and prep for your next session or PbtA's Play to Find Out - I just want the players' contribution to be a large part of the narrative. And the GM should have tools to ensure this.
• Mechanical complexity/crunch had better be well worth it. I can enjoy Pathfinder 2e's relatively high complexity because it makes a great combat system. But there are many examples where this isn't the case and I'd much prefer a simple fast-resolving mechanic like how a PbtA Basic Move brings you back to the fiction immediately.
• Focused and evocative in its themes/genre. It should reward players for fitting into these. I like reading and learning lots of systems, so its rewarding to have a set of specific tools for specific jobs than a more wide-ranging/generic system that acts like a multi-tool.
• Hard Choices - probably best seen in games with Yes, But results. Its not necessarily interesting to just see if the PCs succeed or not, but rather that its interesting to see how much they are willing to pay to succeed. The more this is built into the game rather than GM fiat, the more fun it is

Its pretty oriented towards narrative and especially PbtA games, but they tend to just codify my preferred GM style harder. I really enjoy lots of systems from ICON to Orbital Blues to Swords of the Serpentine that work with a very similar GM style.

 

[clearstream]

My youngest son and I have written some home RPG rules that we are using in our current campaign. The organization is a train wreck, much of the game is derivative, and in short it's a glorious mess. But, we are having a lot of fun.

We came up with some design principles for our game:

1. Character creation should be simple.
2. The experience system should create lots of hard and interesting choices for characters. It should be far more complicated than character creation.
The idea behind the first 2 goals was to create something that is simple to learn, but increases with complexity as you play it - much like chess or bridge.
3. The magic system should not be predictable and have an element of danger for the user.
4. Heavily skill-based game.
5. Use percentiles, (I know this is a dealbreaker for lots of folks), so that players can quickly ascertain their chance of accomplishing something.

I am not asking for you opinion on our design goals - although you are certainly welcome to do so.

I am more interested in what your design principles for a TTRPG would be?

My basic principle will unfortunately not apply well to your situation, but it's - aspire to create something new.

In most cases that means a novel synthesis or subjecting untrammeled material to treatment as a TTRPG.

 

[Emberashh]

Don't be afraid of or prejudicial towards resources talking about video game design.

Game design is a lot more universal than many are willing to give it credit for, and the fact that most writers are aiming for the more financially lucrative video game industry doesn't mean their insights do not apply to tabletop games.

You just have to be cognizant of what you're reading and be prepared to adapt things to the medium, which typically just involves focusing on runtime practicality; ie, making something viable to run by hand. Whether thats still relatively crunchy or not is a matter of taste.

 

[timbannock]

Outside of specific system/mechanics stuff, here are some really, really important ones:

• Include a "Your First Session" chapter, split into sections for the players and the GM. Discuss the procedures of play.
• Include both player and GM principles and agendas so it's clear what "good play" in the game looks like.
• Include topics to cover in session zero.
• Once the text is complete and the layout is set, your job is not done! Create a solid index, and if needed, an additional glossary.
• Your text is not complete and your layout is not done until you have a 1-4 page "cheat sheet" version of your game with the most oft-referenced materials. (Think of it as the rough draft for a GM screen, if nothing else.)
• Include a starter adventure, but don't forget to include ideas on how to expand that, how to devise future adventure scenarios, and perhaps ideas on how to make adventures re-playable.

 

[Robin F]

One principle I try to live by is that every room in a dungeon should have something interesting in it. It doesn't have to be something you can interact with, but it should at least be something that adds to the atmosphere. No empty rooms!

 

[Lanefan]

One principle I try to live by is that every room in a dungeon should have something interesting in it. It doesn't have to be something you can interact with, but it should at least be something that adds to the atmosphere. No empty rooms!

In a crowded or well-used place, sure. But in a deserted complex, or one that has just a few occupants but can hold hundreds? Doesn't make sense.

I've written and run dungeons on the premise that the whole place is empty*; the party's mission being to either map it as a training exercise or find out what became of the last group of adventurers who went in there and haven't been seen since.

* - and when they get there, most of it - but not all! - is in fact empty.