Optimization - One of the things that MotoGP'06 was criticized for was the screen tearing. This occurred when the game wasn't able to render the scene in one 60^th of a second. At this point there are two options. Firstly, the game can display the scene as soon as the rendering is finished, or secondly it can wait until the next video refresh.

The problem with the first solution is that the TV may be halfway through showing the previous scene and so you get an image that is half old and half new -- hence there is a tear at the boundary between the two. The problem with the second solution is that you've just halved your framerate, which can be crucially off-putting to the player, especially if they are navigating a tricky corner.

We opted for the first route judging that it was more important to the player to keep the gameplay intact than have some screen tearing. Unfortunately the paying public weren't happy that their brand new LCD HD displaying what appeared to be graphical corruption.

Maintaining 60 FPS on a near-launch title is hard because we only have final hardware for a very short amount of time before the game's release. As developers, we were pretty happy with maintaining 60fps for 80 or 90% of the time.

However, the public, quite rightly, when they are paying £50 or $60 for a game, don't want the developer to be "pretty happy" with their effort. They expect them to get it right.

Optimization is always a big deal to us but this time we also had a point to prove.

In order for the artists to improve the look of the tracks, we had upped their polygon budget from 500,000 per track to 750,000 per track and this -- combined with the additional spectacle requirements -- meant we were drawing twice as much geometry... and we needed to draw it faster than MotoGP'06!

This time round there was no silver bullet, because our engine had already been through four months of optimisation on MotoGP'06. We had to go through every bit of CPU code, reducing complexity and increasing cache coherency, and put a huge amount of effort into our asset exporters so that by the time the geometry reached the game engine it had good LODs and used the minimum number of shaders.

Our tracks are modeled using higher-order surfaces, which means we can build flexibility into our exporter and tessellate them down to a pre-determined number of polygons. By the time the tracks reach the game they consist of a total of about 30 million polygons, which would be far too many for the artists to optimise by hand.