     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
The new generation of consoles have up to 8 times the memory of the previous generation and yet the DVD read speeds have increased by only about 3 times. Even assuming a perfect data read rate it would take about 32 seconds to fill 512Mb of memory. In practise you need to factor in seek times as the game loads different files, and so MotoGP’06 takes about 40 seconds to load a level. And 40 seconds is a long time. There are many different ways of speeding up load time from having fully stream-able worlds to keeping as much as possible data resident in memory. The old MotoGPs employed none of these techniques. They’d never needed to. They could fill the Xbox1’s memory in 12 seconds and better than that they could dump all that data to its internal hard-drive so that next time round it loaded 10x faster. On the 360 we were aware of our shortcomings but the engineering effort required to rectify them was so huge, and the launch window so close, that they never got addressed. On our next game this will be a high priority.
3. The Data Build When we started on MotoGP’06 we wrote the exporters alongside the renderer. As features were added to the game so the exporter was extended to support those features. Crucially, the exporter never went through a consolidation phase and as is all too often the case it became a second-class citizen to the game. Its code became entangled and its performance was seldom monitored. Our build machine, which was a fast piece of kit, ran the exporters. By Beta it was building 39 tracks and 40 bikes. This process took 17 hours. After the build machine finished we needed to copy the files elsewhere and delete some unused archives and manually go through the process of creating a DVD ready version and a magazine cover version. The process simply wasn’t as automated as it should have been. As we went through Beta and on towards Submission we were submitting builds more and more regularly eventually reaching 3 times a week. Soon, we knew, we would have to submit builds on a daily basis and with a 17-hour build time we were heading toward meltdown. It became clear we hadn’t fully thought through the consequences of the huge data sizes that were needed on these new consoles. A development build was 10Gb in size and our creaking 10Mbit network simply couldn’t handle it. At this juncture we accepted the help of Shep, Climax’s resident build guru. A gigabit network was hastily installed and, in double quick time, he wrote us a distributed build system that built the data on two machines and collated it on a third, file server machine, ready to be pushed out to all the development kits. It also built a DVD ready version and the magazine demo. It did all this in 9 hours which meant we could kick it off before we left in the evening and everything was ready for us when we arrived in the morning (even in crunch the team was sensible with its working hours and we seldom had staff in the office between 10pm and 7am the next day). (Page 6/7)
|
|||||||||||||||
Features
Previous
|
|
|