It’s been a while since I’ve posted an update because I’ve been very busy with the project. With the deadline moving ever closer, it’s time to get serious about the project. I’m always serious about things, but now it’s time to get really serious. Or something.
Up until last week enemies have been spawned in the Game class for testing purposes, and I didn’t have a proper method of spawning them. This week I’ve been working on fixing that. In the final version of the game, the enemy spawn rate needs to start very slow and speed up, reaching a climax at the end of the game. Also the exact rate of this will need a lot of tweaking and balancing, the basic code is there now. The way I’ve done it is to start with a large delay between each spawning (though the delay is fixed, so the spawn rate will be the same every time), and gradually reduce it over time. I originally tried reducing it every time an enemy spawned, but this caused an exponential rise in enemy spawn rate that made the shift between slow enemy spawns and fast enemy spawns happen over about 30 seconds – the game would start slow until about 3 minutes in, then suddenly crucify the player by bringing in hordes of enemies. I’ll need to add code for spawning different enemy types once I get those in which will probably be in the next few weeks.
I’ve also added the HUD text output for the status controller. This shows the player’s time, lives and score. Obviously I also had to move the code for the funds display into this class too, as I’ve simply had that in the Game class for a while.
Quite a large update, this one. I discovered HGE’s brilliant support for particles, including a pretty decent GUI-based particle editor. This meant that I was very eager to get some support for it in game, to make things look more dynamic. While working on adding this, I continued working on implementation of the basic gameplay features such as enemy shooting. The enemy shooting is somewhat more complex than the tower shooting code because the enemy needs to stop when it is front of a tower is cannot pass, change it’s animation and begin shooting until either it or the tower is destroyed. I had to make a decision on when to stop the enemy as well – whether the enemy should stop if a tower is built on top of it (ie once it is past the “shooting point”) or whether it should keep going, as well as the distance from the twoer that it should stop and shoot. These decisions are criticla to the game balance, so I tried a few approaches and settled on stopping the enemy about 24 pixels in front of the tower, and making them walk past towers that are built on top of them.
Naturally, after making the enemy shoot the towers I needed to make the towers destructible; this required adding a HP variable as well as some code for updating the tank grid so that the enemies no longer detected the tower as being there. I’ve also added the basic Status Controller class, which holds status-related game variables such as time, score and funds. I still need to add some HUD-rendering class to make this information available to the player, though.
So I had to recode some of the object manager this week; specifically the object deletion section. Turns out I had a bit of a bug in there, so sometimes the wrong object would be deleted. You’d think that after writing so many of these ObjectMgr classes, I would have a solid method of doing it down by now; turns out that in my haste to get this part of the development out of the way I was careless. You live and learn though – it seems fairly solid now.
The towers also have their basic code down now. I would’ve liked to do more, but fixing that annoying bug took up quite a large amount of my time. The code mainly has to do with targeting enemies; to attack, a tank needs to check all enemies from the EnemyController class to see if they are within shooting range, and if they are, find the closest one. Towers can only hit the target closest to them. The algorithm used for this goes something like (pseudocode):
Enemy* ClosestEnemy = NULL;
float ClosestDistance = high number;
for(all enemies)
{
if(enemy is in range && enemy distance < ClosestDistance)
{
ClosestDistance = enemy distance;
ClosestEnemy = enemy;
}
}
The damage needs to be applied to the closest enemy found. Tanks also have variables determining their minimum and maximum ranges, amount of damage and firing rate. Logically, the next step is to make the enemies fire back, and to code some of the specialised towers such as the barbed wire and supply truck. As a side note, I have to find a better way to paste code or pseudocode into these blog posts…
The code for placing tanks has now been added; a tank type can be selected by clicking on a selection card on the left, then the grid square for the tank to go is selected by clicking on it. Simple. A tank grid class keeps track of all the tanks in play, for when I have enemies in (properly). A few touches have been added to make the player aware of what’s going on – after clicking a selection card, the mouse cursor has a transparent version of the selected tank type under it, indicating where it is about to be placed. Also, the selected tank’s card is highlighted in red, indicating that this is the one currently selected. If a card is currently selected, the user can right click to cancel their selection and select a new card. I also added a preliminary funds system (just chucked into the Game class at the moment, I’ll need to refactor it) so that I can grey out cards that are unaffordable.
The enemy hasn’t really been damaged; it’s health was set at various values to test the energy bar code. I also seem to have forgotten to update the version number at that point… oops.
The tanks are just visual representations on the grid at this point; they don’t actually do anything. Next on the agenda is to fix this and to actually give them some code for targeting enemies.
This week I’ve been cleaning up the code that I’ve already got down, as well as adding energy bars. I’ve also added some basic enemy code, as well as spawning some test enemies to show their movement. The energy bars are an important game feature; it is important for players to know when enemies are approaching the death. Plants Vs Zombies did this by making the zombies lose limbs when they were weak (or otherwise have appearance changes), but since I don’t have the necessary spriting ability to edit those sprites to show damage, and since it would be very difficult to see on such small sprites, I’ve opted for the energy bar approach. While it would have been easy to simply draw a rectangle to represent the health, I wanted to have a nicer looking gradiented bar, with an outer sprite. As such I had to manually create each “frame” of the energy bars in photoshop, then in the game’s code calculate the correct frame to display given the percentage of health left. The result?
The longer bars are for the towers, which typically have sprites about 64 pixels wide, and the shorter bars are for enemies who are 32 pixels wide.
It’s been an interesting month, as you can tell by the lack of updates. I’ve got a lot done on Genetic Tower Defense; the basic game groundwork is all there now – all the boring code really, the ObjectMgr, Game class and interfacing with HGE. Speaking of which, I’ve had a great time with HGE. It’s a really well designed library – incredibly easy to use, and very good for rapid prototyping. I’ve got the skeleton of a game ready, along with finding graphics – some Advance Wars mods used with permission by Kevin900 (kevin900 [at] ymail [dot] com) and PillBox Phil (pillboxphil [at] hotmail [dot] com) – and arranging them into sprite sheets for use in HGE, in the space of 3 weeks. If I’d decided to use OpenGL or SDL this kind of thing would have easily taken twice that amount of time.
There’s not a lot to see, but the groundwork is all there.
I’ve decided that it’ll be impossible for me to get RoTo (XNA) finished in time for DBP. I originally intended to try and get it finished halfway through this month, then start working on the implementation of my dissertation project; however, since it’s not going to happen I might as well mark the beginning of the month by starting Genetic Tower Defense.
The project involves evaluating the use of genetic programming in generating human-competitive AI. Genetic Programming is the practice of applying the principles of evolution to a computer program in order to improve it; starting with a number of population members (individual programs), you “breed” them with mutation and crossover in order to produce new children; this is an iterative process that, in theory, should eventually lead to having a superior program. It’s obviously more complex than this in practice, but this gives the general idea – my project is all about using a “genetic AI” to play tower defense, then comparing the scores it gets against human scores collected from a sample group.
Work on RoTo XNA is going very well; I’m making steady progress, though I still have my doubts as to whether it’s possible (or even worth it) to get it done in time to submit to dream-build-play. However, I’m happy with the work I’m doing, and my plan to continue development of the Oxide engine alongside RoTo is working well too. Recently I’ve been working on getting some of the basic object types in, and doing major work on the level editor. RoTo uses object lists for its levels to save on having lots and lots of physics bodies for all the different tile shapes, so the object editor is the most important part of the level editor for developing RoTo. Since the level editor is the same one as Rocketman’s, I’m building the object editing capabilities on top, and as such I’ve got a fairly complete tile and object editing solution now. It’s still lacking some features but it’s definitely up to the stage where it’s usable and you can create levels with it.
I’ve got a video of it in action on Vimeo (and YouTube):
Next up on my todo list is the addition of the fundamental objects; checkpoints, red zones, exits and keys, among others. I’m goign to knock out as many of these as I can in the next few days, then start focusing on making some gameplay and finishing up the level editor (with features such as setting up level properties like music and ranking requirements). That should keep me occupied for the next little while, at least. I’ll post updates as they come; I’m keen to post more videos to try and generate some interest for the project.
So I’m ready to post about my DBP project; I’m porting RoTo to XNA. It’s early days yet, and I’m having some difficulties with loading times (turns out the XNA has a huge problem with lots of content files on the Xbox 360 which can cause loading times to increase exponentially…), but so far things are going reasonably well. I’ve just been working on implementing basic world rotation and the basic player object tonight, after nearly finishing implementing physics as well as doing lots of work on the Oxide part of the game. Things are going smoothly but I’m having my doubts as to whether it’s possible to finish this game in the 3 weeks I have before I need to enter it for DBP. Ah well, having the deadline certainly won’t hurt development of the game, and if I don’t manage to make the deadline I can always just release on community games after. Here’s some screenshots for now;
I’ve tried to keep the graphical style as clean as possible for now. I’m again not too sure how I’m going to do it, because I wasn’t 100% satisfied with the graphical style of the PC version…
And here’s the rotated test level.
As I said, it’s early days so there’s not a lot to see, but hopefully within the next month I will make a lot of progress with it. Since I’m essentially using a lot of the methods used in the original PC version coding-wise development time shouldn’t be anywhere near as long as it would be if I was starting from scratch.
Stay tuned.