Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

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

Original article below:

It seems Transhuman Design have removed the Linux version of BUTCHER after users reported issues, opting instead to ask Steam to add it as an approved Steam Play title.

Announcing it on Steam, they said this:

Sadly, BUTCHER spontaneously stopped working on Linux. The most likely cause seems to be some incompatibility between the old Unity 5.6 Linux builds and new GPU drivers.

Since moving the codebase to a newer Unity version is potentially a titanic task (including testing, debugging, and hair-pulling) and the sole programmer of the game is tightly involved in another project to keep him afloat, we decided to request the game to be whitelisted as fully compatible with the new Steam Play feature.

Before it's officially accepted, you can try it now yourself and hopefully enjoy your game working on Linux again!

After digging into the Steam forum, I came across this forum topic started in August, where four users mentioned trouble starting the game. That doesn't seem like a lot of people to make such a big decision, but it's understandable that with a tiny team and little time they're trying to make it so Linux gamers still have a good experience. Probably a good case for Valve to allow people to have a choice between native and Steam Play's Proton.

Obviously the problem with them doing this, is that it no longer shows up as a Linux game on Steam, that is until Valve decide what they're going to do about showing Steam Play on store pages (if anything).

I'm pretty curious to know what the actual issue is here. Is it Unity once again messing up in their older builds, is it a driver update that broke it? We know so little.

Worth noting this is only on Steam of course, the native Linux builds are still available from Humble Store, GOG and itch.io.

What do you think about such a move? Keen to see some thoughts on this.

Article taken from GamingOnLinux.com.
10 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
70 comments
Page: «5/7»
  Go to:

jens Sep 21, 2018
  • Supporter
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
Liam Dawe Sep 21, 2018
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.
jens Sep 21, 2018
  • Supporter
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
Alm888 Sep 21, 2018
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 ).
Nevertheless Sep 21, 2018
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.
Hamish Sep 21, 2018
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.
Whitewolfe80 Sep 21, 2018
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.
ObsidianBlk Sep 22, 2018
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.
appetrosyan Sep 22, 2018
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.
appetrosyan Sep 22, 2018
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.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.