27
\$\begingroup\$

PC ports of console games often come out a month or two later. Why is this?

Games are written in languages that compile on PCs too, so the game logic should compile without issue. What's holding them back then? Is it rendering code or what?

\$\endgroup\$

closed as too broad by Alexandre Vaillancourt, Josh Jan 19 '16 at 16:52

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    \$\begingroup\$ It is probably due to publishing deals. They get payed from e.g Sony for making an ps3/ps4 exclusive title. \$\endgroup\$ – Aurus Aug 15 '13 at 8:57
  • \$\begingroup\$ I am talking about games which come out for some consoles. They say that the 'port' will come out X months after the console release. The question is what is the reason they wait. I mean, marketing can have something to do, but I am interested from the programmer's side. \$\endgroup\$ – Bloodcount Aug 15 '13 at 8:59
  • \$\begingroup\$ But Aurus is right, that is the most likely answer. Porting code from the consoles to PC is not trivial for multiple reasons. Most games that come out for PC briefly after a console release were designed for the PC in the first place, or at least the underlying technology supports an easy port. Otherwise a couple of months would probably not be enough \$\endgroup\$ – Grimshaw Aug 15 '13 at 17:08
  • \$\begingroup\$ Regarding your comment "games are written in languages that compile on the PC" has not always been true. In particular, I would like to modify a famous quote, "Consoles and PCs may all be computers, but not all computers are created equal". \$\endgroup\$ – kurtzbot Aug 15 '13 at 20:18
47
\$\begingroup\$

There are a number of reasons why a PC port can take a while. (I apologize if I seem to be repeating myself somewhere; this is sort of written on the fly.)

Adapting controls and gameplay

When you're playing on a console, this alone puts certain limitations on what you can do, since all the user has is a gamepad.

Just creating 1:1 mappings between keyboard keys and controller inputs is not always a good idea - if even possible - so sometimes it takes longer to figure out a good solution.

Hardware abstraction/Fragmentation

When you develop for e.g. a Wii U, you know exactly how a Wii U behaves, because all Wii Us are identical. This is not true for PCs; you have many different graphics cards and CPUs, and sometimes something won't work on some of them. It takes a lot of testing to uncover these bugs, and fixing them also takes time.

If you've never used your engine to make a PC version, you also need to code your hardware abstraction accordingly. Some games want to support multiple DirectX versions and OpenGL for Linux/Mac, and all of that takes time to write if it hasn't been done before.

Resource contention

On consoles, the game doesn't have to compete with an OS for resources, etc. - not a whole lot of stuff goes on in the background.

On a PC, you have the OS running, you have a plethora of background programs, and this all means you won't get as large a share as you were hoping for. This means you sometimes need to perform additional optimizations, especially for players on lower end systems

Improving assets

With a console, you have a fixed target, so you write shaders, etc. to match that target.

On a PC, some graphics cards support more advanced features, and maybe you want to use a better shader for those. Well, that means you'll have to write that shader.

Platform-specific stuff

Console SDKs may have a lot of convenient features that don't map over easily to a PC - for example, it might provide access to hardware timers or a good sound API.

Those things aren't usually available on PCs; you need to use other ways of accomplishing those things and maybe that changes how you have to abstract the platform differences.

\$\endgroup\$
  • 4
    \$\begingroup\$ Related to controls, user interface, you can still see this a-lot, where the menu on a PC desktop doesn't even work with the mouse, e.g they've done 1:1 mapping from d-pad to keyboard. Another potential issue is shader languages and driver support. \$\endgroup\$ – Casper Beyer Aug 15 '13 at 12:08
  • 1
    \$\begingroup\$ Good answer overally. However, in cases where developers want to squeeze maximum performance out of the consoles, a low level layer of platform specific code is usually not enough, the game itself must be engineered to leverage the strong attributes of the hardware of the console, which isn't necessarily the ideal solution for the PC too! \$\endgroup\$ – Grimshaw Aug 15 '13 at 17:10
6
\$\begingroup\$

A simple reason is that a console has a single set of hardware that is the same per console.

Your XBox, PS3 and Wii all have the same hardware as your neighbours XBox, PS3 and Wii. However your computer has a different CPU, different graphics card, different amount of RAM, in fact the whole configuration and Operating system settings, installed drivers could all be a completely unique permutation that no other person in the world has.

This is what makes it difficult to port to a PC. You need to account for every possible piece of hardware within your minimum system requirements and above. That is a tricky and difficult process to program and debug. It is very hard for developers to know every configuration to program for and near impossible to run tests on these configurations.

Once they develop it for PC there is extensive testing done in house by the devs but it also can be reliant on beta testing from users for upwards of a couple of weeks to a few months. This outsourcing of tests with beta players before the port to PC is officially released is typically why you see the gap on release dates between Consoles and PC.

\$\endgroup\$
5
\$\begingroup\$

Porting code to a new platform takes time. Creating a nanosecond timer for Xbox 360 (I've never developed in XNA) is going to need a different implementation than the same nanosecond timer in Linux, Mac, or Windows. Now imagine you have hundreds of these types of functions that need porting, thousands if the engine is massive enough.

It can easily take a month or two of coding to add in these different implementations for the new platforms. On top of this, you can't always use the same libraries on Xbox 360 as you can on Windows, Playstation 3, or some other platform. This means you potentially have to use a whole new library to do the same thing you did on the Xbox 360 version.

Overall, these kind of things add up into a large amount of time. Porting to a new platform is rarely easy for large AAA titles.

\$\endgroup\$
3
\$\begingroup\$

It has almost nothing to do with being hard in many cases.

It just isn't a priority. They're cranking to just barely get out the door in time. Every minute difference takes time to account for. If you can release on a few consoles or the PC by a deadline, do that first, then wrap up the ports. Release early, make more money. Generally the consoles have done better for boxed games this last generation, though it has started to shift- the new consoles might turn that around.

Also, in some case, console makers give benefits to exclusive releases, so the publisher gets a discount or some such if they release on a particular console first and other platforms later. Nothing technical about it.

\$\endgroup\$
1
\$\begingroup\$

Initially, games are harder to make on a console than on PC. On top of it, consoles have very different specs and different hardware between nintendo, sony and microsoft, which not only result in different performance, but also means different bottlenecking issues.

Usually, game will just tweak their engine to maximize quality and performance on each console.

When adapting to PC, there are other problems. Consoles are homogenous, meaning all consoles have the same hardware (all PS3 have the same hardware performance). When you make your game for PC, you target a minimum spec, but you also allow the user to increase quality for more powerful PCs. Games targeted for PCs are less optimized, but are easier to make for programmers.

Programming on console have one advantage, it allows programmers to maximize performance, so any console game will always perform nicely.

On a PC, it's worse, because there are many hardware out there, but granted, it's more freedom, the best resulting looking game will always be on PC, because PC is always at the bleeding edge, at a cost.

Porting a game from console to PC can be tricky, because console are designed for game performance, while PC are not, but overall, it's far easier to port a game from console to PC than the opposite, because console have very much less memory, something like 2 or 4 times less.

Changing the code to adapt to this memory restriction will mostly always mean a complete re programming.

I don't think it's hard to port a game from console to PC, it's just a matter of API. Companies and programmers who work only with consoles will have a hard time porting to PC, because they're not used to it, but also because they constantly adapt to console API, so that means their code will often answers the console compiler restriction, and not necessarily care for PC apis.

Of course, engines can be programmed to run on all consoles and PCs, once it's done it's easier, it's better than telling your programmers to port the engine to PC after they've been told it was never planned for 3 or 4 years.

TL;DR consoles are homogenous and last one console generation, PC are heterogenous, and hardware and API constantly evolves. Costs are spread between programming and hardware building, which are compromises.

One good thing would be to allow all hardware to run everything, but console prices are compensated because game companies pays console manufacturers a license, so they lock their hardware to run only game companies who pay. It's messy.

\$\endgroup\$

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