Unity Engine ToS change makes cloud-based SpatialOS games illegal

What they're shipping right now is the latter.

What they're selling to investors is the former. Planet scale.

Apparently the Unity executives agree with this, otherwise they wouldn't be trying to strong arm competition away instead of competing on a playing field that's already skewed in their favor.

Here is the overview provided by one of Unity's streaming partners Genvid [0]

"Genvid provides an easy to use SDK, with a C interface, which can be used to automatically capture your game content (audio and video), encode it properly (e.g. H264), and to stream it to a service (e.g. YouTube). It also provides routines to send additional game data to spectators (e.g. scores, player profiles, chances of success, etc.), as well as hooks to receive commands coming from them."

In contrast, Spatial OS provides a back-end to a game delivered using Unity:

"SpatialOS is a cloud-based computational platform that lets you use many servers and engines to power a single world. The platform coordinates a swarm of micro-services called workers, which overlap and dynamically reorganize to power a huge, seamless world. The platform also lets you handle a huge number of concurrent players across different devices in one world"

[0] https://www.genvidtech.com/doc/SDK-1.19.0/quicktour/overview...

[1] https://improbable.io/games/tech

I'm surprised to hear that's a scalable model and the terms do seem to read more broadly than that, but it's reassuring that it could be something other than a baldly monopolistic power play.

Can you give a source for that? As far as I know the runtime of Unity has no paid license.

Important to note, neither is Unreal really. It's not a pedantic distinction here either, as it affects how far you can take a project that modifies the core engine.

Not that I'm against Unreal in any way, it's just important to keep in mind.

Does now though [walks into corner growling] :/

How about not having to use the dumpster fire called C++ for game code? C# is far nicer to use. Also, in Unity code hot-reloads instantly and reliably.

> Meanwhile, UE4 is a really good deal and keeps getting better with every release.

So does Unity. I think people underestimate how much more development effort went into Unity in the last years. UE4 has more fanboys, less actual success. On the other hand, with the Fortnite windfall, maybe UE4 will pick up pace now.

> It's really just a better put together engine all around.

It's still a godawful pile of C++ that takes forever to compile. I'm sure the same is true for Unity's core, but they're moving to a subset of C# that can be compiled more efficiently.

Unity shines in its flexibility, easy scripting, and fast workflow. I can whip up a script in C# very quickly that does exactly what I want. With that scripting, I can have a lot of control how the engine and rendering and post effects work, much more than Unreal. Prefab workflow makes much more sense than anything in Unreal blueprints. Mecanim is not as fully featured in some ways as Unreal's animation system, but with the Humanoid skeleton, animations can be used easily on different models. With Unreal, you need to use retargeting, which is painful and can have serious problems if the models are even slightly different in size.

Unity had their brief shining moment in the sun from 2015-2017 when they were supporting the growing indie scene on Steam, their VR was lightyears ahead of UE4, and UE4 still hadn't gone free-to-use. But with all that Fortnite money now and their new business model, I've no doubt UE4 is going to be the best possible game engine moving forward.

Especially C#7, and the support of the latest 7.3 in the most recent Unity.

C# is my favorite of the common primarily OOP languages. I would take a LISP any day... See Arcadia.

First, their class reference documentation is very poor. The majority of classes and functions have either no description, or a description that basically repeats the function name in sentence form. For example, http://api.unrealengine.com/INT/API/Runtime/CoreUObject/UObj....

UE4 is fairly opinionated about what kind of game you're making. A lot of its core classes, like AActor, AGameMode, etc. are designed with a multiplayer fps in mind. For example, the basic actor class is much heavier than Unity's GameObjects. Every actor gets things like a built-in PointDamage and RadialDamage event so they can be damaged by guns and grenades.

There's a lot of minor issues with API/naming choices. ConvertTransformToRelative() has the Transform and ParentTransforms parameters backwards and instead gives you the ParentTransform relative to Transform. FBox.IsInside() should be named FBox.Contains(). As it stands, "if (MyActorBounds.IsInside(MyContainer)) { }" does the exact opposite of what you'd expect. The sin() and cos() nodes in materials don't take radians, nor degrees by default, but revolutions (so sin(0) == sin(1) == sin(2) == 0), even though the C++ FMath::Sin() function takes radians.

More importantly, we encounter engine bugs and crashes pretty frequently. Just recently, I was unlucky enough to encounter 3 separate bugs with OnAudioPlaybackPercent (it returns wrong values in various circumstances). Atmospheric fog started whiting out the screen after updating engine versions (still investigating this one). We've had tons of issues with child actors either becoming corrupt or losing their default values. I think we encounter some engine issue every week.

My favorite was when deleting a question mark from a comment in C++ caused everyone to be unable to compile. That had us scratching our heads. Any guesses why that would happen? (Hint: it's Unreal's fault.)

"Delete binaries and intermediate folders and recompile" is practically our unofficial office motto due to how often it fixes issues. Which leads me to, compiling C++ is slow. The near instant compile times of Unity are like a breath of fresh air.

Finally, the community and Asset Store for Unity seem much better. I wish we had something like FinalIK for Unreal. The Asset Store has 10x more content than the UE4 Marketplace. We usually look on the Asset Store for stuff like sounds or meshes, but it can be inconvenient, especially if they come with custom materials or code.

I prefer Unity over Unreal for a ton of reasons, but unreal has had animation retargeting since the early days.

https://docs.unrealengine.com/en-us/Engine/Animation/Animati...

Blueprints are actually really cool for what they are and have a bunch of interesting debugging considerations, such as being able to see the flow of "code" visually.

https://twitter.com/TimSweeneyEpic/status/108340746025221734...

Not only that but he points out that they intentionally made Unreal Engine's TOS "perpetual" specifically so they can't change it to do something like Unity has done here.

On top of that, Unreal Engine sourcecode is available to all Engine users on Github unlike Unity.

It's a shame really because they did the whole onboarding really well, you could literally get it up and running in a couple of minutes and it was extremely easy to use for developers.

Unity allows streaming for approved partners with the correct liscences, but apparently negotiations with spatial broke down. Since unity didn't comment on why, all we can do is speculate.

The illusory promise doctrine is very seldomly used which means there's a lot of uncertainty about whether or not it would even work. And that's if the dispute gets into the courts in the first place. Which courts it gets into is another big deal; some T&Cs put requirements that the choice of forum for disputes is a favourable one for them, or they force arbitration to be the primary dispute resolution mechanic.

That said, the illusory promise doctrine CAN and HAS demolished these type of T&Cs in the past. Sometimes they even blow up other contractor favouring terms as they go (like the aforementioned choice of forum/arbitration clauses, etc.) But why are people still putting this language into their agreements? Well...

Even if the court doesn't like that segment of the contract and they sever it, there are other ways for the contractor to indicate that the bargain they've arrived at shouldn't be disturbed - including pointing towards continued performance and a lack of notice from others, so even if you correctly note that the contract is busted, the court might say you tacitly agreed to the changed terms and they're read back in, anyways.

Civilian systems have a different strategy for dealing with these types of contracts, calling them contracts of adhesion. They aren't the product of a negotiation, so they treat them will less lenience and deference.

Common law countries often adopt this style of protection through Consumer protection laws or other similar vehicles where the rules of contract are changed to fix different types of contracts.

Basically, it's very complicated - this is just my top-of-mind snapshot on some of the issues, and that complexity creates cost, and that cost prevents oversight.

Its bad law though, if companies can be held ransom to T&Cs they never agreed to. Especially as it seems no notice was given, what happens if a company never got the new T&Cs?

Which leads me to believe they are installing or running the Unity Runtime on their servers? If not I'd love a better explanation :)

Traditional ECS doesn't fit with Godot's philosophy, but you can make behaviors into nodes and just add these nodes as a child for ECS-like behavior. Honestly, I find Godot's way more natural and extendable.

C# on the other hand, is to attract Unity users that are too lazy to put in 30 minutes to go through GDscript's concepts. It's OK that it's there, but personally I found C# one of the least enjoyable languages to program in.

What's missing in Godot?

Like I said, I really hope they get this fixed, because that game looked good.