Reply to thread

Message: <blockquote data-quote="Ovinomancer" data-source="post: 8649729" data-attributes="member: 16814">I see where [USER=7025508]@Crimson Longinus[/USER] is coming from.  If the OP is being described as "fail forwards", then it's fairly evident that this use is going to be in service of what the GM wants.  I've described it as appending "rocks fall" to standard task resolution, and I mean that.  It's a justification for the GM to arbitrarily introduce GM desired content on any failure, regardless of what the players understand is at risk.  In this summation, the risks are not clear to the players, and the consequence space considered steps far outside the task itself, and become just another injection point for the GM to direct play that has some form of thin justification.  And, in this case, if it's being characterized as "fail forwards" then this use is being inserted there as well.  I think that calling it "fail forward" is incorrect.To explain, I'm going to restate a few things.  "Task resolution" is when you are resolving a specific action and only considering that action space.  Climbing a wall, where resolution is about if you do so, or can't find a start, or fall partway up, is task resolution.  The task is climbing, and the resolution only concerns itself with resolving that task."Conflict resolution" is where there's something larger than a task at stake.  Getting access to the Archduke's private library which is heavily guarded is a conflict -- I want something, there's something in the way, we're resolving a conflict.  If the system is taking the resolution process as resolving this conflict, and not a specific task along the way, you have conflict resolution.  If a player declares an action to address this, we're not resolving that task, but the conflict.  So, here, if the player declares sneaking in, we're resolving that action in a sense that will determine if you get the goal or not.  We don't really care how well you slip past the guards or whatever.To bring this to the OP example, the problem in that example is that the proposed action "open the safe" is a task -- it's already seated directly in the task space because we're examining what happens if the attempt to open the safe succeeds or fails.  The suggestion is adding non-task related consequence to the failure of the task, but the resolution is still very task oriented (and 5e is very task oriented in general, so this makes sense).  If it was a conflict, then the question would be different.  We wouldn't really care how well you do picking the lock, because that's up in the air until we resolve the conflict, and that conflict is going to have to be "what we want is inside the safe."  Then you resolve, and find out if that is true or not (or is true with complication, etc.).  Here, opening or not opening the safe is going to be color used to describe how the conflict resolved.  If successful, you clearly opened the safe.  If not, maybe the safe is unopenable, or the OP's idea of nothing in the safe.And so now we're back to "fail forwards."  All fail forwards means is don't dead end the game where there's nothing more to do.  This comes from having a single roll or event be necessary to play, and the GM has nothing to present if this isn't accomplished.  Fail forward just means that you don't do this -- a failure doesn't stop the game or leave it in a weird limbo where players have no idea what to do next.  This often happens with scripted play (again, linear, railroad, whatever's du jour) where you have to pass through the next wicket for play to continue.  In this sense, fail forward can be a tool to keep things moving along the rails.  You see this quite often in task resolution games, like 5e, where you're accidentally hinging a conflict on a task and having realized that you dead end the failure.  Plenty of advice has been given to avoid this (no one path, etc.) and all of that is really incorporating fail forwards.  Fail forwards is super simple -- don't dead end.Now, if you're actually using conflict resolution and not task resolution, this gets easier because you're not hinging conflict on task.  You're being open on the conflict, and everyone is aware of the stakes and the results and how you got where you got, and it's very easy to redefine the conflict with the consequence or to move to a different conflict since this one doesn't work.  However, conflict resolution isn't something you can just drop into a game -- games orient their systems quite differently and 5e is not well suited to conflict resolution.  Which is why the OP's idea of marrying the front end of 5e's task resolution to the back end of conflict resolution is really nothing more than justifying another GM story injection point while keeping players in the dark about how things work.</blockquote>

Verification