Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
November 20, 2017
arrowPress Releases






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Pathing & Movement on a 3D Grid

by Radek Koncewicz on 03/06/15 07:16:00 pm   Expert Blogs   Featured Blogs

9 comments Share on Twitter    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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.

baukThe grizzly Bauk.

Movement Overview

  • 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.
Qd7YBhD.gif
  • 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.
1jV9TXe.gif
  • 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 came to defining movement ranges.

Diamond Range

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

path_triangle

Square Range

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

path_square

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:

path_circle

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.

trudy_circle3D

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.


Related Jobs

TheWaveVR
TheWaveVR — Austin, Texas, United States
[11.18.17]

GAME DESIGNER / PRODUCT MANAGER
Heart Machine
Heart Machine — Los Angeles, California, United States
[11.18.17]

Environment Artist
Bartlet Jones Supernatural Detective Agency Inc.
Bartlet Jones Supernatural Detective Agency Inc. — San Diego, California, United States
[11.17.17]

Senior Technical Artist
Pixel Pool
Pixel Pool — Portland, Oregon, United States
[11.17.17]

Software Engineer





Loading Comments

loader image