What do game developers do when they have to port their DirectX games to PS4/Switch?

Question

I'm not a game developer (hope to be one day though!) and was wondering how devs handle porting their games that use DirectX to PS4/Switch? From what I know neither supports DirectX, only OpenGL, and Vulkan. Do the devs just have to recreate their game with OpenGL or Vulkan? That seems like a lot of work. I'd imagine it would probably be a fairly common scenario, especially with AAA games so I'd assume that there would be something somebody has made to make it easier?

Answer 1

Yes, porting games between platforms is a lot of work.

Typically it involves writing an abstraction layer, so game-specific code never references a DirectX or other platform-specific code directly. Instead it will direct its request to this intermediate layer. When done right, the vast majority of the game code will have no idea if it's running on DirectX or something else.

The old DirectX-specific code will become one version of the implementation of this layer, and the devs will create another version for the new platform - serving the same interface to the rest of the game, with different internals to match the new system.

At compile time, either version of these intermediate layers can be swapped-in, to compile a binary for one platform or another.

Now of course it's not a simple task, since different platforms and APIs work in different ways or make different assumptions. So there's a lot of work in establishing a common set of operations that the abstraction layer can efficiently map to one platform's implementation or the other.

DirectX shader code might need to be re-written for the new platform, or the team might use a transpiler to produce modified shader code automatically for most cases, and only hand-fix the problem cases.

Assets like textures might also need to be re-baked to suit the compression formats or memory size characteristics needed by the new platform. When porting to mobile, assets might also need to be exported at different resolutions to suit different screens. Sometimes an artist or other asset creator will need to make custom versions to support the new platform, like simpler meshes for weaker graphics hardware.

The amount of work involved in all this is one reason why established, cross-platform engines are so attractive. They've already done most of this hard work, so you have fewer steps required to port your game to a new platform (though usually there are still at least a few issues to sort out, since platforms don't just differ in rendering, but also input devices, vibration, player account management, online/store systems, achievements, console settings, certification requirements, etc...)

Answer 2

Having done so several times, I can say that porting the graphics part from PC to (modern) consoles, depending on how the PC code was written, could be relatively straightforward, or very hard.

Just like the differences between modern DirectX and OpenGL are not -that- big (from an API point of view), the several APIs for consoles also use similar architectures, and in general, porting a game from PC to consoles will mostly consist of changing the API calls, changing some of the platform-specific code, and fixing unusual things that might have worked on PC, but no longer work on your console. DMGregory's answer covers what you need to do pretty well.

That said, in my experience, the majority of effort in porting an (indie) game to consoles comes from porting the non-graphics stuff, where the underlying assumptions about how the platform works can be very different between platforms.

This is aggravated with the fact that consoles often have a long and very strict list of technical requirements that your game will be checked against, and has to pass, before it is allowed on the game store (PlayStation Store/Nintendo eShop). Some of these requirements will come and bite you where you least expect it.

For example, saved game data is stored in files in PC, and you might want to show a file open/file save dialog to let the user choose where to save their game. In some consoles, saved game data is not stored with the file IO API (fopen, fread, fwrite, etc.), but uses a special API, with a different GUI, and different concepts altogether.

Furthermore, you might have been able to save data on PC with simple synchronous calls; on consoles, on consoles you might be required to correctly save data asynchronously, and handle all errors appropriately. Depending on how you did saved games before, this might require you to re-engineer the parts where you are saving data in your game.

Another example is achievements/trophies. You can make a game for PC without the concept of achievements/trophies. When you move to consoles, you might be required to do so, and therefore you have to start from even planning what the achievements/trophies will be, where they will be unlocked, and add the code to do so.

Just like these examples, there are many, many, many requirements that have different assumptions on PCs and consoles, and in my experience these take much more effort to resolve, compared to the graphics API differences, which are comparatively straightforward.

If you're porting a game from PC to consoles, I do recommend you budget enough time to do all of this, especially if this is the first time you're working for a specific platform.