That is by design though. The whole point of a RHEL release is to give enterprise a stable platform that will be supported for many years.
It’s minimal maybe if that’s what you do as a job.
I’ve been making and shipping games for 25 years. I’ve shipped various flavors of Windows, OSX, Linux a couple of times, and 3 or 4 consoles.
Because of the proliferation of hardware, drivers, and software, every additional SKU is a lot of work. Shipping a game is like inching your hand into a meat grinder. Each additional platform is just another finger to jam in there.
I don’t use LINUX. For me to effectively ship a LINUX build I either have to pay someone else to do it (and support it!) or I have to get comfortable enough with LINUX to make builds, troubleshoot, and not screw it up. That is not an insubstantial opportunity cost.
I can JUST get by on OSX, but we won’t be shipping OSX builds anymore, because it’s < 2% of our desktop sales, and the cost to support and ship it outstrips any financial benefit.
It’s not just booting it out the door either, it’s the post-release support.
It’s a lot of work to do, it’s not fun work, and almost nobody appreciates it. Those are hours that could make the game itself better. It’s not about that sweet sweet cash - it’s about putting your effort where it belongs given the circumstances, when you have limited time to spend.
If I LOVED those platforms, and it was a labor of love, great - then it pays for itself in other ways. But for most devs, it just isn’t.
Gosh, Travis, it sounds like there’s just a giant Windows logo where your soul should be.
Which AAA graphical quality games have you shipped that I can look at for examples?
#AMIGAforever.
I’ve been doing cross platform development professionally for well over 10 years, in a pretty “optimal” scenario for it (low level geometry libraries that don’t really talk to the OS), supporting teams that use cross platform UI tools to attempt to take the pain out of it for them, and that does not match my experience.
It’s entirely doable. It can even be straightforward if you are super careful and have good processes (except whenever Apple do something horrid because they hate you), but there are certain irreducible costs.
I know. And devtoolset is a fantastic piece of work I love very much. But ultimately 5 years is just too long between major version releases, especially given how much things have changed in the last 5 years.
There are some changes coming with RHEL 8, but I don’t know if that will make your life easier.
Having had a Mac, I can report that the resulting ports tend to run worse than if I took the Windows version and ran it on Wine/Proton. It’s also incredibly common to see native ports that just wholesale drop features because they couldn’t figure out how to port them properly given an OS’s limitations (such as OSX’s always-outdated OpenGL drivers). And then there is post-release support (as you mentioned), which is rarely there. Devs are afraid to release patches on OSX/Linux because they can’t test them properly or the person who did the porting job can’t be bothered, or they just don’t feel there are enough users on those platforms to justify patches.
Native ports are an approach that doesn’t scale. Wine and Proton scale.
For serious.
The OSX OpenGL drivers are the pits, and you can’t even ask people to upgrade to a specific version. On specific chipsets, instancing shaders just… did weird shit… and there wasn’t anything I could do about it. When you start looking at the user numbers and the amount of pain involved it just doesn’t make any sense. I’m going to bleed for this? Ugh.
Standards-compliant shaders that work elsewhere arbitrarily not compiling with no error message was always a highlight of my day.
I’m sure RHEL 8 will be fantastic.
Obviously the G++ breaking change will be a headache, but ultimately my objection is more that RHEL 8 didn’t come out 2 years ago and we would have had to deal with it then.
I actually agree with that. I’m not one of those that think better Wine&Proton would harm Linux development, quite the opposite.
My dream distribution would be one that has Wine integrated at a core level, without the user needing to do any additional steps to run anything. You can simply download, install and run anything as if you’d use Windows.
Of course, for that to ever work out, Wine would have to mature even more, meaning more than just Valve or Codeweavers investing into its development.
And then someone to integrate it into Ubuntu (or make a new distro - just kidding).
Ah, if I found a pot of gold…
Your strategy to try and discredit those who disagree with you is very opaque and somewhat sad.
Do you have to play football to know the rules or be an architect to know about structural analysis? No? Thought so.
You can take my word of knowing what I’m talking about, look me up (it really isn’t hard to find out who I am, though good luck with finding most of my work, since I usually work under NDA and most projects won’t even show up), or just let it be. I couldn’t care less.
I’d just assume that someone telling me they have experience in cross-platform development isn’t just lying through their teeth, though ;)
An actual argument! I could kiss you, my good man.
This sounds to me, though, as if you’ve been working on a very low level. As in, one of the people that develop engines, instead of those using engines to develop games.
I’m talking from the perspective of a user - someone who uses a cross-platform library to develop a game, or other software. In such a case, I’m sorry, but if you did your job right, you won’t see that much trouble on either platform - not after testing sufficiently.
Other people already put their finger into the low-level meat grinder for you. You just have to keep your libs updated and maybe, in incredibly rare cases, apply some patches to lib code manually.
Again, what I understand as cross-platform development is explicitly NOT porting, but using software that removes the need to port to begin with (for the most part, there’s always something).
For games it just is not that simple. Shaders are shaders. Drivers are drivers. These things are not managed fully away by a cross platform engine. Your interaction with them is not fully protected.
Game engines do not insulate you completely from the implications of your choices - and those implications may only appear on specific hardware and software combinations.
Doesn’t stutter on this platform - does on this one, on this hardware. Oops, if you have textures at 4k on this driver on this hardware, your FPS halves. Oh no, if someone has McAfee running, something else shits the bed. Uh-oh, fullscreen toggle doesn’t work right on this obscure combination of things.
It’s just plain not that simple.
The ‘software that removes the need to port’ is WINE/Proton.
shrug
Also this… this is another big thing. ‘Testing Sufficiently’ means a hardware lab for each platform variant with all the common hardware and software configurations. This is not an easy thing to do.
Non developer here but you can’t just keep saying this. The right tools for the job that includes cross platform issue free compatibility might not be the right tools for the job overall.
I’m just a user but I’ve tried Steam on Linux, with poor results. Even games that were flagged as specifically working well, still had issues. Even mature, aging games with no new code in ages (XCom).
That is when you want to completely eliminate every single bug possible, which just isn’t feasible in any scenario (except middleware development).
Specifically talking about Linux game development, you want to target Ubuntu, 64bit, with a set of different most common hardware configurations. That will cover the vast majority, which is enough. People picking Linux, but not Ubuntu, for gaming, know what they are in for, and made that choice out of their own free will - that’s the main reason I’d never pick anything except Ubuntu, it simply has the best support.
This is also why developers’ complaints about “all those distributions” ring very hollow to me. Just support Ubuntu, write that as a dependency on your store page, and you’re good.
Anyone who develops anything knows that error-free software is a myth (except for very simple software, which games are not). You want to keep the amount of errors as low as possible, obviously, and prioritize your bug hunting, but doing “each platform variant with all the common hardware”, especially when you are already using middleware which should have done these tests already, sounds like utter madness to me.
Man it feels weird not being the most certifiably crazy person around here sometimes :)
I don’t know jack about Ubuntu or LINUX. How many man-hours of time do you think it would take for me to get familiar enough to reliably ship software on it?
Lab testing is not about eliminating every bug possible - it’s about eliminating common ones. Otherwise you spend your time chasing those problems post-release and they impact the perceived quality of your title. Ignore that testing at your peril as a developer, especially if you’re doing anything technically interesting.
To be clear, when I’m talking about platform variants, I’m talking OSX/Win/Popular Linux , not every weirdo permuntation of Linux.
I should clarify this so you know what I’m talking about. I’m the only engineer at my current company. I make the game, and am also responsible for engine/low-level work - as well as support, design, a bunch of art, audio, organizing the QA, and running the company. And our games are pretty big projects that are technically complex. I have some of the widest breadth of experience across the entire process of development, end-to-end, that you’ll find around here. I’ve run a studio of 30+ people also, for 7-8 years. I can’t think of any position or job in the continuum that I have not occupied. I’ve been doing it very successfully for quite some time. So I’m speaking from a fairly solid base of experience, developed over a long period.
Not trying to blow smoke, but for the most part, my position is pretty well informed. :)
Then I guess we’re saying pretty much the same here.
With your experience, it really shouldn’t take long.
Linux is a pretty open book, any questions that arise will have been answered by someone already. I consider myself familiar now, but I became so “unfocused” over the course of just using it day-to-day.
To get started with a development, make builds reliably, best set up a build server, etc… A week or two, not longer than a month for sure (not for someone with experience). That’s my guess at least, but as I said, I gained my familiarity differently.