C4 game engine drops Linux support citing frustrations with desktop Linux
terathon.com
terathon.com
Eric is indeed a very skilled programmer, but this engine is very much developed to meet his whims. He hasn't yet released any games on it, and the vast majority of his engine licensees are hobbyists, who quite frankly are also unlikely to release a game.
So while Linux was a nice-to-have earlier on, and likely sold him a few licenses, with UE4 heading to Linux it's unlikely to give him many more sales. And I suspect he's used to developing in Windows, likely with visual studio, and in comparison, Linux can feel quite archaic. And in that context, maintaining Linux build systems can seem quite painful, likely the primary reason it's getting dropped.
On the contrary, with Valve's current and monumental efforts, I suspect we're going to see a lot of games continuing to be released on Linux. And the tools are improving vastly, and some rather nice tools, vogl for instance, are only fully functional on Linux, which provides a strong advantage.
I'm personally pretty excited to see what comes from AMD being much more open with their ISA, and related documentation. I'm pretty hopeful for a very open and fast graphics API, OpenGL in my opinion is the worst part of working on Linux.
That's not it. Eric explained it in here: http://www.terathon.com/forums/viewtopic.php?f=2&t=14050&sid...
Frankly I doubt I will ever see them.
But I'm playing on this Thinkpad running Arch, using my Steam account. I tend to ignore games that aren't cross platform (although I have a gaming box running Windows 8 as well).
It helps that a lot of games that I like (Awesomenauts for example) are available and work amazingly well.
Certainly people still need the need for Linux as an alternative to Windows and I have so little hope that OS X users would also see the need. Looking at you HTF+.
Gnu HURD Forever!
Specifically, advanced controller support. SDL2 is far from enough.
For windows, there's no issue adding support for Logitech G25, G27, F710, Microsoft gamepads and Joysticks (the best joysticks ever made), and several other wheels like Fanatec.
In Linux it seems that only XBox360 compatibility is possible and everything else requires a huge amount of refactoring.
Also, raw keyboard and mouse support requires having root permissions and whatnot, something users can't be expected to set up themselves.
So, OpenGL has some performance issues but it works, input programming is actually a nightmare in comparison.
Still no Steam game works with the G25. Euro Truck Simulator 2 can't read it right, despite having kernel support, and the game is simply boring with a controller instead of a wheel.
It all makes you realise that computers aren't really user-friendly in the least, it's a lot of smoke and mirrors set up just right so one given platform will boot by god's grace and appear to work with stability. Linux won't make inroads until someone manages to write an advanced distributed AI to probe the hardware and automatically receive workarounds, i.e. do the thing that the hardware manufacturers do on Windows.
Not sure if that really is the case - to me it reads like "I spent so much time getting this thing to work and it still doesn't work properly now, so I just give up"
Yeah sure, the underlying reason for this might be that he doesn't know how to properly do it (and the reason for that in turn might be that it is hard), but how is not wanting to spend any more time on it purely a political position rather than a technological or business decision? Especially the latter, which is also explained again by Eric:
I cannot afford to spend weeks at a time just trying to install Linux, get it to boot, and get a development environment working. I simply don't have the funding to justify letting the engine stagnate while I mess around with an OS that should just work. It's extremely wasteful and unfair to users who are waiting on new features.
I think we found the problem. It's between chair and keyboard.
That being said, my last Debian install was pretty much effortless. But I seem to have a machine with which most Linux distors are quite happy :]
Certainly not compared to Windows, where you must consider VS/msvcrt version, if you are using third party SDKs. It gets into "really not funny" territory when they have conflicting requirements.
Compared to that, Linux development environment is a piece of cake.
But that doesn't mean they don't exist partly on Windows. "where you must consider VS/msvcrt version, if you are using third party SDKs." is a bit too narrow: that is (afaik) only the case if you use binary distributions of 3rd party libs and only for particular languages like C/C++ and if they make use of the standard libraries and force that upon the user by exporting instances of objects in it - and more often than not I've encountered all sorts of situation where that was not the case:
- it's OK to have e.g. a C lib linking against msvcrt x and use it in an application linked against msvcrt y, as long as the API is written properly and doesn't do insane things like trying to free what has been malloc'ed elsewhere
- if you have the source, you just build everything with the same VS version and that's it
- for C# etc there's a rather decent package manager so that's it as well usually
It may be or may be not easy to rebuild everything with the same VS version, especially open source packages. Many maintainers do not care about VS at all (e.g. xz/liblzma - use mingw, VS is not C99 anyway... but mingw links agains msvcrt.dll, which is a no-no) or have some crazy build system, that is supposed to work cross-platform, but really works only on Linux and maybe OSX (I'm looking at you, py2cairo). Some of them do care and building is a piece of cake (curl). Or they are somewhere in the middle, where will make their own build system, that defies all your expectations and does it's own things ignoring your vcvars (Boost).
When we get out of the C/C++ realm, it gets easier everywhere, whether C# or Python.
I can easily believe that someone used to windows with its mishmash of installers might have an unpleasant experience. Apt-get works wonderfully on a pristine system, but not so well if the system is halfway upgefucked with tarballs and rm -rf.
And particularly if systemd on ubuntu 14.04 supports his hardware as poorly as it supports my new laptop.
I think it doesn't have to be political. The tiniest bit of ill will towards linux, a bit of windows-like behaviour (tar xf, rm -rf), and a bit of badly-supported hardware is quite enough to end up with an unworkable system and difficult-to-diagnode problems.
> What a pity they've decided to take a political position rather than a technological one.
Ironically, it's the political (rather: religious) position of Linux that is getting in the way here. If you're not looking through the rosey colored RMS glasses it's very clear that the dev has taken the practical position.
Don't get me wrong, I wish it was different. Linux has amazing potential, but it unrealistically hostile toward these guys. Maybe SteamOS will bring some uniformity to the situation.
The resulting package can install the repo by itself - i.e. user downloads the package, install it and suddenly, he has repo for updates installed. Google Chrome does it, for example.
And i suspect this has little to do with the original complaint. I think that is more in terms of "lib version X-1 do not support the feature i need, X+1 breaks a different feature in a subtle way, and version X can't be found in any distro repo out there".
Sadly the above is not a problem of Linux or libraries, but of distro package formats balking at having multiple lib versions installed at once.
It's also possible he prepossesses the comments out.
But, say I propose to stefantalpalaru to write an engine supporting Linux from scratch. And if that's too hard, wouldn't it be fair to say, that it is also a problem between the chair and the keyboard?
But seriously, let's take a quick look (here)[http://www.terathon.com/architecture.php] and think, what might be a clear pain point in Linux, even if the "needed libraries" worked perfectly with all the hardware and all distros and the blobs were perfect.
Did I hear someone say "Linux sound support"? Yes, that is a correct answer. Sound in Linux is a know clusterfuck.
What else might be not as trivial? Did someone say support for multiple graphic cards? Yes, even with OpenGL it might be an issue.
Not to mention all the GUI tools.
So yeah, those all things obviously would never have any less than functioning dependencies on Linux...
C4 isn't the only case where developers are frustrated with Linux. And if Windows and OS X fare better in attracting developers (which these systems do), even though Linux is essentially free (and the competition isn't), that's per definition a sign of a shit product.
So, you can of course, think that all of this is FUD and everybody in the world is incompetent, while more and more people drop support for a system that's too much duct-taped together for its own good.
The spec here isn't that trivial, I mean the thing has clearly strict performance and portability constraints across systems and compilers, not to mention maintainability and quality consistency across the releases. Finding libraries that fit well with those constraints, especially for a large project like this, isn't easy. So I can imagine scenarios where NIH would be justified.
I was mostly making a point, that using such broad strokes to claim someone to be incompetent, while assuming all the libraries and tools required are in perfect condition and perfectly work is dumb and Stefi's hissy-fit here is just self indulgent ego-stroking.
If they say it's a legitimate roadblock for them, then I tend to believe it.
Maybe a possible alternative would be to focus on one particular linux distribution, like ubuntu or debian, with certain dirty intall scripts ?
Or go all the way and just deliver a bootable CD or USB drive that install the games somewhere, and then boots up a certain linux kernel configuration with specific, working nvidia or amd drivers.
Honestly if I had a successful game I could sell, I'd try to sell it at half the price by packaging it with some linux distribution the game works on, just for promoting linux to show the consumers that developers appreciate it.
Maybe another other alternative would be to offer games on certain hardware which is supported, and not to other types of hardware.
But obviously, as long as hardware vendors don't give a damn about linux, I won't be surprised reading those posts.
Game developers should not expect being able to use the latest graphics features on an open platform. It just won't happen. The 3D hardware industry always adds new things, it's impossible to keep up unless you had engineers working tightly with nvidia or AMD.
So drop the support of high end 3D features, only keep the core ones that have been working for a long time (do you really need that shader ?), focus on other basic things (like scriptability and other libraries, there is so much stuff to put in a game engine), and deliver a working 3D engine that is easy to use and program with. I don't think any small developer who wants to release on linux can really compete with AAA, high end graphics titles. The only possible way to compete is to bring something new in term of gameplay, stop focusing on the graphics and the bells and whistles, it just won't happen.
TLDR:
gaming is obviously anti competitive if you want to release on linux. what to do: don't try to compete with what other games have already done, and focus on things that are doable and have been done well for a long time. There are many existing game concept that could be improved if you stop wasting time on the graphics. Having basic 3D rendering is already awesome in itself.
You're really suggesting people in a field that is constantly pushing the boundaries of graphics to drop one of the things they do best?
> do you really need that shader
Yes!
> I don't think any small developer who wants to release on linux can really compete with AAA
You'd be surprised with what a small developer can do, See tomorrow children. Sadly sometimes it sometimes seems that if you want to push graphics features, you cannot release on Linux.
> Having basic 3D rendering is already awesome in itself
No, not really. I'd prefer 2D rendering to basic 3D rendering.
> don't try to compete with what other games have already done, and focus on things that are doable and have been done well for a long time
Did you really just contradict yourself in the same sentence?
Though, more to the point, the problem isn't that getting something running Linux would be difficult. The problem is that in order for Linux to have proper and first-rate support, or in some cases, any support at all, you need to start getting developers working on it as a primary development platform. And if I can't do the things that I, as a graphics programmer, need to do, I'll go elsewhere. Working on Linux is nice, but if I have to choose between developing the game I want to, or having Linux support, that's a trivial decision.
Better work in CGI graphics then. Also, what's the point of rendering ? You won't make a game if all you have is good rendering. You also need quality content. You can't be a good graphics programmers AND spend time producing geometry.
> Did you really just contradict yourself in the same sentence?
I just meant do improve designs that have been proven to work, not try to make the same kind of design you usually see in AAA shelves.
I see many indie games just being some remake, or influenced by many other games. They don't have any kind of standing out feature, the only interesting thing there is, is content, which is not what makes a good game. There is almost never a feature of the game that is standing out in term of gameplay and algorithm.
A good example is minecraft: the game is interesting because it has an infinite, consistent 3D level. No game had that before. All I care is gameplay and interactions. My point is this: if a game is not different in gameplay and can't attract the player imagination, it's maybe not worth doing.
But yeah, as another commenter stated, it just doesn't have the leverage as the bigger engines have (U4, Unity, etc), and those have very competitive pricing for hobbyist developers nowadays. Not to mention the financial means to have their developers also support Linux, with all the headaches that may incur.
I even think that the consumer perspective is the one that hinders Linux. Want to develop something for Linux? What's the display server? Proprietary or free drivers? What Desktop Environment? QT or GTK Application? All those things are fine to develop for, but what do you develop for when you don't have time to test and support every existing configuration.
The answer in my opinion is "develop for Ubuntu LTS". Non-LTS changes too fast. In contrast to Debian, you can assume proprietary nVidia/ATI drivers. If it works on Ubuntu, it (usually) also works for Debian and Mint, although you don't have to explicitly support them. Arch users are probably used to and savvy enough to port stuff from Ubuntu. It implicitly means GTK/Gnome/Unity, although games probably just use SDL and OpenGL.
I don't see why. A Steam Machine would solve exactly the problem you point out: it would set a fixed configuration that developers could target. Then other distros would have to adapt themselves if they wanted to run those games, and not the other way around.
That's the sort of thing projects like systemd aim to fix.
> "Want to develop something for Linux? What's the display server? Proprietary or free drivers? What Desktop Environment? QT or GTK Application?"
You don't need to concern yourself with the display server if you're writing using a library like Qt or GTK+, but it's not a hard question anyway (X.org now, Wayland/Mir in the future). Drivers wise, most devices only have one driver to choose from, the only exceptions are for the GPU, and if you want to play games the answer is clear (NVidia card, proprietary driver). Desktop environment doesn't matter, they all support X.org graphics frameworks.
There are certainly challenges with Linux development, and there is a need for a bit more stability lower down the OS stack, but the situation is improving, and Windows proves you can offer both choice and stability. The only issue I see that is a time bomb with regards to Linux gaming is the sound stack, everything else appears to be improving.
And the only salvation for the driver mess is that apart from Nvidia, Intel and ATI, every other manufacturer has left the picture. No more Tseng, S3, Matrox etc.
But Windows is immmensely popular. So you have to go through those problems. Linux isn't that hard, but it still might not be worth the effort. OS X does pretty well in that regard, not that popular, either, but very homogenous. At least since the days of RealBasic apps is finally over ;)
The problem with Linux (above the kernel) is that everyone is pulling into a different direction.
In Linux, there is glx[1]+OpenGL and SDL. The problem (quality of OpenGL implementations) is not unique to Linux.
[1] - yes, soon to be EGL.
A veritable shitfest of useless and downright poisonous changes that alienate users and non-core developers.
"Oh, you have this thing that works perfectly? Well, here's a shitty idea with a shoddy execution that is the new standard. It supports this feature that 1 percent of users like and no longer supports this other feature that 99 percent of users actually care about."
I personally feel that C & C++ develop on Windows is ANAL. Installing libs and detecting isntalled libs, it's very problematic, when on my GNU/Linux desktop I only need to do a : sudo apt-get XXX or git clone XXX & make & sudo make install
There are outstanding ecosystems for packaging and dependency management in place. That makes it easier to embrace than to avoid dependencies as a library developer.
Wrestling with weird stability problems (which might be a hardware fault, might be buggy display drivers, who knows?) for weeks on end before flouncing out stage right promising never to return is the mark of someone who hasn't really thought things through.
I work on Linux running in VMs every day, but can't recommend this setup at all for OpenGL development.