You often see that a new game will be released on Xbox 360, PS3 and Windows PC.
How do gaming companies do this? Is it a common source code compiled using different compilers? Are actual different source codes required?
example news article announcing this: http://www.gameranx.com/updates/id/502/article/dungeon-siege-3-announced-to-be-developed-by-obsidian/
Many places will have separate teams responsible for different versions. That is why you always see some small differences. However, if a portable language is chosen, these teams may be able to trade code around.
If the company as produced a game engine, developers can just develop on top of that, leaving the engine to handle the cross platform specifics.
I'm guessing that the art/media department is that same for all platforms.
This is often accomplished with a virtual machine that handles non-time-critical game mechanics and an abstraction layer for time-critical but platform-specific operations.
The particular methods are highly proprietary, secret, and are the among the most valuable assets of the game maker.
This is all a guess because I don't work for a company that makes console games, but speaking from experience as a software developer what I imagine happens a lot of times is that external libraries are used against source code that's written in a common language, such as C++ or something. A lot of the core game code (game loop, physics stuff, etc.) can be used because the syntax is the same with the library across platforms.
However, there is a large degree of code that has to be written (and tested) that is unique to the platform. For example, most (if not ALL) graphics card-related code would have to be different for the Xbox 360 vs the PS3.
This allows for a large degree of portability on core functions and then the UI stuff and graphics-related stuff is platform-specific (not always for the UI).
Also, large game companies have 100s of developers working on a project, so they have a lot more resources than some indie developers might.
It's never perfect though. You always have to port SOME code. Unless you're using Adobe AIR, but your game is for consoles (and who uses Adobe AIR to develop REAL games?)
Actually, there are some frameworks that are meant to be able to run on multiple platforms.
For example:
There are other such frameworks as well.
Also, most of the popular game engines (eg. Unreal, etc) are ported across multiple platforms.
The engine takes care of this by providing a platform independence layer. Things that varies between platforms for instance graphics library. threading, clock and filesystem etc; are implemented for each platform in the game engine.
I can make a call to the engine to render a 3D model consisting of triangles. The engine in turn render this model by calling down into the platform independence layer which uses an implementation for the currently used platform.
There are two ways game companies do this:
1) Writing/using a multiplatform engine 2) Porting a game
A multiplatform engine will feature abstractions for platform-specific actions (making a Windows API call, rendering in DirectX vs OpenGL, etc etc) so that all of the work can be done once, then built for both machines. Usually it's a matter of writing simple wrapper methods for things like Direct3D calls and what not. Most newer game engines are being built from the ground up with multiplatform support. Others are adding multiplatform support.
If a game engine isn't multiplatform, it has to be converted to run on the target platform. This is usually a two-part operation. First, all of the API calls and interfaces with the hardware need to be redone for the target platform. The second part involves debugging and optimizing the game for performance. Typically a direct port will not perform very well, as the code will feature platform specific optimizations that do not apply to the new target platform.
For various reasons, ported games can suffer from performance issues, usually in spite of watered down visuals. Take a look at The Orange Box on PS3 or CoD: Modern Warfare for the Wii to see two examples of ports gone wrong. For the OB, Valve outsourced the task of porting the game(s) to EA. In the second instance, Activision decided that it made more sense to port a game on an engine designed for more powerful hardware over to a weaker platform instead of building the game on top of a new engine designed to get the most out of the Wii.
Game companies use commercial middleware, like RenderWare which do not come cheap. Most game platforms also support a C++ environment for code to get compiled on. Additionaly, most consoles come with a Development version (Playstations do) and there are simulators to test most code on. This middleware is now owned by EA (which is like the giant player on the field). Creating 3D games aren't just framework. Most of the game comes from a design document, which documents the flow of the game and game play. The artwork is done in other software (Maya and Lightwave for example) and the 'models' which are the game characters.
Even though it might look horrific a lot of work, when it comes to coding, it isn't that big of a deal. Writing the core functionality takes a week or eight, the rest is more in design and planning. Just remember that 3D is only 10% of the overall game. These are my two cents as a former game developer.
Generally speaking, the vast majority of multiplatform "triple-A" titles are implemented on top of an engine such as Unreal, Source, or other smaller engines. Each of these engines is custom-implemented and optimized for each platforms and may use a lower-level API such as DirectX/OpenGL which in turn uses the console. Each of these engines also has plug-ins for platform specific stuff (e.g., motion controls) that interact with the official drivers or APIs of the hardware.
Many of these engines support their own scripting languages or hooks for many things, so it is write once.
For example, take a look at the unreal engine: http://www.unrealtechnology.com/technology.php
Most of the biggest engines, like Unreal are so flexible and robust that they allow developers to write all kinds of games. For instance, the Unreal engine was used not only for shooters, but also for shooter-RPGs like Mass Effect.
Remember that most of the manpower in making games is devoted to graphics, set designers, audio design, level design, etc., and there are custom editors for all of that. Many of the set pieces are usually programmed via scripting languages. Only a small portion of folks in gaming companies actually write code in low-level languages like C.
I remember reading an interview (or perhaps it was a .plan file/blog) John Carmack gave a few years ago. He was discussing developing for multiple platforms. (If memory serves this was around the time they were releasing titles for mobile platforms) The advice he gave was to always target the platform with the lowest system specs you plan on supporting first. His reasoning was that it is far easier to scale up than down. If you focus on the latest high end graphics you're likely to wind up depending on features only available on the high end. Making it very difficult to scale back for mainstream and lower end systems. Anyway, I thought it was pretty good advice.
I would say "largely they don't." All the money is in Windows or in consoles and a lot of the consoles want an exclusive license. I have seen a few ports but they're always a separate code base branched from a previous version.
Not necessarily video game related, but the best walk through I've seen for doing multi-platform software was in GOF (http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612). Read the case study on the windowing system.
Very often they use #define (for example in C++ code) so before the compilation for the specified platform the proper code is included or used. In bigger projects sometimes the parts of a game are totally different and written in different IDE's and compiled in different (platform specific) compilers.
Example from my experience: When I was working on a game for Nintendo Wii, we were using Torque game engine. We were programming on PC's and compiling code for PC's. When some functionality was ready we used Metrowerks CodeWarrior (with special set of libraries etc.) to compile it for Nintendo Wii, send it to the devkit and then run from the Nintendo Wii console.