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.