How are games ported to other platforms, e.g. PC to PS5?

1.33K views

Also as a game developer who wants to make a game available on all platforms, what platform do they usually start with or is there a “master version” that is then adapted to each platform?

In: Technology

3 Answers

Anonymous 0 Comments

Imagine if you will you held a book written in England English, and its written incredibly well and the speakers fully understand it, even if it has typos and speaks a little too literal for their culture.

We will call this the PS5 port.

Now take it and stick it in front of an american. This will be the XBox port.

The american looks at it and understands almost all of it, but since it wasn’t fully designed for american english they get confused and things don’t have as much meaning in other places.

Theoretically, both could read it. But it’s not 100% the same book if one is American English or English. Though the exception is the language in general, or the base copy.

English does not change regardless of where you go, its spoken language and growth of new words and lingo is. The new words are new hardware and the lingo is drivers. Region after region it changes.

If you make a video game dedicated to one console, you technically can reuse the book perfectly fine in other consoles, but it will require some rewrites and fixes for specific consoles.

Another example would be using a mouse and keyboard in a playstation. Its not impossible, but with some work you can create something to make a similar effect to what you want.

Anonymous 0 Comments

# What’s A Platform?

A “platform” can be roughly defined by a combination of hardware and software. The hardware (e.g., CPU, GPU, chipset(s), …) mostly defines the performance as well as what computing features are available (you may have heard of hardware assisted ray tracing, it’s the new shit). The software (OS, DirectX, OpenGL, Vulkan, other Frameworks) provides the primitives to *access* these features.

So, in order for your code to run on “all platforms” it must be runnable on all the given hardware and also support all the various different ways the platform’s softwares work with said hardware.

# Hardware Platforms

**Hardware-wise**, the current Sony and Microsoft consoles are quite close to a regular PC you could buy. Specifically, they use a (slightly customized) x86 CPU defining the ISA, the set of instructions the CPU can execute. This means, from a pure CPU perspective all programs running on a current PS/XBox run on your average PC. In fact, the PS/XBox are so similar to a PC that quite some have taken up to install Linux as an OS on them.

Android phones *mostly* use ARM CPUs and also work a bit differently inside, more akin to a console than a PC.

# Software Platforms

**The Software**, however, is quite different on all these platforms. While most PCs run Windows, with Linux trailing (and Apple currently taking a completely different route), the XBox runs a modified version of Windows and the PlayStation runs a modified version of FreeBSD.

While on Windows, the dominating graphics framework was/is DirectX, on Linux and BSD as well as macOS this was/is OpenGL^(1). Vulkan was created as an alternative to both, supporting all^TM platforms^(2). So while there is some convergence, even accessing a file works drastically different in Windows compared to *almost* any other platform out there^(3).

Luckily, you don’t need to directly access the OS as many people have built another layer of abstraction which gives you a simple interface to, e.g., open a file, and translates that into the diverse OS specific ways to do precisely that. Pretty much any modern engine gives you such a layer, enabling comparatively easy cross-platform development.

# Issues with Porting

So, what’s the **issue with porting**, if the engines do all the heavy lifting and even out the differences between the platforms? Well, there are bugs and design faults in all of these layers.

We have a “technology stack” reaching from CPU+GPU+Chipset, to OS, to OS Frameworks, to the Engine. A bug at the lowest layer can send all the above tripping. And the Engine, hopefully, accounts for all that, knows that in Windows 10 Build xyz the function `FooBarW()` cannot be called andsoforth. So, in order to ensure compatibility, nowadays one of the most important things after choosing the right engine is to *test*, i.e., Quality Assurance.

The best but also **most expensive** way is to test on all platforms, continuously, while developing the game. This includes game testers. That way, you are likely to find every bug, but also quite many double or thrice as they occur on all platforms — this will lead to many internal bug reports someone has to deal and categorize.

The **cheap** way is to develop on one platform, often either Windows PC, XBox or PlayStation first and, when it’s (almost) done, trying to get the game run on the other platforms. This will reduce the number of bugs found as the tests on the other platforms aren’t as thorough, but you will also have less duplicate bug reports and need less testing time (hopefully). However, if you are unlucky, the fine print of your engine says that feature X that you direly depend on is only supported on platform Y — and you notice that a few weeks before release.

Often enough, companies go route 2, but some at least have “that one developer” who constantly builds and runs the game on the other target platforms, ironing out the gravest problems.

# Other Platforms

What about **other platforms**? You mentioned you want to cover them “all”. Bear in mind that this is a rather big list:

* Android (ARM + x86)
* iOS, iPadOS (ARM)
* Windows + XBox (x86)
* macOS (x86 + ARM)
* Linux (x86 + ARM, supports a bunch more)
* many BSDs (same as above)
* PlayStation (x86)
* Browsers (WebAssembly, JS)
* Stadia (basically as Linux)
* Nintendo Switch (ARM)

So you should make yourself clear what *kind* of game it is, what *controls* does it require? Is controller play actually sane? Is the performance of the Switch feasible? Then you should decide on the platforms.

# Build Portably

Finally, I want to encourage you to **build on different platforms**, even *if* you don’t really look at, say, Linux sales. While porting seems daunting, having a portable program doesn’t only have business benefits. Usually, when testing on not just one stack, you uncover bugs in your code that *might* bight you on your other platform as well but just haven’t occurred yet. Say, you have a bug which triggers under so specific circumstances, you could call it “randomly”. However, the probability is greatly higher, for some reason, on platform Y than on X. So now, having run/tested your code on Y, you uncover that bug and are able to fix it comparatively easily while on X you’d have a hard time even reproducing the bug. Good code is portable code!

——

^1 While OGL had it’s pitfalls, it was *fine*, however MS crippled the OGL implementation on Windows making it rather slow there… .

^2 Vulkan started out as AMD Mantle. DX12 and Metal are pretty much just MS/Apple branded versions of Vulkan.

^3 macOS as well as BSD and Linux (mostly) implement an industry standard for **Portable** Operating System Interfaces, POSIX. This makes it quite easy to program, s.t. your code can be trivially built and run on “all” platforms. Windows XP even implemented some parts of it due to US Govt. demanding POSIX as they didn’t want to depend on one vendor.

Anonymous 0 Comments

Imagine you are baking your grandma’s favorite cake recipe (the software program). You live in America and have measuring cups, half cups, tablespoons, and teaspoons to work with (computer hardware).

But her recipe is in metric and calls for measurements of 100 ml and 250 grams etc. Also baking in C not F. The basics are the same but the specifics are different.

How you get to a delicious baked cake is porting.