« | »

Thoughts on Winter Wars, What Went Right?

We went into production with a team of three. Kiyome was our artist, Steve was our designer who also acted as producer in order to keep us on track, and I headed up all of the engineering. Weekly design sessions were used to keep the project flowing and make sure we were on track. Initial production was somewhat lagging, but I feel like this is just the danger of Indie development. There was a point, though, where we realized that if we don’t really ramp up production, we would miss the holiday season completely and that immediately sent us into high gear.

So we were going into the holiday season with a game way too big for us to finish. There were multiple weapons, purchasing of weapons, more enemies, and crazy effects. It would just be impossible to get all this done with the time we had left so we scrapped most of that. One weapon, three enemies, randomly generated levels. Cutting back to the basic essentials suddenly brought the nightmare schedule right into the realm of entirely possible.

It was this point in the production that I am really a fan of. We were a well oiled machine, with animations surging in from Kiyome and immediately going into the game for testing with our easy-to-use art pipeline. I had planned to get more engine features in, but with the time constraint, I was forced to make do with what I had. It made me realize that dropping tech for quick and dirty solutions can really be a perfectly valid way of doing things if there are time constraints. One major example of this is the day and night cycle. The entire project we had said that this would be impossible. We figured that we would need to create layers of each individual animation to blend between. What we ended doing was just having an overlay and a background to change the color of the entire scene. It worked out far better than we could hope and was relatively simple to implement.

Unfortunately, even though we were doing well getting things done, we missed the deadline for submissions that would make it for Christmas. In December of 2009, Apple decided to shut the iTunes developer connection down for a week before Christmas. This meant that anyone not submitted by this date would miss the holiday. Fortunately, because of the week-long shut down, anyone who submitted after this immediately went into review since the line had been emptied during the shut-down.

Our first submission was rejected by apple because of the use of private frameworks. If you ever find a solution for a problem online and they are using functions that you cannot find in the documentation, refrain from using them unless you don’t intend to submit this app to the iTunes store. Don’t worry too much about it though; if you are using private frameworks your compiler will most definitely warn you about it. I just chose to ignore it thinking it wasn’t such a big deal. After another submission, we were approved and released Winter Wars on January 1st, 2010.

I’d like to now make a few closing remarks about miscellaneous topics. This post mortem seems to shine the game in a negative light but in the end I think it has some enjoyable aspects to it. The game is mindless fun and you get to shoot some punk kids with lasers. The art and animations are a major strength of the game. Kiyome was really able to take our very silly ideas and turn them into characters and props that are fun to look at. I particularly like the young snowball thrower who runs away with his rear-end on fire when you shoot him. I, of course, also have to mention the ghost buster’s style laser beam, even though it doesn’t lend that well to gameplay, looks pretty sweet.

Another piece of the puzzle that fit together rather nicely was sound. We purchased a sound library since we knew we were going to need sound for a number of projects. After going through the entire thing, I picked out a few sounds that I liked and threw them in. For the music, I found a website offering free music and went through a number of different sections. After coming to a list of ambient tracks, I knew what I needed was something upbeat. I found one song that I thought was pretty good so I took the song and put it into a folder called “Pretty Good.” There were a number of songs that I thought fit decently so I put them in a separate folder. At the end of the browse, I found that only one song fit, and that was the one marked “Pretty Good.”

One last major thing that I learned from this project is just how slow Objective-C can really be. It is very easy to fall into the trap of memory allocations and deallocations everywhere. This is compounded by how slow even the simplest function call can be. There are ways of optimizing both of these situations, sometimes involving some dangerous hackery. What I would suggest is to write your heavy algorithms in Objective-C++ and if you really want to use Objective-C features, leverage its dynamic structure in gameplay programming.

Now that I’ve taken you through an indie group’s development of an iPhone game, I hope it’ll inspire some of you to go out and make something fun for yourselves. I can’t say I didn’t have a blast doing it. There were ups and downs throughout the project but that’s like any project. If you have any questions about iPhone development or just development questions in general, don’t hesitate to email us. We’d love to hear from you.

This entry was posted on Monday, August 2nd, 2010 at 6:06 pm 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