Reply to thread

Message: <blockquote data-quote="Sir Robilar" data-source="post: 6007630" data-attributes="member: 75757">It's quite common for discussions about dissociated mechanics that posters show up to explain why each and every criticized mechanic is realistic and in some way an adequate translation of some element of the game world. But - sometimes - that is the "you can explain everything" fallacy and sort of misses the point.This would be a good description for the Gnoll's tactics section so DMs can play them adequately. But the mechanic as written doesn't capture (and doesn't even try to capture) the creature's savage nature. Instead it gives the creature a specific advantage in a combat situation and slaps the "Savage" tag onto it. The trait is a tactical mechanic for a creature in a tactical combat situation and was clearly designed from this point of view. Now this is a suitable design approach for a tactical combat game, but some may say it's problematic in a role-playing game.Outside of the specific situation's that the trait was made for, it doesn't make much sense in the game world. And this is often a problem with dissociated mechanics. They are cool as long as you use them how they are intended. But since they are not the best representation of something that is actually happening in the world, but just the best representation when looking at something in a special way (usually combat) they break apart when you put them into another context.  A bad example: A lone Gnoll controlled with a Dominate Spell should be able to attack with all it's might when commanded to do so by the Wizard, but this trait would disallow it. In my opinion a flexible core system for 5E should carefully exclude dissociated mechanics since a role-playing game's core needs all the flexibility it can get. Or to put it differently, if dissociated mechanics rub some people the wrong way (and they seem to do this especially with many players of old editions) the designers should rethink their addition to the Core and maybe instead add them in a rules module later if there is demand.</blockquote>

Verification