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.
Okay folks, it’s summer and it’s the perfect time to hit the pool! This being a game development blog, you can probably guess that I’m not talking about the filled-with-water kind of pool, but rather memory pools. Oh yeah, programmer puns. They’re the best, right?
All joking aside, pools of preallocated objects are a basic but very useful structure for controlling memory allocation in games. The basic idea is that, instead of allocating (“new-ing”) an instance of an object just before you use it, you preallocate a set number of objects ahead of time and store them in a list (pool). Later, when you actually need to use an instance of the object, you grab an unused instance off the list and initialize it with the relevant data.
This week on Game Dev Without a Cause, we’re going deep. Deep copy that is! Okay, you really have to be a programmer to find that all appealing.
You may not need to do it often, but when you do it’s really useful to have an easy deep copying solution on hand. As simple as it is conceptually, it can be surprisingly difficulty to find a general-purpose way to perform deep-copies on arbitrary collections of data. It can be especially difficult with XNA because the Xbox 360 doesn’t have the full set of features available to the Windows version of the framework. Sure, it’s easy enough to write deep copy logic for simple structures, but who wants to be stuck updating Clone() functions or the like every time they add a member to a particular class.
LIke the scaffolding around an under-construction building, it’s important to have the right structures in place to aid your work even though you won’t need them once the job is done. In the case of games, this takes the form of the various bits of functionality used to debug games as they’re being built.
In the hope that they prove useful to other XNA developers, I’d like to introduce a couple of GameComponents that I use to provide debug functionality for my games: LineBatchComponent and ScreenLogComponent.
Last week, I put effort into making modern, full-color rendering look like an old TV. This time around, we’ll go even further into the past and make the screen resemble an old, faded photo. To produce this effect, I use a pixel shader to apply a sepia tone to the image as well produce a vignette effect by darkening the edges of the image.
Modern pixel shaders have given game developers tremendous capabilities with which to improve the visuals of their games. They’ve also given developers the ability to make their games look WORSE. That’s okay though, when it’s on purpose.
For this week’s post, I’ve put together a pixel shader that takes a normal full-color game and renders it like a black-and-white screen with lots of static. Continue reading