DBMM For The Befuddled – Part 9

Here’s another issue that I’ve come across in a game that raises an issue with DBMM.  Which of the two options below is correct:



For me this requires clarification as my opponent claimed that the major TZ overlap over rode the closer enemy and used it to side step a closer enemy and gain advantage by attacking C where the combat factors greatly favoured X.

As pointed out on the Yahoo! DBMM list sideways movement in the Threat Zone (TZ) is allowed but it must be used to line up with the element “most directly in front".  For the move on the left to be correct “most directly” would have to mean "the least distance to contact" whilst for the move on the right it would have to be "encompasses most of the length of the front edge".

Again I hope this will be resolved in the upcoming round of clarifications. Let’s hope so.

Update: Wed, 21 Jan 2009

Well after two and a half months a clarification of sort has emerged.  I posted this on the DBMMlist as part of a discussion of items that needed clarifying.  Chris Handley, who was heavily involved in play testing the rules with Phil Barker, replied as follows:



So an element in two Threat Zones (TZ) can, and must, contact the enemy element with the greater overlap (most directly in front) even if it is further away.  Sorted.

The clarity is nice but after all this messing about I find I don’t really like the intended outcome; it’s inelegant. It works fine when the enemy is in one line but in these circumstances it forces a counter-intuitive “sidestep” which looks awkward and feels wrong to me.

Updated: Tue, 26 May 2009

Today, Phil Barker posted a proposal on the DBMM list which, if it makes it into DBMM v1.1, would resolve this issue:

“Any move that will enter; or starts in, or at the front edge of, an enemy Threat Zone (TZ) must immediately line up opposite[,] or in front edge-to-front edge combat with[,] the TZ-ing [sic] element most directly in front.”

I like this rule because it means that the starting situation in the diagrams above would never occur.  If you tried to create them by moving X straight ahead towards ABC, X would always contact the TZ of B first and so would have to immediately line up with B.

Obviously, you could create the staring position by moving X around B’s TZ but in the same message Barker has also proposed that:

“An element can change direction to pass around a terrain feature or [another] element but not to avoid a TZ.”

So that’s not possible either.  I have to say I like this proposal as it would eliminate the awkward and counter-intuitive “sidestep” mentioned above.

Let’s see if it survives the DBMMlist and makes it into DBMM v1.1 by the end of the year.