The classic SHMUP (shoot-em-up) may be one of the purest video game designs out there. Even for games like Ikaruga that implement systems that dramatically change the gameplay, the core mechanic stays essentially the same: the player must destroy enemies while dodging loads and loads of bullets.
Given the significance of the relationship between the player and enemy bullets, the design of said bullets is crucial to making a SHMUP work. The following is a series of guidelines that I use when implementing enemy projectiles in games.
No bones about it. Video games have a LOT of text in them. From character names to item descriptions to names for screen-clearing special attacks, there is a lot of text that, at some point or another, has to be rendered to the screen.
With XNA, rendering text to screen is a no-brainer. The SpriteFont implementation makes rendering strings to the screen with a variety of fonts trivially easy. There is one problem though: rendering SpriteFonts with DrawText() can be really slow.
TDD (Test-Driven Development) can be great. It encourages you to address edge cases earlier when you have a better grasp of the code you just implemented. It forces you to de-couple classes in ways that allow you to later combine and re-use them in ways that might not have been possible had you developed them using other methodologies.
TDD can also be a big pain-in-the-ass. Isolating logic for testing can be difficult, especially when you need to rely on code that requires complicated external resources: legacy codebases and hardware being the prime examples. The XNA Framework code, with its substantial functionality abstracting the details of hardware on Windows, the Xbox 360, and Windows Phones, falls squarely into both of those categories.
So, does this mean that it’s impossible to use TDD when working with XNA? Hardly. It can be tough, but there are ways to make it easier. In this post, I’ll talk about how I’ve managed to work with XNA while still giving my code the TDD-loving it deserves / needs.
TDD (Test-Driven Development) can be a hard-sell in many work environments. I said as-much in a previous post. The main problem lies in figuring out how to calculate the concrete time costs of TDD versus the abstract (but real) benefits.
While it’s easy to track the costs of TDD with a timesheet recording the amount of time spent writing tests versus production code, measuring the benefits in a measurable way takes a bit more creativity. My approach to measuring the benefits of TDD in my own code is to keep a journal of moments of when I think I have reaped benefits due to TDD. This is, of course, a very anecdotal approach to measuring the benefits, but it does provide a basis for tracking effects of TDD that would normally go unmeasured.
In a previous post, I mentioned the solution I use for performing deep copies in XNA. Recently, while fixing a bug in a recent project, I made a minor tweak to the deep copy function that made a major difference to its behavior.