XNA Shmup

So for anyone who cares and hasn't heard me rant about what I wanted to do with the XNA stuff I'll just explain it now. Ryan inspired me to go in the direction of a shmup, I have wanted to do one for a long time but this new framework seems ideally suited to a game like this. There isn't any particular art style or theme set atm so I'm just laying out some really basic shmup gameplay elements that are pretty much 'required' to have a respectable game. One of the key ideas though is to completely leverage the 360 controller. I want to have a very natural action mapping to the controller that makes sense and gives you more control than simply shoot and move.

A few concepts that I am borrowing for the GD are:

• Roll defense from starfox
• Polarized attack for the enemies ala ikaruga (radiant silvergun), the difference here is that ground targets must be bombed, squigies must be railed with mass driver weapons and conventially shielded enemies require beam weapons.
• All weapons are effective against all enemies but certain weaons are much more effective. This technique is vital to survival.
• Ability to equip a small pod that can has limited controlled and it's own set of upgrades.
• Clip/reload system for mass drivers/bombs, energy system for beam weapons. Ammo is plentiful but must actually be collected and you cannot hold the fire button the whole time.
  
  
  Here's a screenshot debugging one of the triggers for a mob spawn and the new bullet system:
  
  
  
  Again, not very impressive looking (it looks better in action) but I'll just layout a few of the things that are working now.
  
  
• Follow camera
• Scene trigger system that can fire proximity events
• Mob controller with spawn/death management (hooked to trigger system)
• Mob action scripting pcodes with time driven events (Fire, Rotate, Change properties etc)
• Random terrain generator

I'm not trying to do a fully polished game currently. Just something that starts up allows you to play through a random level with increasing difficulty and records your high score. I will probably implement a few different types of weapons as well.

I don't know if I want to finish it all in one shot.. I have to get back to some other stuff.. really ;)

It's coming along

Well there is more or less something there now. It is actually playable, although not being able to see scores and combos is a bit of a drag. Also the thing is completely full of bugs. It has gotten a lot funner to work on now though. Much less doing the boring plumbing that runs the show and more doing the AI and gameplay that I enjoy.

On Hobby Coding: Test driven development

I always had a focus towards testing. Every major commercial project that I've worked I have been pretty good about writing some kind of developer facing test suite not always before the meat of the code was written. What has really solidified the testing mentality for me was the last 2 or so years up until about a couple months ago I was an engineer completely focused on writing functional test code and stress simulations.

I took this job intentionally, not just because everyone I interviewed with completely impressed me technically but because I really wanted to stretch myself in this role. It has taught me a lot of new things about design and every day coding and it has really evolved my hobby coding as well. I don't write exclusively test oriented code any more but I'm even more sold than ever on the benefit of approaching things from a testability angle.

Wikipedia has a good definition of TDD. Your milage may very. Personally, I usually write the 'client' functionality test and then implement either a no-op interface for it at first or something very basic. If I'm working on something new and complicated I spend some time mulling it over and drawing pictures first. If it's adding some small functionality to existing I'll do the simplest implemention.

During the time I'm implementing I'm always looking for ways to collapse functionality (ie. refactor) or simplify things. A lot of times you find issues before hand as you're writing the test, things you didn't think of when designing. Here's some warning signs you'll likely see:

• This code is totally not testable..
• If I could only get at that lower level thing, this would go way faster
• If I shared that dohicky than I only need to write n/2 lines of test code
• This is going to take some serious time.. do I don't really need this?

These are all really net-positive things to discover early on. Most importantly.. these things are discovered before you write 2k lines of dense game library code. There are some real challenges to be solved here that are going to make you a better designer and coder:

• Proper layering of your code, decoupling and exposing multiple layers so they can be tested individually. This is a non-trivial design challenge to do correctly but done right is really great.
• Cutting down uneccessary feature-creep when you really actually don't need something. When there is nothing left to remove you have the perfect product ;)

And at the end of the day, if you did a half-decent job you have a properly designed testable system that you can easily make changes to because you have a proper test framework for it. There's more here but I'll save it for other posts. Less theory more practice.