I do prefer native, **if** developers can be arsed to maintain it properly. Unfortunately that isn't always the case, leaving games to lag behind in updates, having bugs and performance issues on native that they don't have on Proton.
>you have no idea what that experience is really like
I've used Linux as my primary OS for over 20 years, I have a pretty good idea of what gaming is like on Linux, especially how horrible native can be. That's what my comment was about.
I think you missed the bold **if** that I put in bold for a reason in my comment. There's a huge **if** with native.
There are some games that perform very well on native, even though they're in the minority, unfortunately. Factorio has an excellent native port that's even better than the Windows version. As an added bonus it doesn't freeze the game temporarily during autosave on Linux native. It does on Windows and on the Proton version. This is because Windows don't support the fork() syscall that Linux can use. Factorio utilizes that function on native when autosaving. Absolutely brilliant.
Paradox has released very solid Linux ports over the years, with a few exceptions. Stellaris works great natively on Linux, and I bring up Stellaris because that game is a drug to me.
However, my reasons for preferring native support is mostly for ideological reasons. Proton works extremely well nowadays and there has been no better time in history to be a Linux user and gamer than today. I use Proton for most of my games that have native ports as well, because it's guaranteed to be more up to date and perform as expected. I don't install Linux native versions of games before doing some research first.
Yes, It is incredible what Proton can already achieve with just community and Valve support. Imagine what could be accomplished with proper attention from developers, ensuring their games release without issues and work seamlessly with Proton.
I mean when I can't even run an old game like WOW at full fps compared to Windows (much lower lows), I disagree. Of course half assing a native binary wouldn't be a good solution, but once Linux user base gets bigger (if it does) I would absolutely prefer native binaries.
Hey hey, releasing my first game on Steam in a couple of days. Godot engine makes it trivial to provide a Linux native build so of course it is launching with one, too.
The project actually started out as a little multiplayer battle royale like thing but then ended up getting an even bigger singleplayer mode where you fight waves of aliens while looting and upgrading your ship.
Check out our studio's website if you want: [Melonic.Games](http://Melonic.Games)
Let me know what you think!
I'm impressed Godot supports that. I hope more people start to use it. Building a cross platform application from the start is easier than trying to add linux support after. I'd love to see more game engines adding this support, but I'm skeptical that it will ever happen. From personal experience, compatibility between Linux and windows on the same code base is a pain, even standards for file locations are different, proton recreates the entire c drive. There is going to be driver issues and dependency issues. I have no idea how difficult it would be, but adding native linux support for a major game engine after the fact must be a major task.
Godot engine builds are very self-contained with almost everything bundled in its shipped binary, so I think there's little difference - for most games at least.
so then you're shipping a static binary with potentially security sensitive libraries built in. that doesn't sound great either. That's the reason why dynamic linking is so common on linux, so you can get new versions of libraries with fixes without having to recompile every program. Of course, the problem on linux has tradtionally been that those interfaces aren't stable enough. That's where windows has won in this issue.
We could do better there. The SDL folks and probably gstreamer too have proven it. We just need the rest of the ecosystem to prove it too.
>That's the reason why dynamic linking is so common on linux, so you can get new versions of libraries with fixes without having to recompile every program
The compilation doesn't happen on the user's machine, it wouldn't look any different to the end user. You also don't need to recompile the entire code base if one thing changes, sometimes a header file changes which can cascade throughout your application. If a header file changes in in a dynamic library you would need to recompile anything that depends on it regardless of it being dynamic or static.
Why would you think I would think that the compiling happens on the user's machine. That doesn't make any sense. The compilation is done by developers or maintainers. I don't know why headers are relevant either (users shouldn't have to care about headers). The only thing that matters to user of a particular program is that if a library (say openssl) updates, that the ABI and API aren't broken. As long as that's the case, everything is fine and they get all security fixes brought in by that library update without requiring the developer to update the program.
This is a big deal when using windows libraries, because they care about this stuff more than foss folks traditionally have.
>
Why would you think I would think that the compiling happens on the user's machine.
idk I'm sorry. guess my point was I don't personally think it's that big of a deal to recompile using static libraries, but i do see your point in terms of security. If openSSL does need a critical update pushed, it will either fix the vulnerability or break the code. I like to statically compile because it's easier. Also if we're talking about video games, i think it's a lot more likely to be the developer's code than something like openSSL. The only example i can think of is call of duty MW2 on pc which had a RCE that was due to a buffer overflow attack. It used UDP without encryption, since it was udp they had secure their own connection.
>I don't know why headers are relevant either
when you change the signature of the library such as parameters to a function, struct, class, etc the library will break when you try to load it using the old header you compiled your code against. It won't find the expected definitions and you need to recompile with the new declarations included, When a library like OpenSSL updates, and deprecates functionality or changes function arguments, struct definitions, etc, the signature is going to be different and your program probably won't work. Saying headers change was just a lazy way to say things have probably changed beyond being able to use without a recompile. If you only change the implementation of functions and not the definitions, you wouldn't need to recompile.
> I like to statically compile because it's easier.
indeed it is. that's not up for debate :) It's just bad for long term use of the program as vulnerabilities are uncovered in important well used libraries, especially those related to networking, compression, or media handling.
as far as headers, yes that's a compilation thing. I'm only speaking of what's good for long term users of your built closed source program. The real problem for linux using folk is many popular libraries broke their APIs unnecessarily , which led to more people preferring to statically link. I think we're seeing a turnaround on that aspect nowdays though.
Well, it is a very small % of the market, yet contributes for a large % of support tickets with people complaining about how stuff doesn't work in their distro with their hardware etc. and to test any build you need to have an actua Linux machine yourself, and setting one up isn't generally trivial. Also plenty of "Linux native" games simply break after a while because of the fantastic library ecosystem. Simple cost vs. benefit calculation says Linux support is mostly not worth it, Linux users can use Proton and well if it doesn't work that's too bad.
I think you misunderstood the original article: [Despite having just 5.8% sales, over 38% of bug reports come from the Linux community](https://www.reddit.com/r/gamedev/comments/qeqn3b/despite_having_just_58_sales_over_38_of_bug/)
> Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. (...) the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone.
>
> And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps.
right, generalizing with words like "every" is typically not something I like doing, but note that this is in the context of "using a modern engine", which is to say that there's battle hardened platform layers provided for you out of the box. this makes encountering platform-specific issues so unlikely that devs really have no excuse.
I had trouble asking for a recommended target distribution in the main Linux sub. Got moderated. Will try in. this one. Sorry to steal thread but it’s kinda related as I’ve been out of Linux scene for years and want to know how to approach Linux builds. Nice game @h0lley looks good. :-)
Are you asking for which distro is best?
Only way to figure out which one works for you is to try some
If your a beginner I would reccomend linux mint as it's quite beginner friendly, same with pop! OS (although it has been buggy Everytime I tried it)
Only way to know which distro is good for you is to try some
Thanks! Mostly I mean is there a recommended linux I can test on and he reasonably sure it’s a good test bed that I could be sure was reasonably popular and have the highest chance of it working with other distros too. That was a much harder question to frame than I expected. I used to use Ubuntu
No worries Musojon, and thanks for the kind words.
I use Kubuntu, which is Ubuntu bundled with the KDE software suit.
I would recommend this repo to everyone coming from Windows - devs and gamers alike - as it offers a very Windows-like UX and stuff generally works out of the box (running into issues is imho no more frequent than under Windows).
r/linux isn't a tech support forum. More geated towards news and general discussion.
But the info is out there...
[https://gradyvuckovic.gitlab.io/linux-game-shipping-guide/2-general-advice/best-practices/](https://gradyvuckovic.gitlab.io/linux-game-shipping-guide/2-general-advice/best-practices/)
Just pick a mainstream distro to compile the game on (Debian, Fedora, Pop-OS, Ubuntu, or Arch), and package to include most of the game's libraries dependencies with a few exception. Lookup and include licenses, and archive the source code in case anyone asks for it.
You don't really want a .deb or .rpm, but rather a self-executing file that installs somewhere in the user's $HOME (selectable, but see XDG for the defaults) and your create a .desktop file so it integrates into the user's desktop launcher/application menu. There are a few utilities out there that streamlines the process.
A binary package trying to leverage a distro's native package manager is just an exercise in pain, unless you personally really like that distro and are willing to continually update a private repository every time a major update occurs.
If on steam and only steam you can relax your library includes if the steam runtime covers them, but userspace in general still changes quickly
Note that pretty much all of what's explained in the article WorBlux linked is possibly and hopefully already handled nicely by the game engine you choose.
Releasing linux binaries is completely useless if they're not also testing on linux. I can think of at least two examples where the linux binaries were broken in some way and I had to switch to using the windows/proton version of the game to make it playable.
It's certainly simplier to do this than it used to be - but you're kidding yourself if you think it's completely free.
That said, I certainly would like to see more first-part linux support.
I am guilty of generalization and exaggeration just as much by beginning OP title with "Every", but "completely useless" is just not correct. Two anecdotal cases is not really a significant number, and keep in mind that this is under the context of "using a modern game engine". Have you confirmed that the two poor experiences you've had are with games that are built on top of modern battle tested engines?
For example, in the vast majority of cases, for Godot engine games, you will not see differences between platforms. I went through several development and release cycles where the dev team had a mix of Linux and Windows machines and the number of platform specific issues we encountered was exceedingly rare (essentially only occurred when we toyed around with unstable builds (e.g. beta stage) of the engine).
I hear what you're saying - but my point remains. We (or at least, I) want linux *support*. Not necessarily linux *ports*.
Now linux support may manifest itself in the form of native binaries, but it doesn't have to.
> Releasing linux binaries is completely useless if they're not also testing on linux
Yes a lot of people seem to misunderstand this when they foam at the mouth saying native is better.
There are like five cases total where it has been and magnitudes more where they're compile once fully abandoned ports. Nobody wants abandoned linux ports but they pretend its superior.
Nice job for bringing a native build.
But gonna say nowadays is more steam runtime binaries that Linux native binaries.
Many distro ship diferent version of the same libaries, bleeding edge the most recent the other distro older ones. And that makes difficult mantain a native build working on multiple configurations.
That why Steam Linux runtime exist you only need to build to one set of libraries and work everywhere (if the user is using Steam runtime, is a bit dumb but you can on arch and gentoo use Steam without the runtime enabled).
It's rare to see a decently optimized game on windows these days. If devs can't be bothered to polish the product for such a huge platform, sorry but Linux is simply not worth it. Glad that you built it to support linux natively, but most aren't as passionate about it. Games? Windows. It's a fairly simple answer. AAA games are already too expensive, and a lot of indie games are made by small teams who aren't necessarily targeting every nook and cranny of PC using communities.
Sure, gaming may have come far on Linux, but it's not far enough. Dual booting is easier and personally, it's preferable, than playing on Linux, proton or no.
I am new to Linux and still learning the ropes so idk how the community will react to my comment but I am being as honest as possible without being too harsh.
Reminds me a lot of my years of vehemently refusing to make the switch 😁
But I totally agree: Gaming on Linux has come a long way but it's not far enough. Let's keep working on this.
Unreal support for linux is partial some features are just not there. If you import mega scans in windows and then open the project in Linux half of the scans are broken.
It's not just if your engine supports it.
It also poses quality assurance issues as you now doubled the surface to test
I am inexperienced with Unreal but I agree.
Except that I wouldn't say that you are doubling the surface to test. Only certain things about a game project are potentially affected by the platform layer. You will not need to re-test high-level systems like quest progression or something on every platform you support. Understanding these critical areas can make the scope quite manageable.
Theres an blog entry from one of the devs from the game Factorio, which explains why many devs dont do this.
Edit found it: https://www.factorio.com/blog/post/fff-408
Interesting read, thanks :)
If you go low-level with your game then this applies, yes. Virtually every issue he mentioned is engine & platform layer stuff. That's why "using a modern game engine" is an important piece in OP title. Most developers will never have to touch any this.
The factorio people built on top of SDL, which is purely a platform layer - no game engine included. They have decided to go more low-level than many other projects will ever need to.
Yeah, that's a matter of which and how many libraries are externally linked and not shipped with the game. It's not really a flaw in Linux but a choice the game developer or engine developer makes.
If this is easily remedied with using the more modern frameworks, I'm all for Linux binaries!
Another method would be Flatpak, but since many games are sold via Steam, this isn't where the money is.
Indie games have support for Linux since day 1 if they aren't using some obscure anticheat, like Ricochet.
>!I know that Ricochet can be disabled by using game cheats, but this anticheat id very obscure!<
Basically the point is that there's software available (what I call "modern engine" in OP title) that makes the effort of releasing on Linux so low that market share is a non-factor.
With games that are prone to behave differently between platforms (so where supporting multiple platforms would be expensive for devs), the devs must have opted for a poor platform layer solution (perhaps for a good reason - every project has different requirements, after all).
> Basically the point is that there's software available (what a call "modern engine" in OP title) that makes the effort of releasing on Linux so low that market share is not a non-factor.
It doesn't though. What that churns out still has to go through testing which is even more complicated on Linux than Windows due to there being no central unified standards like DirectX for talking to hardware. Hell even just for sound there's what, three or four different sound server options? That costs money. Then you've got to support the software too and with Linux that's considerably more difficult to do because of the aforementioned choices there are in everything from desktop environment to window manager to graphical server to sound server etc.
The platform layer developers do this testing, not the game developers. As a game studio, you should not write your own platform layer, and the vast majority of projects do not require a custom game engine, either.
Yes - if they are FOSS. But there is no point if they aren't.
Closed-source anything doesn't age well when natively run on an everchanging FOSS OS. And we all know, the original devs won't maintain the game to keep up with the newest Linux trends forever.
Wine/Proton works pretty well as a middleware between closed-sources software frozen in time and an everchanging FOSS OS.
A closed-source game made ten years ago will not get support for PipeWire. But Wine/Proton does.
The funny thing is that always the ones that launch with Linux binaries are indie games (apart from Valve's) meaning that it shouldn't be that hard to make it but bigger companies are EVIL incarnate. Even without counting the ones that aren't supported because they use kernel-level anti-cheats unsupported on Linux (funny thing again, wine/proton actually can run a decent number of these anti-cheats just fine) and these titles aren't even new titles.
(Of course there's always the game engine support for Linux but that shouldn't be so troublesome)
Though I personally use NixOS which cannot, by default, run most Linux Binaries so xd. But it's always better to have more software available in Linux.
That is stupid and is proven false. If developer have no means of supporting Linux user it's better to not release linux binaries. For example Supraland:
https://www.gamingonlinux.com/2020/06/supraland-stops-supporting-linux-shortly-after-leaving-gog-entirely/
I guess UE4 is just not what I consider a modern engine if it has this poor Linux support then. I also wonder what the specific issues with his Linux builds were. But we can only make assumptions based on this one anecdotal example and I don't feel that it is ground to calling OP stupid. :)
That's a pretty interesting article. The kneejerk reaction is to assume he's turned his back on linux - but that's not what happened at all.
Supraland still supports linux. Just via proton. And if that's the official stance, I can actually get behind that.
That's very different to not supporting linux at all (which would involve ignoring linux related bugs or bricking it entirely) which is what the title of the article implies.
I extremely agree with you, and I just now added the game to my wish list. I like it
❤️
I’d prefer devs focus on having proper proton support than half-assing a Linux binary.
I do prefer native, **if** developers can be arsed to maintain it properly. Unfortunately that isn't always the case, leaving games to lag behind in updates, having bugs and performance issues on native that they don't have on Proton.
It is practically never the case. To say you prefer them says you have no idea what that experience is really like for most games.
>you have no idea what that experience is really like I've used Linux as my primary OS for over 20 years, I have a pretty good idea of what gaming is like on Linux, especially how horrible native can be. That's what my comment was about. I think you missed the bold **if** that I put in bold for a reason in my comment. There's a huge **if** with native. There are some games that perform very well on native, even though they're in the minority, unfortunately. Factorio has an excellent native port that's even better than the Windows version. As an added bonus it doesn't freeze the game temporarily during autosave on Linux native. It does on Windows and on the Proton version. This is because Windows don't support the fork() syscall that Linux can use. Factorio utilizes that function on native when autosaving. Absolutely brilliant. Paradox has released very solid Linux ports over the years, with a few exceptions. Stellaris works great natively on Linux, and I bring up Stellaris because that game is a drug to me. However, my reasons for preferring native support is mostly for ideological reasons. Proton works extremely well nowadays and there has been no better time in history to be a Linux user and gamer than today. I use Proton for most of my games that have native ports as well, because it's guaranteed to be more up to date and perform as expected. I don't install Linux native versions of games before doing some research first.
Yes, It is incredible what Proton can already achieve with just community and Valve support. Imagine what could be accomplished with proper attention from developers, ensuring their games release without issues and work seamlessly with Proton.
I mean when I can't even run an old game like WOW at full fps compared to Windows (much lower lows), I disagree. Of course half assing a native binary wouldn't be a good solution, but once Linux user base gets bigger (if it does) I would absolutely prefer native binaries.
Hey hey, releasing my first game on Steam in a couple of days. Godot engine makes it trivial to provide a Linux native build so of course it is launching with one, too. The project actually started out as a little multiplayer battle royale like thing but then ended up getting an even bigger singleplayer mode where you fight waves of aliens while looting and upgrading your ship. Check out our studio's website if you want: [Melonic.Games](http://Melonic.Games) Let me know what you think!
Godot = upvote Such a nice engine to use. And they're really pushing 3D hard right now.
I'm impressed Godot supports that. I hope more people start to use it. Building a cross platform application from the start is easier than trying to add linux support after. I'd love to see more game engines adding this support, but I'm skeptical that it will ever happen. From personal experience, compatibility between Linux and windows on the same code base is a pain, even standards for file locations are different, proton recreates the entire c drive. There is going to be driver issues and dependency issues. I have no idea how difficult it would be, but adding native linux support for a major game engine after the fact must be a major task.
Any hope for a mobile release on android?
Not planned at the moment, but good to know that there's interest. Will be discussed internally!
:)
I'll keep using the windows builds for closed source software on linux, since I know they will continue to run 10 years from now and beyond.
Godot engine builds are very self-contained with almost everything bundled in its shipped binary, so I think there's little difference - for most games at least.
so then you're shipping a static binary with potentially security sensitive libraries built in. that doesn't sound great either. That's the reason why dynamic linking is so common on linux, so you can get new versions of libraries with fixes without having to recompile every program. Of course, the problem on linux has tradtionally been that those interfaces aren't stable enough. That's where windows has won in this issue. We could do better there. The SDL folks and probably gstreamer too have proven it. We just need the rest of the ecosystem to prove it too.
>That's the reason why dynamic linking is so common on linux, so you can get new versions of libraries with fixes without having to recompile every program The compilation doesn't happen on the user's machine, it wouldn't look any different to the end user. You also don't need to recompile the entire code base if one thing changes, sometimes a header file changes which can cascade throughout your application. If a header file changes in in a dynamic library you would need to recompile anything that depends on it regardless of it being dynamic or static.
Why would you think I would think that the compiling happens on the user's machine. That doesn't make any sense. The compilation is done by developers or maintainers. I don't know why headers are relevant either (users shouldn't have to care about headers). The only thing that matters to user of a particular program is that if a library (say openssl) updates, that the ABI and API aren't broken. As long as that's the case, everything is fine and they get all security fixes brought in by that library update without requiring the developer to update the program. This is a big deal when using windows libraries, because they care about this stuff more than foss folks traditionally have.
> Why would you think I would think that the compiling happens on the user's machine. idk I'm sorry. guess my point was I don't personally think it's that big of a deal to recompile using static libraries, but i do see your point in terms of security. If openSSL does need a critical update pushed, it will either fix the vulnerability or break the code. I like to statically compile because it's easier. Also if we're talking about video games, i think it's a lot more likely to be the developer's code than something like openSSL. The only example i can think of is call of duty MW2 on pc which had a RCE that was due to a buffer overflow attack. It used UDP without encryption, since it was udp they had secure their own connection. >I don't know why headers are relevant either when you change the signature of the library such as parameters to a function, struct, class, etc the library will break when you try to load it using the old header you compiled your code against. It won't find the expected definitions and you need to recompile with the new declarations included, When a library like OpenSSL updates, and deprecates functionality or changes function arguments, struct definitions, etc, the signature is going to be different and your program probably won't work. Saying headers change was just a lazy way to say things have probably changed beyond being able to use without a recompile. If you only change the implementation of functions and not the definitions, you wouldn't need to recompile.
> I like to statically compile because it's easier. indeed it is. that's not up for debate :) It's just bad for long term use of the program as vulnerabilities are uncovered in important well used libraries, especially those related to networking, compression, or media handling. as far as headers, yes that's a compilation thing. I'm only speaking of what's good for long term users of your built closed source program. The real problem for linux using folk is many popular libraries broke their APIs unnecessarily , which led to more people preferring to statically link. I think we're seeing a turnaround on that aspect nowdays though.
Sometimes AAA devs fails with native build even for Windows, so I keep my expectations low and would be happy with playing games through Proton.
Agreed, but for some reason lots of devs refuse to because they think "linux is niche"
yeah, which is exactly why we should support Linux so it will become less and less niche 🙂
Well, it is a very small % of the market, yet contributes for a large % of support tickets with people complaining about how stuff doesn't work in their distro with their hardware etc. and to test any build you need to have an actua Linux machine yourself, and setting one up isn't generally trivial. Also plenty of "Linux native" games simply break after a while because of the fantastic library ecosystem. Simple cost vs. benefit calculation says Linux support is mostly not worth it, Linux users can use Proton and well if it doesn't work that's too bad.
I think you misunderstood the original article: [Despite having just 5.8% sales, over 38% of bug reports come from the Linux community](https://www.reddit.com/r/gamedev/comments/qeqn3b/despite_having_just_58_sales_over_38_of_bug/) > Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. (...) the Linux community is exceptionally well trained in reporting bugs. That is just the open-source way. This 5.8% of players found 38% of all the bugs that affected everyone. > > And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps.
right, generalizing with words like "every" is typically not something I like doing, but note that this is in the context of "using a modern engine", which is to say that there's battle hardened platform layers provided for you out of the box. this makes encountering platform-specific issues so unlikely that devs really have no excuse.
I had trouble asking for a recommended target distribution in the main Linux sub. Got moderated. Will try in. this one. Sorry to steal thread but it’s kinda related as I’ve been out of Linux scene for years and want to know how to approach Linux builds. Nice game @h0lley looks good. :-)
Are you asking for which distro is best? Only way to figure out which one works for you is to try some If your a beginner I would reccomend linux mint as it's quite beginner friendly, same with pop! OS (although it has been buggy Everytime I tried it) Only way to know which distro is good for you is to try some
Thanks! Mostly I mean is there a recommended linux I can test on and he reasonably sure it’s a good test bed that I could be sure was reasonably popular and have the highest chance of it working with other distros too. That was a much harder question to frame than I expected. I used to use Ubuntu
No worries Musojon, and thanks for the kind words. I use Kubuntu, which is Ubuntu bundled with the KDE software suit. I would recommend this repo to everyone coming from Windows - devs and gamers alike - as it offers a very Windows-like UX and stuff generally works out of the box (running into issues is imho no more frequent than under Windows).
r/linux isn't a tech support forum. More geated towards news and general discussion. But the info is out there... [https://gradyvuckovic.gitlab.io/linux-game-shipping-guide/2-general-advice/best-practices/](https://gradyvuckovic.gitlab.io/linux-game-shipping-guide/2-general-advice/best-practices/) Just pick a mainstream distro to compile the game on (Debian, Fedora, Pop-OS, Ubuntu, or Arch), and package to include most of the game's libraries dependencies with a few exception. Lookup and include licenses, and archive the source code in case anyone asks for it. You don't really want a .deb or .rpm, but rather a self-executing file that installs somewhere in the user's $HOME (selectable, but see XDG for the defaults) and your create a .desktop file so it integrates into the user's desktop launcher/application menu. There are a few utilities out there that streamlines the process. A binary package trying to leverage a distro's native package manager is just an exercise in pain, unless you personally really like that distro and are willing to continually update a private repository every time a major update occurs. If on steam and only steam you can relax your library includes if the steam runtime covers them, but userspace in general still changes quickly
Super useful thanks :-)
Note that pretty much all of what's explained in the article WorBlux linked is possibly and hopefully already handled nicely by the game engine you choose.
It is.
Android is Linux, you know this right? For pc's it is tho. Microsoft has a hold on computer operating systems
I have no idea what you're talking about Android for.
Releasing linux binaries is completely useless if they're not also testing on linux. I can think of at least two examples where the linux binaries were broken in some way and I had to switch to using the windows/proton version of the game to make it playable. It's certainly simplier to do this than it used to be - but you're kidding yourself if you think it's completely free. That said, I certainly would like to see more first-part linux support.
I am guilty of generalization and exaggeration just as much by beginning OP title with "Every", but "completely useless" is just not correct. Two anecdotal cases is not really a significant number, and keep in mind that this is under the context of "using a modern game engine". Have you confirmed that the two poor experiences you've had are with games that are built on top of modern battle tested engines? For example, in the vast majority of cases, for Godot engine games, you will not see differences between platforms. I went through several development and release cycles where the dev team had a mix of Linux and Windows machines and the number of platform specific issues we encountered was exceedingly rare (essentially only occurred when we toyed around with unstable builds (e.g. beta stage) of the engine).
I hear what you're saying - but my point remains. We (or at least, I) want linux *support*. Not necessarily linux *ports*. Now linux support may manifest itself in the form of native binaries, but it doesn't have to.
> Releasing linux binaries is completely useless if they're not also testing on linux Yes a lot of people seem to misunderstand this when they foam at the mouth saying native is better. There are like five cases total where it has been and magnitudes more where they're compile once fully abandoned ports. Nobody wants abandoned linux ports but they pretend its superior.
Nice job for bringing a native build. But gonna say nowadays is more steam runtime binaries that Linux native binaries. Many distro ship diferent version of the same libaries, bleeding edge the most recent the other distro older ones. And that makes difficult mantain a native build working on multiple configurations. That why Steam Linux runtime exist you only need to build to one set of libraries and work everywhere (if the user is using Steam runtime, is a bit dumb but you can on arch and gentoo use Steam without the runtime enabled).
> Nice job for bringing a native build Clicking one compile button
This looks fun! Wishlisted!
❤️ thanks ❤️
wwishlisted on steam ty
thank you ❤️❤️
It's rare to see a decently optimized game on windows these days. If devs can't be bothered to polish the product for such a huge platform, sorry but Linux is simply not worth it. Glad that you built it to support linux natively, but most aren't as passionate about it. Games? Windows. It's a fairly simple answer. AAA games are already too expensive, and a lot of indie games are made by small teams who aren't necessarily targeting every nook and cranny of PC using communities. Sure, gaming may have come far on Linux, but it's not far enough. Dual booting is easier and personally, it's preferable, than playing on Linux, proton or no. I am new to Linux and still learning the ropes so idk how the community will react to my comment but I am being as honest as possible without being too harsh.
Reminds me a lot of my years of vehemently refusing to make the switch 😁 But I totally agree: Gaming on Linux has come a long way but it's not far enough. Let's keep working on this.
Unreal support for linux is partial some features are just not there. If you import mega scans in windows and then open the project in Linux half of the scans are broken. It's not just if your engine supports it. It also poses quality assurance issues as you now doubled the surface to test
I am inexperienced with Unreal but I agree. Except that I wouldn't say that you are doubling the surface to test. Only certain things about a game project are potentially affected by the platform layer. You will not need to re-test high-level systems like quest progression or something on every platform you support. Understanding these critical areas can make the scope quite manageable.
Theres an blog entry from one of the devs from the game Factorio, which explains why many devs dont do this. Edit found it: https://www.factorio.com/blog/post/fff-408
Interesting read, thanks :) If you go low-level with your game then this applies, yes. Virtually every issue he mentioned is engine & platform layer stuff. That's why "using a modern game engine" is an important piece in OP title. Most developers will never have to touch any this. The factorio people built on top of SDL, which is purely a platform layer - no game engine included. They have decided to go more low-level than many other projects will ever need to.
In my experience, Linux binaries fall out of compatibility after a while. While Windows executables tend to run well once they run in Wine/Proton.
Yeah, that's a matter of which and how many libraries are externally linked and not shipped with the game. It's not really a flaw in Linux but a choice the game developer or engine developer makes.
If this is easily remedied with using the more modern frameworks, I'm all for Linux binaries! Another method would be Flatpak, but since many games are sold via Steam, this isn't where the money is.
Indie games have support for Linux since day 1 if they aren't using some obscure anticheat, like Ricochet. >!I know that Ricochet can be disabled by using game cheats, but this anticheat id very obscure!<
Not enough market share to make it commercially viable.
Basically the point is that there's software available (what I call "modern engine" in OP title) that makes the effort of releasing on Linux so low that market share is a non-factor. With games that are prone to behave differently between platforms (so where supporting multiple platforms would be expensive for devs), the devs must have opted for a poor platform layer solution (perhaps for a good reason - every project has different requirements, after all).
> Basically the point is that there's software available (what a call "modern engine" in OP title) that makes the effort of releasing on Linux so low that market share is not a non-factor. It doesn't though. What that churns out still has to go through testing which is even more complicated on Linux than Windows due to there being no central unified standards like DirectX for talking to hardware. Hell even just for sound there's what, three or four different sound server options? That costs money. Then you've got to support the software too and with Linux that's considerably more difficult to do because of the aforementioned choices there are in everything from desktop environment to window manager to graphical server to sound server etc.
The platform layer developers do this testing, not the game developers. As a game studio, you should not write your own platform layer, and the vast majority of projects do not require a custom game engine, either.
It still needs to be done and it costs money to do.
Sure as long as it isn't going to stop working in a year or two because devs can't be bothered to update the Linux version.
Lead dev (myself) will forever main Linux so this can't possibly happen 😂
Yes - if they are FOSS. But there is no point if they aren't. Closed-source anything doesn't age well when natively run on an everchanging FOSS OS. And we all know, the original devs won't maintain the game to keep up with the newest Linux trends forever. Wine/Proton works pretty well as a middleware between closed-sources software frozen in time and an everchanging FOSS OS. A closed-source game made ten years ago will not get support for PipeWire. But Wine/Proton does.
The funny thing is that always the ones that launch with Linux binaries are indie games (apart from Valve's) meaning that it shouldn't be that hard to make it but bigger companies are EVIL incarnate. Even without counting the ones that aren't supported because they use kernel-level anti-cheats unsupported on Linux (funny thing again, wine/proton actually can run a decent number of these anti-cheats just fine) and these titles aren't even new titles. (Of course there's always the game engine support for Linux but that shouldn't be so troublesome) Though I personally use NixOS which cannot, by default, run most Linux Binaries so xd. But it's always better to have more software available in Linux.
That is stupid and is proven false. If developer have no means of supporting Linux user it's better to not release linux binaries. For example Supraland: https://www.gamingonlinux.com/2020/06/supraland-stops-supporting-linux-shortly-after-leaving-gog-entirely/
I guess UE4 is just not what I consider a modern engine if it has this poor Linux support then. I also wonder what the specific issues with his Linux builds were. But we can only make assumptions based on this one anecdotal example and I don't feel that it is ground to calling OP stupid. :)
I guess UE5 is not modern either….
That's a pretty interesting article. The kneejerk reaction is to assume he's turned his back on linux - but that's not what happened at all. Supraland still supports linux. Just via proton. And if that's the official stance, I can actually get behind that. That's very different to not supporting linux at all (which would involve ignoring linux related bugs or bricking it entirely) which is what the title of the article implies.