There's definitely room for multiple approaches to the examples I gave. For context, I personally see #2 as closer to #1, in the sense that knowing if a wall is structural (i.e. whether it is load-bearing and thus likely too strong to just burst through, or a non-structural room divider that isn't much of an obstacle) may depend more on knowledge of the construction techniques and materials in use, rather than observation of a specific wall. Any sort of panelling or wall covering (in a modern building, plaster or drywall) will often make structural and non-structural walls visually indistinguishable. Even without wall coverings, telling the difference between (e.g.) a divider of stacked mud bricks (that might be burst through with a good run) and something like adobe construction (like running into concrete) is something I think depends more on knowledge than observation.
Ahh, gotcha. See, my understanding of architecture is little enough that I would not have thought about that. Heck, I had assumed by “structural” you meant “structurally sound” rather than asking about whether it was load-bearing.
One of my core conceits as a DM who asks players to describe their actions in terms of goal and approach is that I recognize they are probably not experts on many of the things their characters are, and neither am I. I don’t really know that much about architecture, or locksmithy, or engineering, or whatever, so I don’t expect a high degree of technical specificity in action declaration. It is ok to leave the details abstracted, as long as I can tell generally what you want to accomplish and how. So, I would encourage the player, rather than asking about their character’s knowledge of architecture and whether they would recognize if the wall is structural before attempting an action to try to bring it down on their enemies, just tell me what you want to accomplish and how your character goes about it generally. “I want to bring this section of tunnel down on our enemies. Can I do that by applying my knowledge of masonry and smashing key sections of wall?” is a beautiful action declaration.
As a player I'd be fine with your preferred approach to #2, as long as you still let the check be Intelligence (History) rather than requiring it to be Wisdom (Perception).
So, what I do is I just call for ability checks. I never ask for an ability (skill) combination, instead leaving it to the player to suggest if they think one of their proficiencies would be applicable, whether it’s normally tied to the ability in question or not. So, if you’re examining the wall for structural integrity, I would probably ask for a Wisdom check rather than Intelligence, but you could absolutely suggest that your History proficiency apply, citing your knowledge of historical architectural styles helping you determine which walls would most likely be structural in this style of building. I might even say, “oh, in that case roll Intelligence rather than Wisdom” if that felt more appropriate to your approach.
Although if you required examining the wall to take an action I'd just skip the idea entirely: trying to burst through the wall is likely to be an action already, and spending two actions on an off-the-wall (or rather through-the-wall) plan to gain a tactical advantage is rarely worth the lost damage potential.
Nah, I wouldn’t have that use up your action in combat, for precisely this reason.
For #1 and #3 I see our approaches as functionally equivalent from the player's perspective.
What I see as the difference between our approaches to 3 is that in your approach the player is asking the DM if their character has certain knowledge and if they do, to leverage it to achieve a desired goal, whereas in my approach, they are declaring that they have this knowledge and intend to apply it to achieve a desired goal. Perhaps a subtle distinction, but I think an important one as I believe my approach maintains a better flow of the basic pattern of play. Ideally, in my view, the pattern of play should stick as close as possible to what is described in How To Play:
1. The DM describes the environment
2. The players describe what their characters do.
3. The DM describes the results of the characters’ actions, then starts the process over from 1.
Players asking questions does not fit this pattern, and interrupts its flow, so should be kept to a minimum. Ideally, the players would never need to ask questions, but communication being imperfect, it is sometimes necessary for players to ask clarifying questions about the description. Otherwise, I favor declaration of action with the goal of learning what more you want to know, rather than asking if you know it.
As an aside, another thing that interrupts this pattern is making checks. This is why I prefer only to call for checks to resolve the outcomes of actions that are both uncertain and have direct consequences for failure. Rolling dice, adding up bonuses, and comparing the results to a DC all interrupts the flow of play, and so I endeavor to keep that to a minimum.
Very impressive! Until the above example came up in play I'd never even considered including that much architectural detail in my descriptions. Even now I don't include it as a regular practice, because it's come up exactly the once. I still usually don't even decide ahead of time about which walls are structural and which are room dividers, so I wouldn't have that much detail to give up front. (Also, I sometimes fear I give too much detail in my descriptions already, so even if I knew which walls were structural I'd probably not prioritize that information and end up leaving it out of my up-front drecription)
Ahh, I think I have not made myself clear. I definitely don’t decide ahead of time which walls in a dungeon are structural. As mentioned earlier, I am no architect, and would have no idea how to do this justice. Rather, I meant to express that, if I had planned as part of an encounter for the underlying structure of the dungeon to be relevant - for example, if I planned to use its potential collapse as a hazard, or for the monsters to use this tactic against the players, or something along those lines, I would telegraph that in the description. I was also speaking hypothetically, as I can’t say that’s something I’ve ever done, at least not that I remember. But yeah, if the players come up with the idea to try to bring the tunnel down on their enemies, I would prefer they just assert that they want to apply their character’s architectural knowledge to damage the walls in the appropriate places to compromise structural integrity, rather than asking me if their character knows which spots those might be first.
Generally-speaking, yes: all else equal I prefer that any highly-abstract mechanics with world-building implications be kept under the hood. If there are going to be checks that create new monsters where none existed before, I'd rather not know about it at the table. (Especially if the PCs had done their legwork and figured out IC the number of opponents in advance.) By constrast, if the PCs know an enemy patrol exists and have taken steps to avoid it, I'm totally fine with the DM ruling that the PCs' efforts reduce (but not eliminate) the odds of encountering the patrol, deciding there is an X% chance of the encounter an rolls openly. To me that's probabilistically modeling an uncertainty in the game world, rather that abstractly rewriting the game world.
Interesting. I guess where my perspective differs is in the idea that a randomly triggered encounter or complication is “created” where it hadn’t existed before. In theory, any such randomly triggered event is one that should be possible in the context it occurs in. There are rats in the dungeon, so randomly determining that the party encounters a pack of rats doesn’t seem to me like creating rats where they didn’t exist before, it’s just randomly determining when and if the characters come across the rats that definitively exist there.
If it helps, I tailor my complication tables to the locations where they are going to be used. I’m not just rolling on a generic random encounter table, and I may not even roll to determine the encounter at all. Rather, I’ll have a list of complications that are appropriate to the dungeon, and when the tension pool indicates that a complication should occur, I will choose a complication I feel is most appropriate to the current context. Maybe I’ll use a dice roll if there are many equally-appropriate options. But to my mind I’m certainly not creating events at random, I’m randomly determining when events that are likely to occur in this dungeon do so.
An example of the other extreme would be a table where, when exploring a dungeon, every X minutes there is a Y% chance of new monsters spawning into the game world and attacking the PCs. That wouldn't be immersive for me at all. It's not quite as bad if the monsters are moved rather than created (so fighting them now means less to fight later), and if X and Y are tailored to the environment and PCs' and monsters' actions rather than being constant.
I think I get it. It sounds to me like what you want is for those random encounters to be drawn from the ranks of the dungeon’s inhabitants, such that if you encounter 3 wandering Kobolds now, there are 3 fewer Kobolds in the barracks when you get there later. A lot of old-school dungeons worked that way. That I can totally understand, although to me it seems like there’s no way as a player you would be able to tell the difference.
Ultimately immersion for me requires that the in-game world makes sense. So long as it's plausible that monsters are here, now, then great. Anything that undermines that plausiblity (like causally linking the existence of the monsters to the OOC accumulation of tension dice) I don't want to know about. The flip side of this is that as if it can be made to feel organic, I'm totally fine with the DM noticing that the players are losing focus and adding in an unplanned combat to refocus the game.
Where you’re losing me is with the implicit assumption that because the tension pool was used to determine when an encounter happened, that the tension pool must have been used to determine whether or not the creatures involved in the encounter exist. Clearly those creatures must exist in the dungeon, otherwise you wouldn’t be able to encounter them there.
