Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1371818 Posts in 64670 Topics- by 56794 Members - Latest Member: imobla

January 20, 2020, 06:23:45 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsTrudy's Mechanicals, 3D Tactics Game *New Teaser Trailer*
Pages: [1] 2 3 ... 5
Print
Author Topic: Trudy's Mechanicals, 3D Tactics Game *New Teaser Trailer*  (Read 12521 times)
JustRadek
Level 1
*



View Profile WWW
« on: August 26, 2014, 01:47:30 PM »


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!
« Last Edit: August 12, 2015, 10:52:59 AM by JustRadek » Logged

JustRadek
Level 1
*



View Profile WWW
« Reply #1 on: August 27, 2014, 01:47:23 PM »

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.


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

JustRadek
Level 1
*



View Profile WWW
« Reply #2 on: September 09, 2014, 07:16:28 AM »

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

JustRadek
Level 1
*



View Profile WWW
« Reply #3 on: September 17, 2014, 02:42:02 PM »

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.





With the system in place, we tackled a few more 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.
Logged

JustRadek
Level 1
*



View Profile WWW
« Reply #4 on: September 24, 2014, 01:56:51 PM »

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.
« Last Edit: September 25, 2014, 07:27:28 AM by JustRadek » Logged

mickmaus
Level 1
*


walkying waylking


View Profile
« Reply #5 on: September 24, 2014, 03:47:40 PM »





Awesome, love the editor idea
Logged

JustRadek
Level 1
*



View Profile WWW
« Reply #6 on: September 25, 2014, 08:06:26 AM »

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

JustRadek
Level 1
*



View Profile WWW
« Reply #7 on: October 01, 2014, 09:38:36 AM »

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



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.






Logged

unsilentwill
Level 9
****


O, the things left unsaid!


View Profile WWW
« Reply #8 on: October 01, 2014, 09:51:52 AM »

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

JustRadek
Level 1
*



View Profile WWW
« Reply #9 on: October 01, 2014, 11:09:39 AM »

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

Julien
Level 2
**


View Profile
« Reply #10 on: October 01, 2014, 11:48:11 AM »

I'm in love with your art Hand Clap Shocked
Logged

JustRadek
Level 1
*



View Profile WWW
« Reply #11 on: October 01, 2014, 12:08:48 PM »

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

JustRadek
Level 1
*



View Profile WWW
« Reply #12 on: October 03, 2014, 02:03:37 PM »

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!
Logged

JustRadek
Level 1
*



View Profile WWW
« Reply #13 on: October 09, 2014, 12:57:50 PM »

New art!


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

MereMonkey
Level 2
**


Creator of Music


View Profile WWW
« Reply #14 on: October 09, 2014, 01:50:29 PM »

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

My Site  -  My Twitter - *GASP* MY SPINACH PUFFS!
JustRadek
Level 1
*



View Profile WWW
« Reply #15 on: October 10, 2014, 06:21:34 AM »

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

JustRadek
Level 1
*



View Profile WWW
« Reply #16 on: October 15, 2014, 11:53:10 AM »

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?
« Last Edit: October 19, 2014, 07:50:38 AM by JustRadek » Logged

JustRadek
Level 1
*



View Profile WWW
« Reply #17 on: October 16, 2014, 06:39:39 AM »

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:

Logged

JustRadek
Level 1
*



View Profile WWW
« Reply #18 on: October 23, 2014, 11:35:17 AM »

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

FuzzySlippers
Level 0
***



View Profile WWW
« Reply #19 on: October 23, 2014, 12:12:53 PM »

Moving pretty fast on this. Looks great.
Logged

Pages: [1] 2 3 ... 5
Print
Jump to:  

Theme orange-lt created by panic