Upgrade your account to a Community Supporter account and remove most of the site ads.
Rocket your D&D 5E and Level Up: Advanced 5E games into space! Alpha Star Magazine Is Launching... Right Now!

Reply to thread

Message: <blockquote data-quote="Imban" data-source="post: 4138944" data-attributes="member: 29206">So both the Ranger and Warlock, from the playtest, have mechanics which allow them to "mark" the nearest enemy, who takes significantly more damage from anything they do from that point forth - +1d8 for the ranger, and +1d6 for the Warlock. The principal reason I can see for why these target-marks only work on the nearest enemy is to discourage ranged strikers from attacking "back row" characters, and by cutting a huge chunk out of the damage they deal if they try, make it tactically inviable to do so. As such, even archers will typically fire upon the hard targets in the front, rather than the squishies in the back row.At least in my experience, I've found this to be... incompatible with how tactics have always worked. Yes, it makes it easier for defenders to defend their party's controllers and strikers, but in a way that, much more than marking already does, creates a totally artificial tactical situation.Because, with the way it is now, the tactically viable things for archers/warlocks to do, in 90% of cases, is either fire at the tank and ignore the squishies he's protecting, despite having a bow / shooting magical energy, or dash through the enemy lines *with a bow* to mark a squishy. Unless someone's about to drop, it rarely makes sense to do otherwise. This seems like a very undesirable state of affairs to me. As far as I can see, the obvious house rule to change this would be to allow ranged strikers to mark any target of their choosing, perhaps with some additional restriction to discourage them from changing targets every round. The implications of this would be that ranged attackers can target the vulnerable "back row" members of the party, which I consider the point of having ranged attackers in the first place.Any alternative viewpoints, explanations for why they may have chosen this implementation, et cetera are welcome.</blockquote>

Verification