Game platform codebase differences?

August 28, 2007 8:29 AM

Hey video game developers: how different is the code base for one game across different platforms?

I am curious about how much effort is involved with porting something from the PS3 to the XBOX 360, or vice versa, or the PC. Are the versions 100% different? 50%? Is it getting easier than it was? Very curious.

posted by xmutex to technology (12 comments total)

The typical thing is that there's a library that abstracts away the details of each platform and the game itself is built on the library (aka "the engine"). OpenGL is a basic example of this kind of library, something like the Unreal Engine is a more modern example.

Depending on the sophistication of the library, this results in games that take alowest-common-denominator approach to features, or game code that only applies some of the time (e.g. fancy shading).

Then comes a bajillion hours of testing.
posted by GuyZero at 8:39 AM on August 28, 2007

A bunch of the differences are abstracted away in the core engine of the game. Often that engine is licensed; think Unreal, or Source, etc. One of the big values of a licensed engine is that abstraction.

But a lot of game programming is optimization and getting the last bit of juice out of a platform. And there, every platform is different. Xbox 360 and PC are very similar, but the 360 has a bunch of funky CPU multithreading that you can't count on in a PC. The PS3's Cell processor is totally different and relatively novel for game hardware, so requires very different optimization technique.

I'm not a game programmer, but I am a programmer and follow the game industry a lot.
posted by Nelson at 9:00 AM on August 28, 2007

Depends.

PC games are usually written with microsoft DirectX libraries. So porting this over to the xbox isnt very costly. The xbox can be seen as a specialized PC running DirectX.

The open format competitor is OpenGL. Games written for OpenGL can be moved from PC to Mac to whatever is running OpenGL with ease.

Games written for DirectX are costly to move to machines that dont run DirectX, like a macintosh or a ps2.

Games, as all modern software, are coded in languages that are mostly portable. So a C++ app (like the game engine itself) in windows can be ported to OS X or whatever without too much difficulty. The other parts of the game may not be so portable (like being connected to directx or opengl).

Its generally more complex than what I'm describing. Companies that plan to make cross-platform games just use OpenGL to minimize the cost of porting them over. Doom/Quake /Warcraft are an example of this. Currently, companies who develop on the PC favor Microsoft's DirectX because its easy to develop for and dont care about cross-platform stuff.
posted by damn dirty ape at 9:10 AM on August 28, 2007

Note that a number of engines, like Unreal Tournament's, can either use OpenGL or DirectX. There's a certain amount of optimization that goes into each pipeline, so most focus on DirectX since it has the largest payoff, but adding opengl support to a functional level is not that difficult for many engines.

Porting to consoles is an entirely different ballgame. It used to be that consoles didn't support opengl OR directx, they had their own, specific APIs. Xbox 360 supports XNA now, which lets games run on both Windows & 360, though I imagine a lot of games still use whatever the raw API is. The other issue is that console games are tuned very, very closely to the hardware of the console, since its a standard base. That means that while it is sometimes possible to port from PC to console without too much trouble, the reverse port can be a pain in the ass, because console games aren't typically written with portability in mind. Again, this is changing with new titles being released on multiple consoles /and/ PC.
posted by devilsbrigade at 10:59 AM on August 28, 2007

It depends on what you intend to do from the start. All the major platforms have pretty big differences in terms of processor architecture, available memory, and other hardware in general. If you planned on it from the start you make the decisions that need to be made to get the game running on every platform. But if you decide to port after the game has been completed it can be a huge undertaking trying to adapt 1-2 years of code and art decisions on one platform to work on another.

There are several reasons you're seeing many more cross platform games these days:

1. Games are written in higher level languages (C++ mostly, some C still) that abstract away from the hardware somewhat. It's still a good amount of work porting from system to another, but it's not as much as porting a program written in 100% assembly.

2. Developers have "figured out" how to do multiplatform games. Most of the problems have been solved many times and written about in industry literature. So everyone pretty much knows how to do it, even if they've never done it before.

3. Developers/Publishers are no longer bound by draconian licensing terms. Nintendo used to have insane limitations on porting your game to other systems(or getting on the NES in general). Nowadays it's prety much assumed that a game will be cross-platform unless Sony/Microsoft/Nintendo own the studio, or pay the studio for an exculusive.

4. Since hardware costs for development and testing hardware can be very high (or in the case of launch titles the hardware can be non-existant), it's not uncommon for a PC version of the game to be maintained (I worked on PSP and PS3 launch titles that had these, and the code tends to get reused so the PC ports stick around after launch). This means that the architechture to be multiplatform is usually in place, making ports after the fact easier than they used to be.
posted by hamhed at 11:07 AM on August 28, 2007

Getting it to run at all on all three platforms is reasonably straightforward-- they all have C compilers, they all have similar graphics APIs, etc. Nowadays, they all even run the same instruction set (PowerPC.)

The part which seems to take the most time from what I've seen is the optimization 'shell game'; finding the bottlenecks on a given platform, then moving things around to dissolve them. For example, moving tasks to other cores on a 360, or onto SPUs on a PS3. SPUs are interesting, because they are fastest when you can package your data up in a chunk to send to them. So, for PS3, you'll spend some time structuring stuff to be able to send it along to SPUs. Fortunately, most of these changes are actually good for all platforms-- for example, if you put your data together so SPUs can operate on it more efficiently, you'll also get better cache coherency on non-PS3 platforms. And, of course, multi-core is becoming a good thing on the PC.

As far as the video cards go; yeah, they all have idiosyncracies, but the differences between, say, a Xbox 360 and a PS3's video hardware are a lot less significant than those between an Xbox 1 and a PS2.
posted by blenderfish at 11:46 AM on August 28, 2007

Err.. Intel PC isn't powerpc, obviously.
posted by blenderfish at 11:51 AM on August 28, 2007

Your question seems to be about code, but for the record, the art assets are often required to be considerably different, especially in terms of RAM budget. As with code, this is fairly straightforward if planned in advance, but can involve a vast amount of reworking if the decision to port occurs after (or part way through) the production.
posted by -harlequin- at 1:14 PM on August 28, 2007

Hey -harlequin-, for my own interest: can the art assets be transformed mechanically? What would you have to do to textures or sprites (or whatever you call them these days) that can't be done though generic image resizing tools?
posted by GuyZero at 2:15 PM on August 28, 2007

This is off the top of my head, so I may be missing some important details, but here goes. The issues, in order of increasing difficulty (in my personal opinion):

1. Audio. They all handle playing audio differently, but since they're pretty similar in concept (load sound, play sound, stop sound), it's easy to abstract this out.

2. Standards. Things like memory card usage, save files, and terminology (one may require "Controller" to be capitalized while the other requires it to be "controller") are different. This is also fairly easy to abstract out, but there are so many tiny differences that it can become very tedious.

3. Art assets. Data files often have to be in very specific formats. Most of this can be done in a pre-processing step (so it doesn't have to be done at runtime), but you still have to make the tool (these are often proprietary formats, not just bitmap vs jpeg), and you have to worry about things like different memory limits on each platform. As in, whoops, all our textures fit into memory on platform A, but not platform B.

4. Graphics. This is the big one. The different consoles often have very, very different APIs for drawing to the screen, and an effect that's easy on one console may be downright impossible on another. They are getting closer, though - it's much easier now than it used to be.

5. Undocumented platform differences. Things that "just work" on one platform (like, say, multithreading), can break on another because the timing is slightly different. These kinds of bugs take forever to track down.

6. Creating for one platform *then* porting, instead of creating for two platforms simultaneously. Games are always under-scheduled, and there are bound to be last-minute hacks to fix last-minute bugs. Those absolutely kill you when you then try to port the game to another platform. For example, "Why the *(%! is there a rendering call in the AI code?!"

As a totally ballpark estimate, I'd say something like 30% of the code is different per platform.

It's getting easier, because the platforms are becoming more similar, and because they're faster - you don't need to write everything in assembly, so you can reuse more code. Also, once you have an engine that works across all platforms, it becomes significantly easier to make new games after that.
posted by Sibrax at 2:50 PM on August 28, 2007

Sibrax: Games are always under-scheduled
Unless they aren't. :) But poor management is unfortunately all too common in games.

The different consoles often have very, very different APIs for drawing to the screen and an effect that's easy on one console may be downright impossible on another.

There are superficial differences, but really the underlying hardware is pretty similar (since it was all designed to DX9/10/9.5 specifications.) I really have a hard time thinking of an effect which can be done on one of PC/PS3/360 GPU and not the others. If you can think of one, I'd be interested to hear about it.

Agree with most of your points, though.

Trying to boil it down to a single percentage is pretty misleading-- as you said, things like controller code, loading, saving, whatever are WAY different on the different platforms, but stuff like game logic is very similar. I'd say 30% different is a reasonable ballpark for the renderer.
posted by blenderfish at 3:21 PM on August 28, 2007

GuyZero:
Yup, that's the bit about it being fairly straightforward if known in advance - everything will be done so it can be mechanically converted. OTOH, if it wasn't known in advance, and you were saym porting a console game to the PC and for example need to the textures at a higher resolution, they might need to be partly (or even fully) created again, depending on how they were originally made.
Textures are straightforward, it could get more complicated with things like character skeletons and their animation keyframes, but I don't know much about that side of things.
posted by -harlequin- at 3:37 PM on August 29, 2007