The CMP Game Group (producer of Game Developer magazine, Gamasutra.com, and the Game Developers Conference) established the Independent Games Festival in 1998 to encourage innovation in game development and to recognize the best independent game developers. They saw how the Sundance Film Festival benefited the independent film community, and wanted to create a similar event for independent game developers as well as the student population of game developers.

I talked to one of the developers from Naked Sky via email about their game RoboBlitz, which is nominated for the Seumas McNally Grand Prize and Excellence in Visual Art.

[size="3"]Who are you and how were you involved in RoboBlitz?

My name is Joshua Glazer and I'm the CTO of Naked Sky Entertainment and Lead Programmer on RoboBlitz.


[size="3"]Congrats on your nominations. What made you decide to enter RoboBlitz into the IGF?

Well, we're an independent studio, and we think RoboBlitz is a good example of what a dedicated indie team can do with a lot of hard work, so we thought we should give it a shot.


[size="3"]Where and when did the idea for RoboBlitz originate?

The idea for RoboBlitz was an amalgamation of a bunch of other ideas. We wanted to do a game based on physics where the player would really have some creativity in solving the puzzles, so we decided that the best choice for a physically simulated character was a robot. We loved how MegaMan was always "getting equipped" with new weapons and tools so we worked a little of that in, and we liked the free form, non-linearity of the 3D Mario games, so we threw a bit of that in too.


[size="3"]Was the physics-based gameplay an aspect from the very beginning? How did it evolve as the game matured?

The physics was definitely in there from the beginning, but things got less and less physics-y as time went on. We realized there's a fine line between "entertainingly real" and "too real." Few people want to play a game that has them constantly worrying about a million physics collisions, balancing their robot right, and many other things they'd only have to think about in the real world. As we play tested, we cheated the physics more and more to make sure that Blitz, the main character, was easy enough to control, but still gave a physical feeling experience. We also built in a lot of A.I. to Blitz, to make sure he could take care of balancing himself, bending over when he's supposed to, and using his brakes automatically when necessary. That made the game a lot more fun overall.


[size="3"]What were some design issues that arose from using physics so heavily?

We designed the puzzles to be physically based, which allows the players multiple ways to solve each puzzle. For instance, there's a pulley puzzle where you have to put enough weight on one platform to raise the other platform. There are some boxes hidden throughout the level that you can collect and put on the platform to weigh it down, but you could be clever and just pile up baddies on the platform if you don't want to find all the boxes. Or, if you have the Point-To-Point Beam (basically a giant rubber band), you can just attach a beam from the ceiling to the platform that you want to raise and it will pull it right up. What's great about this is that we didn't have to plan for any alternative solutions- we just designed the puzzle and made sure there was at least one solution, and knew that creative players could find the other (possibly better) solutions themselves. There's one puzzle in the conveyors level that we've now found over 10 ways to solve. However, the drawback here is that there might be a trivial solution that the designers never noticed, so we did have to be a little careful to make sure that nothing was too easy.


[size="3"]Did you guys look into using Ageia's PhysX card at all?

We knew from the start that RoboBlitz would be both a PC and Xbox 360 game, so the PhysX card wasn't really an option.


[size="3"]How did you find working with the Unreal engine?

It was great. Not only does it give solid graphical performance, but the guys at Epic are really good to work with. They were always there to help us out when we had questions or when we were tearing up some of their code, and we sure did a lot of tearing: UE3 wasn't designed for a totally physics based game, so there were a lot of modifications we had to do for that.


[size="3"]Were there any considerations to the gameplay that had to be made concerning the playability on the Xbox console and Live Arcade?

Like I mentioned before, we planned for this to be an Xbox 360 game from the beginning, so we designed the game with that in mind. We built in things like auto-aim to compensate for controller issues. One thing we noticed is that players on Live Arcade expect a much more "casual game" experience than players on the PC, and that's something we didn't expect at all back when we began developing the game. RoboBlitz is not a casual game in any sense, other than the fact that it only weighs under 50MB and you can download it via Live Arcade. It's a fully immersive 3D game with cutting-edge graphics and physics simulation. I think it might be a while before downloadable games can escape the stereotypical expectation of a casual playing experience.


[size="3"]How much of a real robotic aspect was incorporated into the game?

A lot, actually. It turns out that if you're simulating physical motors, you end up having a lot of the same problems controlling them that you do in real life, so we read up on robot control theory as much as we could, and asked some of our friends back at the MIT Media Lab for advice (Thanks Jeff!). We ended up building a lot of control theory routines (PID controllers, mostly) into the code to help stabilize our robots and keep them from flopping around.


[size="3"]What led you to use procedural textures, and how do you feel this has helped the game?

Well, there used to be this thing on Live Arcade where your game had to be under 50MB, so if we wanted to do a game like RoboBlitz, then procedural textures were the only way to go. Using Allegorithmic's ProFX technology, we could create very small instruction lists that would generate the textures at load time to look exactly the way we desired, and that's how we could fit so much content into a 50MB game.


[size="3"]How long did it take to produce RoboBlitz? In hindsight, was there anything during production that you think could have been handled better?

It took a little under a year from the time we started to the time it was released. It was our first commercial project at Naked Sky, and we sure learned a lot, so pretty much everything could have been handled better! Specifically, we could have used a lot more pre-production. We failed to lock down the design at an early stage, which meant we were making sweeping changes pretty late in the production phase and that required us to go back and redo a lot of work that was already done. We won't be making that mistake again, and I hope no one else has to make them either. So lock down your design early on and stick to it!


[size="3"]What tools were used to aid in development and production?

Art was done in Maya and 3D Max, with Photoshop for the textures. Programming was all in Visual Studio 2003. Level design and asset management were done in the Unreal Editor 3.0. For version control we used Subversion, and for bug tracking we used Mantis, both of which are open source.


[size="3"]What's next for RoboBlitz and Naked Sky?

We're working on a free multiplayer expansion as an add-on to the full game.