OK, the main things I've been working on over the last week or so are as follows:
Player/World collision
This is now basically done, along with player ship damage and particle effects at collision points. The particle effects are a mixture of sparks and rock being disturbed from the walls, which looks quite nice when scraping along the side. It also need a good corresponding sound effect!There's still some tidying up and improvement to do on this aspect, but it's sufficient for now. Have a peek:
Scripting zones
In order to make a game with an interesting and interactive world, there need to be scriptable zones within the world that can do a variety of things, from bringing up a certain story conversation, spawning some enemies, changing world states (e.g. opening/closing doors) and a lot of other things. The basic scripting capability now exists, and is embedded within the main global asset management system. At the moment its capabilities are pretty limited, but these will rapidly expand as I add more scripting interfaces.Upgraded collision detection
For anyone unfamiliar with collision detection, the basic problem is one of testing your game object's bounding shape (a circle, in the simple case) against all the objects in the world. Now, if you have 10000 primitives (e.g. lines/triangles) in your world, the easiest way is just to test directly against each of the 10000 objects, leading to 10000 geometry tests per object. However, using a hierarchical (tree-based) model you can achieve this in around Log2(10000) = 13 tests, allowing much greater efficiency. Even better, if you increase the number of primitives by a factor of 2, you'll only need one more test. This scaling allows testing against very complex world geometry in an efficient fashion.Anyway, something that's been niggling at me since I upgraded to using the physics engine is the old hierarchical collision detection, which used a binary tree in order to calculate collisions with each triangle in the world mesh.
However, in reality, using all the triangles was quite wasteful and pointless, as the only important bits are the lines that form the outline of the world itself, and the corresponding bounding circles/bounding boxes were much larger than they needed to be. Since the world is carved from an overall vector brush, though, this outline is directly available, and thus I've refactored the code to produce a collision tree from a set of lines rather than triangles, leading to an overall improvement in efficiency and niceness. This is one of those things that won't have any directly visible effect, but makes further development easier.
Looking at that video, I think you should consider employing George Michael as a beta tester :P
ReplyDelete