Hacker News Reader

Comment by QuantumRoar | Hacker News Reader

Hooray for Linux!

But there's something that has been bothering me for a while about games for Linux compiled with the Unity SDK.

Does anybody know what kind of dependencies a game written with the Unity SDK has? I'm pretty clueless about that stuff but I'd still like to know what it would take to get a game running on a minimal Linux install (like a naked Arch or Gentoo). Ubuntu obviously comes well equipped for the task but I don't really care about that.

So where do the graphics come from? Does it need some special libraries apart from OpenGL? Where do fonts come from? How does it interface with hardware, i.e. does it need X, or does it come with its own drivers for keyboard, mouse, gamepad?

I fear that it is necessary to install half of Ubuntu to get the games running but - as I said - I don't really know anything about that.

View on HN

So, having tried to offer support for a game on linux before it's a giant nightmare. If you don't want to open source you end up with a never ending support task.

Unity should solve that now. Maybe.

To answer a few specifics with out getting too ragey:

To get real usable 3d you need to be running the proprietary drivers. The opensource ones at least a year or so ago when I was paying close attention were uniformly too slow and supported such a limited subset of the specs that the were usually pointless.

The take away for me was to always assume that the user system is completely dumb and to ship EVERYTHING. We ended up packaging the kitchen sink to get rid of the majority of the "I installed this on <nightly build of obscure distro> and it says it can't find libc" issues.

Two of the open source drivers (radeonsi and nvc0) support OpenGL 4.1 now (though only if you've got a bleeding edge build of Mesa, built against bleeding edge LLVM). This is obviously still pretty far behind, but at least it's caught up to OS X.

The performance of radeonsi isn't terrible (though that's partly because the proprietary AMD driver sets the bar kind of low), though still generally slower than the proprietary one. There are some experimental instruction scheduling changes in an LLVM branch that appear to give better performance than the proprietary drivers for at least some benchmarks.

On the Nvidia side it's pretty much proprietary or bust though. Featurewise it tends to be in good shape (at least in comparison to the other open source drivers anyway), but there's no support for changing the GPU clock so performance is terrible.

Offering support for a game is a never ending support task. If you aren't willing to support your users, you aren't ready to publish games. Don't blame Linux users.

You're basically saying "don't support Linux unless you're prepared to spend 50% of your support budget on 5% of your customer base."

And then people wonder why so few devs support Linux.

You're being disingenuous. Every platform requires support, which takes time. It's unreasonable to expect Linux to be an exception to this and not take any time. If you planned on Linux being the special platform which doesn't cost anything to develop for, your disappointment is due to unreasonable expectations.

Linux is the exception because the support burden is much, much higher per user because "Linux" is a catch-all for what is really several operating systems that share a kernel and some userland code, so supporting Linux is much harder than supporting, say, Windows.

Yeah, you can support Windows 3.11, Windows 95, Windows 98, Windows ME, Windows NT, Windows 2K, Windows XP, Windows 7, Windows 10, Windows CE, Windows with single simple exe file, while Linux users needs to execute complex commands, such as "yum install package", to install install software which will perfectly match their environment only.

Lol yeah try running a windows 95 game in windows 8 for fun you will see most of them fail

You know as well as everyone here that "Windows support" generally means two or at most three versions of Windows, and that adjacent Windows versions are a lot more intercompatable than any pair of Linux distros. What do you gain by pretending to be stupid?

It's really a problem with two dimensions. There's versions of the same OS, and then there's incompatible operating systems. You can kinda make the case for Windows being three different OSes, but the Win3.1/Win95 tree has been dead for over a decade, and Windows CE was never really positioned as being compatible with other Windows anyway.

And it's not like Linux doesn't come in versions, and it's not like a change in versions doesn't have similar compatibility concerns as it does in Windows. (Honestly, I think it's worse on Linux -- it is a lot easier to run the same version of, say, MySQL on consecutive releases of Windows than it is on RHEL/CentOS.)

So post-XP, where Windows NT ate DOS-based Windows, you have Windows progressing version to version -- Vista, 7, 8, 10. You can see the same progression in Linux OSes -- Debian goes Etch, Lenny, Squeeze, Wheezy, Jessie over a similar timeframe. But at the same time, Fedora runs from version 6 around Vista's launch to version 23 due out in a few months from now. So, like Windows, you have a concern with making an application run on both, say, Squeeze and Wheezy. But you also have an additional problem where you need to make it work on Beefy Miracle. For most software Linux users come into contact with, developers will write software for one, maybe two distros or so, and each distro ports the software over, essentially. So every open-source project is essentially forked by each distro. It's not a model conducive to closed-source software. Which... there are plenty of people who are openly happy about this, as they would rather encourage open-source software over closed source, so it's not like this is strictly an accident or a mistake. But if you want to ask why games don't get Linux ports, or get Linux ports that involve running the Windows version in a Wine wrapper, that's a big part of the answer.

Commercial developers from Windows world are missing huge paradigm shift which happens outside of Windows world: there is no installers anymore. You cannot install Android app on drive C: or drive D:, you cannot install GMail into c:\googleapps, you cannot do "yum install --from app.exe --to c:/myapps", etc.

What will happen if Google will provide installers for all their services instead of publishing them on the web, if Android developers will do same instead of publishing in PlayMarket? How much support they will need to cover all hardware and software?

There is no problem with supporting of whole Linux, on all OS'es and HW if you understanding it. Opensource developers are doing that for free.

To support 3 major versions of Windows in at least two localizations and in few flavors (home, pro, server, etc.) with different set of software installed, which may affect installation process, you need farm of Windows machines and extensive testing. It looks like that to test various Linux distributions you need a lot more hardware and time resources, because there is so many of them.

In reality, to support a linux distribution, you need to install distribution in a virtual machine, install your application manually (on your side, not at client side, so you can skip all bells and whistles), package result, then publish result into your own repository. So to support 10 major distributions, I need 10 virtual images and about 10 days. Feel the difference.

PS. Sorry, my English is not perfect. I cannot even talk in English.

See below.

The post you responded to specifically said that Linux support is substantially more difficult that supporting any given other platform. Do try to keep up.

Linux users aren't the issue. Nor am I attempting to blame them.

The problem is that basically you are always aiming at a moving target of system configuration when you release. Do you bet that your users have mechanical disks or SSD? If you aim for the latter you can make different choices. Windows as an operating system moves pretty slowly compared to the broader linux ecosystem, your percent users running a particular version of say DirectX is easy to guess, and easy to predict.

The problem when you move to linux is that the landscape is shifting rapidly. Everything from the kernel to libraries to what Distro is hot this week change nightly.OT steal mikepavone's example; In the last few years how many new families of windows video card drivers have come out? How much change have we seen in their capabilities? On linux the answer is, frankly, impressive.

This is great for linux, but it makes it hard to reach out to the smaller percent of the small percent of users who are having an issue and fix their issues.

The result is that at release you can just let that windows binary sit there and maybe fix a few bugs that crop up in your code. Your linux binary is more of a surfing act where things are great, then you are slowing down, and something breaks, and the whole tower comes down.

Fundamentally, it's why things like Unity are popular. The fewer people on a team, the less time you have deal with things like compatibility issues.

> Your linux binary is more of a surfing act where things are great, then you are slowing down, and something breaks, and the whole tower comes down.

This is why you use Steam Runtime and don't worry about that. It's does work even outside of Steam:

https://www.reddit.com/r/gamedev/comments/26pck1/selfcontain...

I am not sure this is the solution, but you could call "ldd <file>" on a unity generated binary to see system dependencies. If they statically compile stuff into the game, that's another question.

Good point. Though, I don't have such a binary.

Get Kerbal Space Program! And then play it after checking its library dependencies!

Or Cities: Skylines, another excellent game that uses Unity.

Between those two, I've probably sunk whole weeks of my lifetime. If someone were to make a game that combined the two into some kind of orbital city builder, I'd be set.

Make KSC into a project your city can build, and all the money it spends goes into your city's economy.

From KSP (unity via steam)

linux-gate libdl libpthread librt libGLU libGL libX11 libXcursor libstdc++ libm libgcc_s libc libnvidia-tls libnvidia-glcore libXext libxcb libXrender libXfixes libXau libXdmcp

Thanks a lot.

I know that steam has some 32Bit dependencies even on a 64Bit OS. I thought it might have only been the steam client's dependency. Unless you're using a 32Bit OS, it seems that Steam, or maybe even Unity3D, enforces the use of those 32Bit libs.

I wonder why.

Edit: I seems that you removed the references to lib32 and i386.

I think its a red herring. KSP (and unity games in general) ship as either x86 or x86 and x64. Full output for ldd of both of them is here http://pastebin.com/KAYF4TFw

> I fear that it is necessary to install half of Ubuntu to get the games running

This could be a good use case for Docker containers. I remember they showed Quake running on Docker at a convention so it should be possible.

Reply on news.ycombinator.com