Pathing & Movement on a 3D Grid

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.

Movement Overview

Diagonal movement also proved problematic when it came 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.

Hopscotching

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 strategically beneficial 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 "attack the back" option.

Let us know what you think of this approach!

Radek Koncewicz is the CEO and creative lead of Incubator Games, and also runs the game design blog Significant-Bits. Feel free to hit him up via @JustRadek.