Reply to thread

Message: <blockquote data-quote="Manbearcat" data-source="post: 9227046" data-attributes="member: 6696971">I'll be honest that "I'm not sure what we're debating."  I know what I'm saying and what I'm trying to convey (that task resolution and conflict resolution are very different modes of play and "here are the distinguishing characteristics"), but its not clear to me what you and FR are saying.  I thought you were disputing that contention (either that you flatly don't believe they're different or that you don't believe the distinguishing characteristics are sufficiently sturdy and sensitive to perform the necessary, distinguishing impacts), but I'm not sure at this point.You mentioned me with this, so I'm going to grab it and throw some words at it:I'm going to say a few things that break out some key concepts which, I hope, illuminate and elaborate.  I'm hoping this does some work here.  I'm only going to talk about scene resolution here.  I'm not going to talk about independent tests, versus tests, or PBtA moves or whatever else.  I'm only talking about scene resolution.  I really think in order for there to be any clarity achieved on these subjects we need to nail down core concepts and focusing on scene resolution should do the most/best work:<h2>All scene resolution frameworks are conflict resolution.</h2>Why?  For starters, its because (a) there are initial conditions which include all of setting, situation, character(s), and goals/stakes that are transparently understood by the participants.  Secondly, (b) there is finality of resolution at the the endpoint which does the work of determining the outcome of those evinced "goals/stakes" and the impacts on the prior three (setting, situation, character(s) ).  Thirdly, (c) the respective participants (players, GM) are "performing their necessaries" within the unfolding play in a way that inherently indexes the prescribed, structural endpoint of "goals/stakes resolved" while simultaneously respecting the evolution of setting, situation, character(s) along the way.  The scene is not over until the resolution framework says its over.  The GM doesn't get to make extra-system extrapolations about some conception of spatial/temporal/metaphorical dimensions or some conception of the fictional arc and therefore decide "ok, in the interests of simulation of process or in the interests of story imperatives, this seems a good place to stop."  No, the scene is over when the resolution mechanics say they're over.NOW...various systems might provide GMs some mechanical widgetry that affords them latitude to go outside of that prescribed endpoint and say "scene resolved" before the typical terminating endpoint of a scene.  An example here is "GM Folds in Dogs in the Vineyard to end the scene" or "GM deploys the Doom Pool in Cortex+ to end the scene."  But on those occasions, these endpoints are not (comparatively unconstrained) GM fiat.  Those "early endpoints" (lets call them) are themselves principally and mechanically systemitized (constrained, directed, and structured by system).Good designers build-out resource and widgetry management (thematic, tactical, strategic) with this paradigm as the nexus of their design. Better ones systemitize it in a more compelling fashion that better imbues play with a moment-to-moment experience and general sense of what this game is about.  Worse ones struggle at one or both of these.[HR][/HR]I'm going to stop here.  Hopefully that does some kind of work to illuminate concepts and focus thought.  If we get anywhere on that, I'll be interested in examining other forms of resolution.  But I'm personally not going outside of that until we grok the core concepts and dynamics above.</blockquote>

Verification