Design Contrast

Pod & Rodney's art direction is all about contrast in one way or another. The characters themselves are a strong contrast to each other in a number of different ways.

First to note is Pod and Rodney's color scheme. Pod is a cool blue and Rodney is a warm orange color. The colors are complimentary on the color spectrum.

The general environment tends to lean towards grays and greens. The green "factory basic color" is a tone directly between Pod and Rodney's dominant colors, also known as a "secondary color" in color theory.

The orange and blue color scheme is popular in marketing and media lately. While it may not be the most avant-garde, we're hoping it will create a sense of familiarity and charm for our characters and environments.

The character silhouettes are also of note, as Pod is very spherical, and Rodney contains a lot of right angles and sharp corners.

This image is a work in progress of the environment and characters, but it also shows off the technique used to pop the characters from the game environment. Set pieces have some detail to their textures with concrete grit and sharp lines for vents. While the two playable characters are mostly solid colors with sparse details. This and their stronger colors against the gray background helps the player interpret the scene better, so that they don't lose track of the character's locations in the puzzle.

This same color scheme and silhouette practice is found in the title graphic. You can even see the green secondary color used in the ampersand between the two character names. Pod's name is bubbly and soft, while Rodney's is sharp and rigid.

There has been a lot of attention to this in everything from character functionality to animation weight. We're hoping this attention to aesthetic detail will not only help the player understand the gameplay better, but also make the game more interesting to look at and play.

It's Alive

Animation in Pod & Rodney is handled through a series of FBX exports. A single FBX file will hold all the animations for any individual game asset. Specific animations are stored in the FBX as a series of frames that the engine will call on when needed. This keeps our filing system simple and minimizes the number of notes we have to take in order to keep things organized.

Here is a sample of what our frame data chart looks like for a few of our animated assets:

door_type0
1 - 30: idle closed
31 - 45: open
61 - 90: idle open
91 - 115: close

lever_type0
1 - 30: idle
31 - 65: switching

teleport
1 - 30: idle

rodney
1 - 30: idle static
31 - 60: idle 0
61 - 120: idle 1
121 - 150: idle 2
151 - 169: walk cycle

etc etc.

And here is a rough render of frames 151-169 from Rodney's FBX file:


This single file / frame catalog is among the many steps we've taken to optimize our communication pipeline between developing visual assets and implementing them into the engine. By doing this we've managed to avoid a lot of potential headaches.

Evolution of Crates.

This will not be a discussion about how some guy decided to nail a bunch of boards together into a box to store all his hats.

Crates, as far as programming was concerned, were not actually present until we started using Panda 3d. Why? Because before that, as Andrew explained in the previous post, we were more concerned about just trying to get models to export from Maya into whatever engine we were using at the time.

Crates originally started as boxes that only the players could interact with. There was very little logic attached to them at the time. At first, crates were set to be independent of the object manipulating them. This being a player or if it was part of a stack. For instance if the crate was on a stack, it would check every update to see if the crate below was moving, within a certain distance boundary and then recenter onto that position. It was ugly and didn't work that well.

Parenting became the saving grace, not to mention the current form we use now to move crates and players being forced by crates. This system has worked flawlessly so far, and as intended. The idea actually came about when reading about a way to attach props to models in Unity that could be remove such as hats and things.

How it works is that if a crate is on a stack, it moves right along with whatever it is attached to. The only thing it has to check for is if it going to be blocked, and act accordingly. This same system is used for players being moved by a forced object too.

To an extend you can actually think of crates as a sort of third character, one that your not able to directly move.

I'll be doing a series of these sort of posts. Going from where we started with a part of the game to where we currently have it. So keep an eye on the blog!