Tuesday, October 21, 2008

iPhone tunnel game progress

It's been a few days, so how is the game coming along? Quite well, actually. I took a step back to think about how I could have multiple levels of content. If I set everything in code, then it will too laborous to create any amount of meaningful play. I came up with a simple level system that allows me to make each level a single text file that events can easily be added to.

The ship slides forward in the level at variable speed and there is a certain draw distance that the program tries to maintain. If it notices that an object mentioned in the level file has come into draw distance, then it makes an instance of it. At first it did this by loading the model file from disk (or is it flash ram?), but that created a one-frame pause in the game when an object was loaded, so I had to preload everything in the beginning of a level, and then just make references to the already in-memory objects when they come into view.

Currently the level file has just two different lines. Either the graphics for a tunnel should change at some depth, or an obstacle should appear at some depth. This seems to work well now, I created a level about 10 seconds long with various obstacles appearing that the player can avoid by tilting the device. It's not clear from this whether or not this would be an enjoyable game, but I think it might be. Obstacle avoidance is a pretty common game element, and players do seem to enjoy it.

I've now come to a sort of mental block. The player cannot crash with the obstacles, they'll just slide through them. I feel that the collision detection code is absolutely crucial to get right. If the player feels that the collisions aren't handled properly, they may feel betrayed by the game. If you die, it should be your own fault, not the fault of inadequate collision detection in the game. But 3D collision detection is not an easy problem. Luckily in my case the player object is very simple, and the obstacles are totally flat.

I was really happy that OpenGL was doing all the matrix operations for me, but now it's coming back to bite me. To do collision detection, I need to know where the vertices are in world space. So I think I'll have to make matrix multiplication code anyway that can mimic what OpenGL is doing, so I can get the post-transform data. After I have the ship and an obstacle in world space, I should be able to see where the flat obstacle is in relation to the ship, then take a z-slice of the ship at that point. After this the collision detection becomes a 2D issue of seeing whether the flat obstacle should collide with a flat slice of the ship.





I also plan to have spherical power-ups and bonuses that can be picked up. In those it could be sufficient to see if any vertice of the world-space ship is inside the sphere.