These last few days have been surprisingly hectic. The results of my testing provided some very important last-minute changes that needed to be made to the code. The most important was that the resume support was broken if the application had some form of unexpected quit. We had a 6-hour power outage half way through my 24 hour test runs. Once the power was back, I attempted to resume the process only to find that the serialization data was corrupt and the process could not be resumed. This made perfect sense as I was overwriting the same files each time – I’m glad this happened when it did though, as I’ve been able to rectify the problem by making it alternate the main ‘resume.txt’ file with a backup ‘~resume.txt’ file and serializing classes to a separate file each time. I’ve also made it write the resume data every generation instead of every 50th, as hard drive space isn’t really a premium and the most this will run to is a few gigabytes.
I’ve released the playable version of the game to the masses, ready to start collecting results!
Here’s the original post:
===
First of all, you can download the game HERE.
Over the last few months I’ve been working on a simple tower defense game to investigate the relationship between human learning and machine learning through genetic programming. It is part of a research project.
I’ve finished the basic game, and now it’s time to start collecting data both from the evolution of the computer AI and from human players. I’m posting this here in the hope that some of you might want to try my game out, and in the process help me to gather data about how human players learn to play the game.
All I need you to do is play the game; when you’ve finished playing and close it, the game will send the score, time and number of times you’ve played the game to my webserver, so that I can later use the data in my project report. (note that this functionality has now been disabled)
I may also continue to develop the game after my research project is done, so feel free to give any miscellaneous feedback too. In fact, the more you give me, the better, even if it’s not constructive or whatever. even if you think the game is just shite, let me know because it helps me gauge interest 
Here are some screenshots…
The game is practically done at this point. I’ve been doing some additional playtesting to find any bugs that need fixing, as well as game balancing issues and geenral improvements that need to be made. One of the more prominent problems was that it was hard for players to remember the range of each tower; to combat this, I added a range marker while placing towers that can be seen here:
The range marker displays while choosing where to place a tower, depicting teh area in which is can shoot.
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.