I haven't posted progress in the past month, because i've simply been too busy releasing patch after patch after patch for the Infinity combat prototype. Yesterday, i released version 2.1 which is fully public. A lot of players have downloaded and tested it, and although far from perfect, it's a giant step up from the old 1.1 version.
I'd like to take a bit of room in this journal to make a summary of the ICP, what went right, what went wrong, and how much of it will go in the final game, what is experimental and will get improved, and the "unknowns".
On textures loading:
Version 2.1 added "unified" textures. I wrote one line about it in the change logs, but since we're in the dev journal which is more technically oriented, i'll give a few additional details here: previously, all textures were using bump + specular (gloss) + diffuse + self-illumination maps. Self-illum are for pixels emitting light ( like the small windows on the hull of the ships ). If you count well, that's up to 4 textures per surface, and that's also 4 texture 2D samples in the pixel shaders.
Since 2.1, the textures are "unified". The goal was to use only 2 textures per surface instead of 4. How is that possible ? Simply by using the alpha channel, as specular and self-illumination maps are grayscale. Another thing was the optimization of textures: converting bump maps to normal map was done at loading time, on-the-fly before. Now, the bump maps are pre-processed into normal maps. That helps loading times.. a bit.
Loading times would be blazingly fast if it wasn't for one thing: texture compression is enabled by default. It could of course be disabled ( and i might add a switch in a future patch ), but it would require a lot more video memory. Texture compression is automatically done by the OpenGL driver when you upload a texture to the video card, and let me tell you something: it's horribly slow. With my timings, i found that usually, a 1024x1024 texture takes 10-40 milliseconds to load, and 200 milliseconds to compress. So without texture compression, loading would be 10 times faster or almost. Unfortunately, there isn't much i can do to reduce this compression time since it's a video card driver thing. Maybe i could pre-compress them, but then i'd loose the ability to store my textures in jpeg2000, the format that i'm planning to use for the full game..
On networking:
Right, that's probably the most controversial part of the ICP. I'm not very happy with the networking model. There are many sides of the network model, and none of them work perfectly.
First of all, there's the network interpolation and prediction. You know, firing at a ship, seeing a hit on the client but nothing on the server.. most first-person shooters ala Quake/Unreal use techniques that can't easily be applied to something like Infinity/ICP, so i came up with my own technique. It looks okay when you've got a good ping ( < 100 ms ) but when it starts to lag, ships randomly jump around or move in strange ways, making it hard to hit anything.. i definately have to review from the grounds up the networking code for the game.
Another controversial point is what i called the "bubble system". Bubbles will likely play a fundamental role in the full game ; they're supposed to act more or less transparently to the players, but in the ICP it doesn't work so well yet. Bubbles are used to align movement of a ship to another one - the closer you are to your "parent" ship, the more you stick to its movement -. In the case where you're in the hangar of your parent ship, or very close to the hull, any movement ( translations or rotations ) your parent ship will do, you will follow *perfectly*. And it better work that way.. when you're docked in the hangar of your parent ship, you don't want to have to adjust your velocity constantly because your parent ship is maneuvring or accelerating ( remember, in space there's no friction ).
Another goal of the bubble system is to avoid seeing weird effects due to the network latency. If your 20 meters long spacecraft is moving at 1000 Km/sec, that means it travels 10 Km in 10 milliseconds. Now imagine an average latency that fluctuates between 100 and 150 milliseconds.. the ship will jump around by many kilometers at each "tick".
At this stage you're probably wondering: why don't other games ( like Quake/Unreal ) suffer from this ? The answer is simple: but they do ! However, their entities don't travel that fast. While in Infinity you'd have a 20m ship traveling at 1000 Km/sec, in Quake you've got a 2m character traveling at.. 0.01 Km/sec. Relatively speaking, it means that the effect is
*one million times* less of a problem.
Bubbles to the rescue! Bubbles won't solve the problem of ships jumping around due to those huge velocities, but they'll make your own ship/camera follow the same movements, meaning that visually, they cancel each other.. or at least, in theory.
In practise in the ICP it doesn't work so well. The reason to this is that it's only working client based, and that it only affects your own ship. What it means is that:
1. Another player spawning in a hangar should in theory stick to its parent ship, and perfectly follow its movement. Because the bubble only affects yourself, it doesn't and so.. you'll often see in hangars other player's ships jumping around, or even entering walls.
2. It is client based, so anything that involves server calculations will be slightly messed up. Plasma shots are one thing - which partially explain the hit misses and the difficulty of playing when you're close to a battleship -. Another thing is for example when you fire a missile and have your own ship collide with it and go mad. That's because the bubble system doesn't affect the missile: at the moment you fire it, your own ship will follow the movement of the battleship, but the missile will not.. and if those two movements oppose each other, the missile ends up hitting your ship.
Those problems can be fixed by unifiying the bubble system; in other words, making bubbles for every single entity in the game, and for both the client and the server. Unfortunately that was too much work for the ICP, so i'll do it for the full game.. and pray that it works as expected.
The A.I.
The A.I. is quite flawed. I used something based on "boids" ( flocks ) to simulate the movement of battleships. Unfortunately, they use different physics than player ships. It makes them possible to rotate by 180? in a second for example ( you can notice this strange behavior sometimes ). I will have to unify that too, and to make all ships use the same physics.
Because at level generation time, the position of all ships and entities ( asteroids, mines ) are random, it is possible to see ( that's rare, but i've seen it happen no less than one hour ago ) the battleship spawn inside the giant asteroid.. huh.
Performance
Last but not least, i'm not satisfied at all with the performance, both of the client and the server.
On the client side: old video cards have serious troubles to keep up with the complexity of the pixel shaders; that makes them slow down a lot in the hangars or near the biggest ships, when a lot of pixels are filled on the screen. But that's expected and there isn't much i can do here, except optimizing the shaders and providing a shader quality option. What's less expected is the CPU usage of the ICP.. it's the main bottleneck at the moment.
Why such a high CPU usage ? There are two main reasons:
1. The amount of objects to update every frame. A fighter is made of 2-3 objects for the body/wings, and 2 to 8 turrets. Frigates or medium-sized ships can have from 4 to 10s of turrets. The battleships have 30 turrets. Each turret is usually made of 3 objects ( they can pitch/yaw freely, count the barrels and the base too.. ). Since teams are usually balanced, a decent battle has around 15 ships per team. Finally, count a good hundred of asteroids and a few mines. Do the sum: in total, there are more than a thousand objects to update every frame. Moving objects indirectly means dynamically updating the octree for frustum culling, and updating the whole hierarchy of transformation matrices ( barrles attached to turrets, turrets attached to ships, etc.. ).
2. The collision tests - usually, the ray casting used for various reasons: plasma shots are the main one, but also testing occlusions ( ships behind asteroids, thruster glow effect visible by camera, lens-flares occluded, etc.. ).
On the server side, you find similar bottlenecks - excepting the video card related ones of course. But unlike the client, the server has to run the A.I. and a lot of additional checks, meaning that all in all, the server isn't really "lighter" than the client..
In the full game, i'm going to use an entity LOD system: merge together objects that are static or with unrelevant animations ( the server doesn't need to track the tens of the objects in gears of ships for example ). I'm also going to use a LOD system in the ray-casts and plasma shots.
The good!
Not everything is bad, of course. The public reaction to the ICP is very good. A lot of people are playing, enjoying and having fun with it. It has a "Star Wars" feeling to it that you can't find in modern games IMO. Probably the influence of oldby games such as "XWing" on me :) When it's not lagging too much and when there's enough players, flying around, passing close to battleships firing at each other, seeing explosions in the distance, all against a nice planetary background.. that's quite epic !
The physics and controls are now pretty good and are unlikely to fundamentally change in the full game. The question of the maximum speed is still floating, though.. if i remove it, i'm afraid most fighters will pass very quickly near each other and never fight. The maximum speed ensures that dogfights are possible.
Controls or HUD will get improved, especially in the way of customization. But it's unlikely to have very different controls: you'll still find keys for rolling, firing, controling your thrusters.. and the "target velocity" with automatic adjustment ( that you can disable for full control ) will likely stay. Newtonian physics are not going to be changed either, although ships will for sure have different behaviors/parameters.
The future
I might patch a few bugs in the ICP in the coming months, but nothing urgent. I now need a small break from the ICP - i'm leaving in vacation in France next week -, and i will now continue the work and finish the planetary engine, as was initially planed.
The next step is in more or less correct order: cascading shadow maps, ground texturing, vegetation and volumetric clouds.
