For those of you who heard me on the Metal Gear podcast hello again. As some of you might remember I talked a bit about our little indie game Rigonauts which was coming to iOS (iPad 2+) as Rigonauts HD. The game is a bit like Gratuitous Space Battles meets Fantastic Contraption. Yesterday the patch finally went live for the new version so I thought it would be fun to offer to do a QA session.
Please feel free to ask about the game, indie development or game making in general. My background is that I have been making games for about 12 years (6 shipped titles). I have worked at Capcom, Crystal Dynamics, Activision, and Planet Moon Studios before founding Engient.
Feel free to ask what you would like. Some specific questions about my former employers I might not be able to answer. However, I will try and be honest or clear as to why.
Tom said nobody had really done this before but I hope it will be fun.
And if you do want check out the game then you can find it all over the place:
On the technical side I used Fraps to suck up scenes and Sony Vegas to put them together. Artsy side, I imagined a story I wanted to tell then contrived game examples that told it.
Where would you suggest for someone to start in game development on the technical side? What steps should I take towards learning game design and development?
I would say 98% of the final work present in Rigonauts was the result of six people, four of them contractors. In terms of labor (but certainly not value) the sound FX and music guy did the least. We worked with them based on the recommendation of my friends at Final Form Games. Both the art guys were also contractors. The UI Artist was a friend of my business partner Jason, so that was a pretty easy connection. The main 2D artist, Sang, was a bit more interesting.
When we were looking for the main artist I put a want add on Gamasutra and Sang was one of the people who applied to it. At the time he had never worked on a professional project. However he had completed a game for the Xbox Live Indie Channel and even earned an award in Microsoft’s Dream Build Play competition. That put him high on the list because it showed he had development-like experience and the gumption to make a game with a small team. It also helped that he nailed the art test, including my partners secret requirements (even I didn’t know he had them). And of course we liked his style. He was with us for about a year but really the game represents closer to six months of his work. Sang did the characters, the machine bits, and the backgrounds.
Jason is a bit of a genius programmer and he also has a good head for design. Therefore, he did most the heavy lifting in the code base and most of the games systems are a joint effort between he and I. Our game engine uses some common libraries but is mostly in house so there was plenty to keep Jason busy.
I was the least specialist of the bunch. I went to school for Computer Science but most of my career I have worked as a Game Designer specializing in systems, control schemes and characters. My programmer skills helped me communicate with others but were not directly applied daily. At Engient this has been different. Besides systems design I also designed most of the levels. I did game play programmer work for some of the higher level tasks. I also did all the FX in the game which was new for me. Also, I was the primary source of direction for all the work the contractors were doing. For example, some of Sang’s characters were based on some sketches I made.
And I wrote a lot of the tools.
And corporate things like payroll and health insurance.
And business development (though I had help from our Agents).
Jason’s secret requirement had to do with the animation task in the art test. I had asked the artist to create three animations: one run cycle and two from a small list. I asked that the animations be submitted as a sprite sheet (a single image that contained each frame of the animation one after another). When Jason and I reviewed the submissions he started by passing on the ones that did not include animated GIFs. Of course, I hadn’t asked for that, but his rationale was that if they wanted to show off the animation off than an animated GIF was the best way to do that. He felt including it showed an attention to detail and presentation, more professionalism.
Actually, it reminded me of one of my job searches where I was asked to design a boss encounter. In the submission I included an animation list even though they didn’t ask for it. When they asked me why I said it was how I was used to working and I didn’t feel that the boss was designed without one. They said they liked it because their character designers often made animation lists. This got the interview off on a good foot.
There was another ‘trick’ requirement in the test kind of like this: I asked the artist to create three Hobs (the little goblins in the game) and for the second character I asked for “A Junior Officer with Peaked Cap (leadership type).” Some of the artists didn’t include Peaked Caps and I took a similarly dim view towards them because I wanted to make sure they would notice the details in a task.
A final note if your trying to get a job: One guy who didn’t include a Peaked Cap still had a pretty good style. On a follow up phone call I mentioned there was no cap and he said “sorry” and nothing more. He really should have asked to take another swipe at it. But he didn’t so the job went to Sang who did everything he was asked to (and more) and did it well.
Huh, does this make us sound like cruel interviewers who expect applicants to caper and dance at our every whim?
Not looking for a job, I just love behind the scenes details. The requirement for the specific cap which several just ignored - I don’t understand that. Why wouldn’t a person do that? Laziness? Deciding they had better ideas than the one you put on paper?
In my experience the most likely explanation is that they just aren’t paying attention. Something just popped into their brain when they saw the words and after that they didn’t think about what I wrote.
But anymore behind the scene stuff you want to know ask away.
iron_weasel – How similar to the game as you first conceived it did Rigonauts end up being? What’s your development process? Do you have a design document? How do you set goals and how do you evaluate the game at different stages?
We did work with foreign developers: Francisco Cedra, our musician, was from Columbia. For me, I would say the decision is based on how much iteration the job requires. I guess iteration is a subset of communication, but a very specific one. Communicating in English, face to face, with someone who works in the same room as you makes rapid iteration easiest. Changing those variables makes the iterative process harder. But some tasks require less iteration. Or some people might be so expert in a task that using their unique talents offsets the costs.
For tasks that meet the above criteria foreign developers have a better chance of competing for the work. But they still have the challenge of being unknown. I need to find somebody who I believe can do the job well. If you look of the list of people we worked with from the earlier post then a pattern may start to emerge. SFX and Music guys had worked for my peers at Final Form Games. The UI guy was a close friend of my business partner. The person who did the promotional art was someone I had known for a long time. The guy that was the biggest unknown was the main artist. In some ways I put a lot of trust into somebody none of us knew. However, I also had him come into the office everyday and sit right next to me.
Aaaahhh, the winding road from start to finish. Rigonauts had a somewhat troubled birth. About two months in we had a toy (not quite a game yet but close) that was very close to how Rigonauts turned out. It had two ships that would fight in a hands off manner. I there was one day where I was very proud. I spend a whole afternoon playing the game and knowing that it was the most fun thing I had worked on in a while.
Then things went wrong.
We spent a lot of time trying to make the game that had a broader appeal. We were afraid that “The robotic cage match” (as one friend put it) was too narrow. However, in trying to broaden the game we ran into a host of difficulties. So there was a big chunk of time where the game became more and more complicated. At one point the player had full control over the machine. You drove and shot the Hobs out of cannons and they fought monsters or repaired things. It was like a 2D Pikmin where you created a machine physics simulated chariot. There were problems and besides the game got too big for us to finish.
After receiving some excellent feedback at GDC (especially from Nintendo) we took a chainsaw to the game and moved it back to the simpler design. It was something we should have done sooner but were afraid to.
So the game was close to what we started with but there was a big chunk of time where it wasn’t.
The classic design document that some studios encourage did not exist. My notebook is full of notes and we had spreadsheets, ‘shopping lists,’ and mockups instead.
Our process is to get things on screen and fun and then grow from there. One needs to identify the the elements that are most vital to the experience and start there. For Rigonauts it was basically: rules, building blocks, damage logic, orders. At some point the basics were set and the rest was creating more guns and levels that fit within the framework we had outlined. Certain things did get revised over time. For example, the builder interface is probably the 5th generation. However, the kind of pieces that you manipulated was mostly consistent.
There is explicit and implicit evaluation. When creating a new thing you make a list of the work that needs to be done in the order of how important the parts are to the final experience. Once you have built it half way you can see if you are moving in the right direction. At that point you’ll either continue, revise, or scrap the plan. If you move forward then you’ll evaluate where you are at a bit later to figure out what kind of polish it needs.
However, core systems like the builder are evaluated implicitly over the course of the whole project. There are some things that take a long time to notice and you can’t evaluate them in an afternoon.
