Live data from Hacker News

Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

twitter.com

291–300 of 415 posts

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#291

Earlier quoted context omitted.

Most games don't make these mistakes...it seems they weren't aware of some other best practices. I see this time and time again. Game developer runs into one of the difficult subjects in computer science/programming. Dismisses the difficulty. Gets themselves into trouble. Blames the library/product/platform. The last time I was at a game jam, I found myself explaining generational garbage collection to a game dev. He…

> I see this time and time again. Game developer runs into one of the difficult subjects in computer science/programming. Dismisses the difficulty. Gets themselves into trouble. Blames the library/product/platform. Members of this particular team worked on the highly acclaimed Total Annihilation (1997) and Supreme Commander (2007) so inexperience or lack of technical expertise seems unlikely to be the cause here.

Parts of PA are brilliant, absolutely brilliant. The team pulled off some incredible feats:

- In a 16-player game, each player can operate thousands of units across multiple planets orbiting a star, and afterwards, you can replay the match exactly within your own copy of the game.

- The planets themselves were mobile battlefields which could be destroyed, moved, and weaponized.

- The path-finding for those thousands of units crashing into an opposing army of thousands of units is smooth and there isn't total chaos on the field.

But the team also made some really questionable bets that ultimately doomed the title.

- Then, for some reason, they used an out-of-proc UI compositor to draw the 2D elements that would fork one process per layer IIRC and drop interaction events, and broke the tool that the players use to interact with the wonderful simulation.

- Then, for some worse reason, they launched it like this, and reaped the terrible early reviews that doomed the title. Even after patches resolved the issues, the long-term damage was done.

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#292
post #224
post #127

Earlier quoted context omitted.

> And distos aren't backwards compatible. ie when libcurl4 is released, they remove libcurl3. So you can't have one binary for Ubuntu 18.04 and 16.04. If you don't want to depend on the libcurl provided by the OS, ship your own. If you don't want to depend on the glibc provided by the OS, ship your own, with your own dynamic linker. readelf -n will tell you the oldest kernel that will run your stuff. Put that in the…

Your suggestion to ship glibc caused coffee to end up over my keyboard :) This is the road to hell, but you'd only know that if you had the slightest clue of the ABI interactions involved in swapping out a core library like that - starting with the reality that parts of the (probably binary-only) graphics stack must be linked and loaded in-process, and they naturally depend on at a minimum glibc. Your suggestion is t…

glibc is pretty good at ABI backwards-compatibility. The right thing to do would be to statically link libstdc++, libgcc, and extras like libcurl, but dynamically link libc, libX11, and libGL. Luckily libX11 and libGL are pure-C so you can get away with static-linking libstdc++, which means you can use whatever C++ version you like.

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#293
post #128

Earlier quoted context omitted.

Technically speaking I'm sure you're right. In practice it doesn't really matter though, if they did it that way it's either because it was easier or because that's the way they were used to doing it. The fact that "technically" it's not Linux's fault doesn't really matter, unless you're more interested in the moral concept of guilt rather that the practicalities of making a Linux port of a game. Why should they chan…

> In practice it doesn't really matter though It does matter unless you just want linux to perfectly emulate windows APIs you will always have to do work to port to a different platform. Choosing the wrong tools for the job and then blaming the platform is just bad engineering. I don't bitch about how hard it is to assembly my desk because it requires a socket wrench when my last piece of furniture only required a sc…

Counterpoint: There's a reason IKEA packs Allen wrenches into everything it sells.

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#294
post #62

I work for a small company that produces a DAW and VST plugins. Supporting Linux is a huge amount of work compared to Windows and Mac. The main issue is that 'Linux' is not a thing you can support. You have to pick the distros you want to support, and then once you've picked a distro, what versions you want to support. And you need to use the C++ version that ships with that distro, so if you want to support old vers…

Why use not Electron? Take a look at vscode it has plugins and it seems to work everywhere.

Friends don’t let friends use Electron

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#295
post #286
post #224

Earlier quoted context omitted.

Your suggestion to ship glibc caused coffee to end up over my keyboard :) This is the road to hell, but you'd only know that if you had the slightest clue of the ABI interactions involved in swapping out a core library like that - starting with the reality that parts of the (probably binary-only) graphics stack must be linked and loaded in-process, and they naturally depend on at a minimum glibc. Your suggestion is t…

Ignoring your personal attacks, you and I are on the same page. I do agree that shipping your glibc is "the road to hell" and shipping with the glibc could be qualified as "shipping in the form of its own Linux distro", as amusing as that sounds :) But that's the price of freedom you pay if you want to draw your platform boundary at the kernel -- you need to ship the whole userland! Where's the surprise in that? That…

Why would you want to take on that massive burden for such a tiny percentage of sales - most of which you'd have gotten anyway?

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#296
post #53

Linux is the perpetual scapegoat. They selected a middleware, Coherent UI, that didn't work properly on anything but Windows. They also didn't make proper use of the Steam runtime, a mistake that continues to cause issues. Most games don't make these mistakes, so this isn't really representative of the larger state of Linux gaming. It's worth pointing out that the devs did make a legitimately good attempt at making L…

Saw "Coherent UI" in your comment and thought, "I bet it's Planetary Annihilation" and was not disappointed. The dev team struggled to get Coherent UI working on Windows, to say nothing of Linux. They switched to Coherent UI late in the development cycle and the beta/launch was constantly glitched out. The problem with trying to run an out-of-proc UI renderer within a game loop were so numerous -- the game would freq…

Truth be told I don't think PA ever had a chance to truly be big. So few people wanted the Supcom style gameplay. Forged Alliance Forever only has a couple thousand people and the best or second best commentator/stream of games (Gyle) gets only a few thousand views per video. I think the gameplay style just doesn't appeal to as many people

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#297
Steam and the work that Valve has done on the linux side seems to show that's not the case. (They've managed to port quite a lot of linux games).

This sounds like a case where a platform wasn't a priority for their business was showing that it had bugs.

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#298
post #53

Linux is the perpetual scapegoat. They selected a middleware, Coherent UI, that didn't work properly on anything but Windows. They also didn't make proper use of the Steam runtime, a mistake that continues to cause issues. Most games don't make these mistakes, so this isn't really representative of the larger state of Linux gaming. It's worth pointing out that the devs did make a legitimately good attempt at making L…

From the article: > "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." It seems that it's because Linux users are unwilling to upgrade their hardware. From a philosophical standpoint, I agree with them, we…

I bought PA early, and tried playing it on a low end 2007 laptop, and it was almost playable. The same machine could only barely handle supcom on lowest settings anyway. Meaning, if your hardware could handle supcom well, then it could probably handle the basics of PA (at least that's my bet)

They should not be expected to support systems that could only kind of handle the previous game anyway

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#299
post #66
post #17

Earlier quoted context omitted.

Your comment is the perfect example of how there's an "invisible" demand demand for gaming on Linux. Nobody can see it, because those who want it will mostly make do with Windows.

Invisible demand is undistinguishable from no demand, as far as B2C is concerned.

Not true. Invisible demand is a potential market and a bunch of prospects in waiting.

However that niche is way too small to be worth it.

Re: Game dev: Linux users were only 0.1% of sales but 20% of crashes and tickets

#300
post #224

Earlier quoted context omitted.

Your suggestion to ship glibc caused coffee to end up over my keyboard :) This is the road to hell, but you'd only know that if you had the slightest clue of the ABI interactions involved in swapping out a core library like that - starting with the reality that parts of the (probably binary-only) graphics stack must be linked and loaded in-process, and they naturally depend on at a minimum glibc. Your suggestion is t…

glibc is pretty good at ABI backwards-compatibility. The right thing to do would be to statically link libstdc++, libgcc, and extras like libcurl, but dynamically link libc, libX11, and libGL. Luckily libX11 and libGL are pure-C so you can get away with static-linking libstdc++, which means you can use whatever C++ version you like.

It's definitely technically possible to find a hacky combination that works today, but only by shouldering the cost of understanding all the possible deps and symbols and the structure of their underlying objects used by all possible e.g. graphics drivers and X11 libraries now and into the future. You can hack around it today, but it's a fool's game and absolutely not something that can be relied on to continue working in any sound manner, without risking e.g. some memory corruption due to a struct layout difference long in the future, etc.

I wanted to check whether the official Nvidia driver uses C++, but it's not installed on this machine just now, and of course that I even have to check just highlights the problem with this approach.

Post reply on HN