| »

Thoughts on Winter Wars, What Went Wrong?

Winter Wars was the first game that RedPipe Media has completed. It leveraged an engine built in Objective-C over a period of a few months by me, our group’s only programmer. The group started in May of 2009 because I had just graduated from college and was looking for a way to keep my skills fresh. A friend of mine, Steve, suggested we go into iPhone development. It was a way to expand my toolbox so I made no objections and immediately picked up a couple of books and started learning.

As I was building the game engine, we brought on an artist, Kiyome, who I had worked with over the previous couple of years on school game projects, to help us start making prototypes.  Since she and I are both insane workaholics, we mesh extremely well together. There’s something for everyone to take from this. If you find someone who you work incredibly well with, that’s actually rarer than you’d think. Keep those people close since you never know when you might need someone with their skill.

One prototype stuck out to me and something that was going to be somewhat easy to make and could be kind of fun. In it, you fire a laser at snowballs scrolling across the screen. I was able to make the prototype in a few hours with my heavily content driven engine. I think our initial enthusiasm really stemmed more from the fact that I was able to make it so quickly, rather than whether or not we thought the game was actually going to be fun.

I personally was fascinated with the idea of firing lasers at things and snow is something that just made sense at the time with the approach of winter. I’m still fascinated with the idea of firing lasers at things, however designers beware: lasers that work like giant beams aren’t that fun in 2D. The issue is there is not a lot of skill development involved. You point at things and they explode. There’s hardly any room for error. It’s like taking a light gun game like Duck Hunt and putting the gun to the screen and shooting. The initial design was based on the roller coaster ride in Final Fantasy VII. You lose power on the laser as you fired it so tapping it was the best way to keep the charge. There were some things about this idea that we found more annoying that fun, so we refined it a bit.

Something happened at this point in the development cycle that I want to really emphasize as what NOT to do when developing a video game. We started building around the core gameplay after a simple prototype that we thought was ok. If you’re making a game, and you’re not totally constrained by a publisher, you have to know with every ounce of your being that your prototype is amazing and not just OK. The prototype is everything. The game built around it is just there to emphasize the prototype. It is your fallback if what you built around it isn’t that great. There is not a single thing in the development process more important than the prototype. It establishes what you’re setting out to do. We made the mistake of moving forward before our prototype was perfect, and we paid the price.

So you might be saying, “Well, this sounds like it turned out pretty bad if you were so unhappy with how it started,” but that’s where the bad ends really. There weren’t that many hiccups once we went into full production and I will go over that process in the next post. The take away here is heavy focus on the prototype is essential to make a good game.

This entry was posted on Sunday, June 13th, 2010 at 9:53 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply