Projectiles and Particles
It’s occurred to me that in a game where particles are not just plain renderer data but can actually affect the environment, there is a blurring between projectiles (part of a combat system) and particles. As I was implementing the basic supporting architecture for my particle system it occurred to me that I was in fact repeating the same code as for the projectile system. This gave me an idea. Why not merge the two concepts? Each particle can use a reference to something implementing a per-particle interface, and the class implementing that interface can then provide the differing behavior for each particle type. I can use raycasts to make my particles bounce off of objects, even dynamic objects, damage things, set stuff on fire, and so on, with very little actual complexity.
For a long time now I’ve preferred a ballistic system over the “instant ray” method of handling bullets and other projectiles in a game. Games like COD feel wrong after playing with a semi-realistic ballistic sim like the one in STALKER or the BF series. A particle system which is integrated with the ballistics system should let me get some of the feel that these games have into my combat system.
I now have a nice, usable projectile system. It doesnt’ look that great when rendered, but it is linked up with the physics engine and the graphics side of things. I’ve created a test case where you point the camera and things and shoot a hail of bullets at them. I think I might put it in as a bonus level and play the Valkyries in the background. (Surely that piece is out of copyright by now?)
Getting this to work optimally was a bit of a challenge. I needed a system which, as per my memory policy, does not allocate anything at runtime, instead using object pools at load time. I implemented an object pool which deals with the starvation problem by reallocating, and gave it a starting size of 1024.
I’m using BEPU as my physics engine. To make the projectile system work, I added a system of tagging physics objects with a special tag, and then extended their Space class to include a new raycast function dedicated to projectiles. The system performs pretty well when I stress test it with 50,000 projectiles per second.
The next step is to code up the response to being hit by a bullet.
I discovered this visual by accident, while writing a shader. That’s not the first time I discovered something cool due to a shader bug. Anyway, this got me thinking. Why not place the entire game in virtual reality? I can keep the lightning strikes, and have something virtual realitywise and awesome as the backdrop.
When I get some better input data for my terrain rendering, I’ll be able to complete the effect, for now, it just looks like I textured a normal terrain with the wrong thing.
Tank driving around terrain woot
I now have a tank driving around the terrain. It isn’t great though. I’ve attempted to simulate a tracked vehicle using a row of wheels down each side, and messing with the friction coefficients of each wheel when the tank is turning. This really isn’t working.
I’ve yet to see a game which uses similar physics to wheeled vehicles for its tanks; it seems that most games are “faking” it using differential drive equations. For example, BC2 doesn’t seem to have any suspension on its tanks; I think it uses a series of box casts against the static terrain and uses some function of these various casts to create an average plane on which the tank is oriented, then uses another function of the amount of spring force each box uses, to compute where the vehicle is in relation to the plane normal. Then is simply fakes movement using differential drive equations.
For the duration of my challenge I’ll stick with my crappy but functional tank physics, and upgrade to the system I described above for the real thing.
Ive created a stress test for the physics and rendering engines; the purpose of this is twofold. There are 2500 tanks falling from the sky, all using instances of the same articulated mesh.
Firstly, im using the clr profiler to stamp out any runtime allocations. Since the garbage collector on the 360 is somewhat crude, every 1mb of garbage created will cause a fully recursive mark and sweep… this is a disaster for a game, so it must happen as infrequently as possible. by removing all sources of runtime allocations now, i will be able to test frequently as I develop the game and remove any other issues without them being buried under the spam of existing allocations.
Secondly, this is a good basis for adding other types of profiling, including my preferred method of in-game stats. Some time soon I will be monitoring the time taken for each stage of the update cycle, and rendering, to monitor what takes the longest in different scenarios.
This looks simple, but its actually a few days work; i can now instance articulated models from a single .X model, which I can export from my 3d editor, and add any number of vehicles using them to the world, and they can each rotate their body parts to different positions.
I now have a basic system for articulated meshes. This is important because I need to be able to make parts of a tank (such as the turret) rotate independently of each other.
I’ve not done much work this week though, mainly because of moving house. My next challenge is to integrate a physics engine with the vehicles. I’ve done wheeled vehicles in havok, but tanks are a bit harder.
I have now added the first type of skybox geometry, a billboard. By using a billboard as skybox geometry I can cheaply draw celestial bodies, or closer objects such as lightning bolts.
An early screen shot. The red light is coming from the “sun” (ive yet to decide what kind of planet has such a red sun) and the white is from a lightning strike. My next step will be to build a geometry skybox with actual objects in the sky, to match up with the lighting.
Directional Lights, Lightning strikes
I have decided to use a traditional forward renderer for my lighting now. I was torn between deferred and forward pass for a while, but I’ve decided that as I don’t really need a lot of lights, forward will be easier.
I’ve added a basic system of 3 directional lights, who’s effects are calculated in the vertex shader and then passed down to fragments, and started an implementation of a sky box with 2 directional lights.