Reply to thread

Message: <blockquote data-quote="pemerton" data-source="post: 7598832" data-attributes="member: 42582">This thread is a spin-off of the <a href="http://www.enworld.org/forum/showthread.php?658089-If-an-NPC-is-telling-the-truth-what-s-the-Insight-DC-to-know-they-re-telling-the-truth" target="_blank">DC to tell that a NPC is telling the truth</a> thread.It starts with some context, sblocked for length, and then a question:[sblock][/sblock]The first sentence of your second paragraph in the last quote is the answer to the second question (making them choose between being analytic and guessing what I have in mind) in your first paragraph.That is: when you run the game without telling the players the immediate consequences of their actions then their decisionmaking options are, basically, two: they can play their characters analytically, studying the situation to try and ascertain what is at stake; or they can play their characters non-analytically, perhaps even recklessly, in which case they don't know what is at stake in the situation except by guessing what you, the GM have in mind in your framing of the situation.In suggesting that this makes analysis a focus of play, I am adding in an additional conjecture: namely, that at least from time-to-time the players want to know what is at stake in a situation, whether for the basic reason that they don't want their PCs to die, or sometimes for more complex reasons that reflect the current circumstances of the fiction (eg they want to know whether they should smash the vessels of magical fluid to stop those from powering the enchanted widget that is sustaining the eldritch field that feeds the ritual-of-whateverness). In such circumstances, the players come under pressure to analyse, because a non-analytic/reckless approach (eg "I run up to the vessels with my battle axe and smash them all!") runs the risk of producing an adverse consequence relative to these important player (and PC) goals in the scenario.If my additional conjecture is false then my suggestion that analysis becomes a focus of play is also false; but at least for many D&D games run broadly in the style you're describing the conjecture is true, I think, even if it's not true in your game.Notice also that, in the example of the player of the reckless PC who declares I run up to the vessels with my battle axe and smash them all, the player can succeed in the action declaration (ie all the vessels of magical fluid are smashed) and yet fail in his/her goal, of depowering the enchanted widget and thereby stopping the ritual, because the GM has actually already decided (in his/her dungeon notes, say, or it's in the module text) that the magical fluid actually dampens the power of the eldritch field, and smashing them generates a magical power surge that bring the ritual immediately to fruition. So the player who chooses not have his/her PC study the situation and instead simply to act is in many ways hostage to the GM's prior decision-making about the nature of the situation. S/he isn't making any sort of informed or deliberate contribution to the overall state of the fiction.Vincent Baker (probably best known for designing DitV and Apocalypse World, which is the progenitor of PbtA RPGs), <a href="http://lumpley.com/hardcore.html" target="_blank">has talked about this</a> also (and has influenced my thinking about it): the quote is in sblocks for length.[sblock]Conflict Resolution vs. Task ResolutionIn task resolution, what's at stake is the task itself. "I crack the safe!" "Why?" "Hopefully to get the dirt on the supervillain!" What's at stake is: do you crack the safe?In conflict resolution, what's at stake is why you're doing the task. "I crack the safe!" "Why?" "Hopefully to get the dirt on the supervillain!" What's at stake is: do you get the dirt on the supervillain?Which is important to the resolution rules: opening the safe, or getting the dirt? That's how you tell whether it's task resolution or conflict resolution.Task resolution is succeed/fail. Conflict resolution is win/lose. You can succeed but lose, fail but win.In conventional rpgs, success=winning and failure=losing only provided the GM constantly maintains that relationship - by (eg) making the safe contain the relevant piece of information after you've cracked it. It's possible and common for a GM to break the relationship instead, turning a string of successes into a loss, or a failure at a key moment into a win anyway.Let's assume that we haven't yet established what's in the safe."I crack the safe!" "Why?" "Hopefully to get the dirt on the supervillain!"It's task resolution. Roll: Success!"You crack the safe, but there's no dirt in there, just a bunch of in-order papers.""I crack the safe!" "Why?" "Hopefully to get the dirt on the supervillain!"It's task resolution. Roll: Failure!"The safe's too tough, but as you're turning away from it, you see a piece of paper in the wastebasket..."(Those examples show how, using task resolution, the GM can break success=winning, failure=losing.)That's, if you ask me, the big problem with task resolution: whether you succeed or fail, the GM's the one who actually resolves the conflict. The dice don't, the rules don't; you're depending on the GM's mood and your relationship and all those unreliable social things the rules are supposed to even out.Task resolution, in short, puts the GM in a position of priviledged authorship. Task resolution will undermine your collaboration.[/sblock]Speaking for myself, I prefer a game which does not generate this particular sort of pressure to play an "analytic" character, or to study situations in order to ascertain what is at stake in them, and hence what potential consequences might flow from succeeding or failing at the task.This requires that players be able to ascertain stakes or consequences in advance of declaring actions for their PCs. (That is, in advance of studying/analysing the situation.) This means that what is at stake, and what consequences are apt to flow from engaging the situation one way or another, need to be signalled by the GM in his/her framing narration. In my own experience, the easiest and most engaging way to do that is by framing the situation in a way that clearly connects to already established goals/themes/concerns/interests of the player.I'll give a fairly banal example from <a href="http://www.enworld.org/forum/showthread.php?658931-Cthulhu-Dark-another-session" target="_blank">the session of Cthulhu Dark</a> that I GMed on the weekend:One of the players had chosen, as his PC's occupation, butler. All my knowledge of bulters comes from having read Remains of the Day many years ago, and I remember the polish on the silverware being very important. So when that PC met another butler he was friends with, the NPC butler started explaining a new technique he had for making his silverware shine, which his master had introduced him to and which involved a special fluid and a galvanic current. The NPC also explained that, as per his master's instructions, the used fluid was retained and decanted into dedicated canisters. When a fire broke out, the NPC asked the PC to help him move the fluied - canisters, plus the current (open-topped) cleaning vessel - to safety. The player made his check, and didn't do terribly well, and this was narrated as him spilling some of the fluid from the open-topped vessel. Some events that followed on this, driven by the other player's play of his PC, led to the rest of that batch of fluid being spilled on that second PC's clothes.At no point in the narration or resolution of the situation did I (as GM) tell the player of the butler what the properties of the fluid were, or what the consequences would be of spilling it. In fact I couldn't do that because I didn't know myself yet!But it's as clear to the player as it is to me that the fluid is significant - it's very obviously been brought into the shared fiction, and made a focus of play, because the player is playing a butler and hence has an interest in the treatment of silverware.  Because everyone at the table knows that we're playing a Cthulhu game set c 1900, it's also obvious that a device involving a strange fluid and galvanically powered is sinister. Hence there's no ambiguity that spilling the fluid is a bad thing, although what the exact badness is is yet to be established.Another element of the situation that is clear to the player, because of the way it speaks to the context established by the player's choice of PC occupation, is the relationship of the NPC butler to the master who provides the fluid and retains it once it has been used. Because the player has chosen to play a butler, it's already established in the context of the game that loyal service is, in itself, a good thing rather than a bad thing. But because we all know it's a Cthulhu game, it's also clear that doing the right thing might lead to unhappy rather than happy consequences. So without any need for me as GM to explain it, the situation establishes the possibility that the NPC butler is a victim of manipulation by a sinister master as well as the (near-)certainty that the master himself as a sinister figure. So spilling the fluid clearly has the potential to create conflict with that figure, and the "badness" that results (as per the previous paragraph) will in some fashion be related to whatever his sinister plans are.As I said, there's nothing very special about this example: I have used it simply because it's recent and so is easy for me to recall. But hopefully it shows what I mean when I say that I prefer an approch which establishes what is at stake in a situation, and hence implicitly establishes consequences of failure without the players needing to declare actions for their PCs that invovle studying or analysing the situation. And it does this by drawing on shared understandings between player and GM as to what is significant for the players in their play of their PCs, given their build choices, evinced thematic concerns, genre expectations, etc.I've used this sort of approach in GMing AD&D, and 4e D&D, and I think it could probably be applied in 5e D&D also if one were so inclined.</blockquote>

Verification