Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="Manbearcat" data-source="post: 9610448" data-attributes="member: 6696971">I'd say in the context of the long arc of TTRPG history, (#1) it (the bolded) means more than that.  Or at least, despite the reality that you can reduce fiat to that, within the scope of TTRPGs, and in particular the "GM Decides/Golden Rule/For the Good of the Story" zeitgeist of the late 80s through 90s (which still predominates today), that you have to go further and discuss the presence of all three of (a) systemic and table-facing constraints on GM decision-making, (b) how stable/table-facing/knowable the procedures of play are, and (c) therefore how gameable the gamestate is (or not) for the players based on that (a) + (b).Now (#2) gameable here can mean different things based on the agenda of play and the game's engine that is (hopefully) working in concert with that agenda.  What the players are supposed to be doing (and the GM for that matter) will mean different things in different forms of play with different priorities and expressions of those priorities via participant principles and procedures.  However, in a game that purports to be challenge-based, both the gamestate and the attendant decisions that players need to be able to persistently interact with need to be stable, functional, and consequential at an absolute minimum.  Otherwise, tactical and strategic control over the gamestate can't be achieved via skillful play.  You'll end up with some form of Ouija Play where the GM is moving the planchette of the gamestate either unknowingly to the players or indiscriminately in such a way that compromises the integrity of the whole challenge-based edifice.(#3) So here is a quick example of procedures where stuff that could be working in concert to produce a challenge-based paradigm isn't:* We're supposed to be playing a wilderness crawl game that features challenge-based priorities.* The Random Encounter (RE) frequency isn't stable over any given hex/map locale.  It changes and it changes indiscriminately in terms of player perception and interaction.  The RE frequency isn't knowable for them in any real way that they can act upon.  Like its not, "every X turns, roll Y % and consult table if N value hits" or something kindred.  It is either (i) wholly unstable and GM decides when to roll for random encounters and what values matter or (ii) GM can ignore those RE inputs or (iii) simply the players have no means of knowing and acting upon this information.* Further still, what is on those RE tables for a given hex/locale is unknowable.  Or perhaps, REs are done entirely ad hoc by the GM.  "Yeah, I feel like an encounter right now would be really good for pacing" or "man, their resources are basically unchecked...let's liven things up a bit...<flips through the Monster Manual> yeah, that Manticore looks good and this is the right terrain for its hunting grounds..."  Something like that.Maybe you're running an AP with an imposed metaplot that actually gives you both this express instruction.  Plot point # 4 needs to be mapped upon play around this point so throw this encounter in roughly now.* Perhaps even further still, the value of Turns in the system isn't exactly stable in terms of rules codification or perhaps the game is sufficiently freeform that the concept and value of Exploration Turn isn't or can't be consistently employed within the actual play of the game.Without even getting into the rest of a system's dynamics (and there are myriad other things that could be a problem for players being able to assess gamestate dynamics and make persistent strategic and tactical decisions around current and future states), this alone is sufficient to flatline a game that purports to be a challenge-based crawl with players having a persistently functional gamestate to be interacted with, assessed, and skillfully gamed.[HR][/HR]We on the same page on those #s 1-3 above or disagreement around something?</blockquote>

Verification