- Open space: This mode is a very sparsely populated 3 dimensional space. This is suitable for 'outer space' situations. This is the mode used in my Asteroids test application. This is pretty much a flat scene graph: A list of objects. Status: It works.
- Indoor: This mode is for tightly closed spaces with lots of complexity. This is for mazes, for inside building, dungeons, etc. The scenegraph here is actually a graph: it is a list of sectors interconnected by portals. Status: Mostly works. There is a critical bug I need to fix.
- Terrain: This mode is underdeveloped. I have old (really old) code that supports this, but only in a very basic way. I currently have implemented geomipmap patches: These are quad (well, square) arrays of quads that can be drawn at different levels. A 256 by 256 quad, can be drawn at 128x128, 64x64, 32x32, etc all the way down to 1x1, which is a single quad. This way, the geometric detail for each square region of terrain can be varied based on distance. This is a very common solution to the problem: Status: Not close to finished. I can draw a small list of patches at various detail levels, but have not made the jump from geomipmapping a couple patches to geomipmapping a large scale piece of planet.
Next Steps:
I can do two things: 1)focus on the graphics code, and fix the indoor bug and finish terrain or 2) I can make a simple game with what I have now and get my code out onto the internet
I am going with option number 2. In the Asteroids test, or whatever you want to call it, you can fly through space and shoot at asteroids, just like the classic Atari game. The open-space portion of the engine works just fine, so these are the next steps:
- Add sound
- Add simple powerups and score system
- Add an alien spaceship to shoot at the player (remember the stupid UFO noise from old Asteroids?)
- Clean up the portions of the graphics code that are exercised by this simple game
- Put it up on github.
