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:

