Reply to thread

Message

<blockquote data-quote="Manbearcat" data-source="post: 6228151" data-attributes="member: 6696971">Its zoomed-out (there is a bit more nuance that would require further unpacking system components, GMing techniques, et al), but your abstract is pretty close to the mark.As an overview, this is the main problem, as I see it.&nbsp; There are too many component parts that are all but (or near to at the very least) mutually exclusive of one another with respect to facilitating disparate agendas; outcome-based design versus process-based design...granular, task resolution to resolve a character's singular action during world exploration (eg climbing a tree to get to the top of it to then make a check to perceive) versus abstract conflict resolution to resolve player intent while paying heed to the conflict's stakes (eg navigating the course of a harrowing, narrow switchback mountain path, replete with icy snowdrifts, during pursuit evasion) .&nbsp; Or, you end up with a truly watered down component that doesn't remotely carry the mechanical heft or narrative malleability (eg 5e's Hit Die are not remotely a proper analogue for the mufti-faceted mechanical impact of 4e's Healing Surges and their free-descriptor nature which provides a malleable, fungible narrative device for GMs to tax PCs and/or make offers).Bolting on an elegant non-combat, conflict resolution framework in a task resolution based system is not as easy as devising a x successes before n failures and subjective, of-level DCs.&nbsp; There are PC build scheme considerations, mechanical means for attrition/ablation on failures (micro and macro), resource refresh rates, that must be in lockstep.&nbsp; And, of course, the math needs to be coherent.&nbsp; The same applies for doing the inverse (going from conflict resolution at the closed-scene level to task resolution at the open-world level).&nbsp; Making the two paradigms compatible requires an extraordinary amount of work or the deft hand of Errol Flynn.</blockquote>

[QUOTE="Manbearcat, post: 6228151, member: 6696971"] Its zoomed-out (there is a bit more nuance that would require further unpacking system components, GMing techniques, et al), but your abstract is pretty close to the mark. As an overview, this is the main problem, as I see it. There are too many component parts that are all but (or near to at the very least) mutually exclusive of one another with respect to facilitating disparate agendas; outcome-based design versus process-based design...granular, task resolution to resolve a character's singular action during world exploration (eg climbing a tree to get to the top of it to then make a check to perceive) versus abstract conflict resolution to resolve player intent while paying heed to the conflict's stakes (eg navigating the course of a harrowing, narrow switchback mountain path, replete with icy snowdrifts, during pursuit evasion) . Or, you end up with a truly watered down component that doesn't remotely carry the mechanical heft or narrative malleability (eg 5e's Hit Die are not remotely a proper analogue for the mufti-faceted mechanical impact of 4e's Healing Surges and their free-descriptor nature which provides a malleable, fungible narrative device for GMs to tax PCs and/or make offers). Bolting on an elegant non-combat, conflict resolution framework in a task resolution based system is not as easy as devising a [I]x [/I]successes before [I]n [/I]failures and subjective, of-level DCs. There are PC build scheme considerations, mechanical means for attrition/ablation on failures (micro and macro), resource refresh rates, that must be in lockstep. And, of course, the math needs to be coherent. The same applies for doing the inverse (going from conflict resolution at the closed-scene level to task resolution at the open-world level). Making the two paradigms compatible requires an extraordinary amount of work or the deft hand of Errol Flynn. [/QUOTE]

Verification