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

Login with username, password and session length

Advanced search

1043285 Posts in 42269 Topics- by 33930 Members - Latest Member: conlan

September 17, 2014, 07:38:11 PM
  Show Posts
Pages: [1] 2 3
1  Feedback / DevLogs / Re: Trudy's Mechanicals (3D Tactics Game) on: Today at 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.

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.
2  Feedback / DevLogs / Re: moonman on: September 10, 2014, 07:27:37 AM
Love the idea of the different moons and the overall look (regardless of its origins). I just hope the head-ducking makes it in -- it looked quirky and fun, and there's something offbeat and appealing about it. I think it's the fact that it was automated and didn't slow down the player's movement; just an extra adaptive touch touch to environment traversal.
3  Feedback / DevLogs / Re: Dinosword on: September 10, 2014, 07:16:55 AM

I love the fact that his teeth remain visible along with the eyes when the area gets dark.
4  Feedback / DevLogs / Re: Band Saga (on Kickstarter) - Action Roguelike where music generates the Levels! on: September 10, 2014, 07:07:51 AM
Backed it a little while ago based mostly on the crazy amalgam of concepts. Good luck with the rest of the Kickstarter!
5  Feedback / DevLogs / Re: 24 Killers on: September 09, 2014, 07:35:29 AM
Just backed this on Kickstarter and looking forward to it. Love the character design and atmosphere you're creating.

Ditto. It's got a unique look and I love the lively bounciness of everything, including the inanimate objects. Glad you reached your Kickstarter goal so quickly considering how much you're taking on your own shoulders.
6  Feedback / DevLogs / Re: Trudy's Mechanicals (3D Tactics Game) 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.
7  Feedback / DevLogs / Re: Trudy's Mechanicals (3D Tactics Game) 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.
8  Feedback / DevLogs / Trudy's Mechanicals (3D Tactics Game) 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. A few months later and it's now far along enough that we can start showing off the game it was designed for: Trudy's Mechanicals!

Trudy's Mechanicals is a turn-based tactics game that takes place on a giant floating Steampunk dirigible. The tactics genre's had something of a resurgence in recent times -- 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.

Some more concept art below:

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!
9  Feedback / DevLogs / Re: Screenshot Saturday on: March 15, 2014, 12:19:26 PM
A GIF of our jolly clerk animation from Feeding Time's title screen
10  Feedback / DevLogs / Re: Screenshot Saturday on: March 08, 2014, 01:32:20 PM
One of the minigames in Feeding Time
11  Feedback / DevLogs / Re: Screenshot Saturday on: March 01, 2014, 12:35:58 PM
Tundra gameplay GIF from Feeding Time

12  Feedback / DevLogs / Re: Screenshot Saturday on: February 22, 2014, 01:22:23 PM
Another GIF from our upcoming Feeding Time

13  Feedback / DevLogs / Re: Screenshot Saturday on: February 15, 2014, 11:49:09 AM
Quick GIF from Feeding Time
14  Community / Townhall / It's almost EAT o'clock time! on: February 12, 2014, 03:14:34 PM

Hey guys, hope you check out the site (and the game, once it's out)!

On a *slightly* less self-promotional note, we also plan on updating our website with more dev-related posts (like this one) that some of you might find useful, so feel free to check out http://www.incubatorgames.com/ as well!

15  Developer / Design / Re: 2D platformer design studies on: July 05, 2011, 08:52:55 AM
Glad you enjoyed 'em.
16  Developer / Design / Re: 2D platformer design studies on: July 02, 2011, 07:15:34 AM
I've posted the third part of my SMB 3 articles if anyone's interested: http://www.significant-bits.com/super-mario-bros-3-level-design-lessons-part-3

This one veers away from typical level design to focus on how the overworld hubs are structured and linked to the core stages, but I think it's still relevant to the topic.
17  Developer / Design / Re: 2D platformer design studies on: February 21, 2011, 01:50:58 PM
In case anyone's interested, I posted a follow-up to the SMB3 article that goes over the remaining worlds: http://www.significant-bits.com/super-mario-bros-3-level-design-lessons-part-2
18  Developer / Design / Re: 2D platformer design studies on: December 30, 2010, 02:59:14 PM
Deconstructing SMB 3 is a huge task, but if anyone's interested, here's my first stab at it: http://www.significant-bits.com/super-mario-bros-3-level-design-lessons
19  Developer / Design / Re: Tactics games. on: November 29, 2010, 11:54:45 AM
I've never heard of Future Tactics, but it seems pretty neat. We actually wanted to implement a bunch of its features, but only a few (such as destructible objects) will make it in as we had to pair-down the scope of the game.
20  Player / Games / Re: Why are there so few top-down 2D indie games? on: November 18, 2010, 09:34:38 AM
Like some people mentioned, I think it's mainly an issue of "bang for the buck."

Side-view games show visually more interesting environments while requiring fewer assets -- left/right character poses can be flipped (without worrying about up and down), Flash-esque bodypart animations work much better, it's easier to fill out the scene with 2D props while utilizing effects such as parallax, etc.

Of course it also depends on the type of game you want to make. Platformers work well with a side-view, whereas top-down games usually avoid complex jump mechanics due to the skewed/limited perspective.

Pages: [1] 2 3
Theme orange-lt created by panic