Interesting take. I wonder if the amount of platform dependent bugs is generally that low for games. I’m a developer, but not a game developer. I would assume that platform dependent stuff comes into play a lot more, when using shiny new tech like direct storage, which is probably used more by AAA titles and less by indie games?
In my somewhat limited but relevant experience, the amount of platform specific bugs is indeed that low. I mean, there’s of course a layer of platform-specific low level stuff which is highly subject to platform specific issues, but once you go above that layer and into game code proper, most bugs are just bugs.
I didn’t fix 400 “Linux-only” bugs, but I did fix dozens of “seems Linux specific” and “only happened when at least one Linux client was connected” bugs, and a grand total of 2 were caused by platform differences. And of those two, zero were Linux specific. The platform difference in this case was about how different compilers optimise non-crashy types of UB.
Of course, we don’t want UB at all so the fix is to remove it.
I have dabbled in basic GPU programming. I think Linux’s GPU wrappers are definitely less user-friendly than Windows’. There’s a reason why most games on Linux are Windows games with wrappers.
That’s not entirely Linux’s fault; a lot of it is manufacturers having their own libraries and tools for things that are done though generic and stable APIs on Windows. There’s also the shitty drivers Nvidia barfs out all over your Linux distro, that doesn’t help much. Debugging a proprietary game is one thing, but playing a game of “game bug, nvidia bug, or Linux bug” is more annoying. Proprietary vendors just don’t seem to test their software very well on desktop Linux.
The difference is money. Vulkan is an incredibly terse spec compared to dx12. You’d think that would make it much more consistent to work with, but really, it’s all it can do to keep up with msft and IHVs who pour money into coaxing AAA devs to use dx12. Then, even when the app gets something wrong and causes issues for end users, the IHV just makes a special case in the driver to correct it, because having a big important dx12 title run correctly on their hw is important to sell units.
Meanwhile, the same IHVs barely bother to support anything beyond the basic vulkan requirements, because it doesn’t gain them anything to do more. If a vulkan game experiences issues, IHVs don’t care because it won’t sell well anyway.
That’s true, and I can hardly blame the Linux developers for this problem. It’s just an unfortunate result of the fact most software is written for profit, including most Linux code. GPU vendors support Linux either because if data center support cases or because they sell devices (like the Steam Deck) and make them money.
Microsoft, making their own money, can clean up after these manufacturers where necessary, or at least clean up much better than volunteers can. It’s not like Linux gamers make or break a product launch, they barely make up more than a few percent on the global gaming market.
With the performance of modern Windows executable wrappers, the lack of native Linux support isn’t even a problem. Some games run faster on DXVK than on Windows, amazingly. Linux may not have vendors hot patching badly programmed games, but Proton does a pretty good job in their place. And honestly, publishing proprietary software of any kind on Linux is a massive pain, because so many parts of the Linux ecosystem assume distro maintainers will pin and compile matching versions of system libraries for you.
I made games primarily for Windows which we also compiled for Linux. It is mostly input/output stuff, aka hardware issues. That is, audio issues, input issues, storage issues, dependency issues. Modern game engine mostly handle the rest. It wasn’t such a big deal to fix, but most gamedev lacked experience with Linux, and most projects are already over budget and late, so fixing Linux for an extra 2-5% of sales didn’t make much sense at small scale. Proton kind off fixed all of this tho.
If you’re an engine developer, it’s a reasonably common problem.
If you’re a game developer using a cross platform engine, it’s pretty uncommon, as the engine developer has already accounted for most of it.
If you’re somewhere in the middle, it’s probably somewhere in the middle.
It surprises me how many indie devs avoid some of the higher level / more popular engines for this reason alone. But I assume they just must enjoy that sort of stuff much more than I.
It surprises me how many indie devs avoid some of the higher level / more popular engines for this reason alone. But I assume they just must enjoy that sort of stuff much more than I.
The problem with indie devs is purely a lack of knowledge and resources. They don’t feel comfortable testing and packaging binaries for distribution on Linux. A decent number of them are also self-taught and actually have almost no exposure to desktop Linux at all. So it’s actually a much higher hurdle than you think.
Interesting take. I wonder if the amount of platform dependent bugs is generally that low for games. I’m a developer, but not a game developer. I would assume that platform dependent stuff comes into play a lot more, when using shiny new tech like direct storage, which is probably used more by AAA titles and less by indie games?
You don’t get many platform-specific bugs if you use cross-platform libraries like SDL2 for OpenGL/Vulkan context creation and human interface.
With my limited experience with Vulkan and multiple targeted platforms, I can confirm that AAAAAAAAAAAAAAAAAAAAAA
In my somewhat limited but relevant experience, the amount of platform specific bugs is indeed that low. I mean, there’s of course a layer of platform-specific low level stuff which is highly subject to platform specific issues, but once you go above that layer and into game code proper, most bugs are just bugs.
I didn’t fix 400 “Linux-only” bugs, but I did fix dozens of “seems Linux specific” and “only happened when at least one Linux client was connected” bugs, and a grand total of 2 were caused by platform differences. And of those two, zero were Linux specific. The platform difference in this case was about how different compilers optimise non-crashy types of UB.
Of course, we don’t want UB at all so the fix is to remove it.
I have dabbled in basic GPU programming. I think Linux’s GPU wrappers are definitely less user-friendly than Windows’. There’s a reason why most games on Linux are Windows games with wrappers.
That’s not entirely Linux’s fault; a lot of it is manufacturers having their own libraries and tools for things that are done though generic and stable APIs on Windows. There’s also the shitty drivers Nvidia barfs out all over your Linux distro, that doesn’t help much. Debugging a proprietary game is one thing, but playing a game of “game bug, nvidia bug, or Linux bug” is more annoying. Proprietary vendors just don’t seem to test their software very well on desktop Linux.
The difference is money. Vulkan is an incredibly terse spec compared to dx12. You’d think that would make it much more consistent to work with, but really, it’s all it can do to keep up with msft and IHVs who pour money into coaxing AAA devs to use dx12. Then, even when the app gets something wrong and causes issues for end users, the IHV just makes a special case in the driver to correct it, because having a big important dx12 title run correctly on their hw is important to sell units.
Meanwhile, the same IHVs barely bother to support anything beyond the basic vulkan requirements, because it doesn’t gain them anything to do more. If a vulkan game experiences issues, IHVs don’t care because it won’t sell well anyway.
That’s true, and I can hardly blame the Linux developers for this problem. It’s just an unfortunate result of the fact most software is written for profit, including most Linux code. GPU vendors support Linux either because if data center support cases or because they sell devices (like the Steam Deck) and make them money.
Microsoft, making their own money, can clean up after these manufacturers where necessary, or at least clean up much better than volunteers can. It’s not like Linux gamers make or break a product launch, they barely make up more than a few percent on the global gaming market.
With the performance of modern Windows executable wrappers, the lack of native Linux support isn’t even a problem. Some games run faster on DXVK than on Windows, amazingly. Linux may not have vendors hot patching badly programmed games, but Proton does a pretty good job in their place. And honestly, publishing proprietary software of any kind on Linux is a massive pain, because so many parts of the Linux ecosystem assume distro maintainers will pin and compile matching versions of system libraries for you.
I made games primarily for Windows which we also compiled for Linux. It is mostly input/output stuff, aka hardware issues. That is, audio issues, input issues, storage issues, dependency issues. Modern game engine mostly handle the rest. It wasn’t such a big deal to fix, but most gamedev lacked experience with Linux, and most projects are already over budget and late, so fixing Linux for an extra 2-5% of sales didn’t make much sense at small scale. Proton kind off fixed all of this tho.
This game runs on the Godot engine, so it has a common base to work with.
If you’re an engine developer, it’s a reasonably common problem.
If you’re a game developer using a cross platform engine, it’s pretty uncommon, as the engine developer has already accounted for most of it.
If you’re somewhere in the middle, it’s probably somewhere in the middle.
It surprises me how many indie devs avoid some of the higher level / more popular engines for this reason alone. But I assume they just must enjoy that sort of stuff much more than I.
The problem with indie devs is purely a lack of knowledge and resources. They don’t feel comfortable testing and packaging binaries for distribution on Linux. A decent number of them are also self-taught and actually have almost no exposure to desktop Linux at all. So it’s actually a much higher hurdle than you think.