1:37 am, Sunday, 8 October 06
It's been a few months since I've had a look at the tankwars game. When I left it in August, the game created the arena ('tray') as a grid of squares at random heights. The squares, and the walls on each side of them, are random colours:
In this screenshot, you can see the two far sides of the tray, olive green in colour. There are two sides on the near-edges of the tray, but they are only visible if you are looking from the inside out.
The player's tank is also there (well, I didn't make a tank model, and used a spacecraft I'd already made):
The player can move the tank forwards, backwards, they can rotate it in either direction, and they can jump with the Q key. The two images below show the tank making a jump off a high black-coloured square:
The movement of the tank is pretty smooth - some of the shots above show the debug text, which gives information about the performance of your program. This debug output is provided as part of the G3D library, and you can of course switch it off once your program is complete. One piece of information which it provides is the frame rate, and you can see that it's routinely above 200 frames / sec.
This high FPS isn't altogether surprising given that it's such a simple game so far. For example, the tank's position is taken to be the centre point of the craft. This results in clipping, as the tank will continue to drive through a wall until its centre point reaches the wall:
Neither is there any optimisation of the graphics code as yet. This is something I would like to experiment with - for instance, drawing only those squares which are in front of the camera (currently all squares are 'drawn', even ones that can't be seen). This is what is called frustrum culling, and I'd expect it to ramp up the frame rate even higher. I would also like to experiment with other refinements, such as drawing only necessary walls for the squares. At the moment, each square has all four walls drawn, while in many cases just one, two, three or even none are visible (the others being 'hidden' by the walls of higher adjacent squares). It would be interesting to see if the extra processing required to determine which walls can be skipped would equate to less processing (ie higher frame rate) than just drawing all four walls.