Trudy's Mechanicals, Steampunk Tactics *New Trailer*

Started by
41 comments, last by Skall 8 years, 4 months ago

Art art art:

ygo8UyE.jpg
The feathered gentry of Trudy.

KxVWuff.jpg
Forgotten machines.

ZaJPbu4.jpg
Marketplace concepts.

qewOfVh.jpg
Map layout for the Aerie's Lyceum.

wMtIA21.jpg
A few UI concepts.

Advertisement

The art is spectacular. Very warm, rusty, and metallic. The steampunk theme is used very creatively.

Thanks Pat, appreciate it!

Pathing & Movement:

Qd7YBhD.gif

There are a lot of things to consider with pathfinding in a 3D game, even a grid-based one. Here's how we're tackling some of the issues:

  • Wanting Trudy to feel kinetic and not like an abstract board game, we're including various movement options such as falling and jumping. However, most tactics games only allow vertical jumping. 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. It still looks a little odd, but will hopefully get polished up and look natural; 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" state (unit's movement range is reduced). We thought about providing the freedom to jump down from any summit, but the confusion of getting damaged and suicide-ing units didn't prove worth it.
  • Getting pushed into a pit is instant death 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.

The Bauk if a fairly grounded unit so we might have to solve more traversal issues once hovering/flying (and potentially grapple-based) units are added to the mix.

1jV9TXe.gif

Another batch of concepts.

J6RoqXA.jpg
More feathered outfits (on account of the game taking place on an airship).

kJUW0LJ.jpg
Scrap-bot sketch, and a more insidious sentinel automaton.

IG36ZEz.jpg
Rotating cannon-mace and a statue concept that serves as a lamp.

WAuQwby.jpg
Crumbled level sketch with houses dotting the faces of the pillar.

2ZCqrZw.jpg
Mechanized walls of the Clockwork Labyrinth.

The art is amazing. I want to see more! And the picture with the logo is very cool too. Congrats for the editor too.

Thank you, it's courtesy of the very talented @dekogame and LeJeanX3!

While on the topic of movement, I'm curious as to what people think about our hybrid approach to ranges.

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

AfDOsMv.gif

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

fNiJweL.gif

Since we're committed to squares rather than hexes, we wanted a solution that was in-between the two options in order to obtain the most natural feel. If the cost of moving up/down/left/right is '1' point, then moving up-right/down-right/down-left/up-left should cost roughly '1.4' points (the square root of '2'). Since dealing with tiles is a bit more binary (you can walk across '1' tile or '2' tiles, never '1.4' tiles), we multiplied these values by two and rounded 'em up similarly to what old Civilization games used to do. The end result is that cardinal movement costs '2' points, and diagonal movement costs '3' points.

This is how it looks in action:

VFLgqw0.gif

The algorithm makes 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 as a shortcut.

This is something of a pet peeve of mine in tactics games. Since many of them implement the idea of different vulnerabilities for a unit's sides (forward, left/right, back), melee units tend to hopscotch around each other in order to attack the most vulnerable spot: the back. This is particularly awkward and tedious when two melee units are isolated but within range of each other, and diagonal movement only makes this easier to accomplish.

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, etc. 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 steps 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" choice.

PIYHIPT.gif

Let us know what you think of our approach!

Over time, Tactics games -- or just games with turn-based combat -- have adopted a few common interface concepts. Here are a few conventions we're considering for Trudy:

1). Player's team is colour-coded blue, the enemy's red, and NPCs green.
aZO8P3R.png

2). Movement ranges reflect team colours, are often represented with filled in tiles.
RidtYIb.jpg

3). Alternatively, movement ranges are represented via an outline that traces the edges of the movement range.
oe7K37z.jpg

4). Multiple ranges are used to indicate that a unit can travel further but at a cost, e.g., can't attack, extra resources need to be spent to attack, etc.
GwX189U.jpg

Blue/Red/Green team-colouring seems like a no-brainer so we'll probably keep with that convention. We'll also most likely go with outlines instead of filled-in tiles to keep UI real-estate to a minimum. However, a bigger factor for using outlines is our desire to save filled-in tiles as indicators for areas from which a unit can attack.

Tom Clancy's Ghost Recon: Shadow Wars is the only game I know of that did this and it worked rather well:

y0oXHDW.jpg

Granted we won't be defaulting to green tiles but potentially stick to team colours. This, however, brings up another issue -- secondary ranges are often colour-coded yellow:

G7FyRL5.jpg

This always seemed a bit counter intuitive to me as gold highlights are standard indicators for something that's interactive. The association in my head is that yellow == can act, team-colour == can move, but not necessarily do anything else.

We might just flip the convention here -- make move+act outlines gold, and move outlines team-coloured -- or simply go with white outlines like Shadowrun Returns:

AAHkrjJ.jpg

I think I have a slight preference for coloured ranges as they're easier to parse, but I'm not sure if our approach would be counter intuitive to XCom players; what do you guys think?

It would just be a different learning curve. All games have them and if the mechanic is easily understood the differences with other games won't be a problem.

This topic is closed to new replies.

Advertisement