If an engine supports Windows, OS X, and Linux, why do we sometimes see games using these engines, like Space Hulk: Deathwing, restricted to Windows only?
- Game made platform specifically: When some developers are making their games, they can sometime rely on platform specific functions. While the game engine might be able to build the game for multiple platforms, the non-game specific code might make a Windows specific call that either doesn't exist on other platforms or would require remaking a difficult part of the game (Licensing services, File Saving systems, etc.).
- Lack of Capable Machines: For a long time, most Apple computers did not come with enough graphics power to run most games. So why release somewhere where the users will most likely only have a bad experience? This is slowly changing, thanks to better integrated graphics, but might still be a reason why some go Windows only.
- Plugin/Library compatibility: Game developers might use 3rd party libraries to help speed up development or use industry standard/validated code (SSL, Serialisation libraries, etc). If these don't support platform X, the game most likely won't run reliably on it, so they get excluded.
- Increased QA: During game development, there is a small subsection of the team that ensures that there are no bugs and that the game meets performance standards. Once you add a platform, the game must essentially be tested twice! The generic parts of the game could be left alone, but there is still much more testing to do before release. This can also lead to increased cost, not only with the additional time needed but also specialised hardware, depending on the platform (Apple, Xbox, PlayStation, Phones, etc.).
- Increased Support: As games release they will have bugs (some games more than others). As you add more platforms, the amount of post-release support the developer has to do increases. Platform-specific bugs will have to be fixed in a way that fixes it for the broken platform and doesn't affect the platforms which are not affected. If a platform changes, say, Windows 7 to 8 or an OSX iteration, there will have to be some level of QA to ensure that there are no bugs on the newer version. And, if there are, that is yet another platform that must be supported alongside the older version. This can have a huge affect on cost, especially after the game has launched (were the game to not make a lot of money), 3-6 months after release.
- Publisher Agreement: Some developers will have agreements with the platform holder to release specifically on their platform. While this happens more with consoles, this could also be the case for PC platforms (e.g., Windows).
- First party Developer: Some developers are owned by the platform holder and are not allowed to release their games on specific platforms. You likely won't see Halo on PS4 or Forza on Mac.
- Lack of an audience: Developers have lots of statistics about consumer trends on specific platforms, especially if they have large publishers with lots of data available. If they have information that says that 90% of their target audience is on Windows, they might not bother to release on other platforms to try and reduce potential bugs or/and keep the marketing material focussed.
- Does not meet Platform Requirements: Some platforms such as Apple's App Store have strict requirements on layout and design that need to be followed in order to be published. If a game doesn't meet these requirements for a particular distribution platform, it might not be worth the engineering time to adapt the game and release it if there are not enough predicted sales.
- Lack of experience with a platform: If the developer has solely worked with Windows (and there are no/few people with experience of other systems), it might be a lot of work to learn the small differences that can cause issues late in development or there might not be enough budget to hire new staff to be in charge of a Linux/OSX build.
- Marketing Cost: if two platforms have significantly different audiences or age groups the marketing material for one may not reach the other meaning that more money must be spent on marketing. If the two groups require different marketing it must all be re-created with the new target audience in mind. Marketing can get extremely expensive especially with big releases, the more platforms need marketing the faster the cost increases.
I'm sure there are more. These are just some of the top of my head. Hope this helps.
Because being available doesn't mean being free & instant.
Supporting one more operating system, in its most simplistic form, means one more platform to provide technical support for.
The more platforms you support = The more platforms you need to provide support for = Spending more time on support = Losing work time that could have spent improving your game.
Supporting a platform all comes down to the confidence in which if your game can draw enough playerbase in that target platform, so it makes up for the time you spend providing support for the platform.
There are good answers so far, but let's get to the bottom line.
According to Steam's June 2017 Hardware survey, 96.24% of users sampled used Windows. Of Windows users, 87.37% are either Windows 10 or 7, 64 or 32 bit. OSX variants represent 2.95% of users, and Linux variants total 0.72%.
Time is money. Unless your market is niche and targets OSX or Linux specifically, you'd have to sell a lot of games before <4% of the market is worth your time, especially as games developers are usually stretched for time to make their product feature complete.
The other answers here are good, but here is one that wasn't mentioned.
I'm having this problem right now - my team is about to release a game made in Unity for Windows/Mac. We've gotten lots of questions as to why our game isn't on mobile. There are 2 main answers:
1) Phones simply aren't powerful enough to keep up with the game. Maybe we can reduce the fidelity of the art (fewer polygons in models, fewer pixels in textures, etc), but that only goes so far. Most of the game would need to be rewritten in order to be optimized enough for a phone to run it. We did try it, but we only got about 0.5 frames per second. Obviously, not playable.
2) Input. The entire user interface was designed around using a mouse, and part of the game depends on knowing where the mouse is at any given time. Our entire input mechanism would have to be rewritten in order for the game to still work without knowing where the mouse is, and translating various "touch" actions on the screen into "mouse" actions to get the same functionality. Like user3797758 mentioned in their answer, this will require stuff to be rewritten so that "mouse" and "touch" inputs can be fed into the same system, and a bug in one won't affect the other, and a fix of that bug also won't affect the other. This requires more resources to do than my team has available at the moment.
Also mentioned in user3797758's answer, we don't even have Linux support because one of our packages crashes on Linux machines, but works on Windows/Mac. Just because the engine is cross platform doesn't mean everything using it is.