Making your own 3D engine is a somewhat daunting and time consuming endeavour, but being technically inquisitive we decided to take the plunge with Trudy's Mechanicals.

Trudy's Mechanicals is a turn-based strategy game that takes place on a giant floating Steampunk dirigible. The tactics genre is having something of a resurgence -- and Steampunk is no longer a niche aesthetic -- so here's what we're hoping will make our game stand out:

Unit Variety - Many SRPGs have long relied on a combination of melee fighter, archer, mage, and priest serving as the pillars of all unit types. We'd like to break away from this format and make each class very unique in both appearance and function. The approach is closer to designing characters in fighting games than in tactics ones, and it encourages each one to have a unique play-style.

For example, our Supplier unit serves a support role early in battle; his attacks are feeble, but he's capable of activating machinery from afar and pulling in enemies using a large suction fan. Towards the end of the fight, however, he can suck in and process corpses littering the battlefield (of both allies and enemies!) and use them to launch devastating attacks.

Offbeat Steampunk - While we like the industrial machinery and intricate mechanisms common to Steampunk, we wanted to create an aesthetic that stood out a bit. The world of Trudy is a grimier, more grotesque place than the gentlemanly courts of Victoriana: coal burning furnaces have polluted the skies and the poor sell their bodies in order to become half-man/half-machine labourers.

We also shifted the cultural heritage East taking some cues from Slavic and Greek fashions and nomenclature. Gone are bowler hats and fine brandies, replaced by fur caps and vegetable alcohols.

Interactive Environments - While individual tile types occasionally provide passive bonuses, maps in tactics games tend to be entirely static. We wanted to breathe more life into them, and also go beyond simple destructible props.

In Trudy it's possible to extend out bridges to form new paths, flood areas (and then electrocute the drenched units), redirect exhausts to provide smokey cover, etc.

Streamlined UI - Battles in tactics games tend to take a long time to play out. While this isn't bad in and of itself, a big reason for the extended durations is the interface. It often takes a very long time to figure out the movement and attack ranges of all of the player's troops and those of the enemy. Once that information is gathered and processed, and a decision is reached, even more time is spent inputting an action, previewing its results, confirming its execution, and finally watching it play out.

Since these are common issues, we're focusing on presenting as much information as possible while minimizing input logistics. One way we're streamlining input is filling-in movement range tiles for only those locations from which the current unit can use an ability. Mouse-overing these tiles also shows exactly which abilities can be used on which units allowing a quicker way to parse viable options.

Voluntary Content - While we think we've created an imaginative world and have an interesting story to tell, some might not dig that aspect as much. We've certainly played our share of games with seemingly endless streams of dialogue, so we sympathize. To limit this problem, we're not only making all cutscene-like content fully skipable, but also providing a lot of it via optional content.

And here's a little teaser trailer we put together:

Eventually we'll post more in-depth articles on our website (and create one for Trudy itself), but in the meantime we thought it'd be a good idea to post about our trials and tribulation on Twitter/Tumblr and, of course here, as a devlog. Let us know what you think!

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.

">Video of Bauk and his detached shield.

With the system in place, we tackled a few more animations:

">Video of all of Bauk's early animations.

One thing I'd definitely advise keeping in mind is that it's difficult to gauge what the walking/running animation speed should be relative to in-game movement speed. That's something that's bit us before as those animations tend to be the first ones in, but inevitably they result in a "running on a treadmill" (animates too quickly) or ice-skating (animates too slowly) effects.

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:

">Video of early level editor for Trudy.

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.