I am pleased to open this subforum with the traditional question: does this game work on Linux? :)

Any experiences, opinions, hints?

Works perfectly through Wine with DXVK but you need to enable a virtual desktop first.

*Sigh*
Look... I suspect you probably meant well.
But this level of details is absolutely WORTHLESS.
"Default settings" may differ between distros as they often have distro-specific package optimisations/changes.

My bad, I tend to underreport things if they went too well.
My system's Arch Linux, Ryzen 1600AF, Radeon RX580 4GB with Mesa 21.1.2 driver.
My initial hour of testing was with Wine Staging 6.10 from the arch repository.
I have DXVK 1.8.1 in my wine prefix.

A tweak that's sometimes needed depending on your system is to enable a virtual desktop as without it the game starts and hangs at a white screen. If you manually manage wine prefixes you can enable it in winecfg or if you use lutris Configure > Runner Options enable the virtual desktop switch.

I use the custom kernel zen 5.12.9 so after an hour I tried with a custom wine-tkg build with fsync/futex patches and got 106/182.5/69.5 avg/max/min fps in the benchmark with everything maxed except for normal quality antialiasing

Would there be any more info that'd be good?

- RAM size, swap size, swappiness (to evaluate overall virtual memory subsystem)
- does this run from SSD or HDD (specifying min possible read speed would be nice, for some games this is a choking point, especially on Wine)
- CPU: SMT enabled or not, static clock or dynamic, P states or not, did you mess with vcore and LLC, actual clock used, what governor, this all is relevant stability-wise, many of these can cause problems with some games
- audio backend used (by the way - did you test the game for more than few hour gameplay? - do you get audio crackling after some specified amount of time?)
- any non standard audio backend settings (very relevant for audio behaviour)
- any game/Wine relevant kernel params
- async used or not
- esync used or not
- mitigations, off, or what on (this may be relevant SOMETIMES)
- exact graphical settings in-game - this can change a lot (exact entirety list specification required, there's extensive list of games that crap out under Wine with specific high settings, and results vary across system deployments)
- in-game settings - full screen, exclusive fs, windowed, or borderless windowed (which one)
- is the GPU stock or is it overclocked (under some circumstances this may become relevant for Wine stability from time to time)
- set game resolution, exact value, especially if non standard (for example 1920 x 1040)
- refresh rate of the screen
- mods used or not
- wineprefix clean or shared (this is never obvious so should always be specified)
- V-sync, if utilised, if yes then enforced where - by game, or by external software
- any winetricks overrides used
- are the default drive symlinks left in winecfg or not (if you don't know what I'm talking about then the answer is likely yes)
- any non standard arguments passed to Mesa
- any used system variables, LD preloads, etc (specificly relevant for the game/Wine)
- any changes to adriconf
- fps cap, especially if enforced by external software
- do you have more than 1 screen connected
- do you have compositor ("window decorations") enabled during gameplay, is it managed by automated scripts or turned off by manual means
- used DE / WM - for example i3 is known to be finicky with games (among other software)
- do you have freesync enabled in system, is the game/Wine blacklisted or not
- Vulkan version utilised

Here's the fun part:
- mouse/keyboard polling rate - YES, it IS relevant, and funnily enough not many people know this - it's because there's long unresloved bug in Wine that causes game stuttering during kb/m inputs for a LOT of games if polling rate of either is above 500 (above 250 even for some people).
Wine devs in their ultimate "wisdom" constantly deny it but it's in fact entirely on them.

This entire list is a starter, isn't extensive, and I'm probably forgetting something relevant.
Imo underreporting is one of the worst things you can do, especially if you use ArchLinux (I use it myself btw) - as with this specific distro one can easily forget doing something custom as almost everything done in it requires manual work therefore it's easy to dismiss some custom change.

Wow. Are you even remotely aware of how obnoxious you come across? You ask a question, someone responds, your first reaction? An arrogant sigh. Nevertheless, the poster actually takes it in good faith, gives you more info, and yet you don't even thank him. Instead, you give him a long list of homework FOR YOUR BENEFIT and admonish him for underreporting. Remember that this is just another gamer, not anyone employed by the studio, publisher or marketplace.

Just... wow.

edit: just realized you weren't even the OP. Again: wow. You must be fun at parties. Do people actually invite you to those?

For your information, you pretentious closet self-proclaimed psychologist, "sigh" can carry a lot of different emotions, such as for example dissappointment, hopelessness, "I've seen this to many times, I'd like for this to change already" tiredness, among others.

Obnoxious is the word I would use to describe your shameless bait attempt.

I honestly couldn't care less how you perceive me.

"for my benefit"?
No. I don't even have the game on GOG.
I speak up for the general internet worldwide populace who often don't have courage to ask questions because of reactions like yours and without detailed-enough reports they are left in the dark with need of very own extensive testing and troubleshooting.

And general "works for me" with ONE added detail is generally not useful for anyone.
The only thing it shows is that something CAN be done, but it doesn't tell enough on the "HOW" part.
I am trying to encourage people to grow some reporting standards, for the general sake of public community.

If it offends you, frankly, I don't care.
I simply want people to provide reports that allow others to rule out "deployment bias" in form of either someone forgetting or not realising that some feature of their distro/hardware or something they set earlier has removed them one step from troubleshooting list and made it look like "it's just that one thing that needs to be set".

If you dare to attack and shame random people on the internet solely because they want to request some actually useful data from someone who has actually allegedly done some testing (therefore can probably deliver) then you shouldn't even be in this thread. Go try to aggravate people somewhere else.
And, as OP said, this thread isn't for "works for me" underhanded reports, it is supposed to be actually useful.
And simply not giving even fundamental relevant details does not count as such.

Thanks! That was enough to convince me to try – and enough to make a game running.
Works like a charm! :D

OS: Linux Mint 20.1
KERNEL: 5.8.0-50-generic
CPU: Intel Core i5-10300H @ 2.50GHz
GPU: NVIDIA GeForce GTX 1650
GPU DRIVER: NVIDIA 460.73.01
RAM: 16 GB
WINE: 6.10 64-bit
DXVK: 1.8.1

Thanks for the Wine 6.10 results @ciemnogrodzianin

I also posted my Lutris and Proton results to the Judas thread a couple days ago using Mint 19 to stick with GOG's Ubuntu 18.04 LTS official baseline.

Summary:

Distro: Linux Mint 19.3 "Tricia" | Cinnamon | 64-bit
Kernel: 5.4.0-65-generic
GPU: NVIDIA GeForce GTX 670
GPU Driver: NVIDIA 460.32.03
CPU: Intel i7-3930K @ 3.20GHz × 6
RAM: 32 GiB
Wine Versions: lutris-5.7-11-x86_64 / Proton-5.9-GE-5-ST

• 64-bit prefix
• DXVK
• Restricted to Single-Core

My test rig's fairly dated (2013), but on a clean desktop after clearing the RAM (as root: sync; echo 3 > /proc/sys/vm/drop_caches) the game runs flawlessly, even single-core.

I was getting some strange stuttering in default multi-core, but when I find time maybe I'll give Wine 6.10 a go and see if that clears anything up.