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.
You can download the game from the RoTo project page. There are also videos to watch. Be sure to read the instructions on the project page before you play!
Note; if the game complains and doesn’t work, try installing the Microsoft Visual C++ 2005 SP1 runtimes – available here.
So this is the final blog post for RoTo’s prototype development (at least as far as my AGT project goes). It’s been a hell of a rollercoaster ride. I’ll make another blog post later with my reflections on the experience; for now I’ll give the updates in standard format.
Over the last few days I’ve been facing crunch time – getting everything done has been difficult, and of course I haven’t had time to implement everything I’ve wanted to. However, I’ve added some finishing touches like the title screen, finsihed adding levels, and even managed to come up with a new gameplay device, in the form of a physics-based spike ball that rolls around and kills the player on contact. These things are fun. Not only can I be exceptionally malicious with them, but they’re also fun to run from as a player.
I’ve been working on implementing the enemy, along with the level results screen and a few less important additions. The enemy implementation went pretty well, and it brought a smirk to face to watch the “Wanderer” exploring my levels, looking for the more spacious route. The AI is simple at best – it’s a basic wandering behaviour with a finite state machine, but it fits the game style perfectly and works brilliantly as a gameplay device. I don’t think shooting is necessary, as the enemy is already competant at killing the player, or at least guiding them into traps, which is exactly how I want it. The design of the enemy is based on the one from my sweets game, but improved – call it Sweet Enemy Mk II. Or “Wanderer”. Or something.
With the final hand-in looming, work on RoTo is really picking up the pace. I’ve been adding and tweaking levels, fixing bugs, scrapping designs… one of the biggest changes is the removal of the rotating/moving platforms idea – it seems OgreNewt isn’t keen on the idea of a moving platform updating the physics of the objects around it, and I don’t have time to beat it into submission. It was a minor gameplay feature anyway, so I’ve dropped it – as well as giving up on the idea of having achievements. I do still plan to have a results screen at the end of each level, however.
In terms of bug fixes, I’ve been going over some minor bugs (and a couple of major ones) that have been in the game for a while now. The biggest of these is a problem that has plagued me for a while – in fact, I changed my whole input system thinking it was a problem with that. Basically, sometimes you’d start the game and wouldn’t be able to jump. It happened completely at random; until Johnny was playing the game yesterday – it started happening consistently. It was one of those moments where you drop everything to start putting debug variables in and getting output so you can finally squash the bug – it turned out to be an uninitialised variable that was obviously getting initialised to a random value from memory – if this happened to be less than 0, the jumping delay would never clear and the player would be left unable to jump. I’m surprised it slipped through, but I guess everyone makes silly mistakes from time to time. I’ll have to be more careful about variable initialisation in future.
I found that flipping/mirroring of curved level pieces caused collision problems, so I redid the way I implemented flipping and mirroring of level tiles – it now detects collisions properly. The red zone filter that turns the screen red was staying on after a level faded out, so I fixed that, as well as the player’s death not resetting the level’s rotation angle. An odd bug showed up where spikes didn’t do anything if they were in a red zone – this turned out to be the game fighting over setting the red zone game state and the player death state, where the red zone state won, so I fixed this. The font for the newly implemented overlay from a few weeks ago had a few problems in it (a couple of pixels out of place), so I fixed those too.
No screenshots today, because nothing visually very interesting has been added.
This week I’ve been working on fixing up various things for RoTo. Adding levels has been a primary concern for a while now, so I’ve gone ahead and started making them. It takes a little while to write them in pure XML, but at least it’s doable, and it’s actually proving to be relatively painless. I’ve also added the collectable score bonus objects;
This blue one is worth 50 points (changed from 100)
This is worth 200 (changed from 500)
And this one is worth 800 (down from 1500)
They look a lot better in game, because they rotate. I decided to keep them simple since there’s to be a lot of them, and there’s a nice particle effect when you collect them.
Another nice addition is fade transitions; with fades between screens the game now looks and feels a hell of a lot more polished. I’ve always been a fan of fade transitions, so it’s only natural that I had to put them into RoTo at some point.
I’ve been thinking about how I’m going to go about doing the enemy object; my plans have been vague since the start for this – all that’s really been set in stone is that I want the enemy to be simple. Other considerations, such as whether it should shoot, have been left until now because I don’t want the enemy to be overpowered or make the game too hard.
My current idea is to have the enemy use a wandering behaviour; basically, it’ll move forward until it reaches a wall, then figure out whether to turn left or right based on which way would cover more ground. After it has turned, it will start moving again – rinse and repeat. I can use a finite state machine to implement the moving and turning. If I need shooting, I can implement that as an extra state.
In terms of colelctables, I want score bonuses; I’m thinking 3 denominations – one giving 100, one giving 500 and one giving 1500. Not sure what to make the score collectables look like – I quite like the wireframe effect I’ve been using throughout the project though, so I’ll probably use a material that has wireframe enabled.
The level editor has gone so badly I’ve decided I need to leave it alone for now… as much as it’s been a huge waste of time, I can’t afford to spend any extra time on it, so I’m going to do the levels manually and see how that goes. That means that I’ve started working on the actual game itself again – I’ve added a retry button and abstracted the overlays into a slightly better system – overlays can be switched and changed now, meanign I can go ahead and implement the title screen when I need to.
Since my last update I’ve been mainly working on the level editor, while considering other aspects of the game’s development – particularly the graphical side of things. My original plans for the level editor were to have it in-game so that the player could drop in and make modifications; however, the level editor has got to a point where it’s eating up far too much time and fully implementing it, then tying it in with the game would be way too much work to be worthwhile for now (especially seeing as the assignment doesn’t call for it at all). As it stands, I’ll use the current level editor as-is to make some cool levels for the final hand-in, instead of putting more time into it.
As for graphics, I’ve never really intended to have the game be a graphical masterpiece; I want the visuals to be clean and simple, while getting the point across. A little while ago I wanted to redesign the overlay system and have the HUD looking nicer; I’ve done this now and it’s looking a lot more professional.
This shows the new overlay in all its glory. I think it looks a lot cleaner and far more professional than the one before. It also shows a bit of the first level… (and yes, I’m about to die)
If I have time I’ll implement a nice player graphic, but beyond that I want everything to be simple and geometric. The game already has a few shader effects in; namely filters, additive & tint shaders for particles and bloom. I may add more when I get the chance, but I have bigger priorities since the level editor has been such a large time sink.
Next up is to polish the gameplay with various tweaks, add the retry button, and get things looking a bit better.
