Sure, this game is not going for sale or being published or whatever. So it wasn’t the complete game development cycle, but there was still plenty to learn. This is my 2nd complete game released, so I’ve still got a ways to go :). But I figured I’d at least run through the motions and write a detailed postmortem. Read on for the details…

What Went Right?

1. The idea. It was rather strange how WildBoarders came to be. As the idea it spawned from had little to do with snowboarding. I was interested in doing some sort of physics based game. More specfically, a balancing game. My first idea involved balancing, jumping, and trampolines (don’t ask). I later realized I wanted a simple control mechanic if ’tilting’ and was just searching for a theme to wrap it around. So I took the easy route. I love snowboarding. So I took to that theme and found the tilting mechanic would work very well with a 2D scrolling boarding game. One of the factors was the controller having shoulder buttons to provide a more intuitive input to the game. The fact that I was simply excited about making the game and I like snowboarding just increased the chances of the game actually getting done in time.

2. The design. For a few hours that day I wrote up some ideas on how the game would play, what the mechanics would be, and how it would look. I did not try to think about the code that would run all of this or have a “how am I going to do that?” type mentality. All I did was pen-and-paper game design. If I had spent my time thinking about code implementations I could have ended up committing to a design far too early just because the code was done or thought up already. I had already scrapped two or three ideas before this one because I didn’t think it would be fun. Making your ideas easily disposable I guess has some merit. At the same time I didn’t get scared off by complexity of some of the implementation because I didn’t concern myself with it. Yet.

3. Colorful art. The next piece of the puzzle was getting art assets, and fast. Thankfully Adam came to save the day on that one. I asked for a very stylistic and simple art style so the art could be produced very quickly and cheaply, but still give it a very prominent style. So the game ended up being very cartoon-ish looking, which I had in mind in the first place and liked every bit of it. Colorful games tend to be more eye catching to the normal passer-by. Especially when browsing galleries of screen shots, thumbnails with brightly lit images tend to grasp the user’s attention.

4. Farseer Physics Engine. Talk about the right place and the right time. When choosing to do this game I was fully ready to get down and dirty and write a physics engine for XNA from scratch to help with the game. A quick search beforehand, and I stumbled upon an alpha build of Jeff Weber’s physics engine he was doing directly for XNA. Sure it was alpha, it had a few minor glitches, but it saved me weeks of work if not months (which in that case WildBoarders might have not been done). This was a major contributing factor to get a very early working prototype in a couple of days. With the outlook of the engine to be in ongoing development I figured I could always update to a newer version should issues arise and be fixed, which in reality did happen.

5. Tools were in a working state. Prior to this competition and XNA being released I had been working on a 2D map editor in a different language. Most of the major functionality had been implemented and was general enough that I could write an XNA library to read the binary map files and use the assets generated by the editor. This also was another major contributing factor to getting a prototype up early in development. Tool development is time consuming. So I considered myself fortunate to have a half-working map editor that I could use for WildBoarders. A lot of the functionality needed to create the last bits of maps for WildBoarders wasn’t added until about 2 weeks before the deadline.

6. Prototype was fun! Within a few days of the concept design I had a crude prototype up and running. It was ugly, had glitchy mechanics, but it conveyed the idea of the game. It was definitely fun and at this point this gave me the motivation to complete the game.

Above: Early WildBoarders prototype screenshot. Ahh, the memories…

7. Testers are invaluable. Don’t ever try making a game and just releasing it on day one without it having it being played by someone else, preferably on a different computer/console. If you do, there’s like a 99.999999% chance something will go wrong if you’re game is any more complex than pong, and that’d being very generous. I had a couple of gaming buddies, friends from home, and just other people play the game in an early state. They would always find something wrong or break it. Even up to deployment with the installer! Apparently, there was a bug in the installer compile script that was auto-generated by the installer program. Don’t under-estimate the value of good alpha and beta testers.

8. Source control will keep you sane. I never start a project I intend to work on more than hour without setting it up with a source control program. I use Subversion, personally, but there are plenty of other programs that may suit your needs better. If you don’t have it then get it. Never lose your source again and never worry about ‘messing up’ your code when you can always roll back to a prior version. It’s disaster insurance for your source. Keep the repository on a different machine is what I recommend (maybe even just a USB key).

What Went Wrong?

1. Tools. Yea, I had a map editor that would save image files and tilemaps and polygons for physics objects and such, but it was very incomplete and had several bugs. If only this editor had been a bit more developed prior to starting work on WildBoarders I feel I could’ve polished up some of the later maps in the game. When you’re fighting or avoiding your tools more than just using them, then that’s a signal the tool isn’t meeting your needs.

Above: The editor that was in the middle of development just prior to WildBoarders, but eventually used to create the maps for the game. Even though it was rather incomplete (aka buggy).

2. I ran instead of jogged. I’ve heard it many times before. Never out-pace yourself when developing your game. You will quickly tire, bore, or simply get burned-out. For the first month I was developing the game at a considerable speed. Things were coming together nicely, but suddenly month 2 roles around and I simply didn’t have the energy or desire to work on the game for several days. The days I did work my actual productivity drastically dropped. No matter how fun your game is or how cool you think it will be, if you work yourself too fast on it you will lose that desire that originally started you off on this game. This inevitably lead to a crunch time in the last week of the competition. Thankfully, due to the nature of the contest it made it much easier to find motivation to work on the game along side other contestants and also with the support of the community.

3. Prototype was too fun. I spent way too much time playing WildBoarders rather than working on it during several days where I needed to keep on schedule.

4. Vague requirements for art assets. Because I didn’t have a complete editor I just kind of ‘winged’ it on how big the art should be and such. Initially it took way too much system RAM to run the game. I later went back and optimized this, but I still feel there’s a lot of room for improvement here.

5. Not a completely finished design. Near the last couple of weeks I had some levels, I had controls, and I had some simple animation state code. The game just didn’t seem to get out of that ‘prototype’ mode for a while. Adam kicked me into gear and I started adding in several components to make the game feel more like an arcade game. Some of these that were added in later were the coins that you collect and the locked levels and high scores. I then added in ‘special’ moves for each character to give them more unique traits. I think I could have avoided alot of the crunch time if these gameplay elements were implemented much earlier.

Above: The coins and some of the tricks were added very late into the development of WildBoarders.

6. Last minute sound. While I did get in contact with the lead singer of Shut Up Travis to get permission to use their songs, I still didn’t have any sound effects for a while. Again, this was more of a last 1-2 week thing that got added in quickly. Sound tends to get the backseat when developing a game; yet, it can really bring a game to life. When the only two senses used for most games is sight and sound you can truly be missing the other 50% of the experience with poor or no sound.

7. No content pipeline. When this game was started in Beta 1 there was no content pipeline available. I implemented my own content management for loading and unloading sprites. It certainly wasn’t as sophisticated as the real content pipeline in XNA Beta 2, but it worked well enough for the game. The downside is I missed out on one of the major features of XNA. Having to write your own load/unload/reload routines was something I was use to from making other games, but it would have been nice to finally leave that alone and focus on writing my game. I did employ the XNA content pipeline where ever I could, but the majority if the images are managed by a homegrown solution. The pipeline would have proved very valuable in the last days of development so I didn’t have to constantly debug file paths and other asset related errors.

Thoughts on XNA?

I’m really liking XNA and what it has to offer. The content pipeline, once you’ve used it for a while, is really hard to not use and you miss it when you’re developing elsewhere. It takes out one of the major snags in game development. I have only two major gripes about XNA after finishing WildBoarders. My first one is the lack of different supported audio formats. Not sure if this is just a limitation due to the cross-platform-ness of XNA or a licensing issue. It sucks to add almost another 40-50 MB to your game for music when using some sort of compressed format would greatly reduce the size. I wonder if they’ll add ogg vorbis support in the future or maybe it’s just a matter of writing a content manager for the content pipeline to manage ogg vorbis? The other issue is the complexity of installing XNA games on users machines.

For the most part, users have no clue if they have the latest DirectX runtimes or .NET 2.0. Adding both these runtimes adds another 70+MB to your already large game file due to audio. And getting users to download both of those and then expect them to install XNA afterwards is asking a bit much. Even I’ve turned down the opportunity to get a user to try my game on their PC simply because I’d have to install so many things rather than just run one install of the game (like most games). With every step that you add between the user getting the game and actually playing it is potentially another lost/disinterested/frustrated user. Hope this improves in the future, and with Vista around the corner it may very well improve. All in all, XNA is a great platform to make games with. Right now it’s not the easiest thing in the world to make a game with if your a complete beginner, but it’s definitely a step in the right direction and for hobbyist developers that have made games before this makes it much easier.