The Problem With Porting Games

Testing, testing

With so many possible combinations of hardware, the other major obstacle for multi-platform game developers is testing. Baranec points out that “consoles are tremendously easier to test for than the PC because of the nature of fixed hardware. Most developers and publishers have entirely separate compatibility departments exclusively used for working with all the weird combinations of PC parts”.

According to Bozz, it takes around six engineers a couple of months to test the game on various possible PC configurations, and that's assuming that this is the only work they're doing. Not only that, but the testing has to be done continually throughout the development process. At Visceral, this means testing early on in the cycle when you're trying to gauge the core specs, then again at the Alpha stage and again at the Beta stage, as well as the crucial testing of the final game.

This is part of the reason why PC versions of games often come out a few months after the console versions – although it isn't the only reason. After all, the core game and code is only one part of the equation. You also have to consider the whole user interface and control system, as well as the save game system, and these work very differently on a PC.

Visceral chose a slightly unusual strategy when it came to developing Dead Space for multiple platforms. The guys wanted to release the PC version at the same time as the console versions, which meant that they couldn't just develop the game for one platform and then port the code over, as that would add several months to the PC version's development cycle. Instead, Visceral shared a huge chunk of the game code between the platforms, but distributed the rest of the workload to different teams for each platform. For the PC version, the extra coding was handled by another group in Melbourne, so that all the versions could be coded simultaneously and be released at the same time.

“I get a bit leery when people say that Dead Space for PC was a port,” says Bozz, aware of the negative implications of the word, “because it was co-developed. A lot of the code was co-developed in roughly the same timeframe as the main game, and you can't do that if you're just porting code.” According to Bozz, it took the Melbourne team about ten months to go through the whole process of developing the PC version. “Once the shared core code is setup on the PC,” says Bozz, “you really start chipping away at the various rendering effects and some of the custom code that's written for things such as level-loading.”

Saving and loading

The process of saving and loading content varies between consoles and PCs. PC gamers have become accustomed to being able to save a game anywhere, and they also expect quick level-loading times. On the other hand, many console games only let you save at particular points in the game, and can also stop to load data regularly.

This is particularly true on the Wii, which only has a 64MB GDDR3 memory chip for RAM and 512MB of flash memory for data storage. “The biggest challenge on the Wii for us is that it doesn't have a lot of memory,” says Telltale's Bruner, “and our style of game is challenging in that regard, because we're not level-based; we have everything in a one-off piece of content. This is very different from an action game where you have a shoot animation that's played over and over again from memory, and you can clean stuff up in level loads.”

Bruner says that you only have 40-50MB of working RAM to play with once the Wii is up and running, and this is why you'll see a lot more in the way of loading screens on the Wii version of Strong Bad than you will in the PC version. The amount of memory available isn't the only issue here; the way in which consoles and PCs manage memory is also a crucial factor. “On the 360, you have 512MB of memory arranged in a shared memory architecture,” explains Baranec. “On the PS3, you have 256MB of CPU RAM, 256MB of GPU RAM and 256KB of RAM per SPU. On the PC, you have a basically bottomless pit of CPU memory, and a rather large amount of GPU memory, but the two are tied together in a very inefficient way.”

According to Baranec, the radically different memory systems mean that you have to structure your code differently with each platform. “Let's say you had 100 character skeletons that you wanted to animate for a frame,” says Baranec, “while some of the core math bits remain common – the way you 'splat' the processing of those skeletons across multiple processors is completely different between the PS3 and 360. You're just going to have to buckle down and write it twice.”