how the same video game is coded for different platforms

425 views

how the same video game is coded for different platforms

In: 8

8 Answers

Anonymous 0 Comments

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.

You are viewing 1 out of 8 answers, click here to view all answers.