AlexSpl
Auto-translated
Berserker: A Deeper Look at Distances
A unit under the "Berserker" effect always attacks the nearest unit. However, the term "nearest" doesn't always align with our understanding of distances on the battlefield. We can conceptually divide the battlefield cells into non-overlapping classes relative to the hex where the "Berserker" unit is located. The attack will target a random unit from the class with the highest priority.
Screenshot #1 shows class A.
Screenshot #2 shows class B.
Screenshot #3 shows class C.
1. Classes A and B have the SAME priority (it makes sense to talk about combining classes A+B);
2. The priority of class C is lower than the priority of class A+B: P(C) < P(A+B).
These simple rules allow us to predict which units might be attacked by a unit under the "Berserker" effect.
For example, in screenshot #4, only two gargoyles can be attacked by the djinn because these gargoyles are on cells belonging to class B, while the rest are in class C.
Of course, in practice, there's no need to think about these classes: the rule is intuitively understandable due to the symmetry. You can also create classes D, E, etc. (all of them will be symmetrical, some possibly with the same priorities).
Add to the above the previous post, as well as the rules for pathfinding on the battlefield (see the thread with FizMiG), and you get a quite consistent picture of the "Berserker".
By the way, flying units really don't see obstacles: whether it's a log or the first hex of a two-hex unit. In screenshot #5, the djinn will skip their turn because of the log. If the djinn were replaced, for example, with goblins, the attack would occur (ground units under the "Berserker" effect are much smarter).
Yes, and what about pathfinding? At first, it's not clear why the djinn skip their turn in screenshot #6. Everything falls into place if we consider that the attack is hindered by an obstacle (a lake), and attacking in another way is not possible due to the requirement of a unique path.
P.S. The case described by Dirty_Player can be generalized (see screenshot #7; I didn't fill all the cells of class A+B to avoid overloading the screenshot).
A unit under the "Berserker" effect always attacks the nearest unit. However, the term "nearest" doesn't always align with our understanding of distances on the battlefield. We can conceptually divide the battlefield cells into non-overlapping classes relative to the hex where the "Berserker" unit is located. The attack will target a random unit from the class with the highest priority.
Screenshot #1 shows class A.
Screenshot #2 shows class B.
Screenshot #3 shows class C.
1. Classes A and B have the SAME priority (it makes sense to talk about combining classes A+B);
2. The priority of class C is lower than the priority of class A+B: P(C) < P(A+B).
These simple rules allow us to predict which units might be attacked by a unit under the "Berserker" effect.
For example, in screenshot #4, only two gargoyles can be attacked by the djinn because these gargoyles are on cells belonging to class B, while the rest are in class C.
Of course, in practice, there's no need to think about these classes: the rule is intuitively understandable due to the symmetry. You can also create classes D, E, etc. (all of them will be symmetrical, some possibly with the same priorities).
Add to the above the previous post, as well as the rules for pathfinding on the battlefield (see the thread with FizMiG), and you get a quite consistent picture of the "Berserker".
By the way, flying units really don't see obstacles: whether it's a log or the first hex of a two-hex unit. In screenshot #5, the djinn will skip their turn because of the log. If the djinn were replaced, for example, with goblins, the attack would occur (ground units under the "Berserker" effect are much smarter).
Yes, and what about pathfinding? At first, it's not clear why the djinn skip their turn in screenshot #6. Everything falls into place if we consider that the attack is hindered by an obstacle (a lake), and attacking in another way is not possible due to the requirement of a unique path.
P.S. The case described by Dirty_Player can be generalized (see screenshot #7; I didn't fill all the cells of class A+B to avoid overloading the screenshot).