Failing Forward

[grendel111111]

I really like this idea of classic D&D. Everything you do matters. If you pick a lock and fail, that is time spent to buy more enemies to kill you. That is a fail-forward system in theory I think. Because even failing a check changes the board. I imagine it's kind of hard to actually maintain that system because it requires a lot of tracking.

Over arching interconnected systems are things I like to see in games, but they always seem doomed to be broken in a tabletop game. They are hard to keep track of and the incentive to cheat for a good story is so high.

I think cheating for the "good story" is actually part of using tables. They give you a start point in creating things happening around the players that are not dependent on the players and even early D and D rule sets, that had lots of tables, suggested using them as sparking of points, and ignoring results that don't fit.
The idea that it can't ever be a truly objective and totally impartial, isn't really a problem for people who enjoy that style of game. The attempt is still worth it, for them.
It would be just like saying that in D and D we will never tell the perfect story so we should just abandon trying to have story in our games. If being impartial is a key enjoyment part of the game for you, then it is worth pursuing, even if you won't fully realize that objective.

 

[grendel111111]

Does this mean that you think that the Climb skill shouldn't be used for mountaineering? Because learning what you can take and managing logistics is a major part of mountaineering. In which case I agree that the climb skill as you have defined it is the wrong skill for the job. And you should instead

Me, I prefer a climb skill that covers almost all aspects of climbing including mountaineering - I don't have the patience for GURPS hundreds of skills. And I especially don't have the patience to make rolls for everything that I can think of that might go wrong (especially with the compound effects of multiple checks doing nasty things to probabilities). Instead I'd rather roll it all up into one check that covers the skill of climbing things like mountains.

As you have said you don't have the patience for GURPS. Surprisingly some people do, and even enjoy it (I'm not really one of them).
So we have a continuum of how to deal with skills:
1. Roll for each little thing. (I hide in the shadows (roll), I sneak up to the cliff (roll), I check for hostile creatures (roll PER), I secure my pack (survival) etc.
2.
3.Roll for the skills that are directly reflected in the outcomes that can come up. (The main risk is getting lost on the way up so roll survival rather than climb)
4.
5.Look at the big skill that is being used and roll all the factors and outcomes into that (Climb for mountaineering, and any mountaineering outcome could be the result (loss of item, hypothermia, bats attack))
6.
7.Look at the current objective (get safely to the top of the mountain) roll on the big skill and anything can get in the way. (rain, meteor strike, getting lost, breaking a magic staff)
8.
9.Look at the over all objective (get to the wizards chamber at the top of tower at the top of the cliff) roll dice to get there and subtract resources... (fail con roll - lose 2 HD, failed climb roll lose a weapon)
10.
11.Look at the overall objective choose the main skill roll once include any outcome in the one roll (Main problem is getting to the top roll climb and every point you miss by you lose 1 resource)

The gaps are for the many approaches I haven't mentioned
Where you sit on this continuum will shape the kind of game you have and different choices will suit different people.

On the other hand the assumption of utter infallibility in the course of subsidiary skills is something that you accept doesn't make for a good story, and it doesn't make for a good simulation of a world. So why do you favour it? Pure gamism? Or because it reduces the complexity and richness of the world to something that fits inside a model?

Because it is a preference. That is what it really comes down to. A preference no more or less valid than your own.
You have chosen your preferences because it creates the kind of game you enjoy, just as those who have chosen a different preference have done so because it creates the kind of game they want to play in.
And the more variance in style of games we have the more likely people will find a game that fits their preferences

 

[Maxperson]

Does this mean that you think that the Climb skill shouldn't be used for mountaineering? Because learning what you can take and managing logistics is a major part of mountaineering. In which case I agree that the climb skill as you have defined it is the wrong skill for the job. And you should instead

Me, I prefer a climb skill that covers almost all aspects of climbing including mountaineering - I don't have the patience for GURPS hundreds of skills. And I especially don't have the patience to make rolls for everything that I can think of that might go wrong (especially with the compound effects of multiple checks doing nasty things to probabilities). Instead I'd rather roll it all up into one check that covers the skill of climbing things like mountains.

You're overthinking it. Mountaineering is a form of climbing, so climb is the skill. I might give circumstance bonuses for appropriate gear, though.

On the other hand the assumption of utter infallibility in the course of subsidiary skills is something that you accept doesn't make for a good story, and it doesn't make for a good simulation of a world. So why do you favour it? Pure gamism? Or because it reduces the complexity and richness of the world to something that fits inside a model?

Infallibility? No skill is infallible.

 

[Manbearcat]

You're overthinking it. Mountaineering is a form of climbing, so climb is the skill. I might give circumstance bonuses for appropriate gear, though.

Still don't have enough time to address several of the posts that I'd wish to, but this is an opportunity to briefly get at a point that I've been aiming at with prior posts.

I'm fairly certain that what [MENTION=87792]Neonchameleon[/MENTION] is getting at is that Mountaineering (which is subsumed under Athletics or Climbing), involves gear management. Further, it doesn't just involve the expedition-preceding, logistical planning of gear, but it also involves the the deployment and management of ropes and belaying equipment (even when free climbing and just using cleats/crampons and pegs/pins) and all the rest of the gear that you're carrying (be it your pack, your cloak, your weapon belt, what-have-you). Why would the successful deployment and management of your gear not be in play within the scope of a Mountaineering/Climbing/Athletics/Scaled Every Mountain From Here to the Horizon/Defy Danger (whatever the system involves) effort? Because it is, indisputably, that case in real life.

And this dovetails back into my post upthread (with the proposed "Basketball Game" resolution mechanics) where I'm trying to pin down the reasoning and "agency thresholds" for folks being ok with abstracting certain things (significantly) into a check (eg a combat to-hit vs armor class) but being inclined toward seriously zoomed-in process simulation. For instance, being unwilling to abstract gear deployment and management within a mountaineering/climbing action declaration/resolution/fallout play procedure (especially odd considering the primary rulesets being invoked don't have a discrete "gear deployment/management" resolution mechanic...and that is even if you consider such a thing to not be needlessly invasive or tedious...which I certainly do!).

Quick aside. Folks are seemingly wanting to dig down much, much deeper into the resolution mechanics of the Bob > Pudding Mountain scenario and pick apart things that were not initially involved in the uber generic example. That starts moving away from the generic conversation of the very general application of Fail Forward as a technique and starts to drive down into how it interfaces with system. If you want to do that, then people are going to need to start interacting with play examples that go into system. I've posted a few, very relevant, ones from my current Dungeon World game above. Conversation about those or about [MENTION=42582]pemerton[/MENTION]'s play examples would be helpful if folks want to start "in-filling" system details about Bobs Pudding Mountain expedition (which was rendered solely for the generic understanding of the system-neutral application of Fail Forward). If this was Dungeon World, Bob's situation might have been (a) failed Navigation on Undertake a Perilous Journey triggering (b) the manifestation of a the crevice and (c) a 7-9 Defy Danger (✴On a 10+, you do what you set out to, the threat doesn’t come to bear. ✴On a 7–9, you stumble, hesitate, or flinch: the GM will offer you a worse outcome, hard bargain, or ugly choice.) by Bob's player leading to the choice we've been mulling for dear old Bob and his player.

All the time I have for now. Happy New Years folks.

 

[Maxperson]

Still don't have enough time to address several of the posts that I'd wish to, but this is an opportunity to briefly get at a point that I've been aiming at with prior posts.

I'm fairly certain that what [MENTION=87792]Neonchameleon[/MENTION] is getting at is that Mountaineering (which is subsumed under Athletics or Climbing), involves gear management. Further, it doesn't just involve the expedition-preceding, logistical planning of gear, but it also involves the the deployment and management of ropes and belaying equipment (even when free climbing and just using cleats/crampons and pegs/pins) and all the rest of the gear that you're carrying (be it your pack, your cloak, your weapon belt, what-have-you). Why would the successful deployment and management of your gear not be in play within the scope of a Mountaineering/Climbing/Athletics/Scaled Every Mountain From Here to the Horizon/Defy Danger (whatever the system involves) effort? Because it is, indisputably, that case in real life.

You can climb a mountain without gear, though. Gear management makes it much easier and is better represented by circumstance bonuses in my opinion.

And this dovetails back into my post upthread (with the proposed "Basketball Game" resolution mechanics) where I'm trying to pin down the reasoning and "agency thresholds" for folks being ok with abstracting certain things (significantly) into a check (eg a combat to-hit vs armor class) but being inclined toward seriously zoomed-in process simulation. For instance, being unwilling to abstract gear deployment and management within a mountaineering/climbing action declaration/resolution/fallout play procedure (especially odd considering the primary rulesets being invoked don't have a discrete "gear deployment/management" resolution mechanic...and that is even if you consider such a thing to not be needlessly invasive or tedious...which I certainly do!).

I don't abstract gear management. If the PCs don't go buy the gear and then let me that they use it to aid their mountain climb, they don't have or use gear. If they do, then the gear is a direct part of the climb and bad stuff can happen to it while climbing.

As for why combat is different. Combat happens much more frequently and already involves more rolling. Certain things must be accepted in order for the game to play smoothly and not bog down. A bogged down game is not fun for most people in my experience. It's why I accept that my character is effectively frozen in time while 50 goblins can all move and attack before my character can move so much as an inch due to losing initiative.

All the time I have for now. Happy New Years folks.

Happy New Year!

 

[grendel111111]

And this dovetails back into my post upthread (with the proposed "Basketball Game" resolution mechanics) where I'm trying to pin down the reasoning and "agency thresholds" for folks being ok with abstracting certain things (significantly) into a check (eg a combat to-hit vs armor class) but being inclined toward seriously zoomed-in process simulation. For instance, being unwilling to abstract gear deployment and management within a mountaineering/climbing action declaration/resolution/fallout play procedure (especially odd considering the primary rulesets being invoked don't have a discrete "gear deployment/management" resolution mechanic...and that is even if you consider such a thing to not be needlessly invasive or tedious...which I certainly do!).

I am a little confused as to why it is important for you that everyone has the same level of abstraction for all action, but I will accept that for you this is very important.
Accepting that I think your example misses the mark. If you want all parts of the game to have the same level of abstraction, and you want all factors involved in mountaineering to be covered by 1 check and the DM narrates any outcomes that come from the roll. Why do you not do the same for combat? Player rolls opposed skill check based on weapon being used. The DM the just narrated how they won the fight, but broke their sword (if they failed their check). Resolved in the same "zoom" scale as your mountaineering example.

But the fact is different actions can be addressed in different scales and we do it all the time. And the level of zoom one person likes for an action can be different to what another likes. Hence the reason I'm not saying my approach is they way the game is "supposed" to be played, or that anyone else should play the game with my preferred style unless they like that style.

Quick aside. Folks are seemingly wanting to dig down much, much deeper into the resolution mechanics of the Bob > Pudding Mountain scenario and pick apart things that were not initially involved in the uber generic example. That starts moving away from the generic conversation of the very general application of Fail Forward as a technique and starts to drive down into how it interfaces with system. If you want to do that, then people are going to need to start interacting with play examples that go into system. I've posted a few, very relevant, ones from my current Dungeon World game above. Conversation about those or about [MENTION=42582]pemerton[/MENTION]'s play examples would be helpful if folks want to start "in-filling" system details about Bobs Pudding Mountain expedition (which was rendered solely for the generic understanding of the system-neutral application of Fail Forward). If this was Dungeon World, Bob's situation might have been (a) failed Navigation on Undertake a Perilous Journey triggering (b) the manifestation of a the crevice and (c) a 7-9 Defy Danger (✴On a 10+, you do what you set out to, the threat doesn’t come to bear. ✴On a 7–9, you stumble, hesitate, or flinch: the GM will offer you a worse outcome, hard bargain, or ugly choice.) by Bob's player leading to the choice we've been mulling for dear old Bob and his player.

All the time I have for now. Happy New Years folks.

Part of the reason that how it interacts with the system is so very important is because it changes the system. They interact with each other. And if I don't like the dungeon world approach to role playing how is pushing D and D more towards that style of game going to make me like it more? A big part of running D and D games is deciding which techniques will create the kind of game that you and your players will enjoy, and employing those that support the experience you want to have. As a result fail forward in all it's forms forms could be moving you towards the style of game (and system) that you want or moving you away from it.

 

[Ilbranteloth]

I'm not a fan of Fail Forward mechanics because I feel it's only necessary following poor design of the scenario.

If there's something that must be done to continue, then it shouldn't hinge on a single die roll where a failed check means the adventure grinds to a halt. There are very few situations where I can think of no other alternatives.

But part of why it's not an issue for me, is that I handle skill checks a little differently.

First, my assumption is that if a character is capable of succeeding, then they eventually will given enough time and chances. So if you fail a skill check that is within your capabilities, it just takes you longer to succeed. If there are potential dangerous consequences (such as setting off a trap), then failure by more than 5 triggers the event.

One important point is that if something is hard (DC20 or higher) you must have proficiency.

Example:

DC 17 lock and the PC has a +3. They'll need to roll a 14 or higher. They roll a modified 10. So the lock will take the 4 rounds to open. They don't know exactly how long, just that they didn't succeed immediately. This is much more effective if there is a time crunch.

If they rolled a 9 or less, then something would happen, like they jammed the lock, broke their lock picks, etc. but as a result they can't pick the lock.

When climbing, for example, they will slip, and it takes time to get back up to where they can continue.

Ilbranteloth

 

[pemerton]

Combat happens much more frequently and already involves more rolling.

If you want all parts of the game to have the same level of abstraction, and you want all factors involved in mountaineering to be covered by 1 check and the DM narrates any outcomes that come from the roll. Why do you not do the same for combat? Player rolls opposed skill check based on weapon being used. The DM the just narrated how they won the fight, but broke their sword (if they failed their check). Resolved in the same "zoom" scale as your mountaineering example.

Plenty of RPGs allow just this. In BW, opposed-check resolution for combat is a key element of the system.

In HeroWars/Quest, the same mechanic is present.

And in 4e D&D, a rather similar result can be achieved by using minions, who are either up or down depending on the player's attack roll.

You're making the same mistake as others here and acting like there is only one type of fail forward. I dislike the type that involves the disconnect and only ever use it when the disconnect can be connected. I gave an example earlier in the thread. The second sort of fail forward I use all the time. That's the type where when the party fails at something, the action doesn't end. Instead there are other avenues to try in order to continue forward. I love that sort. Fail is only really fail if it ends the action.

I don't know that I fully understand what you are calling "the second type".

As I understand it, "fail forward" is a technique which was first explicitly called out by Luke Crane and Ron Edwards, and has more recently been referenced (under that label) by Jonathan Tweet in the 20th anniversary edition of Over the Edge, and in 13th Age. And this technique is one which involves what you call "the disconnect": narrating failure as a failure of intent rather than necessarily a failure of task (to use the intent/task distinction that is an explicit element in Burning Wheel action resolution), the upshot being that failure at a check leaves the PC in a situation in which an unwanted and difficult choice is required. In this way, the action at the table doesn't stop, even though the PC (and the player) has not got what s/he wanted out of the situation.

Your "second type" seems to be something closer to GM backstory authorship (or "scenario design"): if the PC fails a check, the GM authors (or perhaps has already authored) some backstory which, if the players learn it, will permit them another way "forward" - though what forward means here I'm not sure. Forward through the GM's story?

I'm not a fan of Fail Forward mechanics because I feel it's only necessary following poor design of the scenario.

If there's something that must be done to continue, then it shouldn't hinge on a single die roll where a failed check means the adventure grinds to a halt. There are very few situations where I can think of no other alternatives.

In games that use "fail forward" techniques, generally there is no such thing as "the scenario". Nor is there generally anything which "must be done to continue". Fail forward as a technique - at least as I understand it from the games and designers that explicitly call it out and use that label - is not about the way in which the GM authors the backstory. It is about how the GM adjudicates action resolution.

In these "fail forward"-using RPGs, generally, the whole idea is that the adjudication of action resolution takes the place of authoring backstory in advance ("scenario design"). This is part of the radical anti-railroading agenda of these RPGs. Previously unrevealed backstory is authored by the GM in response to action resolution; secret backstory is not generally used as an input into action resolution.

To refer to an actual play example I set out in more detail upthread: it's not the case that, had I done better design of the "PCs retreat across the desert to the ruined tower" scenario, I would have not needed "fail forward" to adjudicate the attempt to find the mace in the tower. (Eg because I would have already decided whether or not it was there to be found.) Rather, the whole point of the resolution of the Scavenging check is to see whether or not the player (and the PC) gets his wish, that the mace is there to be found. When the check fails, then - per the rules of the game - it is my prerogative as GM to introduce some other situation which does not give the PC (and player) his wish. Thus, instead of a mace the PCs find the black arrows. And the mace turns up instead, in the following session, in the hands of the dark elf who has been harassing the PCs.

This is a concrete example of how "fail forward" is a device used to manage the introduction of backstory by the GM, and to maintain narrative momentum, as an alternative to "scenario design" or making sure that there are multiple ways to do what "must be done".

if I don't like the dungeon world approach to role playing how is pushing D and D more towards that style of game going to make me like it more?

I don't think anyone has said that it will, have they?

But this isn't a thread about how D&D should be designed. It's a thread in the General forum about whether or not people like "fail forward" as a technique, and why.

 

[Ilbranteloth]

As I understand it, "fail forward" is a technique which was first explicitly called out by Luke Crane and Ron Edwards, and has more recently been referenced (under that label) by Jonathan Tweet in the 20th anniversary edition of Over the Edge, and in 13th Age. And this technique is one which involves what you call "the disconnect": narrating failure as a failure of intent rather than necessarily a failure of task (to use the intent/task distinction that is an explicit element in Burning Wheel action resolution), the upshot being that failure at a check leaves the PC in a situation in which an unwanted and difficult choice is required. In this way, the action at the table doesn't stop, even though the PC (and the player) has not got what s/he wanted out of the situation.

Your "second type" seems to be something closer to GM backstory authorship (or "scenario design"): if the PC fails a check, the GM authors (or perhaps has already authored) some backstory which, if the players learn it, will permit them another way "forward" - though what forward means here I'm not sure. Forward through the GM's story?

In games that use "fail forward" techniques, generally there is no such thing as "the scenario". Nor is there generally anything which "must be done to continue". Fail forward as a technique - at least as I understand it from the games and designers that explicitly call it out and use that label - is not about the way in which the GM authors the backstory. It is about how the GM adjudicates action resolution.

In these "fail forward"-using RPGs, generally, the whole idea is that the adjudication of action resolution takes the place of authoring backstory in advance ("scenario design"). This is part of the radical anti-railroading agenda of these RPGs. Previously unrevealed backstory is authored by the GM in response to action resolution; secret backstory is not generally used as an input into action resolution.

To refer to an actual play example I set out in more detail upthread: it's not the case that, had I done better design of the "PCs retreat across the desert to the ruined tower" scenario, I would have not needed "fail forward" to adjudicate the attempt to find the mace in the tower. (Eg because I would have already decided whether or not it was there to be found.) Rather, the whole point of the resolution of the Scavenging check is to see whether or not the player (and the PC) gets his wish, that the mace is there to be found. When the check fails, then - per the rules of the game - it is my prerogative as GM to introduce some other situation which does not give the PC (and player) his wish. Thus, instead of a mace the PCs find the black arrows. And the mace turns up instead, in the following session, in the hands of the dark elf who has been harassing the PCs.

This is a concrete example of how "fail forward" is a device used to manage the introduction of backstory by the GM, and to maintain narrative momentum, as an alternative to "scenario design" or making sure that there are multiple ways to do what "must be done".

I don't think anyone has said that it will, have they?

But this isn't a thread about how D&D should be designed. It's a thread in the General forum about whether or not people like "fail forward" as a technique, and why.

OK, I'm not familiar with the sources you quote, but I read through some of your earlier examples. The one opening the door between OD&D and Burning Wheel, all I really see is a simplification of the skill check (quite similar to how I'm handling it in D&D 5e now).

It recognizes that for most tasks that is within a character's capability, it's just a matter of time before success and that there are often consequences as a result. In OD&D it was just keep rolling until you succeed, and each time you fail there's a chance of consequences (wandering monster). It doesn't take into account the amount of time, or that a chance for a wandering monster likely increases the longer you have to take.

Burning Wheel (and my approach) simply says that it will take some time. Burning Wheel uses a similar system to D&D's Take 10 and Take 20 rules and assigns a fixed amount of time. In my case I've randomized it. To keep it simple I've put a cutoff for absolute failure, and when I determine the results for something taking time, I take into account the various factors (noise, location, current situation in the dungeon like guards actively searching for them, and the amount of time) when determining whether anything happens in that time and what. Many times it's obvious - the opening scenes of Raiders of the Lost Ark are fantastic examples of how to adjudicate failures.

I'm totally onboard with all of this, and if that's how 'Failing Forward' is defined, that great.

But on everything I've read online, 'Failing Forward' is related to 'Always Say Yes' and other methods that are recommended to keep things moving. Failing Forward in these cases simply mean that the failed skill check ends in a state that the DM finds unacceptable, and thus must provide a different non-failure result.

These most commonly occur in scenarios where the only way forward is 'blocked' by a skill check in an attempt to create an exciting situation. It might be a published adventure or not. Regardless, the adventure is now stuck at a point where it cannot continue without the DM providing some method to do so.

DM's are being encouraged to use techniques like this on a regular basis. I agree that if you find yourself in that situation, as a DM you have to fix the mistake somehow. But by developing a DMing methodology around these concepts, I think we're creating lazy DMs. It's a good starting place. But whether running a published campaign, running one on your own, or even via random generation, using them to keep giving the PCs a way out drastically changes the nature of RPG games.

Based on the many responses to this thread I'd have to say that the term 'Failing Forward' is poorly chosen if it's supposed to mean what you're describing, and at this point means something very different to many others.

I'd love to see the original source material you mention to see what the original intent of the concept was.

Ilbranteloth

 

[pemerton]

[MENTION=6778044]Ilbranteloth[/MENTION] - the BW rules for "intent and task" can be downloaded for free from DriveThruRPG here. It is elaborated in the Adventure Burner, which is the closest thing BW has to a GM's guide - at the moment I don't have that ready-to-hand to quote, but it elaborates on the relationship between intent and task in failure narration. The key passage on p 31 of BW Gold is this:

When the dice are rolled and don’t produce enough successes to meet the obstacle, the character fails. What does this mean? It means the stated intent does not come to pass.​

Page 32 continues:

When a test is failed, the GM introduces a complication.

“You can try to pick the lock, but you don’t have much time. It is highly likely that the guards will return before you finish.”​

Try not to present flat negative results - "You don’t pick the lock.” Strive to introduce complications through failure as much as possible.​

This has nothing to do with things that "the DM finds unacceptable". It certainly has nothing to do with "lazy DMs". As per the passage I've quoted upthread from Eero Tuivonen, narrating complications that are appropriate to the player's specified intent and task, and that deploy and build on existing backstory, and that challenge the player (and thereby the PC) in an engaging way, is a GM skill that is not trivial to master.

The reason is does not relate to things that are "unacceptable", or to "blocking", is because in these games there is no "scenario." The GM does not prepare that sort of backstory in advance. The backstory is narrated in response to the failures, in the forms of the complications and consequences that result from the PCs trying things but not realising their intents.

Whether or not, in the course of this, the PCs do or don't succeed at the tasks in question is secondary.