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!

The First Eight Months

We decided to start working on Pod & Rodney in the middle of July of 2009. We have a back log of blog posts archiving some of our woes, decisions, and excitement. A lot of the blog posts are just us sometimes discussing how we have something coming or that we should post on the blog more often. We've changed our attitude a lot since then.

A few days ago, we came to the conclusion that we didn't actually get a development pipeline solid until about late April of 2010. I wouldn't say we wasted any time up to this point, but we definitely learned some valuable lessons along the way.

We started out with a lot of ambition. We love video games and we really wanted to make one of our own. At the time, we didn't know what we were getting ourselves into. We had no idea where to start, and we had only dreamed about developing a game up until this point. So we made some classic mistakes right off the bat. One of them was that we tried to develop our own game engine, which was going to be called the "Siege Engine". It was a really catchy name, and we had some cool plans for it. Ultimately it became far more of a challenge than we had anticipated, and we simply couldn't finish it properly within a timely manner. Mostly due to us not being able to efficiently program any sort of graphical rendering code.

To solve our rendering issue with the Siege Engine, we decided to get a pre-made graphics engine called Ogre. Ogre did exactly what it was supposed to, but it didn't change the fact that we were still programming everything else from scratch. So after a few weeks of very little progress, we switched again.

Panda 3D enters the scene. It was a full packaged game engine, and the demos made it's capabilities look promising. It was also free, since it was developed for/by students (Carnegie Mellon Entertainment Technology Center). A game engine being free of charge is rare for anything worth using, so this was a nice start. The biggest problem that Panda 3D presented us was that it used DirectX based rendering, and since we develop our visual game assets using Maya, an OpenGL based 3d development tool, we had to come up with some pretty crazy ways of converting OpenGL files to DirectX. This was like sorcery. We felt like we were literally trying to solve the problem of changing lead into gold. Eventually, after a lot of time spent, we got it to work, but our development pipeline for moving graphical assets to the engine was a total mess by this point. So we started to lose momentum.

We weren't sure what we were going to do, things were functioning, but the sheer amount of work to create such simple results was monstrous. We started hunting around for professional game engines, deciding we were going to bite the bullet and pay for one. We had come across Gamebryo, but the price-tag was ridiculous for our first project. After a lot of hunting we eventually found our princess, our holy grail, our magical solution.

In mid April 2010 we found the Unity game engine. Unity does everything we needed it to. It compiles the game to multiple platforms with the click of a button, it accepts DirectX and OpenGL graphical assets, and it's license price is very reasonable. Anytime we come to a potential hiccup in our development pipeline, we test it in Unity and quickly work everything out. This program, and the people that made it, provide such a phenomenal service that our inspiration and momentum has been soaring. We have developed so much in the past two months, thanks to this game engine.

I've seen our game come to life, and soon any followers of the blog will too. The ambition we started with in the beginning is back and bigger than ever. This is a very exciting time for the Pod & Rodney team, and we've fallen in love with the process because of it.

Tileset Alpha Build

None of this is final yet, but I've compiled a crude representation of what the core tileset will look like when it's properly tessellated with the level compiler. The characters and a lot of the set pieces are still very early test builds. Regardless, the entire thing is coming together very smoothly and we have been making quite a bit of steady progress lately.

Texture Mapping

Rock Bands and Judo

We are a rock band. I use this comparison a lot when talking about the Pod & Rodney team. We get along really well, we joke around and have fun and know when to be serious about a particular subject. We all work hard and have fun while doing what we love. None of us are here for a free ride and we all know that an indie game is a lot of work and time dedication, otherwise the project will simply never come to fruition.

One of our biggest inspirations for team building and responsibility management is Valve Software. They have no hierarchy of management, no job titles, and everyone has a hand in every aspect of their game's development. We pride ourselves in contributing to this tradition with our humble indie game's team philosophy.

Another strong inspiration to our development lately is a book by 37signals called 'Rework'. This book is fantastic for anyone interested in starting their own business, especially in software development of any kind. One of the chapters talks about 'Judo Solutions'. Judo Solutions are elegant and simple solutions to complex problems. If we run into something that is slowing down our progress substantially, we consider whether it's worth keeping and then if it's a necessity, we consider the simplest and fastest solution to fix it. This by no means suggests that we are making a less than high quality product, but it does get things done and allows us to properly prioritize our time.

With these changes in our approach we have progressed more in a matter of weeks than we have in that past few months. This is our first game and we have spent a lot of time learning from our mistakes and building a style, much like a rock band.