Armello, a grim fairy-tale board game from League of Geeks no longer advertises that it supports Linux and macOS due to their new party system that landed with the cross-play update.
In the news post they mention how there's "No Party Functionality (including Private Games) on MacOSX & native Linux. Due to the severity of this one, we've removed any advertising of support for Linux & Mac from Steam (and shortly Humble Bundle), though folks can still purchase and play those versions.".
Giving a little more detail on their official site it mentions how "The service provider we use for Armello’s multiplayer infrastructure has decided to cease support for their party services on MacOSX and Linux. Unfortunately, this means that Party Functionality, including Private Multiplayer, is no longer available in Armello on MacOSX and native Linux platforms." but they don't go on to name whatever company that is.
For the Native Linux and macOS versions, they're still functional and up to date they just don't have the new party system or private matches. For Linux users though you can use Proton to run the Windows version, which fully works. It also has a Steam Deck Playable rating, which uses Proton now too.
This isn't the only game to go a similar route, with ARK: Survival Evolved recently putting the Linux Native version behind a Beta.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
A very sad development. Delisting Linux versions seems to be becoming a trend lately.
6 Likes, Who?
alka.setzer Jul 14, 2022
Well, the Armello developer already had a different version just for GOG.
And in case isn't this why we have Proton? We no longer need native builds, translation overheads and coding for the one true platform (windows, x86[-64] and directx) is easier than solving platform quirks and there is no need to support anything other than Windows (and I'm not even sure if publishers/developers are required to solve problems whenever the issue is while running under Proton).
And in case isn't this why we have Proton? We no longer need native builds, translation overheads and coding for the one true platform (windows, x86[-64] and directx) is easier than solving platform quirks and there is no need to support anything other than Windows (and I'm not even sure if publishers/developers are required to solve problems whenever the issue is while running under Proton).
1 Likes, Who?
A shame they didn't call that service provider out so other devs can stay clear of such a company...
18 Likes, Who?
I wonder if they'll still develop a native GNU+Linux version despite this. They're current now but, for how long?
Is that game still playable without that feature? What if they decide to or need to switch to another party server provider.
We need to find out who this provider is and pressure it into supporting GNU+Linux.
I'm very wary about DirectX / windoze x86-64 being the only platform devs target. On one hand, it's a crusty old platform that Wine handles very well. But, on the other it's one that's likely to have a knife up it's sleeve ready to stab.
Targeting only that, yes, speaks to the power and capability of GNU+Linux, libre software, and the communities around it all but, also shows that it's unnecessary and can nearly be forgotten about.
Edit: Their website says they will continue support GNU+Linux and other affected platforms. Also, yes, it's seems to be a fine single player game.
Last edited by EWG on 15 July 2022 at 6:02 pm UTC
Is that game still playable without that feature? What if they decide to or need to switch to another party server provider.
We need to find out who this provider is and pressure it into supporting GNU+Linux.
I'm very wary about DirectX / windoze x86-64 being the only platform devs target. On one hand, it's a crusty old platform that Wine handles very well. But, on the other it's one that's likely to have a knife up it's sleeve ready to stab.
Targeting only that, yes, speaks to the power and capability of GNU+Linux, libre software, and the communities around it all but, also shows that it's unnecessary and can nearly be forgotten about.
Edit: Their website says they will continue support GNU+Linux and other affected platforms. Also, yes, it's seems to be a fine single player game.
Last edited by EWG on 15 July 2022 at 6:02 pm UTC
7 Likes, Who?
This is going to happen more and more as Proton gets better and better..... Greedy/lazy publishers will use Proton to lower costs as they dont need to make a dedicated Linux port and still get a slice of the Linux user pie.....
Im not saying this is what happened here as it seems they got blindsided by a service provider... but between this and ARK: Survival Evolved you can see where the future is heading.....
Im not saying this is what happened here as it seems they got blindsided by a service provider... but between this and ARK: Survival Evolved you can see where the future is heading.....
3 Likes, Who?
Well, in this case it seems like it was not their choice but their middleware's, and they phrased it right as "not advertising an inferior version as if the platform was supported" instead of "removing platform support due to it being too much work". So I'll keep the pitchfork in the barn for now.
See PR departments, not that hard. Don't insult people, don't imply a platform is less deserving than others, explain the external factors, and show you care about your customers (existing and potential).
See PR departments, not that hard. Don't insult people, don't imply a platform is less deserving than others, explain the external factors, and show you care about your customers (existing and potential).
11 Likes, Who?
Don't forget the fiasco about this dev and their GOG version of Armello...
2 Likes, Who?
Well, the Armello developer already had a different version just for GOG.because they dont want to fix it if anything breaks on wine.
And in case isn't this why we have Proton? We no longer need native builds, translation overheads and coding for the one true platform (windows, x86[-64] and directx) is easier than solving platform quirks and there is no need to support anything other than Windows (and I'm not even sure if publishers/developers are required to solve problems whenever the issue is while running under Proton).
plus we have an history of harrassing developers who call their wrapper (wine/virtual programing) version an native build.
1 Likes, Who?
Perkeleen_Vittupää Jul 14, 2022
Can't even comment on their Steam discussion section if one don't own the game!
5 Likes, Who?
This is going to happen more and more as Proton gets better and better..... Greedy/lazy publishers will use Proton to lower costs as they dont need to make a dedicated Linux port and still get a slice of the Linux user pie.....
Im not saying this is what happened here as it seems they got blindsided by a service provider... but between this and ARK: Survival Evolved you can see where the future is heading.....
what difference it makes if the games run fine? hell, even mods might have an better cross platform compatibility, how is that any different from using multiplatform apis like openGL on windows instead of directx?
i know, its not the same thing, but if steamdeck increasse our marketshare, it wont make a difference our support will be first class no matter if native or proton.
hell proton already gave us better perfomance than native in a few titles.
3 Likes, Who?
EagleDelta Jul 14, 2022
because they dont want to fix it if anything breaks on wine.
plus we have an history of harrassing developers who call their wrapper (wine/virtual programing) version an native build.
This drives me nuts as a programmer. As WINE/Proton is not emulation, but an implementation of Windows/DX/other APIs in Linux/UNIX-based systems, as such things running in WINE are running natively as all WINE does is map APIs to native APIs/calls (well, for the most part).
9 Likes, Who?
Mountain Man Jul 14, 2022
I honestly don't have a problem with using Proton to play games that are targeted for Windows since it generally works flawlessly (and in some cases, playing through Proton offers better performance than playing a native Linux version, as counter intuitive as that might seem). What gives me pause is when developers treat Proton as an unsupported extra, where they're happy to take our money but then tell us we're on our own if we encounter any problems.
5 Likes, Who?
because they dont want to fix it if anything breaks on wine.
plus we have an history of harrassing developers who call their wrapper (wine/virtual programing) version an native build.
This drives me nuts as a programmer. As WINE/Proton is not emulation, but an implementation of Windows/DX/other APIs in Linux/UNIX-based systems, as such things running in WINE are running natively as all WINE does is map APIs to native APIs/calls (well, for the most part).
That's why it's not native. It has to map to native, during runtime. You're running EXEs and DLLs on Linux. Don't know about you, but that wasn't my goal when switching to Linux.
Last edited by Eike on 14 July 2022 at 4:23 pm UTC
7 Likes, Who?
EagleDelta Jul 14, 2022
because they dont want to fix it if anything breaks on wine.
plus we have an history of harrassing developers who call their wrapper (wine/virtual programing) version an native build.
This drives me nuts as a programmer. As WINE/Proton is not emulation, but an implementation of Windows/DX/other APIs in Linux/UNIX-based systems, as such things running in WINE are running natively as all WINE does is map APIs to native APIs/calls (well, for the most part).
That's why it's not native. It has to map to native, during runtime. You're running EXEs and DLLs on Linux. Don't know about you, but that wasn't my goal when switching to Linux.
That's the definition of what APIs do - they map calls to something else so that the programmer doesn't need to know all the details under the surface. Hence why web APIs are so popular because they are so ubiquitous.
It seems the Linux Gaming community wants to change the definition of APIs for WINE/Gaming vs everything else. A Web application isn't "native" either, but the reality is that JS/Electron APIs are mapping to System Calls. Which is what C, Python, Ruby, Go, Rust, etc APIs do as well for desktop/CLI applications.
In reality, DXVK is a DX API for Vulkan, WINE is a Windows API for all platforms, faudio is an xaudio API for all platforms, so on and so forth
Last edited by EagleDelta on 14 July 2022 at 6:24 pm UTC
3 Likes, Who?
soulsource Jul 14, 2022
The program code is native already (x86 instruction set with AMD64 extensions). WINE contains an independent reimplementation of various libraries shipped with Windows. So, instead of calling functions in Microsoft's Direct3D implementation (as example), programs running under WINE call into WINE's Direct3D implementation (which, opposed to Microsoft's implementation, internally uses other graphics libraries like Vulkan to make the code independent of graphics driver - therefore the term "mapping").because they dont want to fix it if anything breaks on wine.
plus we have an history of harrassing developers who call their wrapper (wine/virtual programing) version an native build.
This drives me nuts as a programmer. As WINE/Proton is not emulation, but an implementation of Windows/DX/other APIs in Linux/UNIX-based systems, as such things running in WINE are running natively as all WINE does is map APIs to native APIs/calls (well, for the most part).
That's why it's not native. It has to map to native, during runtime. You're running EXEs and DLLs on Linux. Don't know about you, but that wasn't my goal when switching to Linux.
This is not only true for graphics libraries though, but for almost (WINE isn't 100% complete) all libraries that come with Windows, what includes low-level libraries for accessing basic system functionality.
In other words, the code is still running 100% native, it just might show different performance/behaviour to Windows because the libraries might be faster/slower, and the Windows API documentation might not always perfectly reflect real-world behaviour of Windows libraries (and of course there could be bugs in WINE).
Also, EXE/DLL is just a file format. The distinction if a program's machine code is stored in an ELF file or an EXE file is similar to the one if an MP3 stream is stored inside an MKV or an AVI file. WINE contains a reader for EXE files, and if you want to, you can set up your Linux kernel to just use WINE's EXE reader if you try to launch an EXE file directly.
9 Likes, Who?
We've done it. We've actually reached a point in the debate where not only is using Proton better than native titles, it's all actually been native the whole time.
6 Likes, Who?
soulsource Jul 14, 2022
When writing my posting, I wondered if I should mention that I am programming for 38 years and that I'm professional software developer for over two decades. It seems I should have.
I know all you've written. But you left out that every single call into the Windows(!) API has to be translated, during runtime. It is not native, it is translated into native. Like a human language interpreter doesn't make English native German - they translate.
6 Likes, Who?
We've done it. We've actually reached a point in the debate where not only is using Proton better than native titles, it's all actually been native the whole time.Who said it's better? The "native" discussion is actually answered quite well on the WINE FAQ.
You might want to read 5.8.
Ah, 6.6.3 of eben better:
Another option is to use a shell script to call a native application. Save it as run_linux_program...
Last edited by Eike on 14 July 2022 at 7:46 pm UTC
0 Likes
Patreon
PayPal
See more from me