How do companies port games?

[Tylerdurdened]

I always read about how companies port 360 games to PC and 360 to PS3, and vise versa.

How is this possible?? Doesn't each have a totally different coding system? I don't know anything about coding, but I'd imagine it's sort of like speaking two different languages.

So do they just copy paste, say the 360 code into a PC, and add AllowPCFunctionality=1?

I just don't understand it.

And yes, I know that 360 and PC are similar, don't mention it. If you can't answer the question that way, then think it in terms of 360 to PS3 port.

My only guess is that the codes are somewhat similar and you just have to change a few parameters here and there for it to be compatible.

[kju1]

Well it really depends on the port and how the game was written. Ive not done any console dev but I have ported systems from one OS to the other.

Sometimes it does require a complete rewrite (for example if it was written in a language that cant be compiled on the new system). But more often its about changing the specific areas of the code that dealt with that platform.

It also involves reusing as much of the art/vid etc assets as possible. Sometimes consoles have special formats for video playback (from what Ive read) so sometimes those assests have to be redone.

Basically think of it this way: they go through and find the parts that are specific to that platform and replace them with parts that are specific to the new platform.

The cost/difficulty in doing this varies greatly by platform and will be heavily influenced by how well written the software being ported was.

EDIT: Of course this also means recompiling the code in case you didnt know.

[Ender1183]

Poorly, the only games that seem to do ok are pc to console. Unless console player are more likely to bend over and take it.

[Tylerdurdened]

Poorly, the only games that seem to do ok are pc to console. Unless console player are more likely to bend over and take it.

Thanks for the reply and for reading my post. Have a great day.

[Frostex]

The 360 is more or less a PC, it has GPU based on PC technoloy and runs the directx API based around the PC architecture, as well as other PC based technology.

Engines like the Unreal2.x and 3.0 engines, are designed to run natively on both, so its less ported and more cross developed.

[noobman]

So do they just copy paste, say the 360 code into a PC, and add AllowPCFunctionality=1?


I wish!


I don't know the whole story, but here's my understanding:

Game engines and game content are both coded in C++, so the code handling game mechanics usually doesn't need to be changed. C++ code is C++ code to the developer regardless. The difference is that each platform needs its own compiler to "build" the game (convert the C++ code) into something that the hardware understands. Using a different compiler bring up different issues, as each compiler may handle your code a little differently. Some code that works fantastically on one system may work horribly on the other.

Also keep in mind that each platform uses a different graphics API. The PS3 uses a subset of OpenGL, the 360 uses an implementation of DirectX 9.0c, and the PC can go either way (though DX9c/DX10 are the most popular). An API is a library of pre-existing code that the system can use. If you're moving from the 360 to the PS3, for example, a lot of your DirectX API-specific calls need to be removed and replaced with OpenGL API call. There are some more fundamental differences between DirectX and OpenGL (assumptions on hardware management for example) that make this process FAR more difficult than just repacing DirectX API calls with OGL API calls Since I'm on the topic... OGL is more for professional graphics these days than gaming, though the Wii, PS3, and iD's PC games all use OGL. You're also looking at OGL when you watch a Pixar or Dreamworks film.

The lower level hardware issues include the CPUs features (caching, number of cores, in order vs out of order processor), available system/video memory (PC has much more available than console counterparts), GPU features/limitations (pipelines, bandwidth, efficiency, etc etc). It's possible that an essential piece of code that needs to be executed will fit into one processor's cache, but not another... causing a significant slowdown in the game. Textures may need to be compressed tighter or have their resolutions reduced in order to fit in memory. In the case of the Xbox360, caching gamedata to the harddrive may not be an option.

It's really hard to explain without being too specific. I don't know how much of a techie you are or how much you know about programming, but this is the best I could do to give insight without being terribly technical.

For an example of a bad port, look no further than GTAIV. The game was apparently poorly coded to begin with, and instead of going through the process of fixing fundamental efficiency issues w/ the code, Rockstar just decided to demand PC users to brute-force the game w/ powerful Quad-Core CPUs.

Feel free to call me a n00b and correct me on any errors if you know better than I do on the topic =)

[Tylerdurdened]

I wish!


I don't know the whole story, but here's my understanding:

Game engines and game content are both coded in C++, so the code handling game mechanics usually doesn't need to be changed. C++ code is C++ code to the developer regardless. The difference is that each platform needs its own compiler to "build" the game (convert the C++ code) into something that the hardware understands. Using a different compiler bring up different issues, as each compiler may handle your code a little differently. Some code that works fantastically on one system may work horribly on the other.

Also keep in mind that each platform uses a different graphics API. The PS3 uses a subset of OpenGL, the 360 uses an implementation of DirectX 9.0c, and the PC can go either way (though DX9c/DX10 are the most popular). An API is a library of pre-existing code that the system can use. If you're moving from the 360 to the PS3, for example, a lot of your DirectX API-specific calls need to be removed and replaced with OpenGL API call. There are some more fundamental differences between DirectX and OpenGL (assumptions on hardware management for example) that make this process FAR more difficult than just repacing DirectX API calls with OGL API calls Since I'm on the topic... OGL is more for professional graphics these days than gaming, though the Wii, PS3, and iD's PC games all use OGL. You're also looking at OGL when you watch a Pixar or Dreamworks film.

The lower level hardware issues include the CPUs features (caching, number of cores, in order vs out of order processor), available system/video memory (PC has much more available than console counterparts), GPU features/limitations (pipelines, bandwidth, efficiency, etc etc). It's possible that an essential piece of code that needs to be executed will fit into one processor's cache, but not another... causing a significant slowdown in the game. Textures may need to be compressed tighter or have their resolutions reduced in order to fit in memory. In the case of the Xbox360, caching gamedata to the harddrive may not be an option.

It's really hard to explain without being too specific. I don't know how much of a techie you are or how much you know about programming, but this is the best I could do to give insight without being terribly technical.

For an example of a bad port, look no further than GTAIV. The game was apparently poorly coded to begin with, and instead of going through the process of fixing fundamental efficiency issues w/ the code, Rockstar just decided to demand PC users to brute-force the game w/ powerful Quad-Core CPUs.

Feel free to call me a n00b and correct me on any errors if you know better than I do on the topic =)
Ah, very interesting.

I really don't know anything aside from common programming terms (I know what a compiler and programming languages are, as well as OGL and DX, but not much more than that), you did an excellent job explaining it in a very basic way.

I wish I could understand more of the exact technical issues that are encountered when converting from one system to another, but I guess it's not possible if I don't know much of anything about programming :(

So it's more or less like this: 360 speaks Spanish, PS3 speaks English. To port 360 to PS3 you need a translator. Some translator do a poor job and the system doesn't exactly understand what it wants to do, so it runs poorly, controls don't work, etc. To fix said bugs you would need to manually edit the code and correct the mistakes so that it's fluent. But developers are too lazy (or it will cost too much money to be worth it) to translate the code themselves, or only translate parts of it, leaving much of the game not working well. Is that about right?

Also, this may be another topic, but while we're on it, how come OGL is more for professional work? From my understanding it's better at rendering large amounts of pixels faster/more efficiently, but DirectX is more feature-rich/easier to develop?

[noobman]

Ah, very interesting.

I really don't know anything aside from common programming terms (I know what a compiler and programming languages are, as well as OGL and DX, but not much more than that), you did an excellent job explaining it in a very basic way.

I wish I could understand more of the exact technical issues that are encountered when converting from one system to another, but I guess it's not possible if I don't know much of anything about programming :(

So it's more or less like this: 360 speaks Spanish, PS3 speaks English. To port 360 to PS3 you need a translator. Some translator do a poor job and the system doesn't exactly understand what it wants to do, so it runs poorly, controls don't work, etc. To fix said bugs you would need to manually edit the code and correct the mistakes so that it's fluent. But developers are too lazy (or it will cost too much money to be worth it) to translate the code themselves, or only translate parts of it, leaving much of the game not working well. Is that about right?
That's a pretty good way of looking at it, as long as you remember that some languages share words, some languages don't have words for certain things, and some languages say things differently (IE to say "I am hungry" in French you need to say "I have hunger"... J'ai faim). This isn't linguistics class though :)

The biggest barrier is optimizing the code for different processors. I figure that about 1/4 of your code needs modification to be ported between platforms. With GTAIV, I can't help but shake the feeling that the devs spent too much time working on the video editor and not enough time optimizing code. Optimizing code is very painful =\

The top game engines are designed to be cross-platform engines. The Unreal 3 engine has everything you need to run your game on the PS3, the PC, and the Xbox360 built into it, which makes moving the game across platforms a little bit easier. The latest updates to the source engine include some Xbox360 specific code, indicating that it's grown to become a PC/360 cross-platform engine.



Also, this may be another topic, but while we're on it, how come OGL is more for professional work? From my understanding it's better at rendering large amounts of pixels faster/more efficiently, but DirectX is more feature-rich/easier to develop?

I guess it's a historical thing. 3D rendering and modelling was prominent in movies long before 3D games existed. My guess is that the software they used to create computer effects in movies (Terminator 2, Toy Story) always used to use OpenGL. OGL was designed w/ professional graphics in mind (created by SGI in 1992) It was extensions and upgrades that made OGL a "gaming" API.

DirectX, on the other hand, was designed as a platform to give developers access to hardware that Windows 95 inherintly blocked (DOS, on the other hand, allowed direct access to the hardware). Gaming was the main focus when they made DirectX, which came out with windows 95.

OpenGL is, as you could have guessed, an open standard. You can access a ton of custom libraries with OpenGL extensions. OpenGL probably has more "professional" features and tools.

[bigdogchris]

The team that is making Ghostbusters The VIdeogame, said it's easier to code a game for the PS3 from scratch, then port that code to 360/Windows, than from PC/360 to PS3. I wish more companies did that so that all 3 received equal quality, where not, mostly 360/PC get the most quality and polish, usually.

[noobman]

The team that is making Ghostbusters The VIdeogame, said it's easier to code a game for the PS3 from scratch, then port that code to 360/Windows, than from PC/360 to PS3. I wish more companies did that so that all 3 received equal quality, where not, mostly 360/PC get the most quality and polish, usually.
That's probably true, given that devs seem to always say that it's slightly easier to go from OGL to D3D than to go from D3D to OGL (I wish I knew why) and that the PS3's cell processor is so unique.

That being said, the initial development of the game is probably easier to do for the Xbox360 or the PC based on said reasons.

[riot8ap]

just goto cmd.exe and type:

convert ps3 > x86 ++crap

Not so hard huh?

edit: just so I'm not trolling, a friggin awesome way to handle ports would be for sony and microsoft to put out emulators of their systems for PC. it'll never happen though.

[Tylerdurdened]

just goto cmd.exe and type:

convert ps3 > x86 ++crap

Not so hard huh?

edit: just so I'm not trolling, a friggin awesome way to handle ports would be for sony and microsoft to put out emulators of their systems for PC. it'll never happen though.

May as well just merge technology then..

[kelbear]

If they obey proper procedures for programming, especially if they know it will be multiplatform beforehand, they will do their work in a manner that ignores what platform and hardware is in play. This is done by "abstracting" the work.

For example, in the "game code" instead of referring directly to a 9800GT's architecture, it'll refer to "Video card". It won't specify what kind of video card, that's not relevant to the overall process. It's saying "Go ask Video Card" about the details. Then, inside the segment called "Video card" it'll have seperate sets of instructions specific for the different kinds of videocards. This allows the "game code" section to be worked on without having to worry about what's going on the "video card" code. This allows multiple people to work, it simplifies all the factors at hand that need to be taken into account, and when it comes time to jump from PC hardware to Console hardware, they can swap out the "video card" code for a new set that is specific for the console's hardware while leaving the "game code" the same.

But that's an extremely dumbed down view of the work (abstraction layers are wide and deep in thousands of sections). The hardware on a console is significantly underpowered compared to a PC, but the fact is that a game console is entirely designed to run games efficiently and they can reap more performance from less powerful hardware. This means that ports need to change the game's structure to fit the console. You can't have giant textures loaded up all the time, the consoles have less memory space than gaming PCs. However, the consoles are designed to stream textures continuously off the disc, so they'll keep swapping in the necessary textures as needed instead of holding them all at once. This change in approach needs to be addressed in the port.

Manufacturer standards and reqs need to be met(XBL functionality, achievements, xbox360 harddrive use), xbox360 QA needs to be passed, and the game interface needs to be revamped to work with the controllers. The laundry list of small details can get pretty long.

Xbox360 is a bit easier, because it's built around what is essentially directX 9. Direct X is an abstraction layer like I explained regarding the video card. This saves a lot of work and is why PC/Xbox360 ports are simpler (MS wanted to leverage its PC market domination to help it into the console market). Even though they still need to tweak things to make it work, it's much simpler than moving to the PS3 and the cell architecture. It's a totally different way of thinking and will take a major revamp of everything they've done for PC and Xbox360. The PS3's power is that it has 8 cores to work simultaneously while PCs and Xbox360 just expect 1-4 cores to handle the work. Many use less than the number of cores offered to them to simplify how things work. They hand 1 core a task (physics) and that's it. On a PS3 they might need to ask 3-4 cores to simultaneously work on the same task and interlink their results into a single result in the game in real-time, without getting out of order or getting bogged down waiting for 1 core to finish a section.

Ports are still plenty of work, but the publishers budget much less money and time for it and so they half-ass the job. The work is also often out-sourced to 3rd party development teams or second-stringers who'll have to figure out how everything was done by the original developers as they work on the port. Not all studios have the same approach, and the differences in quality vary wildly.

[Frostex]

Ports take a lot of coding work, but honestly the most amount of work in modern games is creating the artwork, each game requires hundreds of custom built meshes, textures, sound fx, music, and animations, all that work can usualy be ported between systems with ease, the code for the engine in comparison is far less work. Its just a smart move to port games now a days, it requires relatively minimal effort to acomplish compared to making a game on that platform from scratch.

[MrWizard6600]

The 360 is more or less a PC, it has GPU based on PC technoloy and runs the directx API based around the PC architecture, as well as other PC based technology.

the 360 uses an IBM power cpu, which is a pretty far cry from modern X86.

In an intresting little side note, porting hardware from a console to a PC, as is the case with the R500 --> R600 transition, seems to be exceptionally difficult. ATI's first stab at a unified architecture, the GPU in the Xbox360 aka "R500", was backed by said IBM power chip, and it flew. The R600 (aka HD2900XT) on the other hand, backed by more traditional X86 chips... maybe not so much (it was a total flop).

But anyways, as others have said, it depends on how the code was compiled. If you want to go the high-overhead rapid development path (using Microsofts supplied API's and Direct X building tools), and you pay attention to what microsoft says is and is not do-able on the Xbox 360, you'll probably wind up with something which can easily be ported back and forth between the PC and the Xbox360. It is possible (and has perhalps been done) that all a port needs is a new user interface (easier said then done sometimes).

Somtimes it is possible to get a port to run on its non-native platform by doing things like: PCcompatabillity=veryyes, (or xboxcompatabillity=veryyes) but more often than not such a game will have terrible performance on its non-native platform.

[Demon10000]

I've always thought of it like this:

A game is a big loop of computer code called the engine. The engine does certain functions. So when the developer tells the engine to draw a car on the screen, at a certain position, it does.

So once you get your engine performing exactly on all the systems you want to port the game to, your game code should be pretty modular. If your game code is written for your engine, then it wouldn't matter what system the game is running on it.

As an example, half life 2 is just a mod for the source engine. Valve had to get source running on the PC, then the wrote the game scripts, developed the art and sound, then put the whole thing together in the game files.

Along comes the PS3 and 360. So valve writes source again for these systems, and this is where the actual porting happens. They most likely resuse as much code (or at least the logic) so, in the end, it does things exactly the same as the PC version. Once they have the same engine on multiple platforms, they can just load Half Life 2 into the source engine and it should work.

With that said, I'm sure there is some certain tweaking that needs to be done to accomodate the game data when it's ported this way. They most likely have to deal with different texture sizes, AA modes, etc. But once the engine is running on multiple platforms, they've got a lot of the work done.

Thats why you see a lot of games that use the unreal engine, or the quake engine. If it's already running on multiple platforms, then a lot of the work should already be done to go mutli-platform.

[apcviewer]

As an example, half life 2 is just a mod for the source engine. Valve had to get source running on the PC, then the wrote the game scripts, developed the art and sound, then put the whole thing together in the game files.

Along comes the PS3 and 360. So valve writes source again for these systems, and this is where the actual porting happens. They most likely resuse as much code (or at least the logic) so, in the end, it does things exactly the same as the PC version. Once they have the same engine on multiple platforms, they can just load Half Life 2 into the source engine and it should work.

Thought I would just mention that the development of the Orange Box for the PS3 was outsourced to EA while the X360 was done by Valve.

[Slade]

Actually the 360 uses a language similar to C code, a lot of it can be "reused" for PC use, but there is enough specifics within it to make it 360 only.

There's no magic function to simply make a program work on either setup, rather what you do is you program the game to be modular in nature and written in low level language like C++ from the start. Meaning the game's base engine, the rendering portion is separate from the sound portion, from the media portion etc. The actual "game" itself the parts of the code which describe the world only call to the renderer when it wants to show something on screen. Same with sound etc. In theory you can interchange engines and still use the same game code.

I currently got myself back into school to learn this and part of the tools we play with are the XBox developer kit, the Wii developer kit and even Sony's developer kit (which I have not even begun to touch yet). Seriously, It's Computer Science Game Development Stream. They exist.

The problem with writing a game though is knowing what you can and can't do on a platform. Like say for an explosion you call for some function that does a really nice particle effect, or calls some aspect of physics with very detailed movement. What if a platform can't support that? We'll assume the PC can do all, the 360 can but may hit slowdowns due to being limited, the PS3 is in another programming league altogether, and the Wii is gimped. (PS3 multi thread/core programming is a new concept to programmers so trying to explain it to a non programmer when most programmers have a tough time wrapping around it is tough, look up Fortran to get an idea of the basics behind coding for a PS3 as the concept is similar)

So now you have to go into your game code itself and decide whether this effect is too much for the system to handle OR the system can't do it. It's really tedious work. This is all assuming that the game from the get go was programmed to be modular to begin with. Sadly not all games come with that concept, programmers go with the "this is what I know best" concept, then after its done, do the conversion process. The result is a game code and engine that are more intertwined and dependent on each other than necessary.

Ideally to make an ideal programming language, I'd say it'd combine C++, Fortran, and Prolog. Hear me out on this because it's actually an amazing concept. C++ strength is speed and low level code writing this would make the bulk of the code. Fortran has the ability to do complex mathematical functions with multiple data (graphics, many enemies, lots of explosions, think things of a repetitive nature that would be better served than single instruction loops), prolog would be for AI, (if I know this, than this implies this should happen) It'd really get the idea of "knowing" to a computer. Imagine an AI that goes well he's shooting over here, BUT he's making a break for there and I know he's going to the exit, therefore I can cut him off at this point since I know he's going there. That's human level reasoning rather than AI goes to this point and shoots there because the programmer told him to.

[MrWizard6600]

nvm.

[Tylerdurdened]

Thanks for the explanations guys, makes a lot more sense.

So basically there will be no more fresh redoing of games (where a company would make the game from scratch for the other console)? Almost all games are/will be ports?

That's really too bad :( They really do cause a lot of disappointments for me when a company doesn't want to optimize and streamline a game to a specific console and goes the easy way out just because some people will still buy it regardless of how bad it really is done.

[MrWizard6600]

woosh.

It totally depends on the game, the publisher, and the producer. Some devs go to great lengths to make sure their game works flawlessly on all 3 systems, others not so much. How well the game was ported is only a problem when its a problem. If the quick fix yields 60 fps, why bother optimizing?

[Elledan]

In short:

Game assets (textures, graphics, maps &c) are platform-independent. All you have to change is a few bits in the game engine, namely the parts which interact with the platform on which the engine should run. These parts involve the rendering algorithms, physics routines and such. If an external physics library is used nothing has to be changed as it'll just link with the native library. If OpenGL is used on both platforms then only the entry point has to be changed (Windows and Linux use slightly differently named entry points, basically). To use DirectX instead of OpenGL you'd have to write a new rendering path.

As pointed out earlier, not all platforms support the same things, so sometimes you have to tweak the ported game to compensate for this. All in all it's fairly hard to screw up a port, as you shouldn't have to touch the core gameplay mechanics.

As for OpenGL, look at it this way: OpenGL is an open standard, which nVidia, ATi/AMD and others can add their own extensions to, thus adding new features all the time (hence an OGL 2.0 compatible card will probably support most if not all functions of OGL 2.1). DX is closely regulated by MSFT and only they can add new features. The result of this is that OGL is always ahead of DX, but MSFT gets to pick the best features of OGL when it's time to update DX.


Disclaimer: I run a game development company which strictly uses OGL :)

[kju1]

In short:
Game assets (textures, graphics, maps &c) are platform-independent.

Well you are more into than I am, but I was under the impression that you could run into a situation where say System X used a properitary video codec. Say for FMV sequences. So your FMV would all have to be recoded to run on that system.

I would certainly hope that textures etc are, but dont they get optimized for the platform as well?

[Menelmarar]

Well you are more into than I am, but I was under the impression that you could run into a situation where say System X used a properitary video codec. Say for FMV sequences. So your FMV would all have to be recoded to run on that system.

I would certainly hope that textures etc are, but dont they get optimized for the platform as well?Depends, may have to be reduced, console's have significantly less memory and also run signficantly lower resolution... or used to. I guess not so any more with the 1080P supporting high def consoles...

[Slade]

I'd actually say its easier to screw up a port than anything, look at how many games have come out initially on a platform only to have a port done to another. Console to PC ports get brutalized way too often. Dead Space and its horrible PC controls come to mind.

If a company focuses on making a game from the get go on multiple platforms AND takes the time to know or has knowledge of all the platforms, then I would say it works out nicely for all players.

Also this is a business first and foremost. You hit a wider audience IF you make it available for all platforms, you don't do it because you want to share the experience with everyone, more than likely you are maximizing profit margins. There are a few companies that make games for the gamers, Valve, Blizzard come to mind and they rake in cash because they cater to what people want for the most part.

[Tylerdurdened]

I'd actually say its easier to screw up a port than anything, look at how many games have come out initially on a platform only to have a port done to another. Console to PC ports get brutalized way too often. Dead Space and its horrible PC controls come to mind.


FYI it's controls are perfect. I guess you said that because you've seen the huge thread titled dead space PC controls suck balls. It was solved within the first few pages and the culprit was it's bad implementation of Vsync. Turning it off fixes the laggy controls completely, and there's no need for Vsync in the game. I was getting 150 FPS with it off and didn't notice any tearing

[Elledan]

Well you are more into than I am, but I was under the impression that you could run into a situation where say System X used a properitary video codec. Say for FMV sequences. So your FMV would all have to be recoded to run on that system.

I would certainly hope that textures etc are, but dont they get optimized for the platform as well?

It depends on the differences between the platforms you're porting between. If you're porting for example between Windows and OS X all you generally need are some different binaries (modified rendering engine and such) and off you go. Sure, if you were stupid enough to use WMV video for your FMV you'll have to re-encode it to a format supported on OS X, but beyond that no changes are required. You can see this with quite a few games which provided Windows and OS X/Linux binaries which used the same game assets.

Now if you're talking about porting to an excentric architecture like the PS2/3, then yes, you'll probably have to tweak things a bit more to make it all fit :)