Rocket League left behind on macOS and Linux due to DirectX 11 shift
gamasutra.com
gamasutra.com
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.
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.
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.
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).
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.
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.
[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.
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.
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.
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.
Other people on the comments have said similar things.
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.
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.
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.
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.
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...
Can anyone talk about how it plays on Linux? I can’t imagine a huge playerbase there.
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.
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?
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.
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.
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.
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.