That's a bit naive / generous. The primary objective is to get good PR and the secondary objective is to get people to switch to their engine. "Helping devs" is a distant third, contingent on how they actually divide up these $25M. It's a calculated market share expansion push at its core.

And that kinda ends my rant, I love working with Unity and I can create really cool optimized things with it, but I cannot help complaining about how slow the core toolset is evolving and how Unity Technologies as a company constantly tries to create services we can buy into when that development time should be spent elsewhere.

It blew up because Unity changed their TOS overnight at the same time they pulled the SpatialOS license keys, so the SpatialOS guys made a big deal about it, which spread into major tech news sites. But it's larger than SpatialOS - even though Unity's blog post about it says you can run your built Unity app on any cloud server you want, that their beef was about SpatialOS being its own cloud server with a Unity SDK to access it, the TOS does *not* say that, and from Unity's actions they aren't going to change it.

According to their TOS, developers aren't allowed to run anything built with Unity on any managed cloud server without express permission from Unity, and they list only 4 cloud services on the approved list. Meaning, if you make a dedicated server for your game in Unity, you are breaking their TOS to actually put it up on any internet-based server and use it. Their blog post differs from the legal language included in the TOS.

The same can be said for many applications, unity since mid 2017 has generally been very stable, but it will not save you from headaches and memory leakss/infinite loops introduced by developers. Their documentation is quite often extremely bad, especially for more recent additions or smaller changes.

It blew up because Unity changed their TOS overnight at the same time they pulled the SpatialOS license keys, so the SpatialOS guys made a big deal about it, which spread into major tech news sites. But it's larger than SpatialOS - even though Unity's blog post about it says you can run your built Unity app on any cloud server you want, that their beef was about SpatialOS being its own cloud server with a Unity SDK to access it, the TOS does *not* say that, and from Unity's actions they aren't going to change it.

According to their TOS, developers aren't allowed to run anything built with Unity on any managed cloud server without express permission from Unity, and they list only 4 cloud services on the approved list. Meaning, if you make a dedicated server for your game in Unity, you are breaking their TOS to actually put it up on any internet-based server and use it. Their blog post differs from the legal language included in the TOS.

So the entirety of your Unity knowledge comes from the complaints of a single person that, despite it all, is still using it.

For what it's worth, if I had to voice all of my Unity complaints, I could fill an encyclopaedia and the language would make a truck driver blush bright red. But that's how it goes with any piece of software more complex than Winamp, let alone a development environment.

I understood that it kills the devs and everyone using the tool, but why has it gained so much traction in such a short time despite Improbable being a relatively small company and why Epic is involved suddenly?

Epic is involved, at least in part, because Impropable Edmonton, now led by the former BioWare GM, works in Unreal 4 so they already have a pipeline for Unreal and Epic is supporting that, transitioning all other Impropable studios over to that same framework, at least that is what it looks like to me.

My overall impression is this though:
Open Source company TOS violations against Private Corporate company.

Which one am I gonna put more faith in? Yeah, Epic games, you should've read the tiny lines, get your people out but afaik the transparent company here is Unity, not you and this was self-afflicted due to lack of oversight by someone. I've heard the dispute over whether Unity changed their ToS last-minute to cause this conundrum, and while I haven't read it myself, I keep hearing accounts on it saying that what people refer to as "changes" was really clarifications, which is something Unity changed to their ToS as Impropable started crossing their line and also that Unity had given them time to react to these violations, but Impropable kept ignoring their warnings until Unity pulled out.

Unreal 4's C++ support also sucks. If your code has faults in it, it's not just throwing errors or exceptions, the whole UE4 editor goes in lockdown. Besides that, documentation for Unreal is horrendous. Nobody, particularly not indies are going to use Unreal 4 without some face-to-face guide to make them understand how the engine works.

Could Epic manage to put anywhere close to that much money into finishing Unreal Tournament?

Honestly, I think Unity's work flow and accessibility does a lot to get people into game development, and I wish Epic would stop throwing its money around to get people to use its stuff. Unreal Engine was the market leader for a while. If it's so great, then let its positives do the work for you.

Could Epic manage to put anywhere close to that much money into finishing Unreal Tournament?

Honestly, I think Unity's work flow and accessibility does a lot to get people into game development, and I wish Epic would stop throwing its money around to get people to use its stuff. Unreal Engine was the market leader for a while. If it's so great, then let its positives do the work for you.

Unreal 4's C++ support also sucks. If your code has faults in it, it's not just throwing errors or exceptions, the whole UE4 editor goes in lockdown. Besides that, documentation for Unreal is horrendous. Nobody, particularly not indies are going to use Unreal 4 without some face-to-face guide to make them understand how the engine works.

If you're running the editor with VS attached as a debugger, sure. But why would you do that during regular gameplay development? With hot reload I have no problems writing c++ code for the game itself aside from structs which do not play well with hot reload.

You can also use BP for pretty much everything which when cooked is converted to speedy c++. I really don't get your argument here.

Documentation is horrendous though, I'll give you that. Unity's is too, but better than UE4's. With either engine, you're getting the best info from other developers on the forums and answerhub. I don't think that's exactly acceptable, but neither engine is very good about documentation.

Unless Epic has done some major optimisation work on BP compiling, BP, even when cooked, is too slow to be viable for anything other than PC. I've seen numerous stories of devs needing to completely rework their BP code into native C++ for the sake of porting to platforms like consoles.

I’ve been out of the game for a while now but around 2015ish when I was last actively using both toolkits and both languages, I had a far easier time working with C++. Unity was a little easier to get started with but Unreal let me do what I wanted to do with less resistance at the time. There were a bunch of pros/cons to both pieces of tech, but I will fight people who say C# is easier to work in just because it hides some of the memory management from you lol

I’ve been out of the game for a while now but around 2015ish when I was last actively using both toolkits and both languages, I had a far easier time working with C++. Unity was a little easier to get started with but Unreal let me do what I wanted to do with less resistance at the time. There were a bunch of pros/cons to both pieces of tech, but I will fight people who say C# is easier to work in just because it hides some of the memory management from you lol

Everyone comes off as a dick in this story. Improbable for (probably) interpreting the TOS creatively and not wanting to pay extra, Unity for not making their TOS clear and changing it without warning, and Epic for spreading opportunistic FUD. Sigh.

FWIW, Unity has been fine for us. Sure I've wanted to go to their HQ and dump eggs in their air vents multiple times, but they've been doing some Really Good Things lately. Which is why this PR blunder is especially facepalmy.

I’ve been out of the game for a while now but around 2015ish when I was last actively using both toolkits and both languages, I had a far easier time working with C++. Unity was a little easier to get started with but Unreal let me do what I wanted to do with less resistance at the time. There were a bunch of pros/cons to both pieces of tech, but I will fight people who say C# is easier to work in just because it hides some of the memory management from you lol

I appreciate the abstraction, personally. It's not something I want to worry about. It's the same reason I don't program in Assembly hehe.

I haven't used C++ since college, and most of the developer jobs (not game development) are in higher level languages now. So I'd like to keep using something in that realm, if possible. Never wanna stretch yourself too thin over technology stacks.

I say "Unity sucks" because I've been using it for almost two years now, whereas I started using Unreal about 6 moths or so ago and it's just waaay better. However, like I said, C# is easier to teach and learn than C++ - so I get what you're saying about Unity filling a void no other engine tries to fill

I apologise, I meant to imply when people in general say Unity sucks, not you specifically. I wasn't attempting to call you out or anything.

I agree, there are a ton of issues with Unity to the point where I want to switch to a different engine all together for some projects. I just wish Epic or whoever would create something easier to pick up for people new to coding/game dev. That'd give Unity some direct competition and could give new devs more options.

I know that's easier said than done though so definitely wishful thinking on my part haha.

Also, been looking a little bit into the whole issue and while everyone is kinda at fault here (Unity for their garbage ToS and Improbable interpreting the ToS in a really optimistic way putting their customers at risk), it cannot be understated how messed up the Unity ToS seems and how many more developers could be at risk of infringing an altered ToS in the future.

From my understanding SpacialOS is a service that can optimize your Unity builds to run in headless mode and be auto scaled on their server infrastructure, i as the developer will need to supply my own build of my game to them so they can host it. I could make my own build without the SpacialOS stuff and host it on Amazon or even my own physical servers and make the infrastructure for my game to scale up as i get more customers, this would require me to do a lot of work on the networking side and make some upfront investments compared to using a third party service like SpacialOS.

In both these scenarios the binary i have compiled is hosted on servers in the cloud either by me or some third party, it's the same game/application with some integration differences. The Unity ToS however does not allow me to host my application through a third party because it is built with Unity, i must either develop my own infrastructure that i manage or host through a Unity certified platform like what they themselves will gladly sell me.

I might have some of that wrong, but that is my interpretation of the story so far and using services like Amazon GameLift could probably also be seen as breaking the Unity ToS. The problem here is not a ToS specifying how you can host your server, Amazon Lumberyard has such constraints, the problem is the loose wording of the Unity ToS and how they can retroactively enforce it upon developers using the engine. Unity Technologies can overnight kill certain products made with Unity if they wanted to and developers can't defend themselves which could lead to years of work not being able to be sold.

I’ve been out of the game for a while now but around 2015ish when I was last actively using both toolkits and both languages, I had a far easier time working with C++. Unity was a little easier to get started with but Unreal let me do what I wanted to do with less resistance at the time. There were a bunch of pros/cons to both pieces of tech, but I will fight people who say C# is easier to work in just because it hides some of the memory management from you lol

It was always hard for me to get into C++ because whenever I tried, I noticed there's so many toolchains and environments, and also a billion ways to do any one thing. Plus there's .h files that I found cumbersome. Pointers and memory management are no big deal to me, I actually want those features.

I really like Java and C#, they're plenty fast, every platform can run at least one of these, and C# even allows for doing some rather low level things like making structures and packing them how you wish.

That's pretty much the reason why I stuck with learning Unity, but I'm very highly considering giving learning C++ a proper go again with Unreal now.

pretty fast and beginner friendly. The free assets they give from Paragon and their other titles have helped me and my team immensely since you can experiment freely with already rigged and animated models. They are excellent for testing, although some Paragon models are big boys that weigh over 1GB lol. I still strongly recommend Unreal to anyone who wants to get into game development or anything else. Unless they wanna get into the nitty gritty, that's where Unity > Unreal, because C# is sooo much easier compared to C++

Building games in Unreal is also considerably slow, wish I knew how to optimize that part to speed things up or how to build lighting more effectively, but I'm only getting started with it, so one step at a time

Unless Epic has done some major optimisation work on BP compiling, BP, even when cooked, is too slow to be viable for anything other than PC. I've seen numerous stories of devs needing to completely rework their BP code into native C++ for the sake of porting to platforms like consoles.

BP is converted into c++ automatically with the option to do so enabled, completely bypassing the vm. It's not as fast as user-written c++, but the difference is negligible.

And being that the basis is UE4's BP vs Unity's c#, the speed is comparable even IN the vm.

There are no real studies done that have determined whether Unity's IL2CPP or UE's conversion cooking results in faster speeds (and I don't have the patience to create the experiment and profile it myself) so I can't say which implementation is better.

Normally there's be the rest of the meme here, but since this is an actual foot-shooting incident with a slight danger of corporate death, I guess that's kinda inappropriate.

Any aspiring devs who aren't already locked in to the Unity ecosystem would be absolutely insane to choose it now after these ToS shenanigans. There should have been apprehension already from the "Unity can change ToS at will retroactively" clause, and therefore the possibility of them giving the ol' "Nice looking business you got going here, would be a terrible shame if something were to happen to it..." extortion attempt. Which could be pretty easily (naively, as it turns out) dismissed with "Nah, Unity sure seem nice, not the sort of people to do that!" - but here we are, they have done exactly that. For shame.

BP is converted into c++ automatically with the option to do so enabled, completely bypassing the vm. It's not as fast as user-written c++, but the difference is negligible.

And being that the basis is UE4's BP vs Unity's c#, the speed is comparable even IN the vm.

There are no real studies done that have determined whether Unity's IL2CPP or UE's conversion cooking results in faster speeds (and I don't have the patience to create the experiment and profile it myself) so I can't say which implementation is better.

I should probably also point out that, unless that's changed, you can't get parity in terms of what you can do with BP compared to C++ - for instance, option menu interface functionality is significantly more painful to implement than it should be in BP, and good luck implementing something like fucking key rebinding.

I should probably also point out that, unless that's changed, you can't get parity in terms of what you can do with BP compared to C++ - for instance, option menu interface functionality is significantly more painful to implement than it should be in BP, and good luck implementing something like fucking key rebinding.

Out of the box this is accurate. However a free plugin from the forum member Rama adds this functionality to Blueprints. If your game is very simple the entire thing can be done in BP, but I'd say most developers would want to write at least a little bit of C++. The amount depends on your comfort level and how much you're willing to spend on plugins that do the work for you, but it's really not hard to add a new class and write a few lines of code. People have this mental block when it comes to C++ which I can understand, but it's not the insurmountable obstacle people make it out to be. UE's layer of abstraction makes it very user-friendly. Just don't expect very good documentation for that layer of abstraction.

Unity’s Joachim Ante claims that December 2018’s changes to their terms and conditions didn’t cause SpatialOS to violate the rules, because it was already in violation of the old rules. And, he says, Improbable have known this for ages – contrary to what their doomsaying yesterday suggested.

“More than a year ago, we told Improbable in person that they were in violation of our Terms of Service or EULA,” Ante explained. “Six months ago, we informed Improbable about the violation in writing. Recent actions did not come as a surprise to Improbable; in fact, they’ve known about this for many months.”

Ante claims Unity had tried to negotiate a partnership with Improbable but, after that failed, they turned off Improbable’s Unity Editor license keys two weeks ago.

There's more explained but whatever it isn't "Unity bad guy, improbable good guy, Epic savior" nothing is ever really that simple but seemingly epic having nothing to do with it at all mostly just wants people to abandon whatever they're developing for currently (whatever it may be) and come to Unreal.

There's more explained but whatever it isn't "Unity bad guy, improbable good guy, Epic savior" nothing is ever really that simple but seemingly epic having nothing to do with it at all mostly just wants people to abandon whatever they're developing for currently (whatever it may be) and come to Unreal.

Yeah, Improbable is nowhere near being the good guys here and they put their customers into a very tough spot by not being up front about their legal issues with Unity. I do still think what Unity Technologies is doing is way more of an issue since they have now proven they are willing to shut down third party developers through their fluid ToS in order to force developers into using their own services, this should be a huge red flag for anyone using Unity and a major cause for concern going forward.

The problem is not that Unity is enforcing a stricter ToS, the problem is that they can retroactively shut down whatever they deem as a competition towards their own or partner services, regardless of what the ToS was when you began development of the service/product being affected.

Epic is for sure taking advantage of this blowing up in the development circles, but it also highlights how fair they are being towards developers picking their platform since Epic is unable to pull a similar move as their ToS is specific to whatever engine version you license. Epic might enforce similar restrictions with Unreal Engine 4.22, but if i am licensing 4.21 i will be unaffected by the new ToS.

Yeah, Improbable is nowhere near being the good guys here and they put their customers into a very tough spot by not being up front about their legal issues with Unity. I do still think what Unity Technologies is doing is way more of an issue since they have now proven they are willing to shut down third party developers through their fluid ToS in order to force developers into using their own services, this should be a huge red flag for anyone using Unity and a major cause for concern going forward.

The problem is not that Unity is enforcing a stricter ToS, the problem is that they can retroactively shut down whatever they deem as a competition towards their own or partner services, regardless of what the ToS was when you began development of the service/product being affected.

Epic is for sure taking advantage of this blowing up in the development circles, but it also highlights how fair they are being towards developers picking their platform since Epic is unable to pull a similar move as their ToS is specific to whatever engine version you license. Epic might enforce similar restrictions with Unreal Engine 4.22, but if i am licensing 4.21 i will be unaffected by the new ToS.

Exactly. "Improbable good guy" and "Epic saviour" may be up in the air, but for "Unity bad guy" there is no doubt. In no way, shape or form does SpatialOS infringe on the 2016 archive of Unity ToS section 2.4. They have clearly edited their terms in the intervening time - and devs are scuppered.

The clause on third party and streaming services seems much free-er now.

2.4 Streaming and Cloud Gaming Restrictions.
Unity developers are free to use any service offered to Unity developers (each, a “Third Party Service”). Unity does not have any obligation to provide support for any Third Party Service provider or Third Party Service under this Agreement.

Third Party Service providers may not, without Unity’s express written permission: (1) use a stylized version of any Unity name, trademark, logos, images or product icons, or other Unity-owned graphic symbols; (2) use a product name confusingly similar to a Unity product or that could be construed by Unity developers as being a Unity product or service; or (3) create or use any marketing materials that suggest an affiliation with, or endorsement by, Unity. All use of Unity’s trademarks must comply with Unity’s Trademark Guidelines.