Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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)?

share|improve this question
add comment

3 Answers 3

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.

share|improve this answer
    
The biggest problems (beyond general performance) will probably always be with things that touch the filesystem. Between PC, 360, and PS3 you have 3 nearly mutually exclusive file system APIs >_< –  coderanger Jul 26 '10 at 4:37
    
Yeah, graphics, performance, and any other system-specific APIs like filesystem or things like achievements and networking stuff. –  Ben Zeigler Jul 26 '10 at 7:08
    
I know this is an old question, but what about boost::filesystem for the filesystem API ? –  rwols Jul 21 '13 at 14:42
add comment

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.

share|improve this answer
add comment

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...

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.