It's because of things like this that I won't play closed-source games anymore. The modding community has demonstrated repeatedly that they are willing to maintain ports of these things, but only as long as the source code is open so they can actually, you know, do the port properly.
And before someone rails on me about anti-cheat, or about reduced profits because of the whole game showing up on torrent sites, I'm not talking about that stuff -- I'm talking about the bare minimum client code that is required to run the game.
Serious question - What open source games do you play? I'd consider myself a "gamer" and I can't think of many recent successful games that are open source. Indie games sure, modding support sure, games without any DRM sure.
I don't really have much to say here, if your definition of "successful" means giant console release with a multi-million dollar budget, then obviously I can't say anything because the console manufacturers all ban open source on their platforms. And making a giant list of every small open source game I've ever played is not something I have time to do right now. There are a lot of them. Many of them I've found just because they are side projects that people post on HN.
I think there used to be an informal expectation that games in the Humble Bundle would be open-sourced if they did well there. (Just the code, not the art assets etc.)
Nethack's still being developed. You could say it's 'early access'. Probably my favourite game ever.
Of more recent origin, Space station 13 is great. It's a tile-based multiplayer (up to about a hundred) in-depth space station disaster simulator. A stable community of servers and players, innovating and sharing patches among the various major code branches.
(The codebase is a nightmare because the game's written in an ancient engine from the 90's, but that just makes what they've managed more impressive.) It's been over 10 years of intermittent, branching, and re-merging development.
I absolutely love that game. I'd really like to see people play it live on Twitch, I think it'd go really well with the live chatting dynamic. There has been very few, but they always use tiles and I don't want tiles overwriting my imaginary version of objects.
There is a slow trickle of open source games coming out, but you have to actually look to find them. Github does contests for it every year: https://gameoff.github.com
Some closed source games get open source engines, if the game was good enough in the first place to motivate a team of open source developers. Morrowind (OpenMW), Rollercoaster Tycoon 2 (OpenRCT2) and Transport Tycoon Deluxe (OpenTTD) are three very nice examples. All three engines are much better than the originals.
If user base on those platforms is very small then it makes no sense for the developers to spend resources to keep it updated. At the end of the day its about demand and supply.
So I have no experience in 3D graphics and very little experience in game design (I wrote a 2D game in high school but that's it), but if they are already going from DX9 to DX11 why don't they go to another library that supports all the platforms they already develop for such as Vulkan? I'd imagine that would better future-proof their game to make adapting to other platforms that are released in the future easier. So how hard would it be to go from DX to something else? As stated before, I have no experience in this area so I'm being completely sincere with my question.
The developer has come out and said that as of the announcement of them dropping support for Mac/Linux, the two platforms combine make up 0.6% of their active player base [1]. I am guessing they just did the math and decided the cost of switching APIs to something like Vulkan is not worth it when such a small portion of their users would benefit from it.
Yeah, that is completely understandable. I was just curious why they wouldn't invest in developing for a different but more cross-platform library so that maintaining Rocket League on platforms such as the Switch and Playstation 4 (as well as the future consoles from both manufacturers) would be easier. They have stated no plans to remove support from those consoles, and I don't imagine they are much easier to maintain compatibility with than macOS or Linux.
As they stated, most of their players are on windows. If windows is your target market, then DirectX is generally the graphics API you want to support. You don't want to make architecture decisions because one or other approach would be untenable to below 1% of your target. Cross-platform is not a value as such.
At some point, somebody needs to actually tell the hardware what to do. If you're doing 3D graphic rendering in real time, that point is probably now. There are no magical abstraction layers that can let you do performant 3D graphics without paying attention to what's going on at the API level.
Typically a DirectX revision bump would be less work than a totally different API.
To answer "How hard could it be?", the answer is, "Surprisingly hard". Games rely on weird interactions with hardware and need to smoothly render at a consistent FPS. Often a revision bump in a library might introduce subtle changes (for example, a difference in how numbers are rounded might cause z-fighting or change the way shadows are rendered). All of those need to be discovered and fixed. Not to mention that DirectX uses a totally different shader language than Vulkan, so you have to get in there and translate all that code over.
It's definitely non-trivial. Doable, but non-trivial. I don't blame the devs for making a cost/benefit analysis and realizing they would never recoup the cost.
Given the economies of the games industry (where studios are basically always one step away from complete failure and being dissolved into nothing), I appreciate the need to focus on not losing money in this way.
> Not to mention that DirectX uses a totally different shader language than Vulkan, so you have to get in there and translate all that code over.
Vulkan doesn't really have a shader language unless you want to write SPIR-V assembly. Thus you'd use either GLSL or HLSL.
Microsoft's own DirectX HLSL compiler[0] supports SPIR-V as a target in addition to DXIL.
Thanks for the explanation. I guess part of why I'm confused is that they have not stated any plans to stop supporting Switch and Playstation 4 versions of the game and in my mind those are probably just as difficult to maintain as the macOS and Linux version. Do Nintendo and Sony provide support here that make it easier for Psyonix to port to their platforms, or are there just so many more players on those platforms that it is worth the investment?
Good point! I mostly deal with embedded systems so I often forget the difficulty of maintaining a piece of software that needs to run on basically innumerable hardware and software configurations.
Reading the article, it appears that the issue is with the supported functionality and not with the literal library. They already had been using OpenGL instead of DX9 on Mac/Linux but they cannot use it instead of DX11 because the features they need are not available in that version of OpenGL.
Rocket League is made with Unreal Engine 3 so if they wanted to port the game to using Vulkan they would also have to upgrade the game to Unreal Engine 4.
The player base on PS4 and Switch is large enough to justify dedicated engineering support. Mac and Linux on Steam are not. Interesting enough iOS and Android might be big enough markets to put Mac and maybe Linux support back on the table, if they decide to make a mobile version of Rocket League. If Google threw a bunch of money at them for Stadia support Linux could come back also.
From what I understand, they also removed key features (like multiplayer) for people that have already paid for the app. They will not be getting refunds for in-app purchases.
Multiplayer requires latest version, so no getting updates results in losing multiplayer. I agree refunds would be a decent move given that multiplayer is the main selling point of the game though.
I think you're missing the problem for the consumer.
If I bought that game, because it means I could play multiplayer with my friends and now they are removing that feature <3 months after I bought the game, then I would not be a happy camper.
I don't think anyone truly expects a game's multiplayer should last forever, but it should last while the game is still popular and releasing updates.
Totally reasonable to be unhappy, sadly it's a common occurrence in this era of live services. Sometimes you buy an online-only game and the servers go down a month later. If you're lucky the devs will be nice and refund you, sometimes they don't.
They leave a gap in the market where a competitor could emerge.
EDIT: I know the gap is small, less than 1% but it is still a gap. If a competitor could emerge in a small gap like this is a question I cannot answer. There is potential for growth (especially if Microsoft slips up heavily which they almost did) but so far that growth hasn't happened and the future is hard to predict.
It is rumored that Steam uses Linux for leverage in negotiations with Microsoft. Therefore it may have a big strategic value for them even though the numbers are still so low.
I mean, Valve's Linux support happened because they were spooked by the Windows Store and the idea of a possible future iOS style lockdown leaving them shut out of the market
However, Bungie started as a Mac shop, and Stardock started as an OS/2 shop. It's possible to make the claim that had more commercial games been available to these relatively small platforms in the 90s, there wouldn't have been enough space for these game companies to emerge.
As I said, I can't prove that. It's quite possible these companies would have been successful anyway.
The point of dropping support for those platforms is that the market isn't there. There is no gap to fill. There are maybe a few thousand people who will lose the game (unless they use bootcamp or wine).
Games cost money to make. If a game doesn't have a chance at breaking even, it needs external funding or free labour to get it made. This is the economic reality of how games get made.
I don't have good numbers on Linux sales but Rocket League sold over 10 Million copies back in 2017 and Steam had 0.67% Linux users. That would make the estimate 67000 Linux users back then and probably a bit more today.
That's probably not enough for a competitor to make any money, especially since they could only catch a part of these users.
That 10 million copies includes all the free ones they gave away on the Playstation. That's 10 million copies between Playstation, Xbox, Windows, Mac, and Linux. Some articles state about 40% of users were Playstation users with Steam users only being 30% [0]. Assuming the rates stayed the same and that an even number of Linux users bought the game as Windows (quite an assumption either way on both statistics) that would put the estimate of Linux Rocket League users closer to 20k, or 0.2% of the total purchased base. Overall, all these numbers are old and the final estimates are based on some big assumptions which may or may not be accurate.
If user base on those platforms is very small then it makes no sense for the developers to spend resources to keep it updated. At the end of the day its about demand and supply.
That's only if your business model only looks at the next quarter, and if you don't care about your brand.
Amazon, and department stores before it, became huge because they made an effort to cater to all needs. That allowed them to be the go-to brands for people looking for things.
Imagine if in its early days Amazon ran the numbers and discovered that textbooks were only a small portion of its sales, so it stopped selling textbooks. Then it noticed that cookbooks were only a small part of sales, and those were cut. Then it noticed that mysteries were only a small part of sales, so they went out the window. Next thing you know, nobody shops at Amazon because its focus on the big numbers turned it into a niche provider.
If a games publisher chooses to restrict its platforms, that's its business. But I won't think of it for "games" in general when I want to find a game.
Amazon dot com and building a game are so different that it is difficult to follow the metaphor to any place where it offers insight. The reality is that it costs money to support any gaming platform. The cost of supporting platforms with only a tiny number of players can easily outstrip any potential upside.
A prominent indie dev on twitter once said, of his game that has sold at least several hundred thousand copies, that only 100 people will buy your game on Linux and every single one will email you to tell you that they did. That they are technical and vocal doesn't make the playerbase any larger.
At one time, Windows was only 3% of game players. Does that mean companies shouldn't have developed for Windows way back when?
Market growth potential aside, a small portion of users doesn't necessarily equate to abandonment="sensible economical decision." If that small portion is more profitable than the majority, then it's worth serving. That's pretty much how Apple got to be where it is today.
> "Does that mean companies shouldn't have developed for Windows way back when?"
The difference being that Microsoft went all out in building subsystems (WinG and later the various DirectX technologies) for gaming and courting game developers to target it while Windows 9x was still new and popular.
Nothing similar has occurred for any of the Linux distributions nor is that likely to occur.
We are not talking about Amazon, we are talking about Rocket League, which is nothing like Amazon; one is an online retailer and the other is a video game. Epic/Psyonix will be just fine. Lots of people spend money for the cosmetic items they offer.
>If a games publisher chooses to restrict its platforms, that's its business. But I won't think of it for "games" in general when I want to find a game.
But nearly everyone else will, so why would they care about you? No game developer has failed because they lack Linux support.
Linux has a tiny portion of the desktop market, and an evern tinier portion of would be Epic customers if only they could play their games on their preferred OS. It's not like Linux has 30% of the desktop market and people are out there demanding support. Linux support makes no sense.
I love... well, ok, I use Linux, and I've been using it for almost 20 years now. A lot of the software I write to earn my living runs on embedded Linux systems. And still I'd rather poke my eyes out with a toothpick than port, or write, a game for Linux, targeting general hardware. If I owned or managed a game studio, I'd keep on using Linux, but I wouldn't publish a Linux game for the life of me, not with things being the way they are now.
If Linux were just a niche platform, that would be fine. But supporting desktop Linux systems is disproportionately difficult -- it's a small niche, but it's a lot of effort. Userland APIs break all the time. The constant churn in the graphics and desktop space leads to a lot of instability and bug reports. Between Wayland being default on some distributions, unstable graphics drivers, and the umpteenth rewrite of God knows what other component in Gnome or KDE, you get to deal with the sort of bug reports and crash dumps that used to pop up fifteen years ago when a Longhorn beta was leaked and everyone tried to run their games on it for shits and giggles. Linux desktop is basically a neverending beta. People don't write games (or software) for it for the same reason why you don't write games for a leaked Windows beta.
It's no coincidence that Linux is such a big player in the embedded and server markets, but not in the desktop market. Writing desktop software for Linux in 2020 is about as enjoyable as chewing nails. It's an unstable and flimsy platform to target, and not a very profitable one, either. I can't blame any company for skipping it.
It's nice that you have embedded experience but as long as you don't write in directX there is no difference between game development among these platforms except for the massive black box of strange stuff that is the windows API. I would take the Linux API any day over that for basic I/O and most drivers are baked in. There is a reason all consoles historically besides xbox are made in top of a stripped Linux kernel.
First of all, there's no "Linux API". The kernel does expose a stable interface but you're not going to write a game just by issuing system calls.
But the kernel is pretty much the only piece of this tech stack that exposes a stable interface. Pretty much everything else changes a lot. There are exceptions -- SDL2, for example, is great to write against. But most things aren't -- they change a lot, and they're undocumented. This tends to result in duplicate code that goes out of date and results in all sorts of strange quirks and bugs. phk has a good summary of this here: https://queue.acm.org/detail.cfm?id=2349257 .
As for drivers: there's one set of drivers that aren't baked in and they're critical for games, namely nvidia drivers. Anyone who's done graphics programming on Linux has their own horror stories about nvidia's stack. I won't bore you with my own, suffice to say that things are never, ever as easy as "you just write against the OpenGL API and you're set".
"Historically", I'm not aware of any major console that's built on top of a stripped Linux kernel. Sony has been using their own franken-BSD since at least the PS3. Don't know about Nintendo but given how much effort has gone into the occasional port for Nintendo hardware, I doubt they're using Linux.
Linux has been only recently adopted by some console devices, and those are basically embedded systems. You target a single hardware platform (with a single, known set of quirks), a stable kernel, a stable driver, a stable set of userland libs. It's not great -- backporting kernel fixes is notoriously finicky, for example. But it's a scheme that, at the very least, allows you to write code to implement whatever functionality you want to implement, instead of wasting time impedance-matching between userland APIs.
By tying themselves to a single proprietary platform owned by a potential competitor, Epic is giving up control over their own product. This will certainly save them some money in the short term. In the long term, this may not turn out to be such a wise decision. But by then, the executives at Epic will probably have moved on, so not their problem.
It's strange to me that they could support linux and mac back when they were smaller, but now that epic owns them and rl generates 50M(?) per year, they can't.
From a purely business decision? Sure. But why does Valve support linux and attempt to bridge the gap with steam play if it's only about profit?
There are other reasons to support linux:
- Game devs are usually a fan of linux / vulkan / open source (windows is bad for developers, it's closed source everything)
- Linux is still a market portion. Some engines like UE4 support cross-platform builds with minimal work
- Supporting competition to microsoft, and the really poor DX software
The “normal” Windows gamer just doesn’t has a choice, unless they want to switch to PlayStation / Xbox, one of the choices developed by Microsoft, again.
The question is, how high or low is the demand for a equally performing alternative “pc gaming” platform? I personally would banish everything windows-related forever.
> If user base on those platforms is very small then it makes no sense for the developers to spend resources to keep it updated. At the end of the day its about demand and supply.
How very rational. I wish HN had the same attitude each time Google sunsets a well-loved, but little-used product.
For how long? People train for this game like any real-world sport. Imagine if a bill to make football illegal within a year seemed very likely to pass, do you keep practicing?
If I played RL at a professional level (I do at a collegiate one), I would make sure I have a windows partition. It's not a massive issue for this scenario.
The refund process is a mess. I followed the directions on the Reddit page last night and got an email from Steam saying they’re refusing the refund because it’s been more than two weeks.
Other people on the comments have said similar things.
I was _so_ excited when Rocket League first came to Linux, but that was several years before Proton[1] was released.
But according to [2] the game runs really well on Linux via Proton. Personally, I don't see any problem using Proton to play the game on my Linux gaming-rig.
Proton is pretty great, but there are hardware limitations. Im running a pretty old video card. I can run games like Deep Rock Galactic on Windows, but it wont work on Linux as Proton needs newer linux drivers, which don't support my card, in order to run that game.
Proton works great for single player games but isn't that great of an idea for multiplayer games. Their anti-cheat system could end up banning proton users. I believe this has happened to Destiny 2 and GTA:O players.
The concern is that Epic will add EAC and that Proton is going to cause you to get banned or they pull the game from Steam and move it to EGS which doesn't run on Linux, and likely never will. So the question becomes why should I put more effort into a game that's likely not going to be available to me in the very near future?
Epic acquired Kamu, makers of Easy Anti Cheat, for use in Fortnite. EAC is known to block Linux players using Proton, and there's decent odds Epic adds EAC to Rocket League.
I’d be normally more upset about this, but the last sentence is a biggie in this situation. Psyonix is offering full refunds for the base game (which is better than nothing, although I wish it included DLC etc) to anyone, even outside of the two week window.
DirectX9 is ancient, like somewhere between an original Xbox and an Xbox 360 in features. It's very difficult to use any modern graphics techniques with it. DirectX 11 is the most recent version of that classic style of graphics APIs, with DX12 being to DX11 sort of what Vulkan is to OpenGL. If I had a legacy DX9 codebase and I wanted to use some features of newer GPUs than what existed in 2002, I would convert over to DX11.
More modern programming interface that matches the hardware better.
Newer shader model support + newer shader compiler
Newer/more powerful debugging tools
Access to large new features like compute shaders, texture arrays, uniform buffers, etc
Access to new surface formats to enable features like VR and HDR
Better API performance + access to performance-enabling features like multi-threading
Direct3D 9 is nearly 20 years old. OpenGL has at least been receiving new extensions on a regular basis (though people are finally shifting to Vulkan) - with the exception of a few things shoved in by driver vendors via back doors, D3D9 has not changed at all.
Driver compatibility for D3D9 is also very bad at this point - the driver vendors don't give a shit about breaking existing software that uses it. I still occasionally hit driver bugs when working on old code that targets 9. Code targeting 11 will have fewer problems.
Rocket League's creator, Psyonix, was bought by Epic last year. The is concern/belief that this move is a precursor to making Rocket League an Epic Store exclusive, as the Epic store is Windows only.
Psyonix stated that they would offer refunds for Linux/ macOS users. In the first few days post announcement, everyones' refund was being denied. It appears that this has since been resolved. I received my refund yesterday.
It's clearly a metaphor. It just doesn't make any sense in this context. Neither does this reply. I _think_ you're trying to say that they're paranoid for questioning your metaphor? Your unusual grammar is difficult to understand, but you're coming across as a bit hostile.
This is one extra thing I don't like about Epic store - Valve has a Linux client & hosts many Linux native games, is active in many open source projects including GPU drivers and even actively works on improving Wine/Proton to get Windows games run seamlessly on Linux.
Epic does nothing like that and even actively pushes games to be exclusive this Windows only, using their Windows only client.
Epic also owns one of the largest "anti-cheat" software companies. That refuse to support linux, or work with Valve on making it work on proton.
There are quite a few games that work great with proton, but can't be played online because the anti-cheat won't run. Like Arma3. It runs great in linux, but the binaries are always 3-6 months behind the windows ones. so your choice is to find a server with 2-3 people on it, or run it on proton, see lots of servers with hundreds of people, and can't connect.
Just to be clear, it took Valve 10 years to add support for Linux. The Epic store has been out for a little over a year. I have no idea if Epic will eventually support Linux, but I find it hard to fault them for lacking things that Steam has when Steam has existed for 17 years now.
It was much better for gaming than Linux, so far as natively-supported games (so, not counting Wine) until MacOS dropped 32-bit support. Now, yes, it's far worse for gaming than Linux.
FWIW, tried to play Borderland 3 this week with a friend and he couldn't get it to connect, at all. Booted into Windows, worked fine (I was on Windows).
So yeah, the store works - but that doesn't mean the "Linux games" work, or work fully, with network.
Are you saying BL3 not working on Linux is Epic's fault? Or just that they shouldn't be selling stuff that doesn't work?
If the latter, I agree but no storefront actually meets that standard right now. Valve happily sells stuff on Steam that barely works on Windows and before the new refund policies they'd perma-ban your account if you tried to refund a broken game.
I'm simply saying "the store works on linux" is too simplistic. It might be true, but people might think that means the (linux) games on it might work. It's not about blame. My friend was happy he could play it under Linux. He was less happy he had to reboot and patch Windows to use multiplayer.
Are you going to play Rocket League on Windows? I ask because I wanted to let you know that it performs much better on the same hardware in windows than macOS for me (bootcamp). I bought it on steam so it was easy to move from one OS to the other. Not sure how it would work in your case, but hopefully the epic store saves that data across their platform on different OSs.
Maybe I am missing some context here, but why would a game studio make a backwards-compatibility-breaking change to the engine a five year old game? I know that it's a popular game, but this sounds like an excuse to me.
It's backwards compatible for 99.4% of their users. Maybe there is future feature work they want to do, but are limited by DirectX9. Maybe they got tired of working with a 20 year graphics library and it's cheaper in the long term for them to update to the latest.
As someone currently maintaining code that targets Direct3D 9, it's really not worth living with the constraints if the vast majority of your users can run stuff targeted at newer APIs like D3D11. I don't blame them. Newer APIs deliver better performance and useful features, and there are great new debugging tools that don't work with D3D9.
Rocket league is an active multiplayer game that falls under the "Games as a Service" umbrella. There are limited time events, and new aesthetic upgrades being added to the game at a regular clip. Because of that, it's not a "five year old game" but rather a "game in active development."
Think about it like a game like World of Warcraft. It wasn't built once and then released, but rather new content is being produced for it constantly, so the game engine itself needs to be improved at every level as consumer hardware changes and improves.
The article makes it sound like they were running DX9 in Linux and MacOS. If true, how is this so? Is there some type of X11 extension that implements DX9 or something?
They probably have their own abstarction layer that implements the subset of DX9 they are using on top of opengl. This is very common on linux ports as it is hard to justify the cost of a full rewrite of the graphic engine.
Not really, if you read carefully they are saying that their OpenGL renderer is very similar to the DirectX 9 one (probably because feature parity between these two APIs), but they have difficulty matching DirectX 11 features with OpenGL.
Like a database ORM which can have Postgres/MySQL as the backend, but then you want to replace Postgres with BigTable. It will be very hard to keep the MySQL support.
SuperTuxKart (https://supertuxkart.net) is a free racing game similar to Mario Kart and it also has a "Soccer" mode where you play in an arena with a ball and two goals like in Rocket League.
I love SuperTuxKart. It's the first game I install on any new computer, and I've beaten the story mode several times. I usually focus on the racing modes, but I've tried Soccer as well.
SuperTuxKart is not an alternative to Rocket League! If you go into it expecting anything Rocket League has -- polished realistic-looking graphics, physics that let you jump and tilt and drive up the walls of the stadium, a thriving online play community, a matchmaking system -- you're going to be disappointed.
Your criticism is correct. It is similar in the gaming principle but way way behind in user friendliness and polishing. That said, as far as I know, this is the best alternative that we have right now on Linux. Having played it with kids (who never played Rocket League before) I can say that it can be a fun activity.
> Unfortunately, our macOS and Linux native clients depend on our DX9 implementation for their OpenGL renderer to function.
I'm not a gamedev and just have some hobby xp in DX and OpenGL, but I don't begin to understand why an OpenGL renderer would in any way depend on DX. Is this just code for "we have such few Mac and Linux users that it isn't worth our time to support OpenGL"?
They probably use some outdated translation layer that converts DX9 calls to OpenGL ones so that they didn't have to maintain two renderers or use a higher level 3rd-party engine that abstracts over those calls. Newer games using Steam's Proton, like Sekiro, look and perform nearly equivalently to their Windows DX11 counterparts. I know Proton isn't exactly an apples-to-apples comparison, but it's an example off the top of my head. I guess CS:GO is another more apt one.
They wrote the game targeting DX9, and then wrote a custom shim to translate from DX9 to OpenGL calls. Now they are transitioning to DX11 to get some newer features, and have evaluated the amount of work that it would take to either update that shim layer for DX11 -> OpenGL/Vulcan for Linux, or DX11 -> Metal for MacOS (remember, Apple is depreciating OpenGL on their platforms).
If linux and MacOS combine account for less than 0.3 percent of their revenues... then even as a MacOS guy I have to see their logic... there is little chance of recouping the heavy lift that they would have.
AFAIK: The way DX9 works for Windows software running under Wine, is that wine has a layer that intercepts all DX9 calls and retranslates them into OpenGL. There is no equivalent for DX11.
No clue. I was making an educated guess. I was stuck with DX9 for a while because I wanted some stuff to run under wine. I switched to opengl nearly... 6 years ago now? Didn't realize it had been that long.
Epic is probably one of the biggest enemies of Linux since they're killing Linux support of every game/product they buy [1]. And while games aren't as important as some business/productivity applications, people do get lots of enjoyment from playing an occasional game. It's a great stress relief. And now even those little indulgences are being taken away.
Epic's CEO, Tim Sweeney, is extremely negative on Linux if you check out his Twitter feed [2] and I get a feeling from reading his comments that he despises Linux with passion.
I honestly cannot blame someone in that business for hating linux. The number of variables to test for if you only care about windows gamers is staggering. Linux is 10x harder than windows if you care about supporting any arbitrary distribution and driver stack. I think if users were willing to load a linux VM for each game they'd like to play, this would be more manageable from a game developer's perspective.
I understand SDL2 exists. I understand that Valve has "mostly" pulled off linux/macos support. But, is it really worth it from a business perspective for all game developers to support linux? How big and wide do your margins need to be before it makes financial sense to fully support both operating systems? How many features (or even titles) will stay in the backlog because your developers are busy chasing down the 5000th weird linux network/GPU/sound bug that only occurs on this one kinda-old version of Ubuntu?
> I think if users were willing to load a linux VM for each game they'd like to play, this would be more manageable from a game developer's perspective.
As I understand it, this is the direction Steam is heading by running games in containers.
If it turns out that this path is acceptable to the masses, I am 100% on board with all game developers following a similar pattern. Personally, I don't have a problem with this, especially considering most games I install these days are upwards of 100 gigabytes anyways. If 2 gigabytes of each game was a Linux OS image and supporting tools, I probably wouldn't notice.
Having a standardized Linux image with containerization support shared across the entire industry could be a really powerful tool for game developers who want to target Linux but don't have EA's budget. Over time, this could put Linux on equal footing with Windows in terms of platform support cost.
That's not going to happen. The main benefit of developing natively for windows is that the game should pretty much compile for Xbox straight away, with some minimal changes to the code. The PC build is almost a byproduct here. I don't personally see devs making a linux-but-not-really version for Windows if that cuts them off having a "free" xbox version. And from financial point of view having a Linux vs Xbox version is almost a non-starter, unless you're targeting some hyper-nieche.
Supporting only a single distro of Linux would be fine. If it's not my prefered distro, I'd be happy to dual boot into another to play a game. But I don't want Windows on any of my machines, even as a secondary OS.
People always say this, but then post support comments saying stuff like "nobody uses Ubuntu, everybody uses insert distro here". It's a big mess to support.
I'm still not sure.why game developers are aiming to support distros rather than library versions. That tends to be the biggest problem with linux is the huge number of versions of libraries each distro could have or not have and the location of said libraries on the system. That's the issue crossplatform developers should be aiming to tackle rather than trying to cater.to every single linux distro. That's like trying to shoot at minnows in the ocean with a BB gun.
Also last I checked, if it works on Ubuntu, someone usually will make it work on other distros of roughly the same generation, often within a week. If the core is available, the linux gaming community is quite amazing.
I don't even understand why anyone bothers with targeting dynamic libraries. Why not statically compile everything? The system calls aren't changing are they?
Dynamic linking is usually for packages maintained by the distro, but many proprietary software actually use statically linked libraries.
This way they have one binary that runs on all the modern distributions, then packaging is only to integrate with the package system, menus and stuff (and is optional).
Even if you could statically link everything else you would still to dynamically link to the system's native user-mode graphics drivers, which in practice means that you also need to dynamically link to other libraries used by your application and the drivers (like glibc & libllvm) in order to maintain compatibility. Static linking against glibc isn't really recommended in any case.
Nothing prevents you from providing your own preferred versions of most of the dynamic libraries along with the application, however. It should be possible to limit external dependencies to libraries that actually care about maintaining compatibility.
Or...they could just ignore having to target library versions entirely and just target Windows, which represents >99% of the market.
Game developers could do lots of things to support Linux, but many prior attempts to support Linux gaming have shown game developers that it's generally not worth it from a resources perspective unless the engine you're using already supports Linux and you don't need to do additional work to get your gaming running on Linux.
> you don't need to do additional work to get your gaming running on Linux.
Ideally this is how it would be. Develop the game targeting Windows, and simply don’t do the things that unportably tie it to Windows. If you develop it from the start as cross platform, then it shouldn’t be some gargantuan effort to port it. It shouldn’t take that much longer to use platform-neutral APIs than the Windows-only equivalents.
Then just fling off a “totally unsupported Linux build”, stick it on an FTP server, ignore support tickets mentioning Linux, and let the Linux people figure out how to get it working—they will! Let them figure out their driver problems or which distributions ship the right library dependencies. A totally unsupported build is at least better for Linux users than abandoning the platform entirely.
I think a lot of games fail to work on Linux not because of the support costs or the platform fragmentation, but because the developers just don’t care or they choose engines and technologies that are not cross platform. It just never crosses their mind to do it differently.
They could do that, but then people who can't get the game to work will give negative reviews. It's better to just not give them the opportunity at all.
On the other hand, I just recently asked for support on a linux version of a game for a bug that affected only the linux version of the game, the support staff was extremely quick and responsive, the problem was an easy fix when I found out what it was, I didn't ask for a refund because of this and because of my interactions with their support team I wouldn't hesitate to buy another game from them in the future.
Now, same thing happened with one of the worms games, Team17 was dismissive and rude. I ended up just getting a refund. I've been a fan of the series since the very first one, i've bought a bunch of their games over various systems, I own a copy of worms 3d on both GameCube and ps2, but I don't plan on buying another worms game or anything else they put out any more.
D3D11 is much easier to use and more reliable than OpenGL etc, using OpenGL would increase the cost to finish the game and no meaningful gain since Linux is essentially irrelevant.
Also most game devs don't have Linux machines to build or test the game on in the first place.
I thought about it once, tried installing Ubuntu-- it wasn't as simple as I'd like, but eventually worked.. except it didn't seem to be aware of the GPU and was running at 640x480 or some shit.. deleted it.
I have never seen such a support comment. (And I say this as someone who doesn't use Ubuntu and has never used Ubuntu.)
As other people have commented, the usual trend for Linux support appears to be that the developer needs to support the most recent version of Ubuntu (or maybe LTS), and anyone not using that version does the legwork necessary to make it work on their setup. And for consumer versions of Linux, Ubuntu is likely to be by far the most popular distribution.
That does not match my view for hanging out in Linux gamer forums. Most games just support Ubuntu and everyone is happy with that because if Ubuntu is supported then it is easy to make it work on other distros. I have never heard anyone complain.
Not only that, but the community would figure out a way to package the binaries with the appropriate libs. When Steam was released it was only officially released for Ubuntu. Yet it worked on Fedora, SUSE, Arch pretty damn quickly.
I hope somewhere in the next iteration of Xboxes, Microsoft comes up with a version that is essentially a Windows desktop, with support for whatever controllers a normal pc supports, but a trimmed down OS dedicated solely to gaming (supporting at least 1080p at 144 hz), with things like Steam and other game launchers.
For me, that would honestly be the best solution to the OS decision. I could just connect it to my same monitor on the second input, and use the usb switch to just switch peripherals.
That's literally what the current-gen Xbox is. It runs a very slimmed down Windows core and most WinRT and .Net applications can be made to run on Xbox without much effort. It not being able to run Steam or other launchers is purely a business decision, not a technical one.
It already is a console, though. You're suggesting a way to make it less like a console, but still requiring you to pay a premium to game at your desk.
And it loses one of the big advantages of convenient couch gaming.
>I understand that Valve has "mostly" pulled off linux/macos support
Although I think the vast majority of their games don't work on the most recent OSX release. Depending on your perspective, either Apple pulled the rug out from under them, or Valve is letting their code atrophy. Maybe a bit of both, but my opinion is more of the former.
That is 100% Apple's fault and makes me thankful for backwards compatibility.
Music Production has been hit hard by this same move. Plugins and virtual instruments that people have been using for years are all gone from support. All the open source plugins are out right now. Everyone is holding off and I am glad I use Linux and Windows 10 for music.
There haven't been many good reasons to release a 32-bit only macOS app for some time. If Valve is at fault, it's that they didn't require publishers to submit 64-bit builds for macOS years ago.
I forgot about this. Valve released a 64-bit build of Steam two months before Catalina came out [1], but they did not migrate users of the 32-bit version to the 64-bit version automatically.
Of course linux is pretty flexible. Wouldn't it be nice if you could just target linux, and get it to automatically support windows/macos? Like a reverse proton? That should be a lot easier than proton ever was.
That's the direction I'd like to see steam's containerization go.
>Linux is 10x harder than windows if you care about supporting any arbitrary distribution and driver stack.
Not really. Most hardware is very standard these days, which is why you can install Ubuntu on most any laptop or desktop and have it work with less than or equal issues than a Windows install.
Amd and Nvidia both have Linux drivers that work on all the popular distros.
The reason devs don't even bother with Linux is because there isn't enough people that are playing on Linux.
> Amd and Nvidia drivers for what? Big games aren't being made with openGL.
Doom 2016?
> What is the state of vulcan across drivers and engines?
Quite good actually. Intel has older generations supported than on windows. There are 2 mature AMD vulkan implementations.
Also through investments of valve there is a new shader compiler in the works that got merged in mesa which helps quite a lot. The performance is about equal, but sometimes faster under windows (I didn't look at benchmarks of 2020). Oh and vulkan 1.2 is implemented in mesa 20.
This is actually one of the root causes. It would be SO MUCH EASIER, for me, an app developer, if every linux user used centos, or ubuntu, or mint, or whatever the hell. Don't care, pick one. But, customizing is part of the fun... anyways.
Also yeah, desktop Linux is about 10% of users, depending on who you ask. Worse for gamers, although that's just feedback loops.
There's one more thing though, which most people aren't aware of... driver versions. Drivers often ship game-specific hacks for performance fixes. It's an insane, unspoken practice that occurs because some developers will only test heavily on one mfg GPU. Right now, nvidia is taking the brunt of the work because consoles are AMD based.
Nobody is going to support 5 year old Slackware for their game distribution platform. They'll support current Ubuntu and maybe Fedora--anybody else can work out the problems on their own.
And by support I mean a one-off build for the platform and a public forum where users can ask and answer questions of other users. Maybe if you're lucky they'll do a new build when a patch is released.
Linux users aren't asking for much, and Epic has been more than just dismissive to them. They've been outright hostile, doing things like adding checks to make sure the game isn't running under Wine.
It would require them to write it in vulkan which would improve performance across the board on both platforms...so really I think we are asking them to do a job that will cost them more money than they expected for a product they can maintain longer for less effort.
You can have both but you have to know what you are doing, epic is just tending a garden that someone else made and clearly doesn't have that level of forsight.
Is that tweet really "extremely negative" towards Linux? All he says is that he doesn't want to abandon Windows but instead push back on changes to it he doesn't like; he doesn't make any judgements about Linux. The reality is there are many barriers to Linux replacing Windows as a desktop platform for users today so it's not surprising that someone who runs a business that depends on users doesn't want to push for a huge switch to Linux if it's not necessary. If a company not wanting to act outside it's interests makes it Linux's "biggest enemy" then it will be a very long time before it succeeds as the major desktop platform.
When reading the context of the statement itself, it isn't that bad. He was concerned that Microsoft would introduce restrictions that place inhibitors on other vendors hardware with the introduction of a Pro operating system. The statement itself isn't the best, but his stance was that as a community Windows developers and users should push back against such changes.
An employee at Epic has mentioned that if someone with Linux development skills was interested, they would be more than happy to bring them on to develop a EGS application for Linux. The thread can be found here: https://twitter.com/CanalOCaraDoTI/status/110621899365072896... (scroll to the top for the beginning).
It's not hard to hate Linux (Desktop) when you develop proprietary software since Linux seems to go out of its way to make it as difficult to deploy proprietary software as it possibly can [0]. Libraries are constantly changing underneath you in incompatible ways, there are several hundred "distributions" to deal with, etc.
[0] And frankly it is only slightly easier if you write FOSS software.
Many of these distributions, at least the popular ones, are nothing more than forks of Debian, Ubuntu and RHEL/SuSE. And most (not all) people who would want to game on a Linux system use Ubuntu as it's by far the most painless thing to get going. Base yourself off of the latest Ubuntu LTS, compile your project statically as far as possible and you're probably good to go, containers can be used to get your project running on other distros if needed.
If you're using any engine even better, all of the major ones are cross-platform anyway and abstract all the nastiness away.
Target the steam runtime. All popular distros will either support it out of the box or have an overlay to do it. And it doesn't change very often.
Open source is a million times easier. Your source is available. It's up to the distro's maintainer of your package to deal with compiling and binary compatibility.
> It's up to the distro's maintainer of your package to deal with compiling and binary compatibility.
That's bullshit though. Why would you trust some random community maintainer to get between you and the user? Now when shit goes wrong there's one more person in the loop of blame to deal with. There are famous incidents of maintainers introducing problems to otherwise correct software, and ignoring the developer.
"I am constantly getting email from users reporting bugs that have been fixed for literally years who have no idea that the software they are running is years out of date." -jwz
How is this considered a sane way to distribute software!?
The way developers solve this on Windows works on Linux: ship the libraries you need with your application. Steam does this and it works pretty well. Even if you don't, the Linux community will do most of the debugging for you and submit fairly detailed bugs (failed on platform X with error Y, workaround Z produces different error), so all you need to do is interact with the community periodically, fixing the easy issues to keep people happy.
For FOSS projects, everything gets easier once you get it accepted in the package repositories, and if your project is popular enough, you can usually get someone else to do it for you.
In both cases, using a language that has a cross platform dependency manager eliminates a huge number of compatibility problems. Also, keeping libraries reasonably up to date also helps prevent problems from happening. Updating every two years should be sufficient to maintain compatibility with most Linux distributions.
Also, software vendors don't have to worry about every Linux distribution, just pick the top one or two and let users support the rest for you.
1. It seems as if he's addressing the context of the discussion (switching to Linux from Windows) rather than saying anything particularly negative about Linux.
2. I've been making some UE4 projects recently (as im getting back into game development as a hobby) and the toolchain to cross compile to linux is well made and easy to use (and even easy to dockerize).
I think unreal engine support of linux is probably the better barometer of Epic's stance towards linux than their not-so-fully-featured launcher/store (which is many years behind steam).
I haven't tried recently, by UE4 used to work reasonably well on Linux if you build from source, so they're putting at least some effort beyond cross compiling.
This is what I hate about ever-changing games. If it's such a big change, just make a new game, Rocket League 2. I'm sure people will still complain for some other reason, but no one looses what they paid for.
These days even if it's a sequel it might just be a repackaged update. Overwatch 2 is just Overwatch with additional stuff on top, for example - supposedly they both can play in the same matches on the same servers.
There's no reason they can't just let users run their own servers for older games. We're not talking about a MMORPG here, where centralizing the servers might make sense in order to give everyone a shared experience.
And with the use of Vulkan, you get the modern improvements (and technical complexity that comes with it) on both Windows and Linux through hardware vendors' drivers, and MoltenVK for bridging that code to macOS and iOS.
I don't have a comparison chart between DX12, Vulkan, and Metal but if engine authors can standardize on the open standard of Vulkan, it could have huge effects on creating cross-platform games and applications. A big push for this wouldn't be having authors like Epic, Unity, or CryEngine do this, but all the private publishers investing the time to learn and switch their next-gen engines over to Vulkan.
Another problem with OS X support is that there are no modern nVidia cards for modern OS X machines as there are no drivers (Apple refuses to sign them, and nVidia refuses to release unsigned drivers that people could install with SIP disabled)... but many PC games advertise for nVidia.
This is another issue unto itself. This often stems not from a CUDA/OpenCL debate, but rather how well a particular development group may be supported by either vendor in terms of tech and driver support. NVIDIA is usually pretty good at supporting game makers, and getting support for their GameWorks libraries added. GW for a long time was a weak spot for AMD as they couldn’t add proper driver support, crippling performance and limiting feature sets. A good amount of GW is OSS now, so getting those features and support in is up to AMD. I haven’t read the EULAs though.
They are less multiplatform than you would like, though. MacOS is stuck on an old version of OpenGL with no chance of updating since they deprecated it, and it has no Vulkan support (ignoring translation layers like the one Rocket League used, of course). On Windows, Vulkan is a second-class citizen that isn't always available.
And beyond that, there's the age-old problem of driver quality- for a given platform, using the native API tends to hit fewer bugs, perform better, and support more features. This has been true for years with Direct3D vs OpenGL on Windows, for example- browsers on Windows all wrap Direct3D to implement WebGL.
Don't forget consoles, though I've heard reports that you can use some variant of GL on Switch. PS4 requires a custom backend unless you license some sort of middleware. XBox left Direct3D 9 behind a long time ago (which is probably one reason to shift onto Direct3D 11 - to share more code between PC and XBox)
However, it’s worth noting that Vulkan, Metal, and modern DirectX are so similar to each other that translation layers are extremely thin and have a performance penalty somewhere between negligible and nothing. That’s a dramatic improvement from where things were before OpenGL and DirectX had no interchangeability at all.
I'm always amazed by the longevity of DirectX 9. It was a truly excellent graphics API. DirectX 11 had more features, and was in some ways better designed, but it was always really painful to have to reimplement some of the things that were stripped out of the D3DX utility libraries that formerly were part of the SDK.
The game ran pretty bad on macOS though. Same computer with a GTX 1080 runs the game on win10 at hundreds of FPS with everything maxed vs barely able to run the game on macOS with all the detail on minimum.
Honestly the game was not playable on macOS. If you wanted to play on your MacBook you had to run Windows with bootcamp, which you can still do.
So I doubt this change will really impact anyone.
Can anyone talk about how it plays on Linux? I can’t imagine a huge playerbase there.
It's both surprising and unsurprising to me how many comments here are focused on EGS (which is not what the article is about) and almost nobody is talking about how Rocket League's macOs and Linux players make up less than 0.3% of the players, combined. SMH
^ developer time is worth crazy much, it's just irresponsible to waste lots on it on a 0.3% of the users.
just go ask the actual playerbase if they'd prefer the devs working on linux/macos ports or actual gameplay/issues affecting the average player and see the answer.
Seems more irresponsible to not refund the game and DLCs, though. What refunds are happening seem sporadic and limited to base game only, which is pretty reprehensible.
What I find a bit odd about this is the existence of the Switch version.
Surely the Switch's graphical power, presumably it's not going to get a bunch of fancy new DX11-esque features. I imagine they'll do the minimum to keep the Switch compatible with other clients in multiplayer.
But if they're keeping multiplayer compatible with an older Switch codebase, why not keep it compatible with older Mac and Linux branches?
226 comments
[ 4.0 ms ] story [ 224 ms ] threadAnd before someone rails on me about anti-cheat, or about reduced profits because of the whole game showing up on torrent sites, I'm not talking about that stuff -- I'm talking about the bare minimum client code that is required to run the game.
But very few are "open source".
https://indiegamebundle.fandom.com/wiki/List_of_Humble_Bundl...
Of more recent origin, Space station 13 is great. It's a tile-based multiplayer (up to about a hundred) in-depth space station disaster simulator. A stable community of servers and players, innovating and sharing patches among the various major code branches.
(The codebase is a nightmare because the game's written in an ancient engine from the 90's, but that just makes what they've managed more impressive.) It's been over 10 years of intermittent, branching, and re-merging development.
https://github.com/CleverRaven/Cataclysm-DDA
[1]: https://arstechnica.com/gaming/2020/01/rocket-league-will-dr...
To answer "How hard could it be?", the answer is, "Surprisingly hard". Games rely on weird interactions with hardware and need to smoothly render at a consistent FPS. Often a revision bump in a library might introduce subtle changes (for example, a difference in how numbers are rounded might cause z-fighting or change the way shadows are rendered). All of those need to be discovered and fixed. Not to mention that DirectX uses a totally different shader language than Vulkan, so you have to get in there and translate all that code over.
It's definitely non-trivial. Doable, but non-trivial. I don't blame the devs for making a cost/benefit analysis and realizing they would never recoup the cost.
Given the economies of the games industry (where studios are basically always one step away from complete failure and being dissolved into nothing), I appreciate the need to focus on not losing money in this way.
Vulkan doesn't really have a shader language unless you want to write SPIR-V assembly. Thus you'd use either GLSL or HLSL. Microsoft's own DirectX HLSL compiler[0] supports SPIR-V as a target in addition to DXIL.
[0]: https://github.com/microsoft/DirectXShaderCompiler
If I bought that game, because it means I could play multiplayer with my friends and now they are removing that feature <3 months after I bought the game, then I would not be a happy camper.
I don't think anyone truly expects a game's multiplayer should last forever, but it should last while the game is still popular and releasing updates.
EDIT: I know the gap is small, less than 1% but it is still a gap. If a competitor could emerge in a small gap like this is a question I cannot answer. There is potential for growth (especially if Microsoft slips up heavily which they almost did) but so far that growth hasn't happened and the future is hard to predict.
Steam heavily supports Linux and in their numbers are 0.67% Linux users: https://store.steampowered.com/hwsurvey/Steam-Hardware-Softw...
It is rumored that Steam uses Linux for leverage in negotiations with Microsoft. Therefore it may have a big strategic value for them even though the numbers are still so low.
However, Bungie started as a Mac shop, and Stardock started as an OS/2 shop. It's possible to make the claim that had more commercial games been available to these relatively small platforms in the 90s, there wouldn't have been enough space for these game companies to emerge.
As I said, I can't prove that. It's quite possible these companies would have been successful anyway.
Games cost money to make. If a game doesn't have a chance at breaking even, it needs external funding or free labour to get it made. This is the economic reality of how games get made.
That's probably not enough for a competitor to make any money, especially since they could only catch a part of these users.
[0] https://www.gamespot.com/articles/as-rocket-league-turns-one...
That's only if your business model only looks at the next quarter, and if you don't care about your brand.
Amazon, and department stores before it, became huge because they made an effort to cater to all needs. That allowed them to be the go-to brands for people looking for things.
Imagine if in its early days Amazon ran the numbers and discovered that textbooks were only a small portion of its sales, so it stopped selling textbooks. Then it noticed that cookbooks were only a small part of sales, and those were cut. Then it noticed that mysteries were only a small part of sales, so they went out the window. Next thing you know, nobody shops at Amazon because its focus on the big numbers turned it into a niche provider.
If a games publisher chooses to restrict its platforms, that's its business. But I won't think of it for "games" in general when I want to find a game.
A prominent indie dev on twitter once said, of his game that has sold at least several hundred thousand copies, that only 100 people will buy your game on Linux and every single one will email you to tell you that they did. That they are technical and vocal doesn't make the playerbase any larger.
https://store.steampowered.com/hwsurvey
It's simply not a sensible economical decision to invest serious dev time for 3% of your potential players.
Market growth potential aside, a small portion of users doesn't necessarily equate to abandonment="sensible economical decision." If that small portion is more profitable than the majority, then it's worth serving. That's pretty much how Apple got to be where it is today.
They didn't, they developed for DOS well into the Windows 95 and 98 era, at which point Windows had captured the PC market.
Indeed, but that's not the case with macOS and Linux players.
The difference being that Microsoft went all out in building subsystems (WinG and later the various DirectX technologies) for gaming and courting game developers to target it while Windows 9x was still new and popular.
Nothing similar has occurred for any of the Linux distributions nor is that likely to occur.
But... it's not. Not even close. It's tiny and Linux costs far more to support due to variations in configuration and flaky APIs.
But nearly everyone else will, so why would they care about you? No game developer has failed because they lack Linux support.
Linux has a tiny portion of the desktop market, and an evern tinier portion of would be Epic customers if only they could play their games on their preferred OS. It's not like Linux has 30% of the desktop market and people are out there demanding support. Linux support makes no sense.
If Linux were just a niche platform, that would be fine. But supporting desktop Linux systems is disproportionately difficult -- it's a small niche, but it's a lot of effort. Userland APIs break all the time. The constant churn in the graphics and desktop space leads to a lot of instability and bug reports. Between Wayland being default on some distributions, unstable graphics drivers, and the umpteenth rewrite of God knows what other component in Gnome or KDE, you get to deal with the sort of bug reports and crash dumps that used to pop up fifteen years ago when a Longhorn beta was leaked and everyone tried to run their games on it for shits and giggles. Linux desktop is basically a neverending beta. People don't write games (or software) for it for the same reason why you don't write games for a leaked Windows beta.
It's no coincidence that Linux is such a big player in the embedded and server markets, but not in the desktop market. Writing desktop software for Linux in 2020 is about as enjoyable as chewing nails. It's an unstable and flimsy platform to target, and not a very profitable one, either. I can't blame any company for skipping it.
Edit: someone else posted this here and yep, it's spot on: https://twitter.com/bgolus/status/1080213166116597760 .
First of all, there's no "Linux API". The kernel does expose a stable interface but you're not going to write a game just by issuing system calls.
But the kernel is pretty much the only piece of this tech stack that exposes a stable interface. Pretty much everything else changes a lot. There are exceptions -- SDL2, for example, is great to write against. But most things aren't -- they change a lot, and they're undocumented. This tends to result in duplicate code that goes out of date and results in all sorts of strange quirks and bugs. phk has a good summary of this here: https://queue.acm.org/detail.cfm?id=2349257 .
As for drivers: there's one set of drivers that aren't baked in and they're critical for games, namely nvidia drivers. Anyone who's done graphics programming on Linux has their own horror stories about nvidia's stack. I won't bore you with my own, suffice to say that things are never, ever as easy as "you just write against the OpenGL API and you're set".
"Historically", I'm not aware of any major console that's built on top of a stripped Linux kernel. Sony has been using their own franken-BSD since at least the PS3. Don't know about Nintendo but given how much effort has gone into the occasional port for Nintendo hardware, I doubt they're using Linux.
Linux has been only recently adopted by some console devices, and those are basically embedded systems. You target a single hardware platform (with a single, known set of quirks), a stable kernel, a stable driver, a stable set of userland libs. It's not great -- backporting kernel fixes is notoriously finicky, for example. But it's a scheme that, at the very least, allows you to write code to implement whatever functionality you want to implement, instead of wasting time impedance-matching between userland APIs.
https://twitter.com/bgolus/status/1080213166116597760
There are other reasons to support linux:
- Game devs are usually a fan of linux / vulkan / open source (windows is bad for developers, it's closed source everything) - Linux is still a market portion. Some engines like UE4 support cross-platform builds with minimal work - Supporting competition to microsoft, and the really poor DX software
The question is, how high or low is the demand for a equally performing alternative “pc gaming” platform? I personally would banish everything windows-related forever.
How very rational. I wish HN had the same attitude each time Google sunsets a well-loved, but little-used product.
Other people on the comments have said similar things.
But according to [2] the game runs really well on Linux via Proton. Personally, I don't see any problem using Proton to play the game on my Linux gaming-rig.
[1]: https://github.com/ValveSoftware/Proton
[2]: https://www.protondb.com/app/252950
Looks like they were using some kind of translation layer that was translating DX9 calls to OpenGL.
Newer shader model support + newer shader compiler
Newer/more powerful debugging tools
Access to large new features like compute shaders, texture arrays, uniform buffers, etc
Access to new surface formats to enable features like VR and HDR
Better API performance + access to performance-enabling features like multi-threading
Direct3D 9 is nearly 20 years old. OpenGL has at least been receiving new extensions on a regular basis (though people are finally shifting to Vulkan) - with the exception of a few things shoved in by driver vendors via back doors, D3D9 has not changed at all.
Driver compatibility for D3D9 is also very bad at this point - the driver vendors don't give a shit about breaking existing software that uses it. I still occasionally hit driver bugs when working on old code that targets 9. Code targeting 11 will have fewer problems.
Psyonix stated that they would offer refunds for Linux/ macOS users. In the first few days post announcement, everyones' refund was being denied. It appears that this has since been resolved. I received my refund yesterday.
They do push for making more games easily playable on Linux, but they aren't pushing the game developers to release for it.
https://www.valvesoftware.com/en/jobs?job_id=36
Are you able to Google "non violent communication".
You know that I'm german and think I"m not smart, or what?
Or is this a misinterpretation?
Epic does nothing like that and even actively pushes games to be exclusive this Windows only, using their Windows only client.
Don't Epic make Unreal Engine, which supports Linux? I'm not sure it's fair to say they do nothing, if that's the case.
There are quite a few games that work great with proton, but can't be played online because the anti-cheat won't run. Like Arma3. It runs great in linux, but the binaries are always 3-6 months behind the windows ones. so your choice is to find a server with 2-3 people on it, or run it on proton, see lots of servers with hundreds of people, and can't connect.
Also the problem with fortnight, pubg, etc.
So yeah, the store works - but that doesn't mean the "Linux games" work, or work fully, with network.
If the latter, I agree but no storefront actually meets that standard right now. Valve happily sells stuff on Steam that barely works on Windows and before the new refund policies they'd perma-ban your account if you tried to refund a broken game.
Think about it like a game like World of Warcraft. It wasn't built once and then released, but rather new content is being produced for it constantly, so the game engine itself needs to be improved at every level as consumer hardware changes and improves.
Like a database ORM which can have Postgres/MySQL as the backend, but then you want to replace Postgres with BigTable. It will be very hard to keep the MySQL support.
SuperTuxKart is not an alternative to Rocket League! If you go into it expecting anything Rocket League has -- polished realistic-looking graphics, physics that let you jump and tilt and drive up the walls of the stadium, a thriving online play community, a matchmaking system -- you're going to be disappointed.
I'm not a gamedev and just have some hobby xp in DX and OpenGL, but I don't begin to understand why an OpenGL renderer would in any way depend on DX. Is this just code for "we have such few Mac and Linux users that it isn't worth our time to support OpenGL"?
If linux and MacOS combine account for less than 0.3 percent of their revenues... then even as a MacOS guy I have to see their logic... there is little chance of recouping the heavy lift that they would have.
[1] https://www.omgubuntu.co.uk/2018/01/wine-3-0-released-direct...
Epic's CEO, Tim Sweeney, is extremely negative on Linux if you check out his Twitter feed [2] and I get a feeling from reading his comments that he despises Linux with passion.
[1] https://news.ycombinator.com/item?id=19844241
[2] https://twitter.com/timsweeneyepic/status/964284402741149698...
I understand SDL2 exists. I understand that Valve has "mostly" pulled off linux/macos support. But, is it really worth it from a business perspective for all game developers to support linux? How big and wide do your margins need to be before it makes financial sense to fully support both operating systems? How many features (or even titles) will stay in the backlog because your developers are busy chasing down the 5000th weird linux network/GPU/sound bug that only occurs on this one kinda-old version of Ubuntu?
As I understand it, this is the direction Steam is heading by running games in containers.
https://www.phoronix.com/scan.php?page=news_item&px=Steam-Li...
Having a standardized Linux image with containerization support shared across the entire industry could be a really powerful tool for game developers who want to target Linux but don't have EA's budget. Over time, this could put Linux on equal footing with Windows in terms of platform support cost.
This way they have one binary that runs on all the modern distributions, then packaging is only to integrate with the package system, menus and stuff (and is optional).
There's also this: https://appimage.org/
So honestly, people complaining about Linux fragmentation haven't done enough research.
Nothing prevents you from providing your own preferred versions of most of the dynamic libraries along with the application, however. It should be possible to limit external dependencies to libraries that actually care about maintaining compatibility.
Game developers could do lots of things to support Linux, but many prior attempts to support Linux gaming have shown game developers that it's generally not worth it from a resources perspective unless the engine you're using already supports Linux and you don't need to do additional work to get your gaming running on Linux.
Ideally this is how it would be. Develop the game targeting Windows, and simply don’t do the things that unportably tie it to Windows. If you develop it from the start as cross platform, then it shouldn’t be some gargantuan effort to port it. It shouldn’t take that much longer to use platform-neutral APIs than the Windows-only equivalents.
Then just fling off a “totally unsupported Linux build”, stick it on an FTP server, ignore support tickets mentioning Linux, and let the Linux people figure out how to get it working—they will! Let them figure out their driver problems or which distributions ship the right library dependencies. A totally unsupported build is at least better for Linux users than abandoning the platform entirely.
I think a lot of games fail to work on Linux not because of the support costs or the platform fragmentation, but because the developers just don’t care or they choose engines and technologies that are not cross platform. It just never crosses their mind to do it differently.
Now, same thing happened with one of the worms games, Team17 was dismissive and rude. I ended up just getting a refund. I've been a fan of the series since the very first one, i've bought a bunch of their games over various systems, I own a copy of worms 3d on both GameCube and ps2, but I don't plan on buying another worms game or anything else they put out any more.
Also most game devs don't have Linux machines to build or test the game on in the first place.
I thought about it once, tried installing Ubuntu-- it wasn't as simple as I'd like, but eventually worked.. except it didn't seem to be aware of the GPU and was running at 640x480 or some shit.. deleted it.
As other people have commented, the usual trend for Linux support appears to be that the developer needs to support the most recent version of Ubuntu (or maybe LTS), and anyone not using that version does the legwork necessary to make it work on their setup. And for consumer versions of Linux, Ubuntu is likely to be by far the most popular distribution.
For me, that would honestly be the best solution to the OS decision. I could just connect it to my same monitor on the second input, and use the usb switch to just switch peripherals.
And it loses one of the big advantages of convenient couch gaming.
Although I think the vast majority of their games don't work on the most recent OSX release. Depending on your perspective, either Apple pulled the rug out from under them, or Valve is letting their code atrophy. Maybe a bit of both, but my opinion is more of the former.
Music Production has been hit hard by this same move. Plugins and virtual instruments that people have been using for years are all gone from support. All the open source plugins are out right now. Everyone is holding off and I am glad I use Linux and Windows 10 for music.
There haven't been many good reasons to release a 32-bit only macOS app for some time. If Valve is at fault, it's that they didn't require publishers to submit 64-bit builds for macOS years ago.
https://9to5mac.com/2018/07/27/steam-for-mac-64-bit/
That's the direction I'd like to see steam's containerization go.
Not really. Most hardware is very standard these days, which is why you can install Ubuntu on most any laptop or desktop and have it work with less than or equal issues than a Windows install.
Amd and Nvidia both have Linux drivers that work on all the popular distros.
The reason devs don't even bother with Linux is because there isn't enough people that are playing on Linux.
What is the state of vulcan across drivers and engines?
Doom 2016?
> What is the state of vulcan across drivers and engines?
Quite good actually. Intel has older generations supported than on windows. There are 2 mature AMD vulkan implementations.
Also through investments of valve there is a new shader compiler in the works that got merged in mesa which helps quite a lot. The performance is about equal, but sometimes faster under windows (I didn't look at benchmarks of 2020). Oh and vulkan 1.2 is implemented in mesa 20.
Oh and it's vulkan not vulcan
This is actually one of the root causes. It would be SO MUCH EASIER, for me, an app developer, if every linux user used centos, or ubuntu, or mint, or whatever the hell. Don't care, pick one. But, customizing is part of the fun... anyways.
Also yeah, desktop Linux is about 10% of users, depending on who you ask. Worse for gamers, although that's just feedback loops.
There's one more thing though, which most people aren't aware of... driver versions. Drivers often ship game-specific hacks for performance fixes. It's an insane, unspoken practice that occurs because some developers will only test heavily on one mfg GPU. Right now, nvidia is taking the brunt of the work because consoles are AMD based.
And by support I mean a one-off build for the platform and a public forum where users can ask and answer questions of other users. Maybe if you're lucky they'll do a new build when a patch is released.
Linux users aren't asking for much, and Epic has been more than just dismissive to them. They've been outright hostile, doing things like adding checks to make sure the game isn't running under Wine.
It's simply not worth it when 0.3% of your customers represents more hardware and software configurations than the remaining 99.7%.
Generally speaking once a game developer gets it working on Ubuntu the Arch wiki guys will happily figure out the rest on their own.
There's zero chance these for-profit companies are going to open source the current game that they are selling.
An employee at Epic has mentioned that if someone with Linux development skills was interested, they would be more than happy to bring them on to develop a EGS application for Linux. The thread can be found here: https://twitter.com/CanalOCaraDoTI/status/110621899365072896... (scroll to the top for the beginning).
[0] And frankly it is only slightly easier if you write FOSS software.
If you're using any engine even better, all of the major ones are cross-platform anyway and abstract all the nastiness away.
Open source is a million times easier. Your source is available. It's up to the distro's maintainer of your package to deal with compiling and binary compatibility.
https://github.com/ValveSoftware/steam-runtime
That's bullshit though. Why would you trust some random community maintainer to get between you and the user? Now when shit goes wrong there's one more person in the loop of blame to deal with. There are famous incidents of maintainers introducing problems to otherwise correct software, and ignoring the developer.
"I am constantly getting email from users reporting bugs that have been fixed for literally years who have no idea that the software they are running is years out of date." -jwz
How is this considered a sane way to distribute software!?
For FOSS projects, everything gets easier once you get it accepted in the package repositories, and if your project is popular enough, you can usually get someone else to do it for you.
In both cases, using a language that has a cross platform dependency manager eliminates a huge number of compatibility problems. Also, keeping libraries reasonably up to date also helps prevent problems from happening. Updating every two years should be sufficient to maintain compatibility with most Linux distributions.
Also, software vendors don't have to worry about every Linux distribution, just pick the top one or two and let users support the rest for you.
2. I've been making some UE4 projects recently (as im getting back into game development as a hobby) and the toolchain to cross compile to linux is well made and easy to use (and even easy to dockerize).
I think unreal engine support of linux is probably the better barometer of Epic's stance towards linux than their not-so-fully-featured launcher/store (which is many years behind steam).
DirectX on Windows, Metal on macOS, Vulkan/OpenGL4 on Linux
I don't have a comparison chart between DX12, Vulkan, and Metal but if engine authors can standardize on the open standard of Vulkan, it could have huge effects on creating cross-platform games and applications. A big push for this wouldn't be having authors like Epic, Unity, or CryEngine do this, but all the private publishers investing the time to learn and switch their next-gen engines over to Vulkan.
This is another issue unto itself. This often stems not from a CUDA/OpenCL debate, but rather how well a particular development group may be supported by either vendor in terms of tech and driver support. NVIDIA is usually pretty good at supporting game makers, and getting support for their GameWorks libraries added. GW for a long time was a weak spot for AMD as they couldn’t add proper driver support, crippling performance and limiting feature sets. A good amount of GW is OSS now, so getting those features and support in is up to AMD. I haven’t read the EULAs though.
https://developer.nvidia.com/gameworks-source-github
And beyond that, there's the age-old problem of driver quality- for a given platform, using the native API tends to hit fewer bugs, perform better, and support more features. This has been true for years with Direct3D vs OpenGL on Windows, for example- browsers on Windows all wrap Direct3D to implement WebGL.
Can anyone talk about how it plays on Linux? I can’t imagine a huge playerbase there.
just go ask the actual playerbase if they'd prefer the devs working on linux/macos ports or actual gameplay/issues affecting the average player and see the answer.
Surely the Switch's graphical power, presumably it's not going to get a bunch of fancy new DX11-esque features. I imagine they'll do the minimum to keep the Switch compatible with other clients in multiplayer.
But if they're keeping multiplayer compatible with an older Switch codebase, why not keep it compatible with older Mac and Linux branches?