For a long time, an overwhelmingly popular view among game developers and publishers has been that offering Linux builds would involve too much work, because they had either tried it briefly or heard from other devs who had tried it, and found that their problem reports massively increased. Their conclusion was often that Linux causes too many bugs to be supportable. As a gamer, I was of course disappointed every time I read this.
More importantly, as a developer, I couldn’t help noticing ways in which this reasoning seemed flawed. I always felt that it was either poorly informed or not completely honest.
So, when this refreshingly different perspective from a game developer surfaced on social media, it warmed my heart. I thought the rest of you might find it interesting.
That was a few years ago. I imagine the influx of gamers using Linux since then (since it’s easier now) might mean a smaller portion of our group has the technical skills described in that post, but I think it still applies. I hope it also gives us something to aspire to when interacting with the people who make the games we play.
In a perfect world? I fully agree.
In a world where I am limited by hours in a day and how many engineers I have on staff? A bug that nobody knows about is not a bug. That is obviously playing with fire because there is a big difference between “if you unequip and reequip a flashlight over and over it will make you invisible” and “if you mash these four numbers at once then the ATM will wipe its cameras and start spewing benjies”. But for the purposes of adding new features/maintaining developer sanity? Yeah…
I dunno. This comes up a lot. I am going to ignore the circle jerk of “linux users are smarter and make better bug reports and also have bigger dicks” because… either people are slipping their hands down their pants or they know that is nonsense.
But I think it DOES ignore the reality that adding actual support for a new platform does drastically increase the testing and build/deployment overheads which are usually the realest of costs anyway. And… truth be told, I think the standard of “Don’t break Proton support. Fix things as they come up” really is the best of both worlds.
Determining that a bug isn’t a priority is fine and doesn’t require burying heads in the sand.
Its not burying your head in the sand.
If it is isolated or people just don’t care? Then… it kind of doesn’t actually matter. You scan the forums and optimally have community managers/PR people to do the same to keep an eye out for “This was weird?” style comments but you mostly focus on the stuff that naturally rises to the top or that you identify as an issue.
The more bug reports you have? That is engineer time spent assessing what is and isn’t a priority. And the sad reality is that it is a LOT easier to say “we have our five thousandth number one priority” rather than to say something doesn’t matter. Because if stuff does go down? Suddenly you are on record saying the most important thing ever (whether it is a critical vulnerability or just something people fixate on) didn’t matter and you can bet everyone will throw you under the bus.
As a developer? I want every bug reported to me because I genuinely do want to make the best product I can. That said… if you don’t care enough about reporting a bug or it isn’t reproducible enough to matter… I am not going to complain about getting some extra time to work on things that actually interest me. Which may very well be trying to reproduce that “weird behavior” myself because it sounds like it could be bad.
And… as someone managing a project/team of developers? I can watch in real time as people become more and more drained as every single day is fixing all the “this would be low impact if we were allowed to call it low impact” bugs. And that person who clearly was bored and searching for the corneriest of corner cases (the bug that “nobody knows about”)… that causes significant psychic damage to the person who reads the report and has to fix it.
It sounds like you’ve worked in a pretty bad development environment in relation to bugs in the past
This takes a hell of a lot more time than just reading a bug report and adding it to the list.
From your comment, I doubt you’ve ever done any software development before.
Did you read the post? It says, “This 5.8% of players found 38% of all the bugs that affected everyone.”
Bugs that affect everyone are not bugs that nobody knows about.
And beyond this specific game, let’s remember that it’s very common for players to experience bugs without filing bug reports, but still complain (either to you or publicly) about your broken game. So you won’t have identified these bugs, but they will still be out there affecting player experience. If you don’t care about that, consider that they will also affect word of mouth and reviews of your game, and therefore your sales.
We’re all limited by hours in a day. That makes this all the more important: A bug fixed once is a bug that doesn’t consume support time (and budget) ever again.
As a dev with many years of experience, a bug no one knows about is ticking timebomb waiting to blow up when you have the least amount of time to deal with it.
I’d much rather have it captured and known where I can try and find time to fix it then have it blow up in my face.
Thats not at all what’s going on here. These are bugs that are affecting everyone but weren’t previously being reported. The users know, even if their response is to bang their head against the keyboard, frighten the cat, and vow to never give you more money instead of filing a report.
Good bug reports are gold.
And then you just get really weird. You OK?
There is a world of difference between a bug that doesn’t get reported because its impact is minimal and a bug that doesn’t get reported because people can’t be bothered to make the report and just live with it. The latter category is where the general complacency of 94.2% of players makes a negative impact.
It also leads to people leaving negative reviews on steam. It’s a lot easier to leave a bad review than to report bugs.
No, this is absolutely wrong. Most people don’t report bugs, they just stop using the product and move on.
Yes, time is limited, so you won’t be able to fix every bug, so you need to prioritize. How can you prioritize something nobody reports?
FOSS has a culture of reporting everything, but not necessarily fixing everything. Look at release notes and you’ll see bugs getting fixed that were reported 20 years ago. Does that mean they fixed all the recent bugs and they’re finally getting to the harder ones? No, some bugs reported today won’t get fixed for another 20 years. All it means is it finally got prioritized or someone really wanted to fix it.
Linux gamers don’t expect every bug report to result in a patch right away, they just want to add it to the pile. Maybe a dev sees it and fixes it along with higher priority fixes, idk, but it can’t happen unless it’s reported.
Sure. Most Linux users don’t ask for a native build, they just want it to work on their platform. But even Proton support requires some level of testing.
Whether you go with Proton or a native build, the takeaway here should be that you’ll get a lot of free QA and detailed bug reports, so even if you don’t break even on Linux sales, you should come out ahead with that added QA.
What are you basing this opinion off of? Do you have any evidence that would lead you to think this way?