Tue 01 Aug 2006
5:00PM
compton

Tank Wars in G3D

This little game will be a simple two player effort, where each player controls a tank within a restricted environment. The environment is a simple rectangle, where the players' tanks can only move within that rectangle. Also within the rectangle would be various static obstacles. The obstacles would be implemented as an array of Wall instances, à la space-station interior in my first OpenGL game.

The player controls their tank in Battlezone style - each side's tread can be moved independently forwards or back. They'll also be able to fire of course. Perhaps more than one fire mode could be available?

It's a nice and simple game, and it should be possible with my current level of knowledge of the G3D library.

Here's a rough time-line:
  • Make the bounding box using debug camera
  • Add the player tank and POV camera
  • Add the obstacles
  • Add the second player tank
  • Allow control of second tank over network

compton

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.
 
Leave a comment

/xkcd/ Geometriphylogenetics