Here's your utterly weird news of the day. Some time ago Xenonauts was ported to Linux by Knockout Games. The official website now claims it's not actually supported and is only meant for whatever the heck they mean by 'legacy customers'. Thanks to reddit for originally pointing it out.
Despite the Linux version being sold on GOG, Steam & Humble, I find it rather anti-consumer to claim on the official site that the Linux & Mac versions aren't actually supported. With regards to 'legacy customers', essentially, it's only meant for people who purchased it originally. If that's truly the case, having it advertised for sale across those stores is pretty bad practice.
This is taken right from the official site purchase page:
On Steam, they still say this:
That's obviously outdated information then.
The GOG & Humble store copies don't mention anything in relation to this at all.
It's actually another game that was ported natively to Linux to be included in a Humble Bundle (HIB 15 specifically). Games ported to be included in those bundles don't always get the best support.
Notice I said "natively" above, well, it was actually a goal on the original Kickstarter to do a Linux version. They eventually did a Wine-port and then the native port for the Humble Indie Bundle 15.
So, taking all that into account, why is it suddenly being claimed it's only for legacy customers? It just doesn't add up and I don't like it.
Considering the developer has moved on to making the sequel, which might support Linux, this will seriously impact my decision to support them.
I've sent an email to the developer to see if we can get this cleared up, as I never like to outright not support a small developer, but nothing sounds good here right now. Article taken from GamingOnLinux.com.
Despite the Linux version being sold on GOG, Steam & Humble, I find it rather anti-consumer to claim on the official site that the Linux & Mac versions aren't actually supported. With regards to 'legacy customers', essentially, it's only meant for people who purchased it originally. If that's truly the case, having it advertised for sale across those stores is pretty bad practice.
This is taken right from the official site purchase page:
QuoteLinux and Mac versions of the game are available on both platforms but are not officially supported; they were created for legacy customers and no technical support will be provided for those platforms!
On Steam, they still say this:
QuotePlease note that the native Mac / Linux versions of the game are still in beta, however older WINE-wrapped "ports" are available and known to be stable whilst development of the native ports is still ongoing.
That's obviously outdated information then.
The GOG & Humble store copies don't mention anything in relation to this at all.
It's actually another game that was ported natively to Linux to be included in a Humble Bundle (HIB 15 specifically). Games ported to be included in those bundles don't always get the best support.
Notice I said "natively" above, well, it was actually a goal on the original Kickstarter to do a Linux version. They eventually did a Wine-port and then the native port for the Humble Indie Bundle 15.
So, taking all that into account, why is it suddenly being claimed it's only for legacy customers? It just doesn't add up and I don't like it.
Considering the developer has moved on to making the sequel, which might support Linux, this will seriously impact my decision to support them.
I've sent an email to the developer to see if we can get this cleared up, as I never like to outright not support a small developer, but nothing sounds good here right now. Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Alright. No money from me anymore to them. And we still have unbeaten openxcom! :-)
0 Likes
Don't use IDEs to compile releases, use a compile server that lets you recompile all games for a new platform each time you update the platform for a new game. Use automated tests to see if there are any regressions, and if there are none, then offering an updated version shouldn't be too hard.
Last edited by Ketil on 13 May 2017 at 12:27 pm UTC
Last edited by Ketil on 13 May 2017 at 12:27 pm UTC
2 Likes, Who?
Quoting: GuestSorry, I meant, don't use IDEs on desktop computers to compile releases.Quoting: KetilDon't use SDKs to compile releasesHuh ? That doesnt make any sense... in this case an "SDK" is simply a known set of libraries. This is what every other platform does.
Simply building with "Latest compiler" against "Latest glibc/libstdc+++/whatever" is simply not a good idea.
Quoting: GuestHaving a compile server with support for multiple platforms, and automated testing reduces the burden of anything breaking with a recompile. Usually the ABI changes are worse than the API changes. At some point even offering new binary automatically tested, but announcing it unsupported could still be better than not updating it at all.Quoting: Ketiluse a compile server that lets you recompile all games for a new platform each time you update the platform for a new game. Use automated tests to see if there are any regressions, and if there are none, then offering an updated version shouldn't be too hard.That still means pushing new releases.. which with publishers often means they want to do a round of QA before they approve release. Not feasible. Plus there is only so long you can viably do this for. You simply cant expect infinite maintenance on every released game.
1 Likes, Who?
I strongly prefer this over the status quo, which is "we don't want the overhead of supporting Linux, so we just won't port at all". I hate that attitude so, so much, but the vast majority of developers not already porting are taking EXACTLY that stance. There is a significant minority that are stuck with only D3D-based renderer options or a custom engine making the port far from trivial, but in the modern day that's usually not the case; making a functional binary on some common version of some common distribution really is as simple as hitting "build".
We can take care of ourselves, come on, throw us a bone! We'll figure out ourselves how to make that one very distro-specific binary run elsewhere, we've gotten pretty good at that. If we run into an issue we can't work around, we'll document it a lot better than virtually any Windows user and make it a lot easier to fix, and that's all we want -- feature parity and the occasional bugfix.
I feel that taking offense to this approach will push them towards the above attitude and drastically reduce the odds of the sequel being ported.
Last edited by roothorick on 13 May 2017 at 5:05 pm UTC
We can take care of ourselves, come on, throw us a bone! We'll figure out ourselves how to make that one very distro-specific binary run elsewhere, we've gotten pretty good at that. If we run into an issue we can't work around, we'll document it a lot better than virtually any Windows user and make it a lot easier to fix, and that's all we want -- feature parity and the occasional bugfix.
I feel that taking offense to this approach will push them towards the above attitude and drastically reduce the odds of the sequel being ported.
Last edited by roothorick on 13 May 2017 at 5:05 pm UTC
2 Likes, Who?
Quoting: rea987As it is a single player game, my expectation and explanation as follows:
Thanks to stubborn and weird release cycle of the most popular GNU/Linux distro, Ubuntu, developers need to update and adapt their titles for every LTS release. When SteamOS and Steam client updates are added to this equation, some developers simply stop sopporting the games after certain LTS release. Most of the games should still work fine anyway, but in time, outdated dependencies might prevent those games to function properly or even launch. This won't be an issue for now but after half decade, you will wonder for what reason certain games do not work any longer... Does any one remember icculus' Medal of Honor Allied Assault beta port which is literally impossible to natively run on modern distros currently? That is why having "source code" matters...
I have native Metal of Honor Allied Assault running on Fedora 25 just fine right now. That said, it wasn't install and done. I used a walk through for most of it and had to manually figure out audio to get it working. If they have one good Linux person to keep the dependencies/library versions in order (packaging old versions and fixing startup scripts) it shouldn't really be an issue. Contracting that from time to time shouldn't be a problem either, as long as your contractor is good. This is to much for a lot of dev/publishers though, even on Windows after a decade many games don't work without user fixes. I remember editing the binary for Red Faction 2 with a hex editor so it would work with DirectX 9 (this game is still sold on Steam even though it won't run out of the box on anything newer than Win XP).
Last edited by m2mg2 on 13 May 2017 at 8:37 pm UTC
1 Likes, Who?
@jaycee has the right implementation, the ability to be able to have and use multiple .so files (a smarter shared object linking mechanism)- there could be an even simpler solution where the game ships with its required .so files bundled with the game as part of the installation - completely removing dependency issues. Its kind of a no-brainer really
1 Likes, Who?
No support (for Linux, while Windows version is supported) = unprofessional developers.
Last edited by Shmerl on 14 May 2017 at 3:13 am UTC
Last edited by Shmerl on 14 May 2017 at 3:13 am UTC
0 Likes
Patreon
PayPal
See more from me