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!
Playstation speaks Korean
Xbox speaks Japanese (These are both examples for purpose of explanation)
Developers make their game in English, then have translators translate their games into each platform’s specific language that they understand.
At the end of the day, all programs break down into a complex series of MILLIONS Of individual actions. Each system’s processor has a list of instructions, think of it like a table:
Instruction 1: Add two numbers
Instruction 2: Move a number from one place to another
Instruction 3: save a number to memory
Ect…
When we write programs, GENERALLY, we u se what is called “High Level Language”. this means we write a program in terms of actions, rather than instructions Individual lines.
As a simple example, let’s say we wanted to add two numbers. We would write something like “x = number1 + number2”, as opposed to the individual instructions to load each number from storage into the adder, combine them, take the result out and move it to storage, ect.
We then rely on something called a compiler to convert this human written code into the series of instructions. By using a different compiler for each platform, you get a game that works on multiple platforms!
However, this is only part of the story. Different CPUs might be able to do some kinds of math much faster, and other kinds much slower. What will often happen is that developers need to use a different approaches for the same thing (like, say, the way they load a texture), to play to the strengths of a given system. Famously, the PS3 was FAR more powerful than the XB360, and yet a lot games in that generation ran much MUCH better on 360 because the PS3 was a very complex system that was tricky to code for. You had to use special techniques to get the most out of it. For this reason, platform differences are often different in code too, not just when compliled.
As an example of how this manifests, let’s take two systems. One is capable of loading textures from storage very fast, but does not have a large “cache” (place to store something close at hand that is very quick to read). The other has a fairly large cache, but access to storage is slow. You might write a game that loads textures as needed, only to find this causes loading times and popup on system 2 to be bad. So you modify the build for system2 to “cache” some commonly used textures, improving it’s performance
For modern games, cross-platform portability [1] is simple and boring:
– You will likely plan from the beginning to support multiple platforms
– You will likely use tools that makes it easy to support multiple platforms (game engine, programming language, compiler)
– You will likely only target platforms that have similar hardware (modern game consoles, phones/tablets and PC’s/laptops all have similar CPU / GPU)
– You will likely try to avoid portability problems, and you will deliberately choose not to: Assume a specific frame rate, directly access the hardware, write in assembly language, use features that only exist on one platform
– You will likely test your game on all supported platforms, and fix any obvious portability issues before release
This applies if you’re a modern game developer creating a new game in 2023. If you’re Nintendo porting Donkey Kong from arcade to NES in the 1980’s, you’re probably just going to rewrite the game from scratch.
Well into the 1990’s, most games made no attempt to be cross-platform:
– You likely never planned to support multiple platforms
– Few tools exist that make it easy to support multiple platforms, and suffer from performance and functionality issues.
– A game console has very unique hardware that is very different from PC’s and other game consoles.
– You will assume a specific frame rate, you don’t have CPU cycles to spare or any desire to deal with the graphics headaches of simulating the game world independent of displaying it.
– You will directly access the hardware, there is no OS on a console before the mid-1990’s.
– You will probably write parts of your game in assembly language for performance reasons
– You will need to use very non-portable methods to do anything at all with acceptable performance; for example each platform has its own unique GPU-ish functionality for tiles / sprites / backgrounds
– You will only test your game on the platform it’s coming out for, by the time it gets to testing it’s so tied to one platform that even getting a testable build for other platforms would be a monumental, perhaps impossible task
So far I’ve been focusing on consoles, but PC’s weren’t much better. PC’s did have an OS in the form of DOS, and a standard graphics API provided by BIOS, but most games talked directly to the graphics hardware for performance reasons. Early versions of Windows [had a couple games](https://www.youtube.com/watch?v=iGPobbj0Pmo) but most developers ignored Windows and made their games for DOS, until Windows 95 and DirectX, but that’s a story for another day.
I’ve focused on graphics and CPU up until now, but sound was its own special snowflake. For example, modern games usually use pre-recorded music in the form of MP3, Ogg, FLAC files. (It’s expensive to literally record an orchestra playing your custom music, so for most songs in most games, the recording file is generated on the composer’s PC by software — but for playback purposes, a sound file created by music composing software is treated the same as a recording of a live performance.)
Playing recorded music in games depends on three things that didn’t exist until the late 1990’s: Sophisticated compression methods, a fast CPU that can decompress them fast enough to keep up with playback, and a large amount of storage (a game soundtrack is often dozens or hundreds of megabytes). Earlier games usually generated their music and sound effects by synthesis, so in addition to your unique GPU, you have to generate the sound and music by talking to your platform’s unique sound chip. On the PC, sound support wasn’t built into the motherboard; you had to buy a separate sound card. PC music was MIDI which was originally designed as a digital interface for stage instruments. Different sound cards had different synthesis of the [MIDI instruments](https://en.wikipedia.org/wiki/General_MIDI); instrument 72 is always “clarinet,” but the specific sound, timbre, and balance is up to the sound card designer. So running the same game on different PC’s was like giving sheet music to different bands: The sound is going to be unique, possibly very different from what the composer intends, it might sound great, it might sound terrible; who knows what will happen until you play it?
I should also mention that *not all* 1990’s games were portability nightmares. For example, [Out of This World](https://en.wikipedia.org/wiki/Another_World_%28video_game%29), first released in 1991, was designed with portability in mind; it was successfully ported to many different platforms.
[1] “Portability” means it’s easy to make your program run on different kinds of computers. In the modern era this usually means: Windows / Linux / Mac / iPhone / Android / Switch / PlayStation / XBox / web.
Latest Answers