Reply to thread

Message: <blockquote data-quote="pemerton" data-source="post: 6305818" data-attributes="member: 42582">I definitely agree with this. The real world is full of wild and crazy stuff, and I don't see why the gameworld shouldn't be either.Relating that to the hit point issue: we might be confident that on any other day Joe would have died if a single archer got a bead on him, but today Joe was so lucky that he was able to run through a hail of arrows to rescue the princess (mechanically: reasonable hit points in conjunction with lazy warlord princess build means that Joe's player never has to reduce the hit point column to zero).Or we might think that on any other day that frost giant could have fought his way through a phalanx of dwarves, but today his number came up (mechanically: frost giant was a minion, so one hit from the dwarf fighter dropped it).There is certainly no need to frame our ingame counterfactuals around the deliverances of the mechanics in order to maintain consistency!The mechanics influence the narrative. It doesn't follow that they are part of the gameworld, or that the gameworld has elements that systematically correspond to them.The players of the game know that, had the player declared a different attack (say, Twin Strike rather than Biting Volley; or a 1W attack rather than a 2W attack) then Joe still would have been killed. But this is not knowledge about the gameworld. It is knowledge about the real world, and in particular about the game rules and the mechanical game state (eg what number is written in the hp column of the character sheet for Joe).If you assume that these rules and mechanical game states systematically correspond to elements in the gameworld, then you will conclude that there is a true counterfactual in the gameworld that corresponds to the true counterfactual in the real world. But I do not make any such assumption. Hence I do not draw any such conclusion.Because the mechanics do not determine what happens within the gameworld by modelling the gameworld processes. As I play the game (non-simulationistly), the mechanics determine what events are true within the gameworld, and they place limits on how the arising of those events can be narrated (eg if a character is killed as a result of a successful attack roll, then when narrating the events within the gameworld the character's death has to be explained as a cause of someone else's attack upon him/her). But they do not model the ingame processes.Twin Strike and Biting Volley are differences in the metagame. They entitle players to roll different sorts of dice to hit and to damage. Thus, a player who uses Biting Volley rather than Twin Strike makes it more likely that the GM will have to narrate that an NPC/monster has been bloodied or killed. But the explanation, in game, for that bloodying or killing is simply that the player's PC shot the NPC/monster with an arrow. The mechanical difference between the two powers doesn't factor into it. It is a mere metagame device.Imagine, if you like, a table rule which says that if a player fails a saving throw, s/he can chip $1 into the groups "module fund" - used to pay an adventure path subscription - to get a reroll. No one would suppose that paying $1, and rerolling a save, corresponds to anything in the gameworld. It would be purely metagame.Well, the difference between Twin Strike and Biting Volley (as I play them) is the same. It's purely metagame. Likewise hit point totals (as I play them), unless they cross thresholds that actually matter in the fiction (eg bloodied, dead/unconscious, cutting off the head of a hydra, etc). Outside of such cases, the losing or gaining of hp is simply a "momentum" marker - the tide of battle is flowing the PCs way or against him/her.I agree that hit point mechanics don't give us narratively meaningful wounds. This is why I prefer them as a "momentum marker", and in 4e you do get consequences and narration within the fiction (eg second winding rather than attacking, or falling back to the inspiring leader (ie getting in range of Word of Vigour!), etc). It's not always great literature, and I'm not sure that if you were starting from scratch a hp system is the best way to achieve what 4e offers.But I think it's not nothing.I agree with this. It's why I think of hp in terms of "momentum" rather than injury.In 4e, if you wanted to do something like Frodo's suffering at the hands of the Witch King or Shelob, you'd absolutely have to use a disease/curse track in some fashion. (The game has the technical resources to do it, though it would involve some departure from what I think is the default spirit of the game, and you'd also have to decide what to do about the Remove Affliction ritual, which at the moment provides an easy end-run around these sorts of consequences.)As I've said, in 4e this plays out mostly within a given combat, in terms of the "momentum" of victory flowing with or against the PCs. I think this is a distinctive feature of 4e in the D&D family of games. (Maybe 13th Age exhibits it also?) For me, it's a reason for preferring 4e over pure "hp as attrition" in earlier versions of D&D.If a character's arm is broken, s/he won't just be "switching weapons". S/he only has one arm, and hence can't (say) use a shield at the same time as wielding a weapon.I don't think a system needs to be all that complicated to factor this in. D&D certainly has a more detailed level of bookkeeping for other things (eg encumbrance rules; movement rates). For whatever reason, it just doesn't care about those sorts of injuries.As I've said, my solution to this is to assume that the PCs in my game are generally not severely wounded - hit points are predominantly a momentum marker rather a "health" marker.In 4e, I think the reason we track hp and healing surges is unequivocally for their role in pacing combat, and in shaping the players' choices for their PCs within that context. And the attrition of healing surges matters because it iterates back into this (eg the players make choices that reflect the fact that PC A has 4 surges left while PC B has none).</blockquote>

Verification