Trudy's Mechanicals, Steampunk Tactics *New Trailer*

Looks beautiful! I love the steampunk theme and the interactice environments. I'll be keeping track of this!

Thank you! A few months ago we also decided to do a proof of concept for Trudy, which included mocking up a few scenes and creating a small tech-demo.


Trudy's original battle mockup.

The purpose of the tech-demo was to gauge some of the technical difficulties we'd encounter, settle on a few design issues, and use as potential pitch-material for grants. Some of the key points we wanted to implement and test were:

• SDL-based rendering and input (for future ease-of-porting).
• Overall scales of tiles/units/objects and camera positioning.
• Orthographic projection vs. perspective projection with slight parallax.
• Texture pixel density/UV space.
• Pathfinding in 3D, including slopes and jumps.
• Usable and destructible objects that affected pathfinding.
• World-space indicators for movement ranges, usable objects, etc.
• Basic UI system for buttons/menus in screen-space.
• 3D particles that could collide with scene geometry.
• Basic sounds and music using OpenAL.

We started off by doing a level sketch on paper:



And then proceeded to model it in Maya along with the required props and a single unit:



It took a good couple of weeks to put it all together, but we came away from the experience with a few important lessons:

• Perspective projection -- no matter how slight -- added a lot of life to the scene. We still liked the old-school isometric look, but even a small amount of perspective (similar to Harebrained's Shadowrun Returns) made moving the camera feel much nicer.
• Being able to create levels that could be rotated freed up a LOT of options for level design. We'll most likely still add some sort of a graphical effect for units obscured by level geometry so they remain visible, but we won't limit ourselves on overall architecture.
• Texture space is worth it. Our single "mega texture" that covered the whole map looked quite blurry compared to the single character and some of the props.
• Animations played out slower than expected and the lack of blending/interpolation really showed.
• Colliding particles with level geometry worked out really well! It avoided awkward clipping issues and provided a surprising amount of polish, e.g., explosion debris splashing in water, rain drops hitting the surface of a bridge, etc.

Two GIFs of movement and attacking from our tech demo.

While we were quite pleased with the demo, it wasn't something we could build upon to make a full game. There was no proper level/scene editor, collision markers, AI, font rendering, resource allocation, etc. While individual pieces could be taken out and reused, we started on the overall engine pretty much from scratch and are currently building it up.

We learned a fair deal preparing for and making our first character from scratch, the mythical and semi-mechanized Bauk.

The idea behind the unit was a resistant damage-sponge that could reflect projectiles using a large, spinning shield, and also use it to attack his enemies much like a Spartan. Since the unit is one of the few aboard the ship created specifically for fighting, we also indulged a bit by turning his right arm into a shrapnel-firing cannon.



The link to the bear come through the unit’s general hardiness and resistance (he can shake off all status effects after one round), and various aesthetic touches. The most obvious is the bear-cap atop his head, as well as the general stockiness and wild mane of hair. We also embedded a necklace of bear teeth into his beard to provide a semblance of a lower jaw, and attached claws to the ends of the cannon and foot-coverings. A patchwork of leathery fur-trim further added to the ursine look.



Colouring wise we looked to Valve’s Dota 2 approach for guidelines: http://media.steampowered.com/apps/dota2/workshop/Dota2CharacterArtGuide.pdf The PDF is worth checking out even if you’re not making a 3D game, but it was particularly applicable for us given Trudy’s classic iso-style perspective. Of particular usefulness were the tips on picking colour palettes so as to keep units distinct beyond just their silhouettes, and painting techniques (darker at the feet and brighter at the torso and head).

The character itself was modeled in Maya and used 2,698 vertices (2,9120 polygons). It was carved from a template we created as a base for the humanoid units; you can see the time-lapse process below:



The density of the polygons is distributed fairly evenly, with special care paid to the areas that require deformations for animations (joints, beard, cloak). Static components that are animated like the cannon don't require as much detail. Here's a checkered UV layout showing the overall distribution:



For texture mapping, we decided to try out Physically Based Rendering. PBR is a method that describes surface characteristics in more precision than typical approaches, but it also requires a few more maps to be generated. There's no de facto standard for PBR, but here's a good overview that we roughly followed: http://www.fxguide.com/featured/game-environments-parta-remember-me-rendering/

Below are the different maps we created for PBR from a base diffuse map:

Albedo – made by hand with cut out transparencies and dimmed reflective elements such as the breast plate.


Roughness – made by hand to indicate reflective (white) and non-reflective (black) surfaces.


Normal – generated using nDo2 for surface depth via bump mapping. nDo2 is a great Photoshop plugin that can automate normal map creation and allows for painting in normals that aren’t necessarily visible in the texture map itself. Below is an example of using nDo2 and the normal map we created with it.



Substance – made by hand to separate metallic surfaces at near-full brightness for PBR when factored in with the other maps.


And here are the end results, the base map and the PBR version:



One thing we'll definitely keep in mind going forward is the amount of detail on the diffuse map. We found that a lot of the detail got lost in the noise and made the surface a bit less readable. It didn't muddle up the unit when viewed in-game too much, but there were probably too many folds and creases in the leather and fur parts that we'll smooth out later on.

While rigging Bauk, we started off with the left side of the skeleton so as to easily mirror all the symmetrical parts. Asymmetrical components can be tweaked later on, but this really helps speed up rigging and symmetric animations like walking.


Bauk's skeleton; the left side is mirrored for the most part to complete the structure.


The full rig with all its controllers.

One of our primary concerns with animating Bauk was his shield. The shield can either spin or appear static based on a passive state, which means all his animations would have to be doubled and there'd be some awkwardness if the shield started/stopped spinning mid-way through an animation. To compensate for this we bit the bullet and looked into using locators. We've had a few issues implementing 'em in-engine as they add a substantial amount of complexity, but it would've been an issue for various units whose weapons and tools detach during use.

Out of all the isometric and/or 3D level editors I've seen, my personal favourite for quick prototyping is Valve's Puzzle Creator in Portal 2.



Granted it's a very specific editor that's tightly coupled with the game itself, but its interface is much more streamlined and intuitive than typical 3D editors. Extruding/recessing surfaces is a very quick way of mapping out geometric 3D spaces, and it's much less finicky than dragging-and-dropping 3D objects and transforming them to make a whole, or carving out spaces from a 3D block.

We're just beginning to make our version of it that's more generic/suitable for Trudy, but I'm very excited about it so far.



Here's some quick info:

• Uses OpenGL and Java SWT for portability, although this makes it a bit of a processing hog ATM.
• Grid squares are slightly different tints of grey to help differentiate between them.
• Ambient occlusion is used to give the terrain depth -- this helps a LOT with visually parsing the topography, although the implementation is too grainy right now.
• Camera is in and allows for zooming and full rotation.
• Any surface can be selected from any angle, and multiple surfaces can be selected using Ctrl.
• Extruding/recessing surfaces is in, as is proper merging (extruding two different surfaces into the same coordainte).
• Recessing the floor to nothingness creates bottomless pits in the game.
• Height of blocks is visually smaller than width/length, but it's an arbitrary ratio catered to Trudy's needs,

There are still a lot of features to implement and kinks to iron out, but I'm really happy with how it's progressing so far. Here's a smoother video of the gifs above:

Level editor updates!

• Clicking and dragging now selects an arbitrary area of a single surface.
  
• Double clicking selects an entire surface (wall or floor).
  
• Holding Ctrl. allows for appending to the current selection using the above controls.
  
  
  
  
  
  
  
  • Any floor-cell can be turned into a slope.
    
  • Slopes come in 22.5 and 45 degree variations -- anything higher looked odd when traversing it, and anything lower was not noticeable enough.
    
  • Slopes can face any one of the four cardinal directions and can be rotated independently.
    
    
    We've also added support for extending the map in any direction and fixed up some rendering bugs with ambient occlusion.

Now with some colour-coding!



Any selected area can be applied a single colour. This is not actually for in-game purposes, but rather an initial step for further level processing. Blue indicates standard walkable areas, dark blue impassable fences, yellow interactive elements, purple automated props, orange destructible objects, green doorways, and the rest are mostly for aesthetic cues, e.g., what sort of prop/texture should appear there in the final version.

Here are a couple snapshots from our maps:


The Forge Arena -- the purple bits represent floor grates and mounted pipes through which fire and/or steam can shoot out.


The Aerie's Lyceum. The bottom-left part will be a cable-car station.


The sprawling, ramshackle Warrens. Lots of verticality in these stages.

Art Update:


Decorations for the luxurious Aerie. The floating hot-air balloon gondolas are the preferred method of conveyance for the rich.


The ramshackle Warrens, where most of Trudy's populace live and work.


Generator-level sketch for a map in the sewer-like Underworld.


Concepts for an alarm station that summons friendly NPC Constables and a healing station which recharges the HP of all surrounding units.


Initial sketches for a Constable, the default non-Mechanical law enforcement unit of Trudy.


Coloured Constable sketches. The high-tech plasma rifle was replaced with an energy baton to better suit the setting.

More art updates:


A mood piece for the Sleepless Forge.


Level sketch of the Aerie's Lyceum. Inside are housed various punchcard-libraries and technology blueprints of yore.


Miscellaneous prop sketches. Yeah, we couldn't resist putting in an explosive barrel.


Concepts for the creepy, diminutive, and artificial Homunculi.


Coloured variations of a Homunculus.

Art art art:


The feathered gentry of Trudy.


Forgotten machines.


Marketplace concepts.


Map layout for the Aerie's Lyceum.


A few UI concepts.

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

Thanks Pat, appreciate it!

Pathing & Movement:



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.

Another batch of concepts.


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


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


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


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


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:



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



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:



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.



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.


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


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


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.


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:



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:



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:



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?