I submitted Whirlygig to Dream Build Play 2009. I started my game in mid May and it has been a long 2.5(ish) months. It’s actually hard to believe that I did it. While I know that there are a lot of things lacking and many things I would change, I can’t help but have a feeling of accomplishment.

I started programming about five years ago. I have attempted to make a game many times in many languages such as Flash, Java and finally XNA. I have many, many half-games but have never actually gotten a game to a somewhat-polished state that was acceptable for other people to play.

So, in May, when I read about the competition (which had already started), I wasn’t sure if I could do it. I knew that I would have less than two months if you figure in bug testing and play testing. In that time I would have to come up with a concept, create a design style, actually learn C# and XNA (while I had done some stuff, I had never done anything near a complete game), create and integrate the artwork, play test, bug test, solve problems and finally submit the game. This was somewhat overwhelming, especially when I read that some teams had been working on the same game that they submitted to last year’s competition.

I decided to approach it like a marathon. I know I won’t be a competition winner. But, there’s something about completing your first one that is honorable in itself. My goal was to simply complete something that I wasn’t ashamed of and that I would enjoy playing. I feel like I have been successful in this.

One thing that really helped me was reading Building XNA Games. The book was co-authored by the creator of Dishwasher Samurai, one of the earliest successful indie games on the XNA platform. Even though the book is centered around XNA 2.0, it had a wealth of information on really practical things like setting goals and staying on track against a deadline. This was very important in my progress over the last few months. If I had set out to create a 3D RPG with multiple cities, NPCs and environments I probably would barely have gotten a 3D model loaded into XNA by the time the competition deadline rolled around. I would have gotten discouraged and quit long before I had something remotely playable. Instead, I said to myself: “what kind of game could I create that would be fun but achievable in just a few months?” And Whirlygig was born.

Some things I am disappointed with?

• The overall game idea could have been a little more inventive. I hoped to make up for a not-too-innovative idea with lots of features but many of the ideas I had to spice up the gameplay had to be eliminated from the competition release. The good news is, there’s no reason I can’t have them in the game by the Live release.
• Collision detection…it’s pixel perfect but it’s processor heavy. It needs to be vastly overhauled. This is the top item on my list before I release it on Live. I had to make many concessions (see last post) to keep lag down during heavy collision testing processes.
• Learning process. I’m not disappointed in the actual learning, I learned a ton! I am disappointed in the sloppiness of my code. As I learned better ways to do things I improved my code but not having time to go back and fix some things made it pretty messy. Quick fixes to problems that arose also made for some illogical code locations.
• Feature stripping. I had/have some really cool features in mind like the ability to select your player color, save your player name and ship preference (multiple types of ships was another thing that was stripped), and keep track of player stats. I wanted more weapon variety and the ability to create custom maps in addition to randomized maps. I also wanted more robust scoring and combo shots but some of those rely on a better collision engine.
• No single player mode. There just wasn’t time for single player or any other game modes. Hopefully this can be part of a future release.
• Resolution adjustments. The game is locked at 1280×720 (see last post) but the engine actually supports almost any native resolution. The user should be able to select the best resolution for their display device (or the game should automatically select it).
• Error catching. I know very little about error catching. While I think the game is pretty stable, rare errors that happen tend to not fail gracefully! This will have to be improved before public release.

So, yes, there are things that suck. There are things that I need to fix. But I did it! I created a video game that looks cool, sounds cool, is somewhat fun, and is almost entirely my creation. That being said, there are a few people I need to thank:

• Kevin MacLeod of Incompetech.com, he provided the unique and interesting music for the game.
• Catchiso, a programmer friend of mine that helped me nail down a tricky math problem.
• MtbikeMayhem, who provided advice, feedback and playtesting.
• Wifey, who was patient with me during my long nights and frustration when I hit programming roadblocks.
• The authors of the book mentioned earlier in this post.
• All the contributors out there that provide answers, tutorials, examples and other helpful information. It is because of these people that Indie communities exist.

Thank you for reading this post and your interest in the development process and Whirlygig. Here is the competition trailer video:

We’re down to the wire folks. Final submission deadline for the Dream Build Play contest is Thursday, August 6th. Ideally, I will submit the game prior to the final day in case something goes wrong. That means I really need to have everything done by Wednesday.

I made significant, important progress this weekend and the game is pretty much done. I upgraded all code and soundbanks from XNA version 3.0 to 3.1 (a requirement of the competition). Other than the fact that it takes some time to download the latest framework, uninstall the old one and install the new one…the upgrade was pretty painless. I clicked on the project and clicked “Update” and pow – done. Of course, when I built the project it crashed (nothing works the first time) because I hadn’t upgraded the audio portions of the project. Once I did that, it worked fine.

I’m down to the last of my todo list. I [think I] fixed an error that came up in bug testing where if you fired a rocket as the game ended it wouldn’t be unloaded. This didn’t crash the game as the rocket would unload itself when it’s timer ran out. But it did cause some potential memory leaks in addition to looking really unprofessional.

I created a controller diagram that shows how to control the game. I loaded this diagram into the loading screen and also the pause screen. So, while the game arena loads it shows the controls and if you press pause. Controls are simple enough that most players probably won’t even look at this. It currently needs to be positioned a little better on the screen.

Originally the game was intended to scale to any resolution. I still hope that the release version will do that since the graphics look cleaner that way. However, there were significant potential issues with fitting all game elements from 640×480 to 1920×1600. Given a little more time I’m confident that I can tease out these issues but for the competition, the resolution will be locked to 720p and scaled by the xbox automatically…the easy way out. Problems that this fixes: sometimes the buildings go out the top of the screen on small resolutions meaning the player can not access parts of the arena and may spawn on top of a building. In addition, at the highest resolutions there can be significant lag when all four players are playing and are flying close to buildings. This engages the pixel-perfect collision system which has significant overhead. In my tests, it’s able to handle it with rare lag at 720p.

The last big thing I noticed was major lag in a certain situation. There is a building (see post image) that is a stylized version of the Sears (oops, I mean the Willis Tower of course). Since it stairsteps up, the object rectangle is significantly bigger than the building in certain places (near the top). When a powerup icon falls toward the building it quickly enters the object rectangle, causing a basic collision which triggers pixel-perfect collision. Since there are almost 100,000 pixels to test in the tower alone, and they are tested every other frame, the game is basically looping through around 600,000 pixels per second and testing their transparency against the powerup icon. There are much better ways to do this but not in the timeline I had. Anyway, the short term solution is going to have to be to remove the Sears Tower from the game. This is a bummer because it’s one of my favorite buildings. Fixing the problem correctly would require significant coding and there just isn’t time at this point.

So, things I have left to do: Remove the Sears Tower (this will take a few seconds), Fix where the controller diagram displays (it overlaps the loading text right now, this is an easy fix), write a game synopsis (will take less than an hour), and create a game trailer (could take a few hours), remove some debug code and package the game for final submission.

I think I have about five hours of work left before I submit the game. Wish me luck!