Pathing and Movement news

There are a lot of things to consider with movement in a 3D game, even a grid-based one like Trudy's Mechanicals. Some of these issues we tackled ahead of time, while others required playtesting and iteration.

Below are some notable points from our early prototyping using the 'Bauk' unit type.

The grizzly Bauk.

• We aimed to get away from the abstract feeling of a board game, so we included various movement options such as hovering and jumping. However, most tactics games only support vertical jumps, while in Trudy all units have a "high jump" and "long jump" attribute allowing them to leap across various gaps and distances. Bauk has a vertical jump of '2' and a horizontal jump of '1'.
• Vertical inclines of '1' (appear as half a cube tall in the map, about 1/3 of the character's height) are traversed automatically without jumping. The unit's y position interpolates between the bottom of the cube and its top while walking. This still looks a little odd, but we're working on polishing it as we don't want to break up movement with too many jumps.
• Jumping down is possible if the vertical distance is less than unit height + unit's vertical jump + 2. It's still possible to get pushed off a ledge and fall down a greater height, but this results in damage and a "crumpled" status effect (unit's movement range is reduced). We thought about providing the freedom to jump down from any summit, but this resulted in confusion and frustration whenever players killed off their own units by dropping them from a great height.
• Getting pushed into a pit is lethal for regular units, but hovering/flying units can traverse these gaps.
• Diagonal movement and jumping is possible, but only on 45% degree angles and if there are no obstacles perpendicular to the movement path. The reason for this limitation is that all units/props are contained within cells, and travelling between them leads to all sorts of messiness: model clipping, ability-range conflicts, etc.

Diagonal movement also proved problematic when it comes to defining movement ranges.

Diamond Range

In most typical tactics games, there is no diagonal movement resulting in a diamond shaped movement area:

Square Range

Since we have diagonal movement, assigning the same cost to diagonal movement as cardinal movement created an awkward square shape:

Circle Range

Hex-based tiles mostly avoid issues of diagonal movement, but we were committed to squares and wanted a solution that was in-between the above two options.

Logically if the cost of moving up/down/left/right is '1' point, then moving up-right/down-right/down-left/up-left should cost '1.4' points (the square root of '2'). Of course dealing with tiles is a bit more binary (you can walk across '1' tile or '2' tiles, never '1.4' tiles), so we multiplied these values by two and rounded 'em up. This was a similar approach to what old Civilization games used to do in order to achieve a natural movement range. The end result was cardinal movement costing '2' points, and diagonal movement costing '3' points.

This is how it looks in action:

The algorithm made for a more natural radius; a circular area projected onto individual tiles. However, there was one reason why we didn't instantly jump on this solution: the ability of units to constantly circle each other using diagonal movement.

This is something of a pet peeve of mine in tactics games. Since many titles implement different vulnerabilities for unit sides (front, left/right, back), melee-based troops tend to hopscotch around each other in order to attack the back (traditionally the most vulnerable spot). This is particularly awkward when two melee units are isolated but still within range of each other. With diagonal movement, this sort of tedious but strategic behaviour becomes even more tempting.

The issue can be alleviated with unit-specific abilities, e.g., some units can only attack with at least one tile of space between them and their target, others get a free hit on any adjacent enemies that try to walk away, while others still always turn to the attacking direction. While these all help to limit hopscotching, I was still concerned over the behaviour manifesting itself without a global rule to discourage it.

Our solution was the aforementioned diagonal movement caveat: it's only possible to move diagonally if there's nothing perpendicular to the movement path, i.e., to the left or right of it. This way a unit can't walk around to the back of its enemy in just two steps, but has to take the full four-step route.

A few other rules helped to avoid the issue as well, namely the ability to cause extra damage by shoving the enemy into a wall or off a ledge, and the potential to score a critical hit when attacking from an elevation. Combined with elemental vulnerabilities and unique modifiers, we hope to present various strategic options at each unit's turn that rarely boil down to the obvious "

Let us know what you think of this approach!