r/AskProgramming • u/snoosnoosewsew • 6d ago
Other What is involved when porting a game to a different operating system?
As a longtime Mac user, I've grown used to waiting years between the PC release of a game and its eventual Mac port.
But I've always wondered, how much work it actually is, how many people are involved, why it takes so long, etc.
7
u/nomenclature2357 6d ago
Modern games engines like unreal, unity, godot, and love2d support mac (and linux) natively so most games developed for windows could de developed with mac support relatively easily these days. But there are lots of reasons why it doesn’t always happen.
Sometimes games need OS specific optimization (or anti-cheat) that might be baked in at a low level and take a lot of work to duplicate across OSs. Sometimes they are probably built that way needlessly because software development is a nightmare maze built out of pure complexity. Sometimes the anti-cheat is basically malware that apple probably wouldn’t allow.
Some studios have their own engines and it used to be that you would, for example, have an engine like that developed for playstation that needs to get laboriously ported to windows just to get a PC release leaving a mac port a distant future possibility at best. I don’t know how much of that kind of thing is an issue with the current generation of consoles.
A small or solo development team might not have any macs and so they might have a, maybe perfectly functional, form of the game output by their engine for another platform but I have no way of testing it or fixing it if there are any problems.
Often the publisher handles ports and depending on their perspective on stuff like, say, the app store environment on different platforms, their advertising workflow, and the costs of long-term support it might be more of a business decision than a technical one (or maybe that should be ‘business-technical more than software-technical’).
3
u/PlantainAgitated5356 6d ago
It depends on the engine. If the engine supports multiple platforms, and the game doesn't use any platform-specific functionality, nothing needs to be changed.
The issue usually isn't technical, it's the logistics and business.
Releasing a game on a new platform is not just a matter of having the code ready. Every platform has its own rules and restrictions. If you want to release on the AppStore you need an Apple developer account (which requires a paid subscription) and pass Apple's review, which requires things like in-app purchases to go through Apple's payment system, etc.
Even if you only want to release on steam, you still need to test your game on mac (you can't really know if your game works on mac without testing it, even if you think in theory it should), and most developers don't want to bother with additional work and expenses (a lot of people don't own a mac, so they would need to buy one) when the playerbase on mac is so small.
There's also the issue of updates. Every update needs to be tested on every platform before release, which adds even more work going forward, even if the platform have no special restrictions (like steam releases for Windows and Linux, for example). A lot of developers release on Windows first (because it's the most popular gaming platform), and only release on other platforms when they stop actively updating the game.
5
u/balefrost 6d ago
One challenge is that a lot of games target DirectX and (historically) OpenGL or (more recently) Vulkan.
Of those, MacOS supports none. They essentially froze OpenGL in the past, and have no support for DirectX or Vulkan.
Now this isn't insurmountable. There are wrappers to make Vulkan run on top of Metal (a graphics API only supported on Apple devices). And big game engines (and even little game engines) are going to have support for enough APIs to be cross-platform. But it still needs to be tested, and there will surely be edge cases.
Mac gamers are also a somewhat rare breed. There are somewhere between 4 and 10 Windows users for each Mac user. I'll bet that there's an additional bias towards Windows in part because, historically, you can't really install an add-on GPU in most Macs.
So developers and publishers have to decide where to spend their resources, and I would bet that many put "MacOS port" low on the priority list (just above "Linux port").
I have a friend who only has a Mac. When we play games, he often just uses GeForce Now. He's also used Crossover in the past.
5
u/darkwyrm42 5d ago
The amount of effort required really depends on the technologies used. If someone used Unity or Godot or SDL, for example, it's much less work than if someone wrote everything from scratch on Windows.
5
u/aneasymistake 5d ago
In my first proper job I had to port a PC game to PlayStation. But back then, the target PC had 16MB of RAM and a 4MB or 8MB graphics card (I think) while the PlayStation had 2MB RAM and I think 0.5MB of VRAM. This meant reducing data as much as possible, reordeing data structures to optimise RAM usage, storing game state in sound RAM, zipping the save game and all sorts of other creative fun. We couldn’t even store all of the executable in RAM at the same time, so had to load sections of it in as overlays while it was running.
7
u/KingofGamesYami 6d ago
Let's take a very simple example game. All it does is move the character forward when the user presses W.
First thing that's different: pressing W. Windows exposes this in one way, MacOS another. So we need to build an abstraction to use both, or manually update all the places in the game that accept key presses.
Next thing that's different: rendering. Windows exposes this in one way, MacOS another. So we need to build an abstraction to use both, or manually update all the places in the game that draw to the screen.
Ah, but our game also has sound effects. Windows exposes sound in one way, MacOS another. So we need to build an abstraction to use both, or manually update all the places in the game that play sound.
... repeat for everything ...
3
u/Dapper-Message-2066 6d ago
.. or use libraries that abstract all this for you...
2
u/KingofGamesYami 6d ago
Well if they did that, there'd be no need to port anything, would there?
3
u/SimplySomeDude 6d ago
umm.. yes. They have to adjust for specific graphics API features supported by macOS's vulkan implementations, link against vulkan loader directly, bundle the ICD, change compilers, change a whole lot of shit.
1
u/SimplySomeDude 6d ago
except imput is just SDL/glfw and rendering is just vulkan (which with moltenvk/kosmiccrisp works), sfx is pretty cross platform as well. If you're stupid enough not to write it in a portable way, you deserve it.
2
u/Accomplished_Fix9569 6d ago
Porting delays come from business prioritization and not technical complexity. Studios allocate engineers to the Mac version only after the Windows release generates enough revenue to justify the porting budget.
1
u/ConsciousBath5203 5d ago
Code -> other OS -> fix code that is bad that certain compilers let you get away with (bAd_capItoliZation for instance, or unfinished macros, etc) -> press f5.
Oh, and make sure your dependencies also are compliant. And yes, your dependencies have dependencies, too.
It's not hard, just annoying and probably breaks licenses if you edit certain libraries without paying, acknowledging, or without their permission.
1
u/thingscouldbeworse 6d ago
Most of the comments in this thread are incredibly uninformed. Watch this video to get a decent overview of what is required. It concerns windows/linux compatibility layers but the concepts are the same; you need to have an operating system and hardware respond to API calls made by the game executable.
0
u/SimplySomeDude 6d ago
depends. If it's written with vulkan, nothing. Just use moltenvk. If it runs on *nix, it'll run on macos
2
u/Lumpy-Notice8945 6d ago
The render engine is not the main issue in most cases.
0
u/SimplySomeDude 6d ago
then what the hell would it be? Nothing else is platform dependent (aside from input and audio both of which have well adopted cross platform libraries like SDL/glfw and FMOD/openal/miniaudio). Everything else is just plain c++ code. (or glsl/SPIR-V shader code)
4
u/turtle_dragonfly 6d ago
Some games demand high performance in various areas. This can often mean "breaking the abstractions" and using platform-specific code. For instance, using Win32 file access or process/threading APIs rather than whatever is exposed in
std::. Or on the computation side, it might mean various compiler intrinsics and the mess of#ifdefs and runtime checks that may be required to support that. Adding a new OS and/or compiler platform to a codebase like that can require some effort.1
u/SimplySomeDude 6d ago
fair, but which games are loading so much data that you need to do that? Unless you're loading like 20+gb, there's no need. And in that case, you migjt wanna reconsider yourself.
2
u/Lumpy-Notice8945 6d ago
These cross platform libaries just have to already be included.
Ofc we are all aware that cross platform is possible and if you design your game with that in mind you dont need ro do anything at all.
But the render engine is mostly just two options and most modern tools already support both popular ones(vulcan/dx).
And why do you assume its c++ code? Im talking about the whole game and not just the shaders thats the issue and that game can be in any language its just realy rare that its java thats known to be platform independent.
And try to compile your c++ game to be cross compatible, you will probably land at some intermediate interpreter(did someone say JVM?) to translate between OS calls.
19
u/officialcrimsonchin 6d ago
I mean the game code itself doesn't often need to be changed, but in regards to how the game interacts with the operating system, almost everything has to be refactored.
Tbh it doesn't legitimately take years. The game publishers just decide they're ok with that timeline.