XNA Game Studio Coding Jam, Fall '08

I recently signed up to attend an event for developers and artists which allowed them to collaborate on an almost-released build of XNA Game Studio 3.0 and build a game in a short amount of time. When I signed up, I was under the impression that this event took place on a Saturday and lasted all day long. It wasn't until last Friday afternoon that I got an Outlook Calendar reminder which corrected this false assumption, informing me that in fact it was an all-weekend event.

Reluctantly, especially given the time and energy I've been devoting to iPhone development recently, I bit the bullet and told myself that this was an opportunity that I didn't want to pass up.

The event consisted of an Iron Chef-style "five ingredients" challenge (also similar to gamedev.net's "elements" programming contests), in which we picked from randomly generated lists of game elements from which we derived a game concept. We quickly formed into groups, each containing (thank the Lord) an artist, and tried to pick the most appealing set. The elements we chose were Doom, Clock, Robot, Pirate, and Defense. Our game: Doom Clock Robot Pirate Defense.

As an aside, it's funny what goes on in my head when I have to choose team members in a short amount of time. Ultimately I'm looking for enthusiastic, motivated, skillful people who are also mellow (i.e. no Prima Donnas). Obviously it's impossible to gauge this in such a short amount of time, but I was fortunate with my group.

We ironed out the basic details of the gameplay Friday evening, and began our implementation bright and early Saturday morning. (Seriously, it still amazes me that I was able to show up on time at 9am on a Saturday.) Much to my great concern, we opted against using source control, and instead agreed to use a memory stick as our repository. Yikes. In retrospect, I bet I could have created an actual SVN repository on that thing. It wouldn't have been perfect, but it would have likely eliminated many headaches.

It quickly became apparent that our lack of source control was a very bad idea. Nearly all of our changes involved multiple shared files, and the process of merging was very manual, and very confusing. We essentially had four different versions of the code floating around at any given time, and it became difficult to tell whose changes were the newest. Instead of merging to the USB stick, team members would often just copy the changed versions of their files to a separate folder on the stick, making it nearly impossible for me to tell when a line from the USB stick's code was newer or older than what the programmer had copied to the new folder. Suffice it to say, it was a big mess, and I'll write it off as a reminder of why source control is so crucial.

Our artist, Chris, was hard at work from the very start. I regularly glanced over at his drawings and wished I had that ability. I also envied his lack of need for any sort of source control solution. We'd call out when we needed art assets, and I was tempted to ask for something completely ridiculous just for the fun of it, but I restrained myself. I really like the opportunity to work with an artist on a project for several reasons. First of all, I'm much more inspired to work on a project when I have visual gratification at regular intervals. I may be able to create intriguing gameplay without an artist, but I don't really believe it until I see it. As soon as I see appealing illustrations and animations, that's when I first start to feel the real potential of my project. Second, it's a great experience to discover the processes needed for a functioning content pipeline. What format should my images be in? What size? Should each frame of an animation be a separate image or a large composite image? What if the composite image isn't a square; will the texture importer complain? Questions I may not have even considered are suddenly an important part of the process, and this experience makes future projects go much more smoothly.

After a couple full (but not overly burdensome) days of coding, we ended up with a fairly playable prototype. It contained several types of enemies with AI, three different types of towers, several levels, a controllable player, collision avoidance, a snazzy menu system, support for the Xbox 360, and even same-box multiplayer. I added all the code to a repository which I shared with the team, and I've even seen significant updates from one of the developers in the past couple days. I am tempted/eager to clean up the code, since ours was inevitably very messy and arbitrary, and just enough to "get the job done." I am almost as much a Code Nazi as I am a Grammar Nazi. (Although seriously, I don't think that avoiding "u" in place of "you" and knowing the difference between "your" and "you're" qualifies me as a Grammar Nazi; that just means I have at least a third-grade education.) I just think there's something inherently selfish about writing bad code if you're on a multi-person team, but I'll save that soapbox rant for later.