Week off

Pyweek starts today, so I'm on holiday from the game until next Sunday.
In other news, me and Sam pair-programmed the beginnings of the Entity/collision system. We also got Monsters querying tiles for which direction they're going, and in the wee small hours I got the directions for each of the AI paths (now called Red, Green, Blue and Purple instead of 1, 2, 3 and 4) parsed out of the map file and loaded into the game. Added a debug-draw method to Tiles so we can see what's in 'em (the orange blocks are MountPoints):

TDD/Pairing Session

I was thinking, since you guys aren't totally up to speed on the ol' testing front we could do a pair (or tri) programming session on Saturday. I'll share my screen while I TDD the fuck out of the entity manager. The other person(s) watching can be backseat programmers (not nearly as annonying as it sounds - it's ace to have someone catching your stupid mistakes as you make them).

When I've got something in a check-inable state, we can check in the code and switch who's doing the coding.

It was a screencast of someone doing just this that made TDD finally click for me, so I think it could be pretty useful.

Current Build Issues

Just thought I'd raise a few points about how we're approaching this in general, since its starting to look like a game now =D

First off, I'm getting confused by the number of files there are with multiple class/interface definitions in them. Was wondering if this was a temporary measure or the way you guys want do it. I never put more than one class definition in a file unless its a private class (which is rare as-is). Mainly just a concern as it makes it hard to follow where things are. I have a multitude of files ready to be synched, but I can't integrate them properly because of said definitions for things I have that clash with what's there.

Second, and mainly - I don't want to step people's toes by rearranging stuff the way I like it, so I think it would be a good idea to have a discussion about core standards. I'll go ahead and upload what I can right now, but its going to take a bit of fiddling. I feel that a stronger approach to organisation at this stage will prevent problems from arising in the future.

Tower class structure is about 50% in place, though I've made a few assumptions at this stage about what we might need which you will see reflected in the outline implementations and interfaces. Provisions are there for upgradeable entities (towers/weapons), selectable objects (towers/monsters) and (guess work here) some kind of unified update() interface.

Regards.

My monster senses are tingling

Just committed first part of monster senses. You can now get the surrounding tiles for a given tile. Was much harder and took way longer than it should have (in the same time Sam got all the UI stuff done!)

To be fair - in doing this it made me re-think the way I was adding tiles to the world. Instead of keying them by grid square when they're added, I just made a method that gives you the grid co-ordinates (i.e. the top left corner of the tile) for a given screen co-ordinate.

We should be able to get onto some interesting, gameplay-like stuff pretty soon :)

UI rendering updated

Was supposed to look at input today but got sort of sidetracked. Anyway the UI rendering now suports alignment, transparency, strings, background images on containers and empty space atomics.

Menu rendering system beta

Today I got a Swing-ish menu system for the game sort-of working. It's just the rendering (minus animation) at the moment. Above you can see a VerticalFlowLayout container holding three HorizontalFlowLayout containers, each holding a few 'atomic' elements, in this case images. String support is more-or-less implemented but I couldn't be fucked dealing with wrapping at 1am so I had a beer and a banana instead (undecided about that triple-filtered Stella- it's not bad).

The nice thing about the system is that it is recursive and will trigger a full re-layout every time you add a new element, and automagically stretch to fit them as they are added. Padding and borders are supported at every level.

I didn't use TDD- I wasn't sure how I would do a test for a menu system or how much I should presume to get done, whether I should write tests for animation or not, etc. When it came to the point where I assumed the implementation was complete, I went to build my menu and realised I didn't have a clear idea how I was going to use it, and ended up making a good few changes- so now I definitely see the advantage in TDD! With TDD I would have thought about this from the start. I'm still not sure how to go about testing something so visual, to be honest.

So anyway, it remains to include input response, button states, and potentially animation. Oh, and background images. Thinking about it, I don't know why the fuck I have the concept of 'atomic' elements- they should all be potential containers, then background images would be supported intrinsically. Probably a simple change. Oh well, it's late.

First Screenshot

Ported over the code from the level prototype project, including the TileFactory. The main game class now creates a World, with Tiles from the TileFactory (doesn't do anything with them yet, though - the map is just drawing its "terrain" layer).

Not sure what should be passed into World's constructor now. It would be easy to give it a reference to Map, which has the tile width/height and number of tiles. This means a fake map has to be constructed in the tests (not much of a big deal).
The alternative is to extract each of the things World needs from Map and pass them in in the constructor directly.

Comments on a postcard.

Levelling up

Been working on the level implementation. Was originally going to work out paths dynamically using some mad pathfinding algorithm. But then I thought, it's tile based, let's just use tiles for AI paths. So I did.

You can have up to four different paths - as described on the wiki here: http://code.google.com/p/gntowerdefence/wiki/LevelDesign

There's no code to parse these AI paths yet (there was no original requirement for them). I'm thinking either you have a 'Directions[aiPath].Direction' property on a Tile object which the monsters query, or you have a completely separate collection of AiPath objects... open to suggestions :)

Here's a screenshot - blue: start; purple: goal; red: mountpoint; green: path; arrows: aipaths

First commit of game project

Did a few solid hours of TDD last night to get the bare bones of the game in place. So far there's adding/removing towers, and the logic for monsters entering/leaving tiles. That includes the Goal tile, and there's a GameOver event fired when the Goal runs out of points.

The way I imagined monster movement working last night was: every time they move a certain distance they fire a MonsterMoved event. The World is listening for these events. When it detects that a monster has moved over a tile boundary, it fires a MonsterChangedTile event. All the tiles are listening for these, and it allows them to keep a list of monsters they contain (especially important for the Goal tile).

This initially seemed wasteful to me - it's a lot of events - but then I thought "computers are fast as fuck", and ignored myself. I'd like to use the philosophy of naive implementation, only optimising where it's painfully obvious or actually costing us CPU.

(Thinking about it now, World should know which tile the monster has moved into, and message it directly - ah well, the events haven't actually been implemented yet so it's an easy change.)

Doing the tests first was pretty helpful - your code starts off being useable - it has to be so you can test it. It does seem quite slow going at first, but you have a certain level of confidence in your code afterwards that you don't get otherwise. Definitely recommend you guys give it a shot. Give me a shout if you need a hand with the mocking framework or the minutiae of NUnit.

Particle engine beta finished

To familiarise myself with XNA and C# I wrote a little particle engine that can be plugged into the game later on for some neat effects. I had trouble with getting the effect to rotate as a whole but will leave it alone until we are at a point where we can consider using it.

Game Concept

The game description courtesy of Gary:

As far as the game goes, it's a basic tile based tower defence game. The tiles are going to be: start point, end point, path, or mount point (which you build turrets on). The baddies will come in waves from the start point, and you lose a point everytime one gets to the end point. Game's over when all the waves are finished or you run out of points.

You stop the baddies getting to the end by building towers. There will be a few kinds of tower - machine guns, flamethrowers, the usual. Towers can be bought or upgraded for credits which you earn when you kill baddies. There will be a small level of direct user involvement (these games are really meant to be strategy games rather than action games). For example - as in Ninjatown - you'll be able to change the targetting behaviour of your turrets to target the strongest/weakest/flying enemies/etc. You'll also have a weapon or two that you can directly use (when the enemies are about to get to the goal, and you're desperately trying to build turrets but can't in time) like an artillery strike that you can call in.

OK, let's get this started

To begin with, a link to the Google Code site and Wiki.