Hacker News new | past | comments | ask | show | jobs | submit login

> The elf binaries ran essentially flawlessly on my linux machine (although my machine was under powered for the game.)

> Sadly we never released the game on Linux to the public.

That's an improvement over not having a Linux port at all, as it reduces the investment needed to publish the game to Linux eventually. Once the Linux gaming market is big enough, studios might consider to release the game.




I'm not sure that's much of a distinction between not available and nearly available. Rumour is, WoW had an internal linux client for years, and that didn't help gamers.

That said, I wonder if being low-key not released multiplatform might actually mean there's likely less compatibility issues when playing with wine/proton.


WoW ran fine under Wine many years back, building a native Linux client would not make much sense.


The post you are responding to was pointing that this client actually existed - if I had to guess probably to allow people working on the server to test it directly on their machine - but was never released.


Absolutely, but my point is that even in that case, it would make more sense to run it under Wine anyway, instead of maintaining an entire build for a platform that is not officially supported.


I run Linux, and play games, but all in all, I strongly believe that Wine ports are the only realistic, less-worse, alternative. I'm not the only one - Carmack expressed the same (although, to be fair, I've never read other high-profile devs discussing this idea).

This is a real-world Linux game production story: https://twitter.com/bgolus/status/1080213166116597760. Note that the developers tried hard to release the native Linux port.

Crucial excerpt (from https://twitter.com/bgolus/status/1080214424474906624):

> We eventually laid out a guide with known good versions of Linux and graphics drivers, but it didn't matter. Part of the allure of Linux is the customizability, so few actually stuck to it, and generally wanted to run the game on older hardware we didn't support.

In order for Linux games production to be economically viable, there should be a Linux gaming standard, but because of the Linux culture, there will never be (there's nothing wrong; it's just its nature). Even if somebody came up with a gaming standard... xkcd explains what would happen: https://www.explainxkcd.com/wiki/index.php/927:_Standards.

I'm not considering adhoc Linux gaming distributions like SteamOS, as they would have to be treated as an independently installed, separate, operating system.


Same here, and I've also noticed the library churn is a problem: Heroes of Might and Magic 3 and Neverwinter Nights both have had official Linux ports/releases, and neither of them run on modern Linux distro's because of library incompatibilities (in the case of NWN, it's because of libSDL, don't remember the issue with HoMM3).

Even my recent purchases on GOG where there's plenty of native Linux to be found, I usually download the Windows version because WINE is a more stable platform in the long run, in my experience.


The latest version of Neverwinter Nights Enhanced runs without issue on Linux Mint 20.

The Beamdog Client no longer seems to work (pango lib issue), but GOG installs just fine. I like Beamdog and appreciate their ongoing support for Linux and have in turn purchased NWN gift keys for many people, but man - fix the Linux client please.

(Beamdog, feel free to contact me and I'll fix the broken client for free - seriously).


To be honest wine is so awesome it makes games run better even on Windows.

On another computer I had, with the supremely buggy nVidia Optimus, SimCity 4 and Arcanum: Of Steamworks and Magick Obscura both worked correctly only with Wine DLLs on their folder, preventing them from using Windows normal APIs.


HoMM3 has an open source port, and NWN not because of LibSDL, which still works, but maybe with GL functions, something solveable with an env var. If it's OSS related, wrappers exist.


There is the steam linux environment [1] which is pretty standard for native linux builds on steam. And that works independently of the distribution steam is actually installed on. I think it should be possible to use it without steam too..

[1] https://github.com/ValveSoftware/steam-runtime


The libs in the steam-runtime are often times very old. The newest compiler for building inside the runtime seems to be gcc 5. I understand the need for stability, but why isn't this stuff updated from time to time?


because you would need multiple runtime versions and games would need to target a specific runtime version.

because if you don't keep your game up to date, it would not run. in windows you basically can run games for way longer because libraries are way more binary compatible. for running webservers/cloud whatever a breakage doesn't hurt and removes old crud, but sometimes the old crud is used in xyz in a way that nobody tought and without it the game would crash, that's why you would need to target a specific runtime.

the same thing more or less did windows up to 7 relativ well, via the version selection. unfortunatly windows 10 broke some games even with the version selection.


Hollywood sees it otherwise with the VFX standard.

https://vfxplatform.com/


What you linked is more about programs relying on the same computer graphics libraries that then need to rely on the same system libraries.

Games stand alone and don't need this integration.


If you compile everything statically yes, otherwise yes they need this integration.


Games can have their dependencies shipped with them with or without static linking. They aren't transferring data to another game that has to line up exactly.

CG programs and renderers need to have subdivision surface data be the same and image filtering be the same. They may be able to architect their way around standard library versions, but games don't need this same treatment because they stand alone.


> because you would need multiple runtime versions and games would need to target a specific runtime version.

Yes. Steam already supports multiple Proton runtimes, why not multiple Steam runtimes as well? With the latter, native Linux games could say in their metadata which one they need and the user wouldn't even notice.


> And that works independently of the distribution steam is actually installed on

Not entirely, it still relies on some system libraries, and you will see there are times where games do not run on Arch despite using the steam runtime. It is known.


> there should be a Linux gaming standard

As bizarre as it sounds, it is looking like the "Linux gaming standard" is really the Windows API. And that's where we are.


Thanks for the links, that's quite revealing.

> auto reported crashes and support tickets (most gfx driver related)

I wonder if open-sourcing the game would see those same support tickets come in with patches.

Part of linux has always been about patching it up yourself. Rather than being a time sink for the developer, these linux bugs could actually be a way to crowdsource code improvements.

I know there are intellectual property concerns that prevent open-sourcing commercial products, but maybe there's some sort of hybrid solution to be found.


Disclaimer, I love Ubuntu server.

I hate that Linux philosophy for a daily driver. I remember being age 16, 17,18,19 23,26, and 27 and being told to figure it out. Every time I'm vastly more fluent and the community is just as unhelpful.

There's nothing intuitive about computers, a human came up with the rules. The negativity is cancerous.


Wine has a non zero overhead compared to Linux or Windows. Maybe one could come up with a mix of the Win32 API and Linux calling conventions? IDK. Or design something from scratch entirely, but then you have to write and maintain a translation layer like Wine for the rest of time :). Ideally one would take Wine and remove the overhead causing parts but keep most of it intact.


If the Windows program uses the Vulkan API, I imagine the Wine layer wouldn't be doing much work, would it? My guess is that the function-call conversion doesn't cost much on modern CPUs.


It's not just the graphics API. These phoronix benchmarks show worse Wine performance even on CPU only tasks: https://www.phoronix.com/scan.php?page=article&item=wine-ubu...


Interesting link, thanks.

It's curious that Wine outperforms Windows on some CPU-intensive tasks, but is far slower for certain others. The article just gives the numbers, but doesn't give a deep analysis. Perhaps cache issues?


Most Android games could be easily ported to GNU/Linux, that just doesn't happen because studios don't see any commercial value in doing so, versus the development costs of supporting yet another platform.


I'm doubtful about this. Even though Android uses the Linux kernel, its userspace is completely different; There isn't much overlap in the APIs you can use on Android vs ones you can use on desktop Linux, besides a few things like openGL and syscalls.


I am fully aware of it.

ISO C, ISO C++, OpenGL/Vulkan, OpenMAX and OpenSL ES are certainly available on GNU/Linux.

https://developer.android.com/ndk/guides/stable_apis

Just as Cocos-2dx, Unreal and Unity are, the main engines used on Android games.

However, having 2% of users responsible for 50% of support requests + extra development effort, is what puts GNU/Linux off their plans.


>having 2% of users responsible for 50% of support requests

If you're referring to [1], you might be interested in reading [2] as well.

[1] https://twitter.com/bgolus/status/1080213166116597760

[2] https://twitter.com/bgolus/status/1080544133238800384


I am aware of those tweets, although my remark was based on experience among game developer friends all the way back to the Loki days.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: