Where does programming for consoles take place?

[PrayForDeath]

I've been thinking about porting games between consoles, cross-platform compatibility, etc. People often say that PS3 games would require a significant effort to get ported into PC or Xbox 360. Same applies for Xbox 360. And the reason behind that is the vastly different hardware architecture behind each platform.

There are simulators that do the job for older consoles (including PS2 and Wii), but they are extremely inefficient, and not feasible for the PS3 or the 360.

My question is, aren't the games for these platforms developed on PCs? If so, how do the developers test these games during development? Do they run each build on a special console designed for testing? Do they run the code on PC? At what point does the code stop working on PCs and run exclusively on the intended console?

 

[Modelworks]

I think there are a lot of misconceptions about developing for other platforms on the pc. The code for other platforms is never run on the pc or its processor. The pc acts as a way to input code into a development software , then using a special version of the platform hardware is transferred to either a hard drive or ram on the target platform and then run on the target cpu.

The target platform and the pc are usually connected via a hardware link so that the programmer can set up breakpoints in the code and can see the code running on the target platform for the pc. Really the pc acts more as a terminal showing results and working as a hardware interface for things like keyboards, mouse, etc to make the handling of the hardware target easier.

 

[swanysto]

I think there are a lot of misconceptions about developing for other platforms on the pc. The code for other platforms is never run on the pc or its processor. The pc acts as a way to input code into a development software , then using a special version of the platform hardware is transferred to either a hard drive or ram on the target platform and then run on the target cpu.

The target platform and the pc are usually connected via a hardware link so that the programmer can set up breakpoints in the code and can see the code running on the target platform for the pc. Really the pc acts more as a terminal showing results and working as a hardware interface for things like keyboards, mouse, etc to make the handling of the hardware target easier.

Yeah, that was my understanding. It is kinda like when we had to program java games for phones before they came out with the simulator. We had to write the code and compile it on the computer, send it to the phone, and then run it from there. Obviously that was on a much smaller scale of hardware and coding development, but same idea.

 

[SonicIce]

What Modelworks said. Also, sometimes development for consoles is done on workstations that have add-on boards that contain actual console hardware, complete with video outputs and controller ports. That way they can test the game without having to transfer it to a stand-alone system. Same goes for arcade games, handhelds, what have you.

 

[dwell]

I am doing Xbox development now. You develop on the PC and push to an Xbox with a special extension called a sidecar when can run unsigned code.

 

[Pia]

It's normal to isolate the platform (console) specific code whenever feasible, so that the rest of the codebase never stops running on PCs and consequently can be developed, tested and debugged without the console devkit. All of that is easier when it can be done locally on the PC. Doing this stuff is more important the harder that particular console's devkit is to use. If the devs want to have the whole game running, instead of just testing individual bits and pieces, they have to code PC-specific replacements for all console-specific stuff. These can of course be of lower quality; for instance, they could do stick-figure graphics on the PC to see the game logic play out in 3D but avoid wasting time on a renderer they aren't going to release anyway.

 

[RampantAndroid]

I think there are a lot of misconceptions about developing for other platforms on the pc. The code for other platforms is never run on the pc or its processor. The pc acts as a way to input code into a development software , then using a special version of the platform hardware is transferred to either a hard drive or ram on the target platform and then run on the target cpu.

The target platform and the pc are usually connected via a hardware link so that the programmer can set up breakpoints in the code and can see the code running on the target platform for the pc. Really the pc acts more as a terminal showing results and working as a hardware interface for things like keyboards, mouse, etc to make the handling of the hardware target easier.

Don't forget that emulators exist. They don't perform well, but they can work. Look up things like Platform Builder (WinCE) and Sidecar (XBox) for some idea on how they transfer bits compiled on a workstation to the device.

But for the XBox, you need a developer device (meaning it has special signing stuff set up. A developer signed game will not run on a retail xbox - this is why piracy on games is limited to copying the game disc, and leaked copies of the game generally are un-useable by retail consoles - for example when GOW3 leaked.)

 

[Modelworks]

Don't forget that emulators exist. They don't perform well, but they can work.

Emulators are rarely used for anything but slower processors. The reason is they often have bugs or don't emulate the code properly. What works on an emulator may not work on a target cpu or the reverse. They are also extremely slow compared to the target cpu. I can't even emulate a 400mhz mips core on a quad core 3ghz at real time speed.

 

[RampantAndroid]

Emulators are rarely used for anything but slower processors. The reason is they often have bugs or don't emulate the code properly. What works on an emulator may not work on a target cpu or the reverse. They are also extremely slow compared to the target cpu. I can't even emulate a 400mhz mips core on a quad core 3ghz at real time speed.

I've worked on emulators before. They are an amazing thing that allows you to develop in lieu of hardware. I used an emulator for months. Slow? A little...but that was for lack of GPU support. And how do you think the 360 (PowerPC) runs XBox 1 games (x86)?

 

[Modelworks]

I've worked on emulators before. They are an amazing thing that allows you to develop in lieu of hardware. I used an emulator for months. Slow? A little...but that was for lack of GPU support. And how do you think the 360 (PowerPC) runs XBox 1 games (x86)?

They are okay to play with but when designing something they can cause problems . Is the error a problem in the emulator or with the code ? Is the slow down a code issue or hardware issue or is it in the emulator ?

 

[RampantAndroid]

They are okay to play with but when designing something they can cause problems . Is the error a problem in the emulator or with the code ? Is the slow down a code issue or hardware issue or is it in the emulator ?

I didn't work on OS layer stuff, but was able to assume that my code functioned properly on the emulator. And we obviously only did profiling of the code once hardware was in hand. But again, feature work was in fact doable on an emulator. When using a VS emulator for something like ARM, you can assume that things above the BSP are generally OK.

 

[alent1234]

all the consoles work on C++. most of the game is art, music and animation which is console agnostic. you just have to dumb the detail level depending on the target console.

there are dev tools out there to port the rest of the code to each console. kind of like UNITY for mobile development. a huge number of games also license the Unreal engine and its console independent as well