Itween and way points

Recently, I received a monthly newsletter from Unity. These usually contain updates about the new engine, new games that came out using Unity and any other general news. This last one contained a link to an updated plugin for Unity, Itween. Itween has alot of cool things you can do, anything from making movement stupid simple, to controlling music and sound better etc. Originally I was going to try this out over the course of a couple of days. Get a feel for it and maybe change over to it to make my life a bit easier.

Well....

You can only use plugins with the Unity Pro license. Which we have not gotten to purchasing yet. That'll come later.

But! One of the features that Itweens contained that got me thinking about a bit of optimizing and bug proofing was the way points movement feature. Which is pretty much as it sounds. You have two points, the computer interprets the path between them and the object moves along them. So what I've begun to do is experiment with way points that are more customized towards our needs for Pod & Rodney.

Change Is In The Air

An update about a change that we've decided to make to Pod & Rodney. After a few attempts and much discussion on it we will be removing the rewind feature from the game. This is actually for the good of the project, the rewind has always been the biggest hill to climb. So instead of attempting to climb it we're going around it.

We will be replacing the rewind with a similar feature. Save states. These will be user created "snapshots" of the level. It will save the current state of all objects in the level. Similar to those used in game emulators for the PC. You will be able to create multiple states throughout a level, no limit, and jump back through them.

The idea is that if you approach a section of a level that you're unsure of, use a save state, then be able to experiment with different solutions for the problem.

The biggest reason that we have decided to change this aspect of the game is that we will be able to bring you Pod & Rodney much more rapidly, and guarantee a more stable gameplay experience in the end. This will also allow us to continue development using the Unity 3D game engine.

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.