Back in the days of 8-bit microcomputers, the various machines were so different from each other that porting a game often meant a complete rewrite, and the results could be quite unlike the original. Surely enough, they are called conversions instead. Despite that hurdle, many of the classics exist in an astonishing number of variants. Elite was ported to no less than 13 distinct architectures!
Granted, the relative simplicity of those old games was a factor. When 64K is all you have, complexity doesn't have room to get out of hand. Still, in this day and age of generic hardware, plentiful resources, standard APIs and file formats you'd think we're in a much better position to make one game available on multiple platforms, especially as we no longer have so many of them to worry about.
Yet sometimes it seems more difficult than in the past.
C is by far the most widely ported programming language. Write your code in ANSI C and it's sure to run essentially everywhere, from microcontrollers to supercomputers... as long as it's a command line application. The moment you have to take a display into account, trouble starts. Even in text mode, you never know exactly how many rows and columns a particular terminal has — and it can vary wildly. Add graphics to the equation, and things get really hairy. Not just resolution is an issue, but also how many colors are available and how they are stored. RGB or palette? Bit-planes or contiguous storage? And then there are exotic color systems like that of the ZX Spectrum or (shudder) Apple II.
For a while, developers could rely on a small range of resolutions, from CGA to SVGA, with straightforward color palettes. Those days are gone, but you can always make your game run in a, say, 800x600 window and know it will have ample room on even the smallest display. 32-bit color is also the norm — another reason to breathe more easily.
And then you start looking at mobile devices and it's 1982 all over again.
The situation with software isn't much better. Sure, all the important libraries, such as SDL and OpenAL, run everywhere. But horror stories abound with regard to OpenGL compatibility, or trying to make one source tree build across various platforms. Especially when you can't afford to keep three different operating systems installed at the same time.
No wonder, then, that many developers turn to cross-platform runtimes such as Java. But Java is large, not installed by default (except on Solaris) and many people hate it. You can bundle it with your game, but that's non-trivial, overkill for all but the largest titles, and pretty much misses the point. Python may be a better solution, as it's installed by default on any OS but Windows (always the odd one out), and easy to bundle there. But Python's performance, while better than most people think, is still that of a dynamic, interpreted language.
Then there's the Web browser. Unlike any other, this one is a truly ubiquitous runtime. It's also easy to start with, enormously powerful, and very very convenient. But compatibility, while — again — better than most people think, still suffers from the "one thousand cuts" syndrome, and browsers have hideous resource consumption.
Honestly, I'm increasingly tempted to just make games for Linux and let other people port them if they feel like it. Years ago, that would have been a ticket to obscurity, but now Linux is a mainstream platform, no matter what trolls will tell you. Except there's a better solution.
See, technology's big open secret is that progress seldom actually causes obsolescence. Film didn't relegate theatre to history books any more than audio books relegated print to museums. You'd think computer games are special, but people do want to preserve them, either for academic or nostalgic reasons. And because old hardware is no longer made and prone to breaking down eventually, there is a thriving emulation culture. From ancient operating systems through virtual machines that never existed as hardware to actual obsolete computers, all kinds of old platforms are being preserved as software. And since, like Latin, they no longer evolve, compatibility across implementations is guaranteed to beat that of any other kind of runtime.
For now, emulators have mostly been used for making old games available to new audiences. But there's no reason not to also use them to host new games. After all, if your game concept would fit the NES, why make it for the Wii? Just so Nintendo can sell even more hardware? It's not like they're paying you royalties on that. Plus, those 8- and 16-bit machines had personality. It's not the same if you paint with watercolor on paper or oil on canvas; why would you treat computer platforms as interchangeable?
Surely enough, new games for retro platforms are still being made, even commercially. And while a ZX Spectrum game probably looks too primitive to make a profit nowadays, there are more powerful retro platforms out there that are suitable for artistic games at the very least. For bonus points, you can even offer them for online play, except without the usual headaches.
Is this a solution for everyone? Definitely not. But I think it's crazy enough to work for at least certain purposes. At the very least, it's worth learning how they used to do things 20-30 years ago, when one couldn't just throw arbitrary CPU and RAM at the problem.
As for how to make a game portable across modern platforms, stay tuned. I have a few ideas about that as well.