TIGSource Forums

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 (http://trudysmechanicals.com/). 

---

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!

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


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 (https://www.libsdl.org/) 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 (http://www.openal.org/).

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 (http://image.jeuxvideo.com/images/pc/s/h/shadowrun-returns-pc-1365587821-002.jpg)) 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.

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. (http://en.wikipedia.org/wiki/Bauk_%28mythology%29)

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.

(http://i.imgur.com/QGQqZEk.jpg)

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.

(http://i.imgur.com/DgAmQiy.jpg)

Colouring wise we looked to Valve’s Dota 2 approach for guidelines: http://media.steampowered.com/apps/dota2/workshop/Dota2CharacterArtGuide.pdf (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:

(http://i.imgur.com/UYg1wRx.gif)

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:

(http://i.imgur.com/LWOpzhP.jpg)

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/ (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.
(http://i.imgur.com/D64Gp3c.jpg)

Roughness – made by hand to indicate reflective (white) and non-reflective (black) surfaces.
(http://i.imgur.com/FMcYJqw.jpg)

Normal – generated using nDo2 (http://www.quixel.se/index2.php) 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.
(http://i.imgur.com/A0ie1Gn.jpg)
(http://i.imgur.com/kUXeOH2.jpg)

Substance – made by hand to separate metallic surfaces at near-full brightness for PBR when factored in with the other maps.
(http://i.imgur.com/SQCX7Bc.jpg)

And here are the end results, the base map and the PBR version:
(http://i.imgur.com/FziAbJP.jpg)
(http://i.imgur.com/OS4JajG.jpg)

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.

(http://i.imgur.com/E4jqYCf.jpg)
Bauk's skeleton; the left side is mirrored for the most part to complete the structure.

(http://i.imgur.com/behxR6f.jpg)
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 (http://nccastaff.bournemouth.ac.uk/jmacey/RobTheBloke/www/research/maya/mfnlocator.htm). 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. (https://www.youtube.com/watch?v=BcDyY3JQi2Q)

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

(http://i.imgur.com/awivM8I.gif)(http://i.imgur.com/mJ5HnOq.gif)(http://i.imgur.com/zRcy3nz.gif)

Video of all of Bauk's early animations. (https://www.youtube.com/watch?v=3u8waPH-0HM)

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 (http://theportalwiki.com/wiki/Puzzle_Creator) in Portal 2.

(http://i.imgur.com/87JDDQ8.jpg)

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.

(http://i.imgur.com/GsHkLF9.jpg)

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.

(http://i.imgur.com/QfVHOCH.gif)(http://i.imgur.com/muFlnke.gif)

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 (https://www.youtube.com/watch?v=5uHHMDViG6Q).

Awesome, love the editor idea

Thanks! We'll be posting updates as the (rather long) feature list for the editor gets implemented.

We've got an abstract test level and a unit, so it's time to begin with pathfinding!

(http://i.imgur.com/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 gaps as well. 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 interpolate 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 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 seem 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 in 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.

(http://i.imgur.com/1jV9TXe.gif)

Video of Bauk's map navigation. (https://www.youtube.com/watch?v=cDuAYZYuNSE)

Some high level vision and polish going on here, can't wait to see more. The name seems really odd, and glad to see some subtly with the steam theme. Amazing stuff.

Thanks a lot! The name is something of a minor plot point: it refers to the dirigible itself, and how no one seems to remember where the it came from.

I'm in love with your art :handclap: :o

Thank you very much; I'll be posting more of our concept art once we get through the current level-related tech stuff.

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:

(http://i.imgur.com/AfDOsMv.gif)

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

(http://i.imgur.com/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:

(http://i.imgur.com/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.

(http://i.imgur.com/PIYHIPT.gif)

Let us know what you think of our approach!

New art!

(http://i.imgur.com/QnzO7fb.jpg)
Decorations for the luxurious Aerie. The floating hot-air balloon gondolas are the preferred method of conveyance for the rich.

(http://i.imgur.com/TqoLx3O.jpg)
The ramshackle Warrens, where most of Trudy's populace live and work.

(http://i.imgur.com/06Pa813.jpg)
Generator-level sketch for a map in the sewer-like Underworld.

(http://i.imgur.com/ju8I99h.jpg)
Concepts for an alarm station that summons friendly NPC Constables and a healing station which recharges the HP of all surrounding units.

(http://i.imgur.com/OlChy9z.jpg)
Initial sketches for a Constable, the default non-Mechanical law enforcement unit of Trudy.

(http://i.imgur.com/XMgcF00.jpg)
Coloured Constable sketches. The high-tech plasma rifle was replaced with an energy baton to better suit the setting.

This game is looking gorgeous, it seems like a world I could live in for days!

Thanks! Hopefully we'll be able to fully realize this world in-game given the usual constraints.

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.
(http://i.imgur.com/aZO8P3R.png)

2). Movement ranges reflect team colours, are often represented with filled in tiles.
(http://i.imgur.com/RidtYIb.jpg)

3). Alternatively, movement ranges are represented via an outline that traces the edges of the movement range.
(http://i.imgur.com/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.
(http://i.imgur.com/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:

(http://i.imgur.com/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:

(http://i.imgur.com/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:

(http://i.imgur.com/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?

Forgot to mention: for movement paths and outlines we'd like to go with smooth, curving lines over sharp, angular ones. Quadratic bezier curves can be used to achieve this look, and here's our first shot at it going through a colour-cycle:

(http://i.imgur.com/bd9XJfa.gif)

Level editor updates!

(http://i.imgur.com/igp7A2F.gif)

• 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.

(http://i.imgur.com/5qYNFLx.gif)

• 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.

Moving pretty fast on this. Looks great.

Thanks! There are still a bunch of features for the level itself -- nevermind the game -- but we're trying to be consistent with pushing ahead.

You're speed is pretty impressive, as is how experimental you've been.

My only comment is that adding a conditional to the movement range will be confusing for players. Making it harder for them to estimate next turn's moves. Granted for a tactics game that sounds fine.

I'm facing the same questions about interface in my own project so that was interesting. However I don't really see the point of colour-coding the movement range in team colour. I got the impression that this will be a single player game, and then you would probably only see your own movement anyway. If you're planning to include a hot-seat mode I could see the point, but I'd personally solve it by indicating the active team in another way, like a team banner on the UI or something.

The game looks cool though, I really like that you're not using an established fantasy setting.

Looks great. I love tactics games.
I hope it's going to have a comprehensive single player campaign.  :toastL:

We're not too worried about this element as it has worked rather well for various turn-based combat games in recent years. One of the benefits of this approach is that it's not quite as complicated as an action-point system, but it does allow for more flexibility than typical SRPGs.

One thing I'm not a huge fan of that's common to tactics games is the gradual inching-forward of each army, and having a secondary movement range does help to get the units into the fray much quicker while allowing for strategic retreat. To further compensate for potential downtime, we're also trying to give each unit a special defense ability when there's no target in range. In addition to raising def% and being able to pick a facing direction, defending can potentially also reload weapons, summon allies, heal, set down a projectile-deflecting shield, etc.

The movement indicator of the opposition is there for potential preview options/range estimates, but it's also used to indicate the team itself. Underneath each unit, the tile is filled with the team colour. Since we're not palette swapping the characters as in a typical 2D game, and a single unit type can exist in both teams, it's very easy to mix them up without colour-coding. 

Yup, we're definitely aiming for one. It's a lot more resource-intensive than making a multiplayer-only title, but creating a (hopefully) cool campaign in a cool setting was always one of the driving points.

More concepts:

(http://i.imgur.com/8Ik45Js.jpg)
A mood piece for the Sleepless Forge.

(http://i.imgur.com/ag9Gipi.jpg)
Level sketch of the Aerie's Lyceum. Inside are housed various punchcard-libraries and technology blueprints of yore.

(http://i.imgur.com/8HANYFb.jpg)
Miscellaneous prop sketches. Yeah, we couldn't resist putting in an explosive barrel.

(http://i.imgur.com/mAFv1oh.jpg)
Concepts for the creepy, diminutive, and artificial Homunculi.

(http://i.imgur.com/vX6aJez.jpg)
Coloured variations of a Homunculus.

(http://i.imgur.com/ob7xwaC.jpg)
Initial mockup of the forge arena.

One of the first gameplay elements we'd like to iterate on is the concept of an arena battle where the crowd and/or a "battle master" can have an impact on the fight itself. These modifiers range from items being tossed down by the crowd in the rafters, to the layout of the map itself changing based on in-battle events.

To prototype this gameplay, we've decided to mock up an arena in Trudy's "Sleepless Forge" district.

(http://i.imgur.com/yNkcmj9.jpg)
Destructible barrels can cause a fiery explosion or shower units in oil making them more vulnerable to heat-based attacks.

The arena battlefield is asymmetric with a giant furnace leaning against one wall. In the center rests a rough hill of terminals and crates, while the opposite end of the furnace is used as storage for various carts and hazardous materials.

(http://i.imgur.com/fIP4w4S.jpg)
The mine carts can be pushed to knock around enemies, while the terminals activate the conveyors leading up to the furnace.

Various pipework and heat grates also present dangerous areas that can be activated based on each team's performance. There's no real safe spot in the arena, but plenty of points of interest that can either provide an advantage or backfire in spectacular fashion.

(http://i.imgur.com/S298fD4.jpg)
Conveyors above the arena can be activated to feed the giant furnace.

The furnace itself was designed to look demonic with twisted metal at its top forming downcast eyes illuminated by the inner heat, and a front-side grill tapering into jagged teeth. The whole front plate can be raised and lowered with a pair of chains to imitate biting and chewing.

(http://i.imgur.com/HdmEVoZ.jpg)
As the furnace is fed, molten metal drips from the sides of its mouth.

It's possible to stay at the edges of the arena, blowing up barrels from afar and pushing carts into oncoming foes. However, reaching the center allows the activation of the terminals that feed the beastly furnace causing fire and steam to explode from the pipework spread throughout the arena.

Furthermore, feeding the furnace will eventually cause molten metal to drip out and cover the lower sections of the map making the central hill the only spot where units can survive.

(http://i.imgur.com/KYgHELC.jpg)
3D mockup of the forge arena.

Hopefully this variety of options will encourage players to explore various strategies, including shoving their enemies -- and perhaps even allies? -- into the gaping maw of the furnace in order to gain instant favour of the forge. 

The visual style in this game is fantastic. You've got some great concept artists! A tactics game that has real interactivity with the environment would be great, forcing the player to change tactics in order to survive. Looking forward to watching this progress.

Appreciate it! We're definitely going for a more kinetic, interactive vibe. The idea is to make the battles feel a something like a turn-based moba rather than an abstract board game.

Even more concepts!

(http://i.imgur.com/ygo8UyE.jpg)
The feathered gentry of Trudy.

(http://i.imgur.com/KxVWuff.jpg)
Forgotten machines.

(http://i.imgur.com/ZaJPbu4.jpg)
Marketplace concepts.

(http://i.imgur.com/qewOfVh.jpg)
Map layout for the Aerie's Lyceum.

(http://i.imgur.com/wMtIA21.jpg)
A few UI concepts.

I am impressed at the level building. So cool to see that.

Thanks, soon enough I'll be able to model those for in-game using our editor!

Gorgeous concept art.

I noticed from your company's website you have unity experience.  Why did you choose to create your own 3D engine?  Are you building it on top of SDL, or was that only for the tech demo?

Networked multiplayer is a huge amount of work - are you guys using any middleware?  Although being a strategy/tactics game, you will probably avoid some of the headaches around latency.  Is it turn based?

Thanks for the detailed updates, it was a fun read.

Glad you're enjoying the devlog so far!

Yup, we're still building on top of SDL for porting purposes. One of the reasons we went with a custom engine was just the fun of developing the tech itself, but there were practical considerations as well.  Being able to scale and implement whatever middleware we want is a big plus, as are potential costs. Unity might be great, but outfitting the whole team and keeping it up to date can get quite pricey in the long run.

We've also actually worked on both real-time and turn-based multiplayer games in the past, so we have some tech we can use here. For Trudy, it's more an issue of keeping things deterministic enough to prevent cheating. Granted multiplayer is much more of a wish list item at this point, but we're trying not to shoot ourselves in the foot.

Another batch of concepts.

(http://i.imgur.com/J6RoqXA.jpg)
More feathered outfits (on account of the game taking place on an airship).

(http://i.imgur.com/kJUW0LJ.jpg)
Scrap-bot sketch, and a more insidious sentinel automaton.

(http://i.imgur.com/IG36ZEz.jpg)
Rotating cannon-mace and a statue concept that serves as a lamp.

(http://i.imgur.com/WAuQwby.jpg)
Crumbled level sketch with houses dotting the faces of the pillar.

(http://i.imgur.com/2ZCqrZw.jpg)
Mechanized walls of the Clockwork Labyrinth.

Our editor got some colour-coding!

(http://i.imgur.com/iFMoHhP.gif)

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:

(http://i.imgur.com/8ccozWQ.jpg)
The Forge Arena -- the purple bits represent floor grates and mounted pipes through which fire and/or steam can shoot out.

(http://i.imgur.com/QWwUT8B.jpg)
The Aerie's Lyceum. The bottom-left part will be a cable-car station.

(http://i.imgur.com/pvFqOqG.jpg)
The sprawling, ramshackle Warrens. Lots of verticality in these stages.

Back from our break with more concept art!

(http://i.imgur.com/hSHdAQT.jpg)
The four-armed, pantsless version of the Bulter Bot, and the finished base one in a tuxedo.

(http://i.imgur.com/RGp8h0w.jpg)
The electrified ram structure at the front of the ship.

(http://i.imgur.com/8BQhg8N.jpg)
Ravagers, the deranged cousins of the Homunculi.

(http://i.imgur.com/L1kxjA1.jpg)
Bridge overpass concepts for the sewer-like bottom of the ship.

(http://i.imgur.com/Ty6qBU1.jpg)
Various plants and coral that has sprouted in the above sewers.

Quick update with some in-game screenshots from our original tech demo:

(http://i.imgur.com/MvlM6Fy.jpg)
Zoomed-out view on the sewer-like Underworld.

(http://i.imgur.com/5vvYGyJ.jpg)
Flooding a room with water to limit traversal options.

(http://i.imgur.com/hr2nIVW.jpg)
Extending a bridge over a chasm -- these can be a variable length and collide with rain particles.

(http://i.imgur.com/CsHrSKJ.jpg)
Blowing up some pipes/barrels and lighting an oil slick on fire.

(http://i.imgur.com/taesCmF.jpg)
Destroying a coal station from inside a cannon turret.

Posting to follow cause :o!

Hah hah, thanks!

Animations update!

(http://i.imgur.com/bt39mkf.gif)
Idle animation of the boxy Supplier.

(http://i.imgur.com/WdrMkoc.gif)
Automaton's "spare-gear" attack.

(http://i.imgur.com/hIUEuQ4.gif)  (http://i.imgur.com/R6w5DUK.gif)
Corsair's and Supplier's death animations. We plan on turning the Supplier's body into a traversable block when he perishes!

WOW! :monoclepop:

Thanks you; glad it's worth of a monocle popping off!

Concepts update!

(http://i.imgur.com/OCcaPgal.jpg) (http://imgur.com/OCcaPga)
Outfit sketches for the police/military corpse.

(http://i.imgur.com/gXkmUSZl.jpg) (http://imgur.com/gXkmUSZ)
Gatling Turret, phone-booth design.

(http://i.imgur.com/GugTdtil.jpg) (http://imgur.com/GugTdti)
Tea-pot bot!

(http://i.imgur.com/xrVpBwkl.jpg) (http://imgur.com/xrVpBwk)
Tatjana and her spider-walker (initially a wheelchair).

(http://i.imgur.com/IgnXf9Ul.jpg) (http://imgur.com/IgnXf9U)
Further work on the sprawling warrens area.

holy shit, how haven't i seen this devlog before? :monoclepop:
definitely following this 

They scroll by so quickly it's easy to miss 'em; glad you like what's here now that you've found it!

Really great looking game! I like a lot of the concepts you're playing around with, and I really love the look of the characters that you've posted so far. Keeping an eye on this one!

That editor looks amazing. I'm looking forward to seeing more. :gentleman:

Thanks, we'll be looking to show more of the editor soon!

Amazing concept art! Really cool.

And I enjoyed the part about some conventions of the genre (outlines etc). I like posts that explain not only what's been done but why and what the alternatives might have been.

I definitely enjoy the why-and-how posts, so it's always nice to hear that we're passing on some useful or just interesting info as well.

Oh yeah, the info posts are definitely valuable, I think. Screenshots are pretty and all, but I think sharing your process is a huge boon, not only to people who are trying to learn how to accomplish similar things, but also to people like me (sound designer/fledgling programmer) who often don't get to see the whole development process. It's been a big learning experience for me, looking through devlogs and seeing how the sausage is made, so to speak.

We've been making lots of progress on the level editor, and although things haven't always taken the most obvious path, it's been coming along nicely. I figured it'd be fun to demonstrate some of these plodding advances by creating a small, abstract map and dressing it up. The scene below is colour-coded using our old annotation fills:

(http://i.imgur.com/QuhboZR.jpg)

First let's do some basic texturing.

Based on the in-game camera view, each "tile" is a 128x128 PNG as we found that it displayed enough detail given the overall size and scope of the geometry. These tiles can be painted directly on the scene, or used to flood fill a selection. Here's a quick demonstration of painting the map with three textures: grass, stucco, and rock.

(http://i.imgur.com/karvflI.gif)

It's easy to see that even though the textures tile seamlessly, the end result is quite uniform and repetitive:

(http://i.imgur.com/hR8XWiJ.jpg)

The most obvious way to solve this is to create a bunch of 128x128 tiles that can all connect to each other, but this is very time-consuming. Worse yet, it prevents larger details from being an option as any tile must connect to any other tile, from any side, removing the possibility of larger details flowing from one to another. To compensate for this, we first tried using Wang Tiles (http://research.microsoft.com/en-us/um/people/cohen/WangFinal.pdf).

(http://i.imgur.com/C0bsv0h.jpg)

While these were quicker to produce than 16 individual grass tiles, there were still issues that only became evident once the tiles were randomly laid out. There were no obvious hard seams, but the changes in brightness around the tile-edges created straight-line patterns when viewed as a whole. These were difficult to accommodate for ahead of time, but looking at the distribution-image we had an idea: what if we just created a giant texture that could tile seamlessly?

Since we were not bound by the same memory limitations, we decided to try this out by providing support for a large texture -- 4 times the size of the original -- to be painted over the scene one tile at a time.

(http://i.imgur.com/KIZB85p.jpg)

This allowed us to give the texture more organic details, and its large size prevented any patterns from becoming too visible. Here's a comparison of the original map and the large-tile approach:

(http://i.imgur.com/4MxwFUs.jpg)

Finally, to make the scene start looking less abstract, we wanted to give the house a slate roof. While this was easy enough to do with a single tile, we quickly realized another problem: all the textures "flowed" in one direction. This meant that all the rooftops were covered with the exact same pattern despite being perpendicular to each other:

(http://i.imgur.com/MdkxgXQ.jpg)

We didn't want to create numerous versions of each texture rotated to a specific angle as that'd take more prep work and demand more space for textures in terms of both memory and file-size. Instead, we added the ability to select and rotate individual texture-pieces without altering the geometry:

(http://i.imgur.com/GehP5kQ.gif)

And that about covers our first steps. Next up: layering!

awesome work and art style !

did you think about using some detail/untile map ? at work to hide this kind of tiling, we have the same texture scaled up and multiplied with the original one over the all level size.

Doing blended overlays is not something we've tried yet, but it's on our long list of potential features. In fact, Starcraft II's Galaxy Level Editor does this really well by allowing masks and precision-blending between overlapping textures: http://gamedevelopment.tutsplus.com/tutorials/starcraft-ii-level-design-aesthetic-design-and-editor-tips--gamedev-3312

For the time being we're sticking to more obvious layering and fringing, but we'll investigate additional options once we've nailed down some more of the base-features.

Our level editor has a total of 5 texture-layers, but this number is somewhat arbitrary -- everything gets baked down into a single texture map in the end. Since we haven't experimented with texture-blending (yet!), all of our upper-layer textures contain transparencies and are stored in .tga format to avoid mipmapping/alpha-channel issues.

Below is an example of some extra details added to the grass via a secondary top layer containing a few flourishes:

(http://i.imgur.com/oeeY5yj.jpg)

It's subtle, but further helps to break up the grass.

Once this basic layering was in, it was time to create various aesthetic extras. However, to get the most mileage out of our decorations, we decided to reuse and expand on our roof-tile-rotation feature by allowing any texture to be rotated (0, 90, 180, or 270 degrees) and mirrored (horizontally and/or vertically). While such drastic transformations usually result in obvious seams, none of our decorative tiles touched tile-edges or were big enough to look odd following random transformations. Below is an example of a single leaf tile placed as is, and then randomly rotated/mirrored. 

(http://i.imgur.com/2Wg03Lj.jpg)

These random transformations were actually done by hand, though, so our next step was to create the concept of tile "mini-sets" that would automate some of the work for us. Each mini-set consists of 1-n amount of tiles, and a list of valid transformations for the mini-set as a whole. The editor allows for filling/painting with mini-sets just like with regular tiles, except the actual tile placed on the map is randomly selected from the list and transformed according to specifications.

(http://i.imgur.com/DnqvfOp.jpg)

Mini-sets require a bit more groundwork to set up, but they've already proven big time-savers. Below is an animation of cycling through some of fill possibilities using a leaves-set.

(http://i.imgur.com/w17cark.gif)

With more experience, it quickly became evident that it was beneficial for virtually all decorative tiles to be part of a mini-set. With paths, for example, we split the stone pieces into centre/corner/side mini-sets and painted with them directly.

(http://i.imgur.com/9Jp2gHg.jpg)

Next up, we'll try to make that building look a bit less like a stone slab.

Pretty cool!

Uh, how does the insides of boxy supplier looks like?

Like this:

(http://i.imgur.com/mxmODru.gif)

He's meant to suck up and grind opponents, and even corpses for "re-processing" purposes.

Hey this is looking great! I am very much looking forward to where the project is going  ;D

Looks awesome! I love everything from the design to mockup, keep up the great work!

I just read through this devlog, can't believe I have missed this before.

I am impressed by your levels and the 3D dimensional movement. Also the fact that you are making this with your own engine, that is amazing to me. Keep it up!

Thanks guys! Yeah, the custom engine stuff has taken a long while since we're not just jumping into Unity, but it's also been nice to learn more and have a custom tool that we know we can take in any direction.

A few more unit animations:

(http://i.imgur.com/d2IEWm7.gif)
Koschei's run on all fours.

(http://i.imgur.com/xvpSinj.gif)
The Supplier overheating.

(http://i.imgur.com/TmHBSIf.gif)
Scavenger bird's idle state.

Oh God, I am loving that bird SO much

I love that this is so stylish. :handthumbsupR:

Thanks guys, appreciate it. We definitely want to make sure we imbue the units with as much personality as possible.

Here's another batch of concepts:

(http://i.imgur.com/GJYz1YCl.jpg) (http://imgur.com/GJYz1YC)
The sombre Konstantyn.

(http://i.imgur.com/CtxO0Dtl.png) (http://imgur.com/CtxO0Dt)
The trains of the Sprawl.

(http://i.imgur.com/RqdH0yUl.jpg) (http://imgur.com/RqdH0yU)
Potted plants of the Aerie.

(http://i.imgur.com/vr83wDal.jpg) (http://imgur.com/vr83wDa)
Miscellaneous icons.

(http://i.imgur.com/tgs3Hxql.jpg) (http://imgur.com/tgs3Hxq)
The Sleepless Forge

Since we have multiple layers for the textures, lets start by adding some basic fringes to our house:

(http://i.imgur.com/LQhsLZF.jpg)

The above image has vertically-fringed corners, but we quickly ran into an issue with horizontal fringing. Since our heights are done in half-blocks (64 "pixels", which are half of the 128 minimum texture height) and the fringe textures occupy only a small portion of a tile, it was possible for the textures to be applied with no visual alteration. The animation below shows the same fringe being applied to different elevations, with some of the textures not appearing until they're "nudged".

(http://i.imgur.com/T6Nxkub.gif)

This nudging alters the anchor of the texture so that the fringe part starts 64 pixels lower and properly aligns with the tile. This nudging was required in numerous places, so we also implemented it for horizontal orientation. This allows us to quickly fine-tune other decorations such as vines:

(http://i.imgur.com/Inr2Xui.gif)

And here's our house with some grass fringes, extra vines, and a few windows:

(http://i.imgur.com/eO8fQ1l.jpg)

Will do a quick update on lighting next time!

Just a quick update showing some lighting variation via different skyboxes/light point samples.

(http://i.imgur.com/bH15mEr.jpg)

The lighting intensity and skybox saturations are purposefully overintensified to show off the contrast between them. It's still all fairly subtle to ensure that coloured lights don't completely distort the painterly style. We hope this approach gives us some options for "tinting" each biome and giving them all a unique atmosphere.

One more update on textural decorations: decals.

Unlike regular textures that are placed on top of each other, decals don't have to conform to a specific tile size and can be smoothly moved around. They can also scale easily and wrap around objects as shown below:

(http://i.imgur.com/jQ0UFfu.gif)

However, since decals are projected down, they tend to unintentionally overlap multiple objects. In the case of the house, any prop standing next to it would "absorb" a part of the crack decal, which didn't really work out. In the end, we used them somewhat sparingly and in more desolate areas.

(http://i.imgur.com/LlVZ8hn.jpg)

Next up, we finally decorate the scene with some objects!

Finally, it's time to add some decorations. These make a big difference.

(http://i.imgur.com/jgHR1QK.gif)

Objects by default snap to the ground tile beneath the cursor, and like textures can be rotated around. Since objects contain collisions and can be of any size, rotating ones that have a large base uses the top-left corner as the anchor.

With objects, we generally didn't need to worry as much about snapping to corners or rotating by 90 degrees as with textures, especially for aesthetic ones. We also added the ability to rotate around any axis, not just the y, and "nudge" each object by a small fraction of a tile.

With those capabilities in hand, we went ahead and added object sets. Like with textures, these allow us to "paint" with a randomly selected object from a list, and rotate/nudge it up to a maximum amount based on given parameters. Here's how it looks in action:

(http://i.imgur.com/D7Vbl05.gif)

Once the trees and tree trunks were put in, we manually adjust them so that clipping is not a visible issue, and add various other decorations such as brambles, miscellaneous plants, benches, lamp posts, fallen leaf clumps, etc.

A few dirt patches later, and we get this:

(http://i.imgur.com/JxzCx6j.jpg)

Of course it's still not done yet, but it's beginning to look more and more like an actual place, don't you think?

Yes.  :addicted:

This is one of the nicest/best looking 3D map editors I've seen. I love map editors in general, because the possibilities are endless with them. It looks great. :D

Thanks! It's still something that needs lots of work, but what's there has proven to work fairly well.

Thanks a bunch; I'm sure our artist will love to hear it!

We've finally gotten ourselves a proper website (http://trudysmechanicals.com/)!

Check out the accompanying teaser trailer below, as well as some more-polished screens and concepts:

---

Looking incredible. Your GIF in Screenshot Saturday made it impossible not to click the link and follow. Disturbing and unique.

Thanks! We've been keeping up with screenshot saturday, but have mostly focused on dev work in recent months so the devlog hasn't gotten as many updates. Hopefully we'll have some time to post for stuff on our end soon!

Hello, I have been following your game on the makega.me forum for a while.
Glad to see a devblog here as well.

The art is spectacular! Especially the painted concept art with it's Victorian steampunk and strange characters.
And following your progress with the level editor and the details of your process is a real treat!

Good luck with further development.

Oh, the concept art is lovely!

Thanks guys! We just got through a long dev stretch, so I'll try to share more art soon (here and on makega.me and elsewhere) and get back to the more tutorial-ish posts.

To hide some of the harsh map-edges, we've implemented a global fog system. It's separate from any particle effects that accompany props/characters and specific map elements, but it helps to set the tone for each area.

(http://i.imgur.com/lfDtoaI.gif)

In the animation above, we cycle through a few coloured skyboxes, settling on a sunny-day scene for the cottage. We then apply the skybox colour to a global fog. The fog tapers out to full transparency as is rises up, and its vertical start and end can be altered to match each map's scale. In the end, only a small amount of fog is allowed to seep through the ground of our cottage to subtly soften the area as a whole.

The fog is also useful for tapering off the bottoms of the maps, especially vertically-oriented ones.

(http://i.imgur.com/cBZue3v.jpg)

As shown above, the fog gradient can recede to full opacity and cover the bottoms of the walls and columns. Combined with some billowing particle clouds that replace the level-editor grid, the scene becomes a bit less abstract and more loosely defined at the edges.

Can't believe I haven't seen this before! It's nice to read through the devlog and see someone wrestling with similar design challenges. The game looks amazing, keep it up!

Thanks! And yeah, it's easy to miss stuff in-development -- sometimes I spot what appears to be a cool new project but then discover that the thread is years old and it just flew under my radar.

what the hell this is so cool, art is amazing, editor looks so cool too!

that supplier is creepy as hell though  :screamy:

Hah hah, we've definitely tried to embrace the creepy and grotesque with some of our units.

I just read through the previous page and it was really cool to see the evolution of the map with the house. The way you added the fringes, then the vine textures, then the decals, really exposed part of the 3D level design process that I've never seen before! I've just taken that kind of stuff for granted.

Haven't seen an update or a reply in a few months, though. Is the project still moving forward?

It is, but slowly right now as we've taken on a work-for-hire project that's now our current priority. Hopefully it'll help us raise the funds to continue work on Trudy in full swing.

I hope so too. Keep up the great work guys, on this project and others!  :)