This week we’re bringing you an interview with Pixeljam Games about their stellar game creation Dino Run. If you haven’t played the game before, I recommend that you stop reading this article and go play it here because you’re missing out! (and then don’t forget to come back here to finish reading this article ;D) –Ada

MochiLand: Hi Miles! Let’s start off with an introduction. Tell me about yourself and Pixeljam Games.

I’m Miles Tilmann and I’m the programmer for Pixeljam. Rich Grillotti does all the art and animation, and Mark DeNardo takes care of everything audio-related.

MochiLand: How did you get the idea for your latest creation, Dino Run?

I’m not sure exactly :) I think Rich had the idea about a year ago when we were brainstorming for mini-games. Something simple and exciting. And then somehow the whole thing kind of exploded into the size that it is now. That’s usually the case with us. We thought we would have it done in 3 months, and then 3 months turned into 7….

MochiLand: You had 300 beta testers for Dino Run. Can you share with us how you found these beta testers and collected feedback from them?

First of all, it took months to even collect that many. We beta tested the game twice… once in mid-production and once at the very end. This made a huge difference, as it allowed lots of time to gather testers, and we made a lot of changes to the game mid-stream before bad or untested ideas could take over the game.

We were lucky enough to get linked to from indiegames.com and tigsource.com, who have a very devoted following and always like to help out other developers. We are also fortunate enough to have a decent amount of indie cred from Gamma Bros, so lots of people that went to our site saw the link from there as well.

So to answer the question simply, patience and perseverance.

MochiLand: Sometimes feedback can be contradictory. Some people think a level is great, and others hate it. How do you decide which way to go?

We rarely do exactly as our testers suggest. Most of the feedback is used to tip the scales when we are on the fence about something. Also, the delivery of the feedback is really important. A very negative criticism that is well-thought out and well written will get a lot more weight than blind praise.

It’s very easy to get emotional about passionately delivered feedback. Take it all in and let it simmer in your head for a while before taking any major action.

MochiLand: Tell me about how the beta testers influenced how Dino Run was made and how it changed during your testing period.

I dont think the game would be nearly as successful had it not been for the testers. To get so many different perspectives on a project while you are working on it can be very overwhelming and possibly frustrating, but overall it’s a necessity, unless you are omniscient. As with any endeavor, big or small, if it becomes too insular it’s going to disappoint a lot of people except yourself.

In the middle of the game we needed alot of feedback on basic gameplay mechanics. And at the end we just needed to make sure everything worked. Theres no way we could have done this by ourselves. The game had become way too complex for just a few people to approach it from all angles to make sure it was solid and bug-free.

MochiLand: Would you use beta testers for all your games?

Absolutely.

MochiLand: Any advice and recommendations for other Flash game developers?

As we transition from starry-eyed amateur developers to a self-sustaining company with a few titles under our belt, we’ve definitely learned alot in the process. Some of these points are no-brainers for more experienced developers, but all of them are worth considering again:

• Your game is not just a game, it’s more like a small universe that will eventually self-create it’s own community and politics. Keeping this in mind is very important, even before game development has
  started. Expect for a lot of unexpected things to happen once the game goes live.
• Making up the rules and features of the game as it is developed can be a nightmare, especially if the game is large. If possible, plan everything out beforehand and then program the game to make it easy to change later if (and when) you change your mind about how it’s all going to work.
• One mistake we made with Dino Run was adding a few more features after testing was done and a day before the game went live. I could have sworn that it was a simple change and couldn’t possibly break, but if you are lone programmer working on a large game, assume that every tiny change can break the game, even if it doesnt seem possible while you are adding it. Do a lot of testing mid-development, and then finish the game 100% before doing the final beta testing. When you add more features, ask the testers to play it again. Do this over and over until you are certain everything works. Better to delay the release by a few weeks than to get a bunch of stressful emails from frustrated players after the game goes live.

Thanks for your time, Miles! Please feel free to ask any Miles questions via comments, and if you would like to see anyone else interviewed, please let us know who and what you’d like to ask them!