+1 for Linux native app, but realistically this is why I run Windows in a kernel virtual machine.
Don’t think I saw anyone post this or not but there’s something I’ve always assumed there was one massive roadblock when it comes to a Linux workstation/PC and games, and that’s the non-standard environments users operate in. UNIX and UNIX-like OS kernels and graphics APIs aren’t the problem, Sony has based the PlayStation OS off of FreeBSD since the PS3. Nintendo also used its kernel to power the switch unless I’m mistaken. But those platforms all have something in common with Windows and that’s the single, predictable, engineered environment to build the game for.
In the Linux world we’ve got X11 or Wayland, Vulkan or OpenGL (for legacy), KDE, GNOME 3/40, Xfce, lxde, etc… with who knows what kernel version and extensions/drivers/mods… Now I do understand that 90% of all that stuff I listed off shouldn’t make a bit of difference to a game (at least on paper), but the Linux port of Shadow of Mordor is a great example of how this can impact experiences of the end user.
On KDE it ran fine in full screen, on GNOME 3 I had odd graphical pop ins from the top bar and occasionally my mouse could trigger the app search function if I moved it just right.
All that is to say, imagine trying to support an end-user with that wildcard setup. This is normally when I hear people argue that they put work in with WINE to get a game to work, they’d be willing to work with Larian on this too (And I suspect for many folks that’s true). but I’ve found a lot of times the relationship between consumer and vendor changes once $$$ is exchanged for something that’s supposed to natively work on a platform. There’s a much higher expectation placed on Larian or any developer to support the thousands of disparate configurations of a “desktop” on Linux based operating systems, and that’s not something they want to tackle while trying to get their game running on the 5-7 platforms they’re targeting at the moment.
Now just as container tech like Docker and podman have made shipping programs to run predictably in every Linux based OS much easier, there is similar technologies to containerize graphical applications to circumvent all the pitfalls having to support 20 DEs and 30 window managers can create. Flatpak is one that comes to mind, Docker has an implementation of it too (though I’m not as familiar with it). That may help circumvent the problems Larian may run into if they want to pursue a Linux native client for BG3, as they’ll just need to target the container runtime rather than the host system.
Anywho I’ve rambled enough, and I may be all wet when it comes to the actual issues developers run into that make them avoid native support for Linux based Operating systems. Kudos if they can/want to do it, but I’ve got a backup plan if they can’t/won’t
