How do game developers target multiple platforms (Xbox 360, PS3, PC and Linux)?

Question

How do game developers target multiple platforms at once? For example, Xbox 360, PS3, PC and Linux. For 2D games, is it possible to also target the iPhone? I'm be interested in engines used (2D/3D, etc), how the build pipeline is setup and generally how much of the "core code" can be centralized without having to write platform specific code branches.

Or, if completely separate code trunks are usually maintained for each platform, how are libraries / code reused (in terms of linking and modularization)?

Answer 1

For commercial console game development, setting up a build system to target 360, PC, and PS3 simultaneously is irritating but is not particularly difficult. The 360 dev kit is simply a new a new target for Visual Studio + some tools and uses a very similar compiler to the standard windows MSVC++ compiler. The PS3 uses a GCC compiler back end but plugs easily in to the visual studio front end. For gameplay and general utility code, it should generally be possible to have code that is 99% the same between the 3 platforms. There ARE some incompatibilities between GCC and MSVC++, but luckily if you work those out linux (assuming you use a gcc version close to the PS3 one) will not be too much more trouble on top of that. The last 1% of code that differs you can normally fix with kludgy #defines. You can actually have the same visual studio solution build PS3, 360, and windows builds, so you can have them entirely integrated at that level if you wish.

Past the basic build steps, the big hurdle is going to be the graphics systems as well as any high performance elements of your game. For these elements you're realistically going to end up writing platform custom code, or using an existing engine. Memory will be a huge issue but that's for another question. A commercial project I worked on was able to get console versions of an originally PC source base up fairly easily, but making them actually perform well was a completely different problem.

If you wish to integrate iPhone as well you may want to go with some sort of existing engine/middleware solution. The iPhone setup of openGL + objective C doesn't really fit very well with any other platform. That's very much a choice on Apple's part, as they are heavily discouraging the use of interpreted middleware in any iPhone applications.

Answer 2

For most platforms, you can write subsystems which abstract away from the specific APIs used to call out and get information back from the platform you're running on. IO APIs are usually the easiest to abstract - all file systems work on some pretty basic assumptions about opening, closing and reading from files, even when you factor in asynchronous calling. Then you have your core systems like reading controller input, querying the time, accessing memory and thread primitives, most of which work the same way.

Even graphics can be abstracted to a large extent, and indeed in most good engines they are. But you have to package up the 'renderable' things into black boxes where you aren't allowed to know what's going on inside them. You know that you have a 'thing' which you render in a particular position in the world. You don't know how it's rendered, just that it is. And the graphics abstraction layer takes care of all of the details of getting it on-screen. The platform specific build pipelines package up the graphical data in such a way that it can be referenced from the engine without really knowing how it's represented internally.

All that said though, when it comes down to actually shipping a game, there are certain parts that you just can't abstract away. It would be ridiculous to think you could ship the same code on iPhone as you would on 360 or PS3, as the input mechanisms, fundamental way of operating, and platform capabilities are just too different. You could make an iPhone sized title on 360, but it would have to limit its input mechanisms to only those that the 360 can support. So, a virtual cursor on screen simulating a finger, and possibly using the joystick where the 3D accelerometer input is used.

More sensibly, parts of the game can be written in a re-usable way, and individual code modules can be ported between platforms, even though the majority of the title is different. For example if you have an AI state machine, that doesn't really care whether it's running on 360, PC, or iPhone. Your game will use many such components, and as long as they've been designed well so that they take well defined inputs and outputs, then the rest of a game can be wrapped around them, regardless of platform, and avoid having to rewrite those components.

That re-usability is the key to a cross platform development, not looking for a one-size-fits-all engine which works on all platforms. Even if such a thing did exist, it would be so crippled by having to work on the lowest common denominator, it wouldn't be of much use to make games with.

Answer 3

A way is using a multiplatafom engine such as Torque or Unity3D. But I don't think they work on all those plataforms. There's also another way: developing one engine...