I've been using the "experimental" LTS 2017.4 Linux version at work for over a year and the only platform-specific issue has been broken .NET 4.6 support, which has long since been fixed in 2018.x. Other than that, I've found the Linux builds to be in good shape since the 5.x series (platform-independent Unity buggyness notwithstanding).
Steamplay has been a huge influence in my household. Dunno about the bigger picture. It's much less hassle than the Wine wrappers of old and for the most part just works.
Well the question is if Blizzard ports Hearthstone to Linux as a “hey, we have a beta for you guys”, and bring some buzz. The annoying part is the battle.net launcher.
This comment brings to mind a discussion I was having in my current company.
We produce our own game launcher (think: uplay or origin) and I asked if there were plans to produce a Linux version of the launcher. They replied “no because productions (games) [weren’t] asking for it.”
Inversely, when I ask productions if they will support Linux they say that there’s no point because the launcher doesn't support it and the launcher is mandatory.
To a degree if demand for Linux support was loud enough, they could probably swing a mandate to add support to both. I'm not sure if it'll ever get there but one example is that Valve is now aggressively investing in tools to enable playing existing Windows games on Linux. This could result in more happy Linux users asking for improved compatibility or direct Linux ports (for a better experience), but we'll see...
The Battle.net launcher uses Qt, and they already have a macOS version of it, so it shouldn't be too difficult to port.
Edit: That said, it's not like the lack of Unity Editor on Linux was stopping them from having a Linux version of Hearthstone. It has been possible to target Linux for years.
One simple example: battle.net installs its own root certificate to the OS trust store. How do you do that for Linux? There are plenty of distributions with different rules. That would be some work.
Varies by distro. For example, on my CentOS 7 desktop just now:
$ cat /etc/pki/ca-trust/source/README
...
QUICK HELP: To add a certificate in the simple PEM or DER
file formats to the list of CAs trusted on the system:
Copy it to the /etc/pki/ca-trust/source/anchors/
subdirectory, and run the update-ca-trust command.
That README is part of the "ca-certificates" package.
As seba_dos1 points out though... why would doing this be needed for a single application?
It should be possible to point the cert validation code at a non-system-wide CA chain.
How is that going to work when most of the users are behind NAT/Firewalls? That's a connection model that just doesn't work well on the modern Internet.
I'm also kind of baffled by the need to install a Blizzard root cert in the cert store. That's normally only necessary for people who are too cheap to get their certs signed (Blizzard makes enough money to do this) or who want to MitM encrypted traffic from your host.
You're opening their website. JavaScript on their website connects to https://localhost:12345 and uses that connection to interact with battle.net software that runs on your PC. NAT/Firewall is not an issue. But that client software have to present valid certificate for that localhost website. To do so, they generate that self-signed certificate at installation time and mark is as trusted, so browsers will accept it. There's no other way to do that, really (well, there's a way actually, but it requires to sign some very non-standard agreements with certificate authorities, I know that Plex does that). Blizzard does not use that certificate to MitM your connection, because they don't send it back, it's generated, stored and used locally.
I don't like this practice too and I would opt-out of that "feature" having the choice. I just used to develop similar software, so I understand why they did that.
Browsers require it. If you're establishing connection from JavaScript that was loaded on HTTPS website, you can't establish connection to HTTP.
I've heard recently about some movement to allow HTTP connections to localhost, but I did not investigate that thoroughly. TLS should not be needed for localhost, that's true.
I think this is more about making it easier to run the Unity editor headless in a docker container than it is about making lives easier for those extreme few who actually want to use the editor within Linux. Linux users often choose Linux because it is open. The Unity editor is definitely not open.
That's an educated guess, not something I know for a fact, and it makes sense given what I know about how the tool has evolved.
Unity has been able to produce games that run on Linux for a long, long time, so Linux is making some headway, you're right.
It is very intuitive! I picked it up in about 30 minutes, and I'm using it for a small project for a friend. I've previously written games in Python/Pygame, WebGL, and C++, and I've tried out Unity and was a bit overwhelmed. Godot is way faster, simpler, and friendlier. Try this tutorial: https://docs.godotengine.org/en/3.1/getting_started/step_by_...
I recommend using GDScript instead of messing with C#, which is supported but much more difficult to set up. GDScript is really similar to Python, the editor has Intellisense/autocomplete (even for strings!) and all the documentation is built in under the Help menu. It's a very very pleasant experience overall. It's also the first time I've been able to work fully offline thanks to the extensive built in help, and this does wonders for productivity.
I'd also like to point out that Godot 3 has full 3d support with PBR support, custom shaders, skeleton animation, and basically everything you'd expect in a 3d engine. It's way more fleshed out than when I last looked at it in Godot 2, and ready for prime time.
Coming from Unity, I've tried Godot and I'm never going back to Unity. Yes the Asset Store is basically empty, yes will have to wait version 4.0 to have a powerful renderer, but the architecture is so clean and intuitive.
Unity feels like Windows, they stack on top of each other all the latest shiny features to attract customers resulting in a massive mess instead of thinking about a coherent overall architecture/UI. Their latest ECS system is an eg of this, they have just stacked on top of the pile a more FP approach although their architecture is not necessarily designed for that, but hey, FP and data-driven is trendy so let's add this too on the pile .
The real drawback right now with Godot is the 3D renderer which is okay but clearly not on par with UE or Unity, but 4.0 is coming with a re-written from scratch new Vulkan renderer.
I would love to use an open source alternative like Godot -- but their intense OOP system vs Unity's push embracing a more FP approach has really put me off.
Godot and its documentation is great! Was able to wrote a working mobile app under 5 hours with GDScript. As of version 3.0, C# support is available, haven't check it out tho.
For anyone interested at all in software freedom Godot is an excellent choice, and I hope it will grow more.
Unity's licensing terms are complicated and litigious, and because of this their tooling is locked to their online platform -- you can't use Unity without logging in. This means they at any time they can lock you out of their tools. I'm honestly more comfortable with older licensing models where you'd get your software on a disc for a fee. Not only do you not own the engine, you don't own what you created on it. They can lock you not only out of selling, but out of even compiling or editing your own game.
I get that the games industry is driven by revenue, and I'm comfortable with buying and selling games as a product. I'm even comfortable with selling commercial software at a flat fee. But that doesn't mean we can't collaborate on engines and tooling outside of a revenue context to move the state of the art forward. Most advances in game development have been locked for decades in the proprietary engines of large studios, and every serious indie developer had to develop in 2d or start from scratch. Unity's more open licensing model was a huge step in the right direction and has inspired a lot of creativity but it's still fundamentally a closed platform that can lock further innovations behind a paywall and deprive creators of tools.
This is their right -- they're not hiding the terms of their licensing at all. But if as an indie developer you really want to own your game's code instead of locking it into Unity's platform, Godot is the way to go.
You definitely can, but it requires working with a sales rep to buy named or floating licenses that are served up by a locally run license server. I would be surprised if they did this for single quantity license purchases, though.
Additionally, after subscribing for two years, you can stop subscribing at any time and continue to use the latest version of the editor at the time your subscription expires, perpetually, as in "perpetual license that you own." This was announced at the same time they announced the switch from perpetual licensing to subscription licenses, if I remember correctly.
I didn't know they sell floating licenses, that is interesting. I think the fact that this is available for large clients shows that the default is giving up a lot of freedom though, and that there is demand for more.
With regards to the perpetual license, this is rooted in a promise from the company that they will continue to license it "perpetually", not that it is impossible for them to shut down your software. What happens if their licensing servers go down, or they decide that you as a user are so egregiously in breach of their contract that they cannot continue their perpetual license? This can be due to arbitrary restrictions, such as a local government passing laws which do not allow them to continue their license. Consider if an old version of the Unity engine is in violation of GDPR, for example. They would not be legally able to continue perpetual licensing for their product, and they would be forced to shut you down. That is not ownership, and do not let anyone fool you into thinking it is.
hope it's better than UE4 support for it, which is basically 'here's a bunch of code, good luck'. it has such crippling bugs its utterly unusable. Good luck unity to do better! I hope they make it awsome.
They have the ability to sell floating licenses, but you must work with a sales rep to get them, and purchase through one of their resellers, if I recall.
I do not know if they roll their own license server or if they can use commercial license servers that may already be in place in an organization.
License servers exist. Surely it is cheaper for them to license from someone who does license servers, or use a client's existing license servers than it is for them to develop and support their own server.
I have high hopes for it, since the experimental version already worked quite well for some time. Still, Unity was one of the reasons I got Win10 on an external hard drive...
It's quite a dead meme, but with things like photopea, Blender, smooth Linux VsCode version, stepping stone distros like Mint and now Unity the year of the Linux desktop might come!
I am interested in a switch to Linux (web developer, I use OSX, I need the terminal for all my tasks) but had not looked at Mint yet. The website looks like it was made 15 years ago, are they more modern than the website seems?
For "most MacOS-like experience" and "willing to compromise on FOSS philosophy for practical convenience in GPU-related work", I recommend taking a look at Pop!_OS. It's System76's take on Ubuntu with Mac-like UI tweaks and proprietary Nvidia drivers built in.
I've personally found Budgie Linux to be the most "MacOS-like" distro. It is also based on Ubuntu.
Earlier this year I was forced to do an OS refresh on my home system, and I decided I wanted something closer to MacOS; before I had a hacked together system that approximated (virtually identical) Crunchbang (#!) - but was based on Ubuntu Minimal (14.04 LTS) and built up from there.
I wanted something that was still "lightweight" in the sense that it did what you wanted and no more; something with a fairly MacOS-like "intuitive" interface. I wanted something that could be configured easily without needing to hack on config files (as I had to do with my mess - updating OpenBox, etc). But I still wanted to be able to easily modify it to make it mine (unlike MacOS which is pretty locked down in the modding department).
I looked at PopOS, I looked at Mint, I looked at straight Ubuntu, and I tried BunsenLabs (what evolved out of #!); it wasn't until I tried Solus that I found the interface I liked - Budgie Desktop.
Unfortunately, I hated the Solus package management system; I wanted my Debian archive files, and Ubuntu repos, etc! But a quick search found me Budgie Ubuntu - I tried it, and loved it.
Ultimately, to each their own; Budgie Linux may not meet your definition of "MacOS-like" - but it met mine, and is certainly worth a look I think. I don't regret choosing it (my only "regret" - which is minor - is choosing the 18.04 LTS - so I couldn't get the latest version of Budgie, and won't until the next LTS release; currently Budgie is on 19.x (x.10 and x.04) - and that version has the latest version of Budgie, but LTS won't get it until 20.x).
I liked Budgie, which is an "official flavor" of Ubuntu these days[1] like Kubuntu, Xubuntu etc. Personally I didn't find Budgie to be a lot nicer than stock Gnome, but it has some visual flair for sure.
I've found Chrome OS to provide the most Mac like experience outside of Mac. Its Linux app support is still in development, but I successfully made a Unity game on my Chromebook!
Lack of website design skills is sadly a chronic illness of the FOSS community.
Mint is super solid though and probably the most approachable beginner distro in 2019. Comes with an easy installer, a choice of desktop environments that are all pretty nice out of the box and familiar and the fact it's based on Ubuntu/Debian makes looking up any problems or looking to customize it a breeze.
If you are looking for a Distro that works out of the box, Mint is pretty good.
"Modern" is kind of a loaded word, but Mint is both new and has a very polished UX, if that helps. Coming from OSX you should have smooth sailing, besides inherent things like window management button order and switched up yes/no dialogues ;)
For example, the installation is a window where you just click through the settings, not some command line jungle, to give you some kind of feeling of Mint. Under the hood there is of course the full power of Linux.
Personally, the switch brought me to discover i3wm (https://i3wm.org/) which is a fundamental different way of thinking about your screenspace. Not affiliated, but if you currently have an open mind about your workflow, I can highly suggest it for frontend-dev. Basically, windows automatically fill all available screenspace, which is awesome for the plethora of terminals you tend to have sometimes as well as resizing graphics/webpages.
