The initial version of Space Defense Hero served as my introduction to the XNA Framework. As such, the actual design and use of technology is rather atrocious. Since the conclusion of the semester, I have done some work towards refactoring and redesigning, but I think it’s important to go over the initial “release” of the game first.
High Level Overview
The concept is exceedingly simple. You are an unnamed hero who flies through 2-dimensional, side-scrolling levels of increasing difficulty, shooting any asteroids or enemy ships you find in your path. At the end of each level is a boss, which you must defeat to proceed. Each level is randomly generated, choosing locations for asteroids and enemies at run time. The initial position of the boss, however, is set, so each level is the same length.
There is no “winning” in this release. Game play continues, cycling through all of the boss models every third level, until the player has died enough times to run out of lives. As level increases, both the damage taken from getting hit and the score for making kills scale upwards. Theoretically, you could eventually get to a high enough level that requires you to avoid getting hit at all, because any one shot could kill you. As a practical matter, however, it is unlikely that anyone will get past level 6, except perhaps on easy difficulty.
The reasoning for this is simple. Since the class was “Sensor Enabled Game Design,” we hooked up a Wiimote to the computer, via Bluetooth, as the primary method of controls. The general lack of precision this introduces (since we did not have time to involve the sensor bar for a “point where you want to move” control scheme) makes it very difficult to accurately dodge anything. The real goal becomes dodging as much as you can, without making an sudden jerks that may slam you into more than you were trying to dodge initially.
However, this also adds the gimmick of the game: movement in and out of the screen. By tilting to the Nunchuk 90 degrees to the left or right, the player’s ship will dodge in or out of the screen, and then slowly return to the plane that all of the other enemies are on. As a result, the player can dodge laser fire and ships/asteroids. Of course, your lasers won’t hit anything either, while you’re dodging. To prevent abuse, this ability is usable every three seconds.
Of course, every gimmick must have a counter gimmick to encourage use. In this case, it’s the idea of “special weapons” on bosses. Every boss has a standard attack that fires a single shot in a random direction in front of it. The second boss model adds a secondary weapon, which shoots a sustained burst of weaker lasers in the direction of the player every once and a while. Taking one or two of the lasers from this burst will not hurt much, but on higher difficulty levels, taking the entire burst is enough to kill a player.
The third boss model adds another weapon, which is only used once the boss is under 50% health. This ability creates a wall of lasers, from top to bottom, all of which do significantly more damage than an average laser. Dodging this attack is crucial, as it will do a very large amount of damage. However, without the dodge gimmick, the only way to actually void it is to hope that there happens to be an asteroid between the player and the boss. This gamble is foolish at best, and at worst a failing strategy.
Each object has a base score. The score actually received depends on both the current level and the difficulty setting. Player max health, health regeneration rate, starting lives, and damage output all scale downwards with difficulty level. Enemy damage and health remain constant, but from the perspective of the player, who does not see the raw numbers, they appear to gain more health and hit harder.
As would be expected, sounds play when things blow up and lasers are fired. In addition, there are two pieces of music — one for levels, and one for boss fights. For a bit of eye candy, there are particle effects for explosions.
Code Structure
The game is based primarily on the GameStateManagement example. Modifications were made the the InputState class to allow Wiimote handling, as well as some basic additions to give a level completion screen. The bulk of the code, however, has just been thrown into the GameplayScreen object. It’s a fairly simple setup, involving lists of all of the objects we’re interested in, but with few functions. The code itself is pretty unwieldy here. Particle effects were implemented using an adaptation of the Particle sample. Essentially, we brute forced it into the GameStateManagement code. Audio was pulled from the internet (music from Overclocked Remix), converted to WAVs, and pulled in through XACT. The audio content makes up the bulk of the program size.
There are remnants in the code of an attempt to use Steffan Palleson’s Poly-perfect collision detection work, though we were never able to get it working properly. There were some issues trying to explain to our modeler what exactly we wanted in terms of low-poly physics models, so it is quite possibly just an issue of using models that are too complex.
Our object hierarchy could have been better designed, but it worked for the sake of getting an A in the class. Basically, we have a top level GameObject class, and several (Player, EnemyShip, Laser, Asteroid) classes that derive from that. Bosses are simply an extension of EnemyShips. A large amount of relevant data, such as the model and scale, must still be passed in on the constructor, however. Also, there is no really easy way to add additional types of enemies.
Our camera does not move, but rather the player moves within certain bounds, and all objects have been given velocities that will eventually move them into view. Lasers are destroyed once they get off screen, and objects are destroyed once they go off the left side of the screen.
Reflections
A lot of this was brute forced. By the end, encapsulation hardly existed. The concept is sound, and we were able to follow through to enough of an extent to achieve the short term goal of an A, but the code is in no real state to be expanded or improved upon.
To that end, my next project is to reimplement SDH, paying closer attention to design details and planning, then improving the game to fit more closely with the original vision.
