Transhuman Design has removed the Linux version of BUTCHER due to issues in favour of Steam Play (updated)

Quoting: liamdawe

Quoting: jensWhy is it so important how the game is packaged and compiled? It should perform, should be stable and the developer/publisher should know that the money came from Linux. I'm fine if these three conditions are given.

That's how I feel about a lot of this stuff, to the end user (the actual gamer) it should matter, everything behind the scenes should be invisible to you.

Part of the problem though is what I mentioned, Steam Play titles don't currently show as a Linux game on the store + the problems then other stores have. We don't want to end up having Steam lock-in. As much as I value what Valve does, the last thing I want is them getting everything and other stores getting nothing.

Yes, as stated, I get the issue with other stores. Though it is no actual lock-in, Valve does not prevent GOG or itch.io to setup something similar to proton.

Edit: Lots of typos.


Last edited by jens on 21 September 2018 at 2:47 pm UTC

Quoting: jens

Quoting: liamdawe

Quoting: jensWhy is it so important how the game is packaged and compiled? It should perform, should be stable and the developer/publisher should know that the money came from Linux. I'm fine if these three conditions are given.

That's how I feel about a lot of this stuff, to the end user (the actual gamer) it should matter, everything behind the scenes should be invisible to you.

Part of the problem though is what I mentioned, Steam Play titles don't currently show as a Linux game on the store + the problems then other stores have. We don't want to end up having Steam lock-in. As much as I value what Valve does, the last thing I want is them getting everything and other stores getting nothing.

Yes, as stated, I get the issue with other stores. Though it is no actual lock-in, Valve does not prevent GOG or itch.io to setup something similar to proton.

Edit: Lots of typos.

I'm not saying it will create lock-in since Proton is open source, but the reality is developers who end up relying on it will not do Linux versions and since they will then put even less effort in, the chances of them bundling it for other stores IMO is zero.

Quoting: liamdawe

Quoting: jens

Quoting: liamdawe

Quoting: jensWhy is it so important how the game is packaged and compiled? It should perform, should be stable and the developer/publisher should know that the money came from Linux. I'm fine if these three conditions are given.

That's how I feel about a lot of this stuff, to the end user (the actual gamer) it should matter, everything behind the scenes should be invisible to you.

Part of the problem though is what I mentioned, Steam Play titles don't currently show as a Linux game on the store + the problems then other stores have. We don't want to end up having Steam lock-in. As much as I value what Valve does, the last thing I want is them getting everything and other stores getting nothing.

Yes, as stated, I get the issue with other stores. Though it is no actual lock-in, Valve does not prevent GOG or itch.io to setup something similar to proton.

Edit: Lots of typos.

I'm not saying it will create lock-in since Proton is open source, but the reality is developers who end up relying on it will not do Linux versions and since they will then put even less effort in, the chances of them bundling it for other stores IMO is zero.

Yes, I think too that this is very likely to happen if Value is the only store that offers such a "packaging" solution for Linux. Not sure though what is better, much more visible Linux users on Steam vs less releases on other stores. I don't know, time will tell. My hope is still that more visible users will get Linux earlier on the agenda for developers, though that will take some time and requires lots (really a lot) of new Linux users.


Last edited by jens on 21 September 2018 at 3:08 pm UTC

Quoting: GuestAgain, the dev should download Proton, compile it, and release it as an official port. Not something installed by SteamPlay. If they did that they could release it on GoG, Itch, etc.

WINE had this option available long ago (it is called "WineLib" ), but almost nobody used it (well, there are some ports like "FlatOut 2" and such on GOG).
I'd be happy to see how they drop Windows™ support seeing someone wasn't able to launch the game! In this situation the developer just used the convenient excuse to drop support and reassign the responsibility to Valve® while keeping the money ("to eat the cake and have it too", as someone mentioned earlier :D ).

Quoting: jens

Quoting: liamdawe

Quoting: jensWhy is it so important how the game is packaged and compiled? It should perform, should be stable and the developer/publisher should know that the money came from Linux. I'm fine if these three conditions are given.

That's how I feel about a lot of this stuff, to the end user (the actual gamer) it should matter, everything behind the scenes should be invisible to you.

Part of the problem though is what I mentioned, Steam Play titles don't currently show as a Linux game on the store + the problems then other stores have. We don't want to end up having Steam lock-in. As much as I value what Valve does, the last thing I want is them getting everything and other stores getting nothing.

Yes, as stated, I get the issue with other stores. Though it is no actual lock-in, Valve does not prevent GOG or itch.io to setup something similar to proton.

Edit: Lots of typos.

Yes it's really great they not only pragmatically, but also consequently build on free or open solutions. Everyone could just take Valve funded or initiated work for their own open gaming. They just have to do it. Maybe it just takes some time until they do...
I'm still not sure where this all leads, but if Valve should really have a unified Steam Play platform in mind, it will be based on open multi platform APIs and Win32. Win32 mainly because Linux is a lot more flexible than Windows in that regard. I had no problem beeing regarded as a normal gamer, just with a Linux Steam Play (or whatever the platform might be called) OS, if I could purchase compatible games on other stores too, no matter if I really did.

Quoting: CreakOn the other hand, Linux changed a lot in the recent years in becoming a more mature gaming platform. But the differences between 3 years ago and now are still huge (which is great!), but it doesn't help when you try to support this platform.

Can I have some elaboration on this? I am not saying it is not true, but from where I am standing, I have not seen much change in the last five years to how my setup functions. I have been in a fairly sweet spot for awhile now. Granted, five years ago is about as long as it has been since I have changed my hardware.

Quoting: 3qET7rL9BdThis decision by the developer confuses me a lot.

How many Linux versions of the game have they sold? Judging by the comments here they have sold at least one. What if this was a game sold for Xbox and Playstation but it turns out the Xbox version doesn't work would it then be acceptable if the developer just dropped support for the Xbox version? I assume the developer legally have to make sure that the product they sold actually works otherwise offer refunds?

I would equivalent this with a car manufacturer finding a manufacturing error in one of their cars and issuing a full recall of all sold units meaning a full refund for everyone who bought it.

Since they they have asked Valve to whitelist the game using Proton I assume they've spent hours and hours and hours testing the game with Proton and knows the game works flawlessly with it? Right? Right? For some reason I highly doubt it mostly because the developer themselves say "and hopefully enjoy your game working on Linux again" which means they don't even know if it works with Proton.

Sigh.

I hope Valve gives them a proper response for asking them to whitelist a game they don't even now works with Proton.

I'm also guessing since the sole programmer is no longer available any bugs found in the Windows version due to them using an old version of Unity for any other reason will also go unfixed. One the one hand I guess you can't expect developers to update games after release. What you see is what you get. But what if you find a game breaking bug? I really think you should be able to expect the developer to fix problems preventing you from playing the game from start to finish.

In the end we weren't the ones deciding what platforms to release the game on, the developers did. If they now have found that the version of Unity they are using has a lot of issues on Linux and therefore decided to stop selling the game on Linux shouldn't they have found this when performing their own testing before releasing the game? To me it just seams like the developer clicked "export for Linux" without doing any sort of testing and hoped for the best. I appreciate they trying to bring their game to Linux but I do think we should be able to expect a little bit more from developers.

The decision makes sense if for example they do not have in the inhouse ability to fix the issues, and do not deem it financially viable to hire in those skills. Or two they looked at the game sales on linux and looked at the cost of support and just said its cheaper and easier to let it run via wine that way we dont even have to support it. As long as they dont dramatically change the windows code the wine version will just keep on trucking.

Quoting: Whitewolfe80The decision makes sense if for example they do not have in the inhouse ability to fix the issues, and do not deem it financially viable to hire in those skills. Or two they looked at the game sales on linux and looked at the cost of support and just said its cheaper and easier to let it run via wine that way we dont even have to support it. As long as they dont dramatically change the windows code the wine version will just keep on trucking.

The decision is lazy, cowardly, and destroys trust.
They should have done their research on Linux and their engine's history with the platform before ever adding Linux as a target platform. Given that they released a Linux binary, I'm going to assume they actually did their research... so their sales numbers on the platform be damned, honestly.

They should have the pride and self respect to maintain that binary and take ownership when issues arise. What decisions like this tell me is when the code gets tough, they bail. If this were a bug on the Windows side, you bet your bottom dollar they'd be trying to get to the bottom of it. If it's Unity, they'd be hounding Unity for a fix (or fix it themselves if they have direct source access... not sure if Unity gives that option). Even if they put out a "we're sorry, we're working with the Unity team, but for now Linux users are stuck on an older version", fine... but no... they pulled their work as if it never existed and washed their hands.

These developers need more pride in their work. Make a decision and stick with it, come what may.

Quoting: tuubi

Quoting: appetrosyanSDL versions are even worse: it's the same kind of indirection, simply less flexible and far less maintainable. Why do we insist that a compiled closed-source POSIX executable is better than an interpreted foreign one?

The SDL dig doesn't make sense, but of course a closed source native build is better than a closed source "interpreted" one, if everything else is equal. ("Interpreted" in quotes because Wine isn't really an interpreter.)

A bad native Linux port VS a good wrap job is a bit different, but this doesn't mean the wrapper is the better technical solution. Using one is simpler than writing a truly portable game though, especially if you don't really know your target platform, and it might work just fine. Or it might not.

See my rationale is, Linux changes fast and by a lot. So if you want your old games to conform to a new standard, eg. wayland, if you have a very good interpreter you only need to modify it, and since wine is FOSS, that's not a problem.

If you wanted to huue a native game to conform to these new standards, you'd have to convince game-devs that it's worth it., which is considerably harder since it's extra work, without extra pay.

Quoting: ObsidianBlk

Quoting: Whitewolfe80The decision makes sense if for example they do not have in the inhouse ability to fix the issues, and do not deem it financially viable to hire in those skills. Or two they looked at the game sales on linux and looked at the cost of support and just said its cheaper and easier to let it run via wine that way we dont even have to support it. As long as they dont dramatically change the windows code the wine version will just keep on trucking.

The decision is lazy, cowardly, and destroys trust.
They should have done their research on Linux and their engine's history with the platform before ever adding Linux as a target platform. Given that they released a Linux binary, I'm going to assume they actually did their research... so their sales numbers on the platform be damned, honestly.

Mate, that's the exact attitude why we still don't have the Witcher 3. Itis lazy, and it does show incompetence in the port, however, if you have a game engine with native support, what you end-up doing, is delegating an entire Feral Interactive's worth of work to just one person. The real issue isn't the cop-out, but the fact that Windows binaries are developed and tested with way more resources. Don't be angry at the developer, at least they had the decency to admit, that they can't do it, instead of having a broken game on the storefront, or so they say.
-

Quoting: ObsidianBlkThey should have the pride and self respect to maintain that binary and take ownership when issues arise. What decisions like this tell me is when the code gets tough, they bail. If this were a bug on the Windows side, you bet your bottom dollar they'd be trying to get to the bottom of it. If it's Unity, they'd be hounding Unity for a fix (or fix it themselves if they have direct source access... not sure if Unity gives that option). Even if they put out a "we're sorry, we're working with the Unity team, but for now Linux users are stuck on an older version", fine... but no... they pulled their work as if it never existed and washed their hands.

Would you maintain a binary by hand, without pay, when an automatic tool ddoes that job better.

I do, however disagree that maintaining and delegating are the only two options. Make it open-source, have the guy who found a fix be able to fix it, and take credit.

I'd like to point out: putting GOG and Itch under pressure is a good thing. While they're objectively better platforms, they haven't made a huge, or even small step forward with GNU + Linux.

They will need to compete for this market so they'll probably have to release GOG galaxy, and maybe offer a similar solution to proton: shipping ready-to-play packages, e. g. flatpaks, with a tuned wine prefix. Use it or lose it.

Quoting: appetrosyan

Quoting: tuubi

Quoting: appetrosyanSDL versions are even worse: it's the same kind of indirection, simply less flexible and far less maintainable. Why do we insist that a compiled closed-source POSIX executable is better than an interpreted foreign one?

The SDL dig doesn't make sense, but of course a closed source native build is better than a closed source "interpreted" one, if everything else is equal. ("Interpreted" in quotes because Wine isn't really an interpreter.)

A bad native Linux port VS a good wrap job is a bit different, but this doesn't mean the wrapper is the better technical solution. Using one is simpler than writing a truly portable game though, especially if you don't really know your target platform, and it might work just fine. Or it might not.

See my rationale is, Linux changes fast and by a lot. So if you want your old games to conform to a new standard, eg. wayland, if you have a very good interpreter you only need to modify it, and since wine is FOSS, that's not a problem.

Linux does change (for the better) and this seems to happen relatively fast, but in reality every bigger change takes months or years of groundwork and libraries like SDL and the various audio solutions can easily keep up. For Wayland support, you'd have to rebuild your game with a version of SDL2 from the last couple of years, or a modern release of GLFW if that's what you prefer. Wine doesn't support Wayland by the way.

If your main game logic is properly platform agnostic and you don't tie yourself to a platform by exclusively using D3D, Metal or similar, you'll find plenty of open source compatibility libraries (with stable APIs) to handle platform differences for you. As the developer, you carry the burden of long-term support as long as you sell the game, but that's how it's supposed to be. You might even have to rebuild your game on more modern libraries every few years. When you eventually stop supporting it, open sourcing would be the ideal way to go.


Of course, all this is off topic. The problem Transhuman has is that they'd need to move their game over to a newer Unity release to fix a bug. I've never used Unity, but seems like the engine doesn't exactly make it simple.

Update: They changed their minds on this, they've put the native version back up. See here.

They've also updated their FAQ with troubleshooting steps for any Linux users who hit this problem in the future.


Last edited by Cheeseness on 22 September 2018 at 12:41 pm UTC

Just installed the native Linux version off Steam onto my Debian Buster, Nvidia driver gaming PC and no problems. Game working fine. Played it for 20 minutes. Predicted this same outcome earlier on.

Quoting: CheesenessThey've also updated their FAQ with troubleshooting steps for any Linux users who hit this problem in the future.

Great work! Why debate problems when you can solve them?
I lift my hat and bow down!

Quoting: appetrosyan

Quoting: ObsidianBlk

Quoting: Whitewolfe80The decision makes sense if for example they do not have in the inhouse ability to fix the issues, and do not deem it financially viable to hire in those skills. Or two they looked at the game sales on linux and looked at the cost of support and just said its cheaper and easier to let it run via wine that way we dont even have to support it. As long as they dont dramatically change the windows code the wine version will just keep on trucking.

The decision is lazy, cowardly, and destroys trust.
They should have done their research on Linux and their engine's history with the platform before ever adding Linux as a target platform. Given that they released a Linux binary, I'm going to assume they actually did their research... so their sales numbers on the platform be damned, honestly.

Mate, that's the exact attitude why we still don't have the Witcher 3. Itis lazy, and it does show incompetence in the port, however, if you have a game engine with native support, what you end-up doing, is delegating an entire Feral Interactive's worth of work to just one person. The real issue isn't the cop-out, but the fact that Windows binaries are developed and tested with way more resources. Don't be angry at the developer, at least they had the decency to admit, that they can't do it, instead of having a broken game on the storefront, or so they say.
-

Quoting: ObsidianBlkThey should have the pride and self respect to maintain that binary and take ownership when issues arise. What decisions like this tell me is when the code gets tough, they bail. If this were a bug on the Windows side, you bet your bottom dollar they'd be trying to get to the bottom of it. If it's Unity, they'd be hounding Unity for a fix (or fix it themselves if they have direct source access... not sure if Unity gives that option). Even if they put out a "we're sorry, we're working with the Unity team, but for now Linux users are stuck on an older version", fine... but no... they pulled their work as if it never existed and washed their hands.

Would you maintain a binary by hand, without pay, when an automatic tool ddoes that job better.

I do, however disagree that maintaining and delegating are the only two options. Make it open-source, have the guy who found a fix be able to fix it, and take credit.

What's the reason they haven't ported Witcher 3? CDPR didn't promise a Linux version. They didn't release a Linux version then pull it, sighting some lame excuse. I assume they did their research and concluded that Linux wasn't a viable option. Oh well. They never lied or reneged, so... I'm not seeing where you were going with that.

Proton doesn't maintain or fix the binary for you. It's a wrapper around Windows... it's glorified WINE. On top of that, the company is not obligated to confirm their Windows binary remains functional via Proton. So even if the game works for most at the point of whitelisting, if the developers make a change that breaks with Proton, "oh well".

And where are you getting "without pay" from? The game was for sale. Linux users were paying them for their game. This game was not a charity, it was a product. Again, I don't care what the Linux demographic size is compared to Windows. That goes back to my last statement about the developers doing their damn research before committing to Linux in the first place. If they didn't like the size of the demographic, then don't release for the platform.

Does it suck that not as many developers release for Linux as I'd like? Hell yes. What hurts Linux more, though, is when someone new to Linux comes in, sees a game they want, then has that game pulled from them. How could anyone trust our platform for gaming if game developers treat it like that?

I give developers who pull stunts like this no quarter.

Quoting: liamdaweUpdate: They changed their minds on this, they've put the native version back up. See here.

Glad to hear it. Let's hope they don't flake out again.

Quoting: Hamish

Quoting: CreakOn the other hand, Linux changed a lot in the recent years in becoming a more mature gaming platform. But the differences between 3 years ago and now are still huge (which is great!), but it doesn't help when you try to support this platform.

Can I have some elaboration on this? I am not saying it is not true, but from where I am standing, I have not seen much change in the last five years to how my setup functions. I have been in a fairly sweet spot for awhile now. Granted, five years ago is about as long as it has been since I have changed my hardware.

Disclaimer: I don't know exactly how it went, I'm speculating simply based on my coding experience.

Imagine the devs at Unity making their engine to run on Linux somewhere around 2015-2016. At the time, a bunch of OpenGL features weren't implemented in the drivers, Mesa got just about OpenGL 4.0, Vulkan wasn't even a thing on Mesa, and there wasn't as many games as today to test these drivers in the field.

And they couldn't base their code only on the very latest drivers, since it doesn't represent the vast majority of the devices Unity is being run on. So they had to compromise to have the best balance between stability and bleeding-edgeness.

3 years forward: we have OpenGL 4.5 on Mesa and 4.6 on NVIDIA, we have more and more AAA games, there's been hundreds (thousands?) of bug fixes in the Mesa drivers, X11 received at lot of fixes as well and a bunch of additional improvements when dealing with GPUs, Wayland is more and more a thing, ...

My point: Unity 5.6 on Linux might be outdated by all these improvements.

On the other hand, Windows 10 was already a thing in 2015, developers could already play with Vulkan at its release in 2016, and, apart from Vulkan, the drivers didn't evolved that much in 3 years. So Unity 5.6 on Windows is still more likely to work well, it's just a bit old.

Edit: typos, rewording


Last edited by Creak on 22 September 2018 at 2:48 pm UTC

Quoting: ObsidianBlkWhat's the reason they haven't ported Witcher 3? CDPR didn't promise a Linux version. They didn't release a Linux version then pull it, sighting some lame excuse. I assume they did their research and concluded that Linux wasn't a viable option. Oh well. They never lied or reneged, so... I'm not seeing where you were going with that.

CDPR promised the witcher series to come to Linux. They first (and last) "ported" Witcher 2 by delegating it to Virtual Programming. The resulting "native" binary ran worse than through wine: it was crash-happy, it gave about 1/3 framerate, and half the graphical options didn't work at all. Naturally everyone was outraged, they said "CDPR should this" and "CDPR should that", as a resulteverybody in the linux community got a response like this one "We're not porting any more Withcer games. We got enough of a backlash and death threats from Withcer 2".

I'm not saying they were right, they didn't see the numbers they wanted, and VP can't code for shit, but we made it easy for them to perpetrate the myth about a toxic community in Linux. It wasn't our fault, but keeping it up won't help us gain any traction.

QuoteProton doesn't maintain or fix the binary for you. It's a wrapper around Windows... it's glorified WINE. On top of that, the company is not obligated to confirm their Windows binary remains functional via Proton. So even if the game works for most at the point of whitelisting, if the developers make a change that breaks with Proton, "oh well".

If a Windows binary works on Windows, it's Valve's job to fix their win32 wrapper. If a working windows executable doesn't work on Linux, and it works on Windows, so the fault is in the compatibility layer, not the program. Fortunately, wine is in active development and developed by more than one guy. Their game on the other hand isn't. They clearly state that it's easier to delegate responsibility to Valve, and not worry about it. It's sad, but it's the absolute truth.

QuoteAnd where are you getting "without pay" from? The game was for sale. Linux users were paying them for their game. This game was not a charity, it was a product. Again, I don't care what the Linux demographic size is compared to Windows. That goes back to my last statement about the developers doing their damn research before committing to Linux in the first place. If they didn't like the size of the demographic, then don't release for the platform.

Games that aren't visible don't get sold. I haven't heard of this game until now. If they fixed it, the best they can hope for is avoiding negative reviews from Linux users, and that's not much because the sales period for the game is out. Even big publishers abandon their older games simply because it's not profitable. And speaking of committing to Linux, you should have done your damn research : the game isn't being pulled from you, instead of using a native poorly written game you get a machine interpreted executable. Also, the developer has decided that - "let's keep the native version on the storefront anyway. Linux users can, if they want to, run it through wine no problem, and the bug isn't that big".

QuoteDoes it suck that not as many developers release for Linux as I'd like? Hell yes.

Hardly relevant.

QuoteWhat hurts Linux more, though, is when someone new to Linux comes in, sees a game they want, then has that game pulled from them. How could anyone trust our platform for gaming if game developers treat it like that?

I think you shouldn't be outraged over the fact - they pulled the game, as much as why they pulled the game. Essentially, they had a dev. team consisting of one person. One person to write the code, one person to test, one person to debug and one person to maintain. You complain about a people not wearing safety glasses when picking uranium. Don't you see the massive leap here?

QuoteI give developers who pull stunts like this no quarter.

Then don't buy games from small studios. Don't buy games with proprietary source code, and actively tell game developers that you expect them to have done their research, before buying the game.