how the same video game is coded for different platforms


how the same video game is coded for different platforms

In: 8

Each CPU has its own language that it understand. An x86 CPU (Intel and AMD) couldn’t understand the language to a ARM CPU (mobile and Apple).

This base language is called machine code and has very basic instructions such as add, load, move or bitwise and.

Most programmers do not write in machine code. They did in the past, when efficiency was more important. Programmers code in high level languages, which is much easier to read by humans and quicker to write. However a CPU cannot make heads or tails of the high level language, so you have an interpreter to stand in the middle and convert high level code into machine code.

Since high level languages are not specific to a single type of machine code, you can have different interpretators to turn the same code into many different machine codes, to distribute to different devices.

This is the simplest way to make the game playable across platforms. However with modern Xboxs and PlayStations using the same x86 architecture as PCs, this is a less of a worry.

You need to optimise for different devices, different memory size, CPU speed, core count all have to be considered to make a program run well on a different platform

As another person said, modern consoles have similar architectures so it’s probably fairly easy to develop multiplats. It was more interesting in the past when they had different architectures (or I suppose when the Switch gets the same games as PS5/Xbox). When developing PS3/360 games, developers would often build the game for Xbox and then port it to PS3 because it was easier to develop for Xbox. This is why multiplats of that generation were often better on 360, despite the fact that the PS3 had more theoretical power.

All the textures, sounds, possibly models, etc could be reused, though possibly converted to a different file format. Then they basically had to take all the 360 code and whenever they’d call a function to do X, they would replace it with the PS3’s equivalent, or create a work around if it didn’t have one.

Starting from PS3 and moving to 360 could be more difficult, depending on the game. Going from a blu-ray to a DVD means they possibly needed to cut content or downgrade textures and audio files to actually fit on the disc. Then if the game actually took advantage of the PS3’s Cell processor’s abilities, they’d have to find workarounds for whatever that was doing or remove those functions from the game.

Making a Wii version was basically that but to an even larger degree. That’s why Wii often just didn’t get the same games as the others did, or they got completely different versions of the game. Compare the 360/PS3 versions of Sonic Unleashed to the Wii/PS2 version for example. They have the same themes, art design, music, story, etc, but the gameplay and level design is very different.

You separate what you want done from how you want it done.
What you want done is the same on any machine (turn right, look up,,etc).
How you want it done is a different set of instructions from one type to another. On the Xbox there is one set of instructions that handles “turn right” there is a completely different set of instructions for PlayStation. They both accomplish the same thing n the appropriate way for what they are operating

Coding a video game for different platforms is like writing a story in different languages

Each platform (like Xbox or PlayStation) has its own language (coding language), so developers need to rewrite the story (game) using the specific language for each platform.

Our codebase uses a programming concept called “abstraction.” Say you wanted to read the state of the various buttons on a controller. The actual code needed will differ based on whether the controller is an Xbox controller or a Playstation controller or a Switch joycon, etc. So we built a library of generic controller functions (e.g. our code uses labels like “Button1” which is the primary button – A on Xbox and Cross on PS).

An implementation of these functions is written for each platform we support; we’ll write a version for Xbox controllers that calls Xbox API functions and another version for PS controllers that calls the Playstation API functions and each version will be it’s own code file (something like ControllerInputXbox.cpp and ControllerInputPS5.cpp).

Our project is set up so that each platform target uses a different implementation code file for our generic functions. This means that, from the perspective of the code that wants to check the state of the controller, it only needs to ask what the state is for “Button1” and it will get the correct answer because it was compiled to translate “Button1” into the appropriate controller button for the platform.

Now apply this concept to other platform-specific parts of the game, such as graphics, audio, and file systems, and you can write the vast majority of your code to be platform independent with only a relatively small amount platform-specific code hidden behind such generic functions.

Hope that makes sense!