Tech Interview: Trials HD

All our materials have per-pixel control for base colour, diffuse lighting, specularity, glossiness, ambient lighting (ambient occlusion), normal (compressed two-channel normal), height (for parallax mapping), opacity and emissive components (for self-illuminating surfaces).

We have compressed all this info into two or three DXT5 textures in a way that causes the least compression artifacts. The DXT5 format alpha channel is much higher quality compared to the other three channels (RGB). And the RGB channels are also tied together (same end values and interpolator). The green channel also offers slightly increased bit depth compared to the red and blue channels.

It took me a lot of time, experimentation and testing to calculate the best way to pack all the required material info into the multiple DXT5 textures. But the end result is really good. Our texture memory and bandwidth usage is really low and we still have pixel-perfect control over the surface details. We created a texture converter tool to do all the messy work behind the scenes and it has been integrated into our content pipeline for easy artist access.

We use the Bullet Physics library for our physics simulation. We have ported and optimised it in-house to the Xbox 360 CPU and its vector units and integrated it to our game engine. We have split our workload to all the six of the Xbox 360's hardware threads. We simultaneously process physics in one thread and graphics setup, graphics rendering, game logic, sounds, networking and particles in the others. One of our threads takes care of the timing, scheduling and data synchronisation between the other threads. It's a brand new fully multi-threaded game engine, built especially for Xbox 360 and the newest multi-core PC hardware configurations in mind.

One of the three CPU cores is completely reserved for the physics engine. In the most physics-heavy levels the physics engine utilises the majority of its CPU core processing time. In the final content optimisation we were most often bottlenecked by our graphics setup thread (it does viewport culling, shadow map culling and scene setup), but in some really physics-heavy levels our physics thread was exceeding 100 per cent usage as well. In the final levels we have achieved a really well-balanced workload without any bottlenecks. Most of our threads are constantly working on, or near 100 per cent workload, but never exceeding the limit.

With further optimisation it's possible to get even more performance out of the hardware. Trials HD was our first Xbox 360 title and we were really happy how much we managed to get out of the platform on our first try.

GPU-accelerated physics is definitely possible on gaming consoles as well. But porting an existing high-end 3D physics engine designed for multi-core PC hardware to a console GPU is a huge task for a small team like us.

Whoever creates good tracks must also be a good rider. The tracks in the game are created in a way so that they feel right for the bike. The jumps are measured so that they fit the selected bike features, so we don't just create the tracks in a way where we just put objects in the world and test if it's fun to ride. We measure the jumps and when we know where the bike lands with certain speed or by using a certain trick, we tune the objects to that position. Also the positioning of checkpoints is really important. The more the better. We set up one obstacle, and after that comes the checkpoint. On some of the extremely hard tracks, people will try them 200 times because they see the next checkpoint... if they just pass this one obstacle. That's a really important thing. Balancing comes when you play the tracks with multiple players in-house and check how they pass and ride the tracks.

It's exactly the same editor. We created all our levels in-house by using the same editor on Xbox 360. This means that the players can use all the same features (glue, various physics joints, forces, explosives, triggers, etc.) used in the original game levels. If the player has enough time on his hands, he can use the editor to create complex physics vehicles, suspension bridges, catapults, robots and all kinds of deadly machines.

Now, three weeks after the game's release, we already see that the players are starting to make amazing and even more complex physics creations than we have in our built-in tracks. We are really surprised about the quality of the user-created content quality that has been made in such a short time. The game will surely have a really long lifespan.

Arcade developers have exactly the same platform tools, development kits and technical limitations compared to AAA retail game developers. It's just a matter of how much workforce can a small game development company allocate to technology development and optimisation, and how much they can invest to license AAA-grade commercial tools and technology. Many small developers don't have the required expertise to build their own technology from scratch like we have done, gradually during the past years. Nor that it's even the right path for many companies to aim at.

In the future we will likely see more CPU cores and more GPU cores both on PC and on consoles. Basically we are now going wider and wider instead of faster and faster like we used to be in the past. Having to process more and more things in parallel makes development slightly harder, but the majority of professional game developers have already adjusted to this style of programming now. Transferring vector floating-point intensive algorithms to the GPU is the next step. The GPU is a harder thing to use properly compared to multi-core CPUs, as the latency to get the results back from it is much higher, and you need to process considerably larger data-sets at once to get best performance out of it. GPUs also historically have really bad random branching performance compared to CPUs. It's really important to design the algorithms properly for the GPU in mind. Sadly this often means large structural changes to the game program, as GPU latencies can be more than a frame long. Multi-threaded game programming has already increased the input lag a bit (often by a frame at least). This is one of the main reasons why many recent games suffer from noticeable input lag.