Developers invest the least amount of money in the PC.
I mean with PC yuou also have to deal with so many configurations as well on PC, comparing console to pc is not a great comparsion. this is a really good post that explains it.
(I should say upfront--there is a big difference between porting a game, and porting an engine. Keep that in mind.)
So it really, really depends.
It depends on the console that's being ported from, and the engine that the game was written in.
For games written in a general, multi-platform engine like Unity or Unreal, porting is as simple as clicking a button to switch the platform you're targeting. (Except that it's not--there are still platform-specific adjustments to the game code and resources you'll have to make, but generally this is done at a fairly abstract level, in the same language that the game was originally written in.)
Porting a game created in a proprietary engine (as in an engine used by a single company, like the engine behind Halo; not one licensed to many companies, like Unity) written to target a specific platform is much less abstract, and more difficult.
I'm a general programmer with a poor knowledge of low-level systems design (computer hardware is a black box to me).
For the engineers who make games like The Last of Us and Grand Theft Auto V possible, an intimate understanding of their target hardware is critical to doing their job. Console games (especially towards the end of a generation) that push their hardware to the absolute limit can only exist because of performance optimizations and hacks to their engine made at a low, low level in code. These console games (particularly exclusives) are tied intimately to their native hardware. Developers know exactly what they're going to be running on, and what all the quirks of that architecture are.
(As an example, Grand Theft Auto V on Xbox 360 was only possible because developers figured out how to stream game data from the disk drive and hard drive simultaneously--something very specific to that console.)
So compare consoles to PCs. PCs have infinite, unknown, ever-changing configurations. You can’t optimize to a generic PC's hardware the way you can to a console's, so some of the tricks that made your game run on Xbox just won't carry over.
It's not just that different PCs have different performance specs (e.g. differently clocked CPUs, different amounts of RAM); it’s also that different PCs can have completely incompatible architectures. (Different CPUs work very differently.)
Some consoles (like the Nintendo 3DS and Switch) are ARM-based. But most builds of Windows are tailored to x86.
Consoles like the Xbox use an AMD graphics card. So do some PCs; but many use Nvidia chips, or integrated graphics on the CPU. Each class of graphics processor has a unique driver implementation that needs to be accounted for in order for them to be compatible with graphics APIs (the libraries that make it possible for programmers to send instructions to graphics hardware).
Luckily, most open APIs support most graphics cards--but not all APIs are open!
Playstation uses a custom graphics API similar to but different from other common graphics APIs. So if a developer wants to port their custom game running on a custom engine targeting Playstation, they need to go through their code and replace all of their API calls! (While hoping that the two APIs have analogous features.)
Even if you're using a cross-platform API, support across all architectures isn't necessarily even--DirectX can run on ARM hardware, but in a way that's limited compared to its performance on x86.
So if you write your game engine on DirectX, but decide you want to port to ARM devices, you could be in trouble.
In some ways (speaking as someone who has never had to do this), it seems like the nightmare scenario is not actually porting a game from console to PC, but from console to console: take the Switch, an ARM-based device with a custom graphics API, and Playstation, an x86 device with a completely different custom graphics API. Your game’s engine needs to totally change the architecture it supports, and the API it uses.
By contrast, consider moving from Xbox to Windows: x86/DirectX to x86/DirectX (an Xbox might as well be a highly custom, standardized PC).
So: porting an entire engine is difficult, because of the problem of targeting multiple distinct architectures. Large AAA studios can afford to do it.
But for the majority of mid-tier and indie developers, maintaining and porting an in-house engine just isn't worth it. It’s much less risky and much more cost-effective to just license an engine from a third party whose main focus is engine development, not game creation.
Choosing to develop with an engine like Unity is choosing to outsource your low-level graphics programming. Porting your game becomes much simpler, because you have a guarantee that your engine will work out-of-the-box with your target platform. All you have to do is make sure your game runs within the performance constraints of your target platform, by managing the assets you use. (Which is still difficult! Just not as difficult as porting from scratch.)
Low-level graphics programmers make a lot of money for a reason: their work is complex, endlessly intricate, and the backbone of the rest of the industry.
So far in talking about porting I've touched on the approach of writing an engine, writing a game in the engine, and then porting that engine.
But there’s one more approach: picking an engine, writing a game in that engine, then throwing the engine code away, and translating the game code to work in a different engine altogether.
Take Binding of Isaac: it was originally a flash game, coded in ActionScript. Flash is proprietary, and only runs in browsers (or a browser wrapped in a desktop app). There was no way for the developers to port flash to console (because it’s closed-source, and Adobe has no interest in that). So if they wanted to port BoI, they'd have to abandon flash, and reimplememt the game in an entirely different engine. And that's exactly what they did! BoI’s game code isn't in ActionScript anymore, but it’s probably one-to-one translated, and functionally the same.
This also happened with porting Minecraft to Xbox: Java binaries don't run as console games, so the game code was reimplemented in C++/C#.
Sometimes, people want to port a game, but not only do they not have access to the engine code; they've lost access to the game code entirely. So they have to do the whole project from scratch, and try their best to mimic the original game’s functionality.
That's what happened with the rerelease of the Crash Bandicoot series: the new games aren't true ports; they're complete recreations. Functionally Crash, but not at all internally.
So. Apologies for such a text wall!
In sum: the process for porting depends on what code you have access to (engine, project, or both); whether or not your engine is cross-platform; whether or not it’s possible to port the engine to a new platform if it isn't; and whether or not it’s more cost-effective to port an engine, or to just move a game to a different engine where the work of porting has already been done.
Cheers!
www.eurogamer.net
