Hacker News new | past | comments | ask | show | jobs | submit login
Unity Engine ToS change makes cloud-based SpatialOS games illegal (arstechnica.com)
264 points by MikusR 3 months ago | hide | past | web | favorite | 268 comments



So right now we know the "what", but not the "why".

What Improbable really has, or claims to have, is a way to scale massively multiplayer games where everyone is in the same world. They have a back end which is basically a synching system for small data elements between computers in a data center. Think of it as being like the way a shared memory multiprocessor synchs its memory system. Some data items belong to a single CPU, and that CPU has read/write access to it. Anybody else can read, but they get updated if the data changes. Who has write ownership can change based on demand. Improbable has a downloadable demo if you want to play with this.

The game use of this is as a solution to the "region crossing" problem in Second Life. The big Second Life world is divided into squares 256m on a side, each managed by a separate process. The processes talk to each other, and objects can move across region boundaries. The system used is ad-hoc and fails frequently. If you drive around Second Life, about twice an hour you'll have serious trouble at a region crossing and may have to relog.

Improbable raised $500M, the largest investment ever made in a European tech startup.[1] They put 150 developers on the problem. They claim to have a solution. It's set up as a pay per use service. You pay for data storage, you pay for network traffic, and it has to run on Google's cloud. They don't publish prices, but at least one developer dumped them for cost reasons.

This is going to be like physics engines. In the 1990s it was really hard, and physics engines required heavy research into nonlinear differential equation solvers and fast collision detection. I used to work on that. There were startups with unicorn dreams - Mathengine, Havok. Now, everybody does it, and multiple open source libraries are available. Mathengine is gone, and Havok had a down round, downsized, replaced the management, and was sold twice. Physics is routine middleware now.

Right now, though, Improbable has the only system for this. Until someone else figures it out. This event pushed Improbable to open source their API code with the MIT license. That means anyone can now see how to talk to the back end, and start thinking about how to replace their back end. Progress marches on.

(Hm. What if you wrote a back end which, instead of needing multiple "cloud" machines, ran on a single huge Amazon AWS instance, like the one with 128 CPUs. That's an easier problem than coordinating it over the network. You might not be able to support a planet sized world, but you could support large islands you have to teleport between.)

[1] https://www.theguardian.com/business/2019/jan/10/british-gam...


The "why" is apparently "so we can capture that revenue stream". They just launched an alpha of a competing service (autoscaling dedicated servers, on Google's cloud) and apparently want to nix the competition.

https://unity.com/solutions/real-time-multiplayer/game-serve...


And I'd bet every penny I have that it's going to be a massive clusterfuck that nobody would freely choose to use. Unity has continuously dropped the ball on multiplayer.

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.


> (Hm. What if you wrote a back end which, instead of needing multiple "cloud" machines, ran on a single huge Amazon AWS instance, like the one with 128 CPUs. That's an easier problem than coordinating it over the network. You might not be able to support a planet sized world, but you could support large islands you have to teleport between.)

You can get really big systems these days; scaling up before scaling out really helps with coordination problems. But scaling up your servers also makes redundancy and data retention harder. And, when you end up running single (or paired) systems that are the biggest you can get, economics are often lined up against you -- motherboards and processors for 4-socket systems cost way more than for 2-socket systems, and they're updated at a slower pace. If you can make a system to allow seamlessly transitioning region boundaries across server nodes, that should work fine with a single node server, but also enable you to use less expensive nodes; and in cloudy situations, could enable ramping capacity to match usage in real time.


They have this tech for sure, and have been working on it for a long time. I cant get into many details, but I beta tested a game that made a very short teaser announcement at either pax or E3 one year by dean hall. He was working with IO on the tech and a game, but the deal must have fell through. Dean went on to do a solo project (space engineers) which has nothing to do with any of this, but maybe inspired in some ways. When I beta tested the game, they had already successfully made it where the UI was basically streamed over the servers, so even mouse clicks was server side. The 3d rendering was done client side. It was buggy, but had stronger potential than anything I have ever seen up to that point. So this news is very interesting to me.


Improbable doesn’t have planet scale solutions. Their most touted title, Worlds Adrift, is explicitly discretized into regions. They use ‘creative’ solutions like ‘impassable storms’ to prevent crowding.


It's likely they have both.

What they're shipping right now is the latter.

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


Why do you think that they have what they are selling to investors?


That is a very good question. Has anyone tested the scaling and load limits of the thing yet? I haven't seen any reports.


>world is divided into squares 256m on a side ... about twice an hour you'll have serious trouble at a region crossing and may have to relog.

Eve online has similar division per solar system, last time I played you had to wait up to 30 minutes to cross during massive rush hour, with some cross points being outright disabled when node reached its limit.

Naive mind who never worked in the field would say the most obvious step is following video codec world and moving to dynamic variable block size segmentation (quadtree). Compact sparse regions together, keep dividing the busy ones to manageable levels of load.



You mention havoc but i still notice Havoc being used for a lot of different games.


> You may not directly or indirectly distribute the Unity Software, including the runtime portion of the Unity Software (the “Unity Runtime”), or your Project Content (if it incorporates the Unity Runtime) by means of streaming or broadcasting so that any portion of the Unity Software is primarily executed on or simulated by the cloud or a remote server and transmitted over the Internet or other network to end user devices without a separate license or authorization from Unity.

These terms are incredibly vague. Makes it sound like you cannot run your own dedicated server for multiplayer without being in breach of the new terms. If Unity forces their new multiplayer hosted service on their users, I (and I foresee many others) will immediately start transitioning to Unreal.

Ref: https://unity3d.com/legal/terms-of-service/software (sec 2.4)


I don't know why people are still using unity instead of UE4 except for historical reasons where users of the engine are hesitant to switch and have to relearn some things.

Unity is not open source, it does not come with batteries included (so you end up buying a bunch of poorly maintained unity assets/plugins to do stuff that UE4 does out of the box), and I think they're struggling as a company more than people realize (having raised large investment rounds and now seeking ways to monetize to an extent that would justify such investment). The best thing Unity has going for it is its dedicated user base.

Meanwhile, UE4 is a really good deal and keeps getting better with every release. It's really just a better put together engine all around.


Well, I've used both extensively, and they are good at different things. Unreal is far better IF you fit cleanly into one of their templates (first person, third person, etc). Superior renderer with great built-in post effects, FAR better multiplayer support, better materials/shader editor. However, if you try to do something substantially different than they have imagined, it can get ugly very fast. The C++ used is strange, with all kinds of weird GC macros strewn about. As a programmer, I hate blueprints. I wish there was a scripting language alternative. And god help you if you actually want to modify the engine code substantially, it's a monster (not poorly done, just sprawling and extremely complex). Look at the nvidia gameworks integration, it's all these forks of the engine built by random people, it's a mess.

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.


The kind of sad thing to me is that I’ve talked to several people who hold UE4 up as a shining example of “modern C++ done right”.

...but it’s really quite a mess when you look closely.

A successful project and “good code” aren’t necessarily the same thing.


UE4 uses their own C++ containers (such as TArray and TMap), which is very far from modern C++ (which recommends using STL like a part of the language). And UE4's macro system has garbage collection support built in, which would upset the modern C++ folks using shared_ptr and unique_ptr. They don't even like macros, they prefer using template metaprogramming whenever possible...


Re: scripting

Ue4 has the source available, so you definitely can integrate your preferred scripting language.


You're technically right, but that's potentially an enormous task. If we're comparing Unity with Unreal functionality, integrating a scripting language should include editor integration, debugging, etc. I'd rather spend my time actually making a game.


> Unity is not open source

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.


Yes, UE4 is not FOSS as per GNU, it is open source in that you can see the code and there's a large community contributing fixes and additions with every new version. I think the distinction is pedantic for most users.


"Source-available" seems to be the preferred term for what UE4 is.

> I think the distinction is pedantic for most users.

In a technical discussion, there's no reason not to use the proper terms for things.


> I think the distinction is pedantic for most users.

The distinction is that the code you write belongs to Epic. You become an unpaid contractor.


The Open Source Definition doesn't come from the Free Software Foundation or "GNU". It's a separate organization.[1].

Also the whole point of this story is that license terms do matter, especially if you want to sell games commercially.

[1] https://opensource.org/osd-annotated


I think the distinction is pedantic for most users.


Isn't Unity similar in that regard? (well, as far as viewing the source-code, they don't accept patches to my understanding)

https://blogs.unity3d.com/2018/03/26/releasing-the-unity-c-s...


That's just the C# code; not the native C++ bits which are the core of the renderer and engine.

UE4 is open to every last bit.


No, the amount of unity released is tiny.


You're wrong, users of software libraries care whether they're allowed to fork the library or not.


Define fork. You can make your own custom version and share that code with anyone, and use it exactly as freely as the original version.

The reason it's not open source is the royalty clause, not lack of ability to see/edit/modify/fork the code.


Unitys C# code is also visible source


I missed that announcement, good for them, too little too late: https://blogs.unity3d.com/2018/03/26/releasing-the-unity-c-s...


Note that this is just the C# layer. The underlying C++ engine code is still only available under "call us" license terms.


Shared source isn't open source. You may have access to it, but you don't own it.


I just like developing in C# much better than C++.

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.


For a lot of us we started with it, and once you know it, if it meets your needs, switching doesn't make sense.

Does now though [walks into corner growling] :/


Did so many people use SpatialOS?


The new terms are undesirable for any kind of multiplayer game, not just those using SpatialOS.


>I don't know why people are still using unity instead of UE4 except for historical reasons where users of the engine are hesitant to switch and have to relearn some things.

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.


With a choice between C++ or Blueprints I doubt I'll ever be using Unreal. I might take a look at Godot one day.


Unity has a great asset store with a lot of reusable content (art, models, scripts, shaders, sounds) within their walled garden


UE4 focuses on high-end console/PC. For rapid development of mobile games, Unity is basically the only choice.


> For rapid development of mobile games, Unity is basically the only choice.

Why? Unreal Engine has targeted iOS + Android phones for 5+ years now, successfully. (Fortnite, PUBG, Dungeon Defenders, Horn, etc).

More mobile developers are experienced with Unity over Unreal today, but that's largely inertia more than anything else.


UE4 has always pushed high-end rendering tech hard and not prioritised mobile. There’s little awareness of the current state of its mobile capabilities, with few big UE4 hits on the App Store (and hundreds of Unity success stories including Pokemon Go and Hearthstone)

F2P mobile dev is also very UI heavy, and UI work with Unity/C# is easier than dealing with C++/Unreal.

And Unity has a wealth of ready made plugins that can be quickly integrated into a project for things like IAPs, advertising, analytics, etc. Although maybe UE is catching up in that area by now?


Unreal has a new UI system and designer that feels really really good to use. And has visual blueprint code support.


Package sizes are pretty big. I think an empty project packages to about 60 MB.


> Why? Unreal Engine has targeted iOS + Android phones for 5+ years now, successfully. (Fortnite, PUBG, Dungeon Defenders, Horn, etc).

Dungeon Defenders and Horn are not UE4 titles, UE3 isn't available anymore. PUBG and Fortnite only work on higher-end phones. UE4 is going the "easy" route by not supporting older devices. With Unity, you could still target fixed-function hardware up until recently.


>UE4 focuses on high-end console/PC. For rapid development of mobile games, Unity is basically the only choice.

This is a false dichotomy that came about because Unity was the first major AAA engine that was free to use. UE4 has easily surpassed them at this point. See PUBG Mobile, Fortnite Mobile, etc. There's absolutely nothing like that on mobile using Unity.


I'm not saying UE4 isn't good, but I have a pretty long list of complaints.

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.


How is UE on mid-range and low-end mobile devices? I have the impression that's in increasing important chunk of Unity's end user base.


Unity is huge in mobile gaming. UE4 barely made a dent on mobile until the recent mobile release of Fortnite that is, which requires a fairly high-end device


Somehow I always had the impression Unity was a heavy C# moloch and Unreal was a fast C++ racecar.

Interesting.


It's not about the language, C# is generally fine if you know how to work the GC (which admittedly many people don't). The kind of C++ that is used for game code in UE4 isn't exactly "zero-overhead" either and it also uses garbage collection. Plus, on mobile C# in Unity is translated to C++ anyway. My guess is that the difference is negligible in most cases.

What really makes the difference is that Unity has light-weight rendering pipelines available, running on older GPUs. UE4 just ditches those devices.


Can you expand on "knowing how to work with the GC" in Unity? I'm a Unity dev and rarely touch GC other than keeping mindful of the work I'm giving it by size/quantity of objects in my scene/making sure objects are dereferenced/can be collected.


Basically, know what does and doesn't allocate heap memory, don't give the GC more work than it can handle and measure on the target hardware. Do it right at the start of development and consider things like object pooling and the new ECS, if necessary. Understand how your GC works: https://blogs.unity3d.com/2018/11/26/feature-preview-increme...

It's not about performance in 99% of frames, it's about not dropping frames when the GC kicks in and needs more time than your budget accounts for.


C# is just the scripting layer in Unity. It's a C++ engine just like Unreal.


Doesn't unity make it "easier" to be cross platform still?


> I don't know why people are still using unity instead of UE4

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.


I dunno this seems clear enough to me - they don't want you circumventing the terms of your license by running the game on a single machine and streaming it to many players. Each game instance requires a separate license.

I'm sure this isn't intended to stop you from running your game's central multiplayer server. It's just to make sure you pay an appropriate licensing fee for Unity.


As far as I understand you needed your own Unity / Unreal / Cryengine license to develop using SpatialOS, they don’t do streaming the way you described.


Gotcha, so it's an effort to close a "run the game on the server, stream video back and forth, and don't pay for client-side licenses" loophole?

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.


Scalable because players can take turns with the same license ;)


That may be what they meant, but the wave of confusion and fear says that they communicated it poorly. (Also the fact that I had to go this far down the thread before anyone even attempted to answer "why".)


>Each game instance requires a separate license.

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


The article explicitly says that Improbable was told by Unity that the new TOS “specifically disallow[s] services like Improbable’s to function with their engine.”


I think Unity has a much easier learning curve than Unreal. The other thing about Unreal is it’s really targeted towards triple A workflows, which is great if you’re triple A but a bit heavy if you’re not. They also have some IMO killer features that UE lacks, like humanoid animation retargeting. If you’ve ever done animation you probably realise how much time and effort it takes to make a good one, so being able to reuse animations can be huge. None of that is really a criticism of UE4 which is great, just, Unity has some attributes that make it really appealing to smaller shops.

[edit: derp meant this in response to a different comment but I think it still stands. Weird/possibly terrible move by Unity but I don’t know if UE4 is a realistic alternative for a lot of places. Surface level they seem similar but there are so many differences]


> They also have some IMO killer features that UE lacks, like humanoid animation retargeting

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...


I stand corrected


I've done a lot of work with multiplayer on Unity. Running a version of the game in the Unity engine as a server is necessary if you want your game to be authoritative to prevent cheating. Fortunately my game uses a custom server that I wrote, but this will be a huge hit to pretty much everyone else.


It says "primarily". If the game runs both server and client side, I don't think there is a problem.


before that it says "any portion of"... so "primarily" could apply (ostensibly) to a single line of code, if that is a "portion".


Yeah, unless Unity quickly reverses this, I'm likely going to uninstall it and fully switch over to Unreal.

Those terms seem absolutely insane to me, and I'd never develop on a platform with them.


Doesn’t this also make services like Nvidia shield in breach of the terms for any Unity games?


Doesn't Unreal require you to code in C++? That's a big reason why I'd avoid it when I don't require maximum performance.


UE4 has C++ and their UI based programming language called Blueprints. Unreal C++ is super powerful, but very few people actually need to use it due to some performance bottleneck.

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.


It also supports C#/.net and Blueprints (their own node-based language).


Wait do they? I wasn't aware that UE4 supported C#.


Via a plugin developed by some Microsoft employees:

https://mono-ue.github.io/


Yeah, the github.io page is still up, but the actual repo for that plugin has been deleted.


It's a private repo so you can't see it without Unreal Engine Github access, see my sibling comment for details.


That's either a dead project or it's moved somewhere that I can't find it.

Either way it's not something I'd trust enough to use for a commercial project, so I definitely wouldn't say UE supports C#.


No its still there. You just need to first get access to the Unreal Github repo to be able to see it since its a private repo (by signing up for an UE engine dev, it takes a couple minutes).

This is mentioned on the linked site:

"You will need source access to Unreal Engine on GitHub to get access to the MonoUE fork".


I did some digging around, I can't tell how active this project is, but given how little I found, this definitely isn't something I'd feel confident using outside of small experiments.

I wouldn't go around telling people UE4 supports C# based on this.


That reads to me like you can still have servers, just without them using the Unity runtime. Is using the Unity runtime for servers common? The multiplayer Unity games that I know of don't do that.


Yes, as far as I know, running a headless version of the game (Unity in "batch mode") is how a lot of (most?) games do dedicated authoritative servers, otherwise your server wouldn't actually be running the same game. Or am I misunderstanding something?


You don’t strictly need to have the same codebase for client and server. If you’re making a slower paced game it’d be wasteful to burn processing power running the full Unity runtime.


The whole point of SpatialOS is that it executes Unity runtime in the cloud. You create regular unity objects and they execute somewhere in the cloud.


I understood it to mean, "You cannot offer a managed service for headless server Unity to support multiplayer for game developer clients", but "You can still do this for your own game in-house"


I believe Rust does and that’s perhaps the single biggest Unity multiplayer project in terms of concurrent users AFAIK.


It is. Even after suggesting otherwise to some senior friends who work on MMOs it seems they're locked into doing it for some reason probably just inertia and general fear of game companies to do things the right way and not the "easy" way.


Or Godot, a highly capable free engine!


As much as I love Godot (and really truly I do) it does not run as optimized in multiplayer 3D as Unity or UE4,YET! But, it's always looking for talented people to help. It is an open source project that you can code in an offshoot of Python or in C# (which is fairly new, so give it a shot and help them out)... sorry for the plug =)


Also free as in freedom of speech, not just free beer.


It's more vague without it.

After all, you can distribute the runtime to customers. You can run the editor as a developer.

How many license-seats should you purchase to run a headless server? How many customers are being licensed to use that server?


Just to confirm: does Unreal have any similar clause? Do they look like they might go that way too? (e.g. do they have "authorized" cloud partners)


Tom Sweeney, Epic's CEO tweeted about this saying no:

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.


If you do have to redo everything, why the hell would you switch to another proprietary technology?! Why not use OpenSceneGraph, OGRE, Irrlicht, Cube2, or one of the hundreds of other free game engines / frameworks out there instead?


Based on your comment it seems like you haven't looked into or used a game engine since the late 90s (Cube 2 and Irrlicht?). The only real open source competition for Unreal and Unity is probably Godot, and it's not really competitive. Many of the engines you mentioned (OSG, Ogre) are not full game engine, but renderers and scene graph implementations. For that something like bgfx or even three.js if you're targeting the browser is a better open source alternative. Most of the engines you mentioned haven't been updated in years and don't have support for modern tech or platforms (VR, AR, DX12, Metal, Vulkan, PS4, XB1, Switch, etc) so you'd be better off writing your own engine if you wanted to actually ship a game. Your advice is like telling someone to license idtech in 2019...


Then put your money towards improving them (or writing your own, if that's cheaper/better?), rather than feeding yet another proprietary hog.

By continuing to buy UE you're just digging yourself a deeper hole for when things inevitably turn sour (as they just did for Unity).


That's an absurd proposition for most people. Rolling out our own worked for Minecraft. It also may work for bigger companies (Frontier Developments, Bethesda?).

Successful releases using open-source engines are rare.

For the overwhelmingly majority, they are much better off just using one of the big game engines, even after paying them.


Because open source game engines are bad. There is a huge gap between Unity/Unreal and an open source engine, it's not even comparable.


Godot is getting pretty close but I agree with Unity and Unreal being quite a bit ahead at this time.


The commercial offerings are far more used, which means there's more tools, there's more prebuilt assets you can buy, there's more documentation and StackOverflow answers. I would bet that either of Unity or Unreal have more dev resources going into them than all of the ones you mentioned there combined, too.


Because it's easier and cheaper to hire developers who already know Unreal. Also, one reason enterprises pay for RedHat Linux is so that when something goes wrong, there's a business liable for it. You can't get a service level agreement from a community.


This is about streaming games.

There are other providers that do this that are allowed to: https://unity3d.com/legal/terms-of-service/software/authoriz...


Spatial OS is wholly different from game streaming.

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


"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"

I'm planning on releasing something like this, with Unity clients on the roadmap. I've no plans to run headless Unity instances on servers, however. Would Unity make my system "illegal?"


(Unity employee here) While I can't comment on legal specifics, the controversy is entirely about Improbable's server-side use of Unity, so you should be fine. That said, you can send us an email (with details of your specific situation) on terms@unity3d.com and our team can clarify. (You can also wait and see, as we'll be updating the ToS again, as they're evidently much too vague at the moment...)


I was planning to implement automated gameplay video/stream production from recorded server-side player data. However, I was planning on using a Javascript game engine running in Chrome for this, not Unity. I'll keep the terms email address in mind.


Tim Sweeney (Founder of Epic Games) reacted strongly to this in a thread on Twitter.

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

"We specifically make the UE4 EULA apply perpetually so that when you obtain a version under a given EULA, you can stay on that version and operate under that EULA forever if you choose."


In fairness, that's easy for a guy sitting on Fortnite to say.

That said, I do agree with his point. Unity should consider making these new TOS provisions apply from today forward instead of making them apply to everything. (That probably won't happen, because it would kneecap their upcoming cloud offerings, but I think ideally that's how it should work.)


A retroactively-changeable EULA sounds totally radioactive and not doing that seems more like table stakes than a luxury. But I guess that's what we get with a game engine specifically aimed at less-professional developers.


IANAL but really, is this enforceable, for code already downloaded, used and deployed in compliance with the license at that time?


According to Crytek, it should be. Their engine license[0] is, if I am reading it correctly, similar in this respect.

> By doing so, you, the Licensee, agree to all terms and conditions of this Agreement or in the accompanying documentation. You should read this Agreement carefully before the Start Date. If you do not agree with the terms and conditions set forth in this Agreement you are not authorized to use the CRYENGINE.

> You agree to check www.cryengine.com periodically for new information and terms that govern your use of CRYENGINE. Crytek may modify this Agreement at any time. Crytek will inform you about revisions to this Agreement by email and/or by a notice on our home page and/or during log in. Revisions to terms affecting existing CRYENGINE shall be effective thirty (30) days after posting at www.cryengine.com If you do not agree with the new terms your only remedy is to stop using CRYENGINE.

...

> If your register your Game later than June 30, 2018 then this current Agreement shall apply (no matter which CRYENGINE version you use);

...

[0] https://github.com/CRYTEK/CRYENGINE/blob/release/LICENSE.md


I wonder what a court has said about this, or if there are laws or regulations at the federal level about this.

I always thought a contract had to include "a meeting of the minds," and I cannot see how that is possible if one party can change their mind for any reason at any time without any discussion or renewed agreement.


This was their pitch with UE4 even back when Fortnite was just some weird survival game they demoed at an Apple keynote.


I’m pretty aghast at this move by Unity. They have made it clear they have a managed cloud hosting infrastructure in the works, but explicitly blocking others from providing it as a service strikes me as a “we really need this revenue and will do anything to protect it” move.

PlayFab is unmentioned but they will also be affected by this move as they offer a dedicated server hosting service among their offerings.

Even more frustrating is that Unity’s offering is not even in beta yet. Details have been sparse, though I expect to hear more at GDC this year.


Also, blocking Improbable sucks even more because their MMO architecture is unique to anything else out there. There is no way Unity will be offering anything except dedicated servers with their service, leaving anyone who wants to use Improbable tech to have to switch to Unreal.


It basically signals to me they don't give a fuck about you; it's Unity-first, and you can deal with it. Take it or leave it.

After being burnt by the Source Engine, I'll never use Unity again after having read this.


What happened with Source?


Valve pretty much abandoned developing everything but Steam. You'll still see a few token projects come out of Valve, but it seems like they've basically turned into Steam, Inc.


That's not true at all, though? Source has continued to get changes & upgrades over the years. It has a vulkan backend, the UI system is no longer scaleform but a web-based system called Panorama, a new physics engine called Rubikon that replaced the old Havok engine, etc...

They aren't putting out many new games, although they did just release Artifact a couple months ago. But DOTA 2 & CSGO continue to get updates, changes, and improvements. CSGO for example has an entirely new, machine-learning based anti-cheat system called VacNet: https://www.youtube.com/watch?v=ObhK8lUfIlc

They have tons of talks on GDC of all sorts of really cool stuff they are doing that's related to Source 2 and has nothing to do with Steam.


Are those updates to the Source engine/SDK available to devs outside of Valve though?


Does that really matter? Source Engine was never really open source and never really on a continuous update schedule. Anyone with a vested interest in using source would have obtained a license for it anyway as it's always been non-free, and that license would presumably have terms for what you do and don't get access to.

But you can apparently hack around with Source 2 by using The Lab's Robot Repair (Source 2) as a mod base and use the Hammer 2 tools from DOTA 2. So... technically yes, you could play with it. Just maybe not easily, and maybe not entirely intentionally.


It's not really that surprising. That can do 1/10th the work as before and make 100 times the revenue. Until something seriously disrupts the online PC game market they can sit back and ignore game development.


They actually had a new game, Artifact, come out the end of November. It didn't have a good reception, mostly due to unrealistic expectations set by people in the beta, but they've commited to supporting and improving it for a long time.


This is directly relevant to that Cory Doctorow article from yesterday.

In real world inventions someone could make a compatible piece and users could just buy it and plug it in. Say you have a clever new attachment for a vacuum cleaner.

In cyberspace you can make things incompatible by law, and it's very effective to police.

So what should you be allowed to do this with?


There are protections against that in the EU - you can reverse engineer and otherwise circumvent all the protections for the sake of making things interoperable.


Isn't Unity Danish?


According to https://en.wikipedia.org/wiki/Unity_Technologies they're based in San Francisco these days (but were founded in Denmark).


US users (both devs + gamers), and companies would still be subject to US contract law.


IANAL, but if you want to include a blanket “we can change these terms at any time” clause in your TOS, it seems like you should be obligated to specify a “grandfathering” window, i.e., a length of time during which any licensee will be allowed to operate under the old terms in the event of a change. Otherwise, you’re not actually giving reasonable consideration, since you’re accepting payment in return for what could potentially be a single day (or hour, or minute) of use of your software. Furthermore, a particular licensee’s window ought to be proportional to the amount of consideration given by that licensee, i.e., the number of licenses/renewals purchases by them. How is a contract conscionable if it allows one party to become dependent on the other’s services—and to pay them accordingly—while providing for the latter’s right to suddenly withdraw support?



So in essence, this doesn't affect anyone except for SaaS platforms that are attempting to release their own products while heavily using Unity's engine within them. Which 100% makes sense. You're building your company based off of someone else's commercial product... You need a specific license for this. GG Improbable


Reading between the lines, it sounds like they only want the game developer to be running Unity on the server, not any other third party. Does this create an opportunity for a professional services outfit to provide maintenance and support for running cloud servers rented by the game developer? Can I put an AMI up in the AWS marketplace and charge for it?


That's what their PR people say, but that isn't what their terms and conditions actually do say... "2.4 Streaming and Cloud Gaming Restrictions. You may not directly or indirectly distribute the Unity Software, including the runtime portion of the Unity Software (the 'Unity Runtime'), or your Project Content (if it incorporates the Unity Runtime) by means of streaming or broadcasting so that any portion of the Unity Software is primarily executed on or simulated by the cloud or a remote server and transmitted over the Internet or other network to end user devices without a separate license or authorization from Unity..."


In September and January of last year Unity raised a considerable amount of cash [0].

It seems like VCs want their growth number up and Unity has a very clear plan to run their engine in the cloud to create artificial growth by being the sole vendor of Unity Multiplayer Hosting.

This is the shadiest move I’ve seen in the Industry, even worst than MongoDB.

[0]https://www.crunchbase.com/organization/unity-technologies


What did MongoDB do?


Their product wasn't fit for purpose for the first five years or so*. Of which their marketing mentioned nothing and they were extremely misleading when questioned.

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.


Probably the licensing change: https://en.wikipedia.org/wiki/MongoDB#Licensing


What’s the problem here?


It "requires that those making the software publicly available as a service must make the service's source code available under this license".


That change seems to be in line with the FOSS ethos. I imagine that from the perspective of the FOSS community, using FOSS software in a SaaS product without releasing the code that drives the service is just a loophole.


IIRC, the uproar was less about the principle, and more about how it is defined:

> If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge [...] Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version

If I make a generic website that uses Mongo as a database, does that constitute making Mongo available as a service? It's clearly interacting with the functionality through a computer network, and could be said to derive its value primarily from the value of Mongo. That's clearly not the intention[1], but I would not be confident making that claim solely based on the licence text (and the FAQ is not incorporated as part of the licence).

There's also some debate about whether it meets Section 9 of the Open Source Definition ("License Must Not Restrict Other Software").

[1] https://www.mongodb.com/licensing/server-side-public-license...


Well.

No reasonable person would ever say that your website derives its value primarily from the database engine.

But lawsuits aren't forced to be reasonable.


Exactly - I don't think it's reasonable, but I also don't think it's clear enough to make a business decision based on it.

I would also find it difficult to argue that it's _not_ "enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network" (given how broad it is), which is the first example given.


This is not about multiplayer hosting. It's about streaming. Basically, primarily running the engine on a cloud provider and streaming the game to a local client. They even list authorized partners: https://unity3d.com/legal/terms-of-service/software/authoriz...


SpatialOS is not a streaming service, it is a multi-player hosting service that runs the unity engine on multiple servers to support MMO worlds.

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.


This is why I tend to shy away from proprietary tools like Unity-an event like this is sort of like an asteroid strike, it's improbable but there's no defense against it and if it happens you are wiped out.


Do that, and your game will never ship - because developing your own engine is a beast of a timesink.

The open source offerings are toys compared to Unity/Unreal.


Not necessarily. Many developers still write their own engines, they just don't usually make high-end graphical AAA type games. Even then it is possible, as Jonathan Blow proves.


Jonathan Blow was a hugely success indie developer prior to creating The Witness, and it had a multi-million dollar budget.

Also it's a great game, but I wouldn't say it's comparable graphically to a high end AAA game.


What do you think of https://xenko.com/ ?


And Godot?


I think Godot is a bit behind in 3d offerings. But I think it's close enough for most games that don't want AAA next gen graphics.


Only if you need an engine that powerful and flexible. A toned down and simplified engine is certainly not as hard to develop.


maybe, but we can see that projects built on spatialos won't be shipping either. (hopefully this is a temporary unintended consequence of the license update.)


There are GPL and MIT licensed engines to be had out there.


Improbable's response: https://improbable.io/company/news/2019/01/10/unity-blocks-s...

"Worryingly, this change occurred during an open commercial negotiation with the company to find a way to do more together."

So they had an ongoing negotiation and Unity just went ahead and made the change? Yikes.

Also kudos to Improbable for setting up an emergency fund for partners affected by this.


Unity's response, saying that Improbable is incorrect: https://blogs.unity3d.com/2019/01/10/our-response-to-improba...


The relevant portion of Unity's EULA which says that they their PR folks are incorrect "2.4 Streaming and Cloud Gaming Restrictions. You may not directly or indirectly distribute the Unity Software, including the runtime portion of the Unity Software (the 'Unity Runtime'), or your Project Content (if it incorporates the Unity Runtime) by means of streaming or broadcasting so that any portion of the Unity Software is primarily executed on or simulated by the cloud or a remote server and transmitted over the Internet or other network to end user devices without a separate license or authorization from Unity..."


It's funny, I worked for a company that was negotiating a license with improbable and they also changed the terms in the middle and left us hanging. I'm playing a very small violin right now.


That blog post is so slimy. Making Unity look like the bad guy when there's clearly business dealings in the background that the public is unaware of.


Maybe it's a shady negotiating tactic? I wonder if they had come to an impasse.


Unity's CTO responds: https://blogs.unity3d.com/2019/01/10/our-response-to-improba...

"If a game developer runs a Unity-based game server on their own servers or generic cloud instances (like GCP, AWS or Azure), they are covered by our EULA."


Funny, that isn't what their EULA says "2.4 Streaming and Cloud Gaming Restrictions. You may not directly or indirectly distribute the Unity Software, including the runtime portion of the Unity Software (the 'Unity Runtime'), or your Project Content (if it incorporates the Unity Runtime) by means of streaming or broadcasting so that any portion of the Unity Software is primarily executed on or simulated by the cloud or a remote server and transmitted over the Internet or other network to end user devices without a separate license or authorization from Unity..."


Forum post on the Unity forums from the Unity CTO:

"We are preparing a blog post because there is a lot of mis-information but the short summary is that using Unity as a game developer or game studio in a generic cloud (GCP, AWS, Azure) or on your own servers is perfectly legal."

https://forum.unity.com/threads/recent-tos-update-blocks-the...


The CEO of Unity is the former CEO of Electronic Arts. I do believe that he might be executing the same business practices on Unity's developers as EA did on their customers.

The first time I saw their CEO choice I thought that this can't be good for the dev community around Unity.

Here is a question, even though Unity is incorporated in the US, did anyone find the filings with the SEC? Or is it not required for and Inc to publish them?


> Here is a question, even though Unity is incorporated in the US, did anyone find the filings with the SEC?

Unity is a private company.


Incorporation doesn't mean you need SEC filings. You're thinking of going public.

Basically, if you can't go buy a company's stock, they probably don't have public filings with the SEC.


Who thought it was a good idea to hire's EA's ex-CEO?


I’m surprised the developers can’t simply reject the changes to the Unity TOS and keep using an old version of the engine (especially for production games!)

Anyone know why that’s not an option?


Because Unity's TOS, like many software agreements, stretch retroactively and proactively across versions.

If you use Unity, you agree to Unity Technologies terms, and their discretion to change them, without notice. It's literally in the terms. It's not so much software as it is software as a service.


The doctrine of illusory promise makes a lot of the 'we can change the license however we want' clauses very weak, as far as contractual robustness goes. There are other similar contractual doctrines that attempt to deal with similar issues, but the issue isn't that the release valves don't exist. It's that they're old, rusted and require a lot of force to turn.

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 highly unlikely that retroactively changing an agreement like that is actually legal.


A lot of the instincts around one-sided or surprising contract terms come from consumer protection laws in some countries. Not only is that comparatively absent from the US legal climate, it often doesn't apply to business to business relationships (such as between Unity and game development companies) even where it is present for consumers.


The agreement that you agreed to previously included terms that stipulated that Unity specifically had the right to unilaterally revise the terms.

If you don't agree with the new terms, you must immediately stop using the product.


Just because it's in the terms of service (or any contract) doesn't mean it's valid and legally binding. I'm not a lawyer but I would be surprised if a term which allows arbitrary retroactive changes of contacts is legal (at last in Europe). Through that's just wrt the retroactive part.



I don’t think Unity is under any obligation to tie their ToS to specific engine versions. Additionally, losing the ability to receive bug fixes, enhancements, and new platform support by sticking to an older engine is a bit of a non-starter for a lot of devs.


Id like to say you're wrong.

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?


I feel like people are missing the mark here, complaining about commercial game engines.

SpatialOS was basically re-distributing Unity under a SaaS model. Unity is in the right here.

Edit: Have heard some pretty good points about the ambiguous wording of the ToS (such as theoretically making the distribution of a Unity-made game through a storefront illegal). It will be interesting to see if this ToS change sticks.


Not really, developers were still under the legal obligations of paying Unity if your company had more than $100.000 revenue and all the other contractual clauses.


No, Spatial was not doing that, they are an integration with Unity. Developers still needed to install Unity with a license, get the SpatialOS framework running as their net code, and then write a game.


I'm not so sure. Maybe I am misunderstanding but the terms prohibit the "use [of] a managed service running on cloud infrastructure...to install or execute the Unity Runtime on the cloud or a remote server".

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


If I write a Java app and run it on AWS, I'm in the clear.

If I write a licensed Unity app and run it on SpatialOS, well, that's now no longer allowed.


Yes they are running unity runtime on their servers, there is nothing in the TOS against that, what is illegal is to share any of the data from that runtime online with other Unity instances. Which has nothing to do with "re-distributing" Unity has a SAAS.


Re-distributing was the wrong word to use. But it seems to me that the Unity Runtime is a part of the stack of their SaaS.


Yes it is specifically the part of their stack that one distributes to customers. It's like if the Java runtime or the DirectX runtime wasn't distributable to cloud machines.

Unity had a pretty clear model as providing a software stack that one pays for using, primarily containing a bunch of proprietary tools for creating applications for their runtime. And then one could package that runtime and their application and give it to whoever one wanted (as long as they followed the revenue share part of the contract).

So yes it's part of the stack. but it's the part of the stack that people are meant to redistribute with their game.


The EULA bans any SDK, not specifically the GDK which presumably includes some part of Unity in a re-distributable form. If it was only banning the GDK, then developers who want to use SpatialOS could integrate the SDK on their own just like someone who uses CryEngine or builds their own engine instead of using either Unity or Unreal for which the GDKs were created to streamline the process. But the EULA doesn't stop at using Unity on the cloud with an SDK, it bans all use of Unity running on the cloud. "2.4 Streaming and Cloud Gaming Restrictions. You may not directly or indirectly distribute the Unity Software, including the runtime portion of the Unity Software (the “Unity Runtime”), or your Project Content (if it incorporates the Unity Runtime) by means of streaming or broadcasting so that any portion of the Unity Software is primarily executed on or simulated by the cloud or a remote server and transmitted over the Internet or other network to end user devices without a separate license or authorization from Unity. Without limiting the foregoing, you may not use a managed service running on cloud infrastructure (a “Managed Service”) or a specific integration of a binary add-on (for example, a plugin or SDK) or source code to be integrated in the Unity Software or Your Project Content incorporating the Unity Runtime (an “SDK Integration”) to install or execute the Unity Runtime on the cloud or a remote server, unless such use of the Managed Service or SDK Integration has been specifically authorized by Unity. Additionally, you may not integrate the Unity Runtime with a Managed Service or SDK Integration and offer that integration to third parties for the purpose of installing or using the Unity Runtime on the cloud or a remote server. For a list of Unity authorized streaming platforms, Managed Services and SDK Integrations, click here.This restriction does not prevent end users from remotely accessing your Project Content from an end user device that is running on another end user device. You may not use a third party to directly or indirectly distribute or make available, stream, broadcast (through simulation or otherwise) any portion of the Unity Software unless that third party is authorized by Unity to provide such services."


So what?


Perhaps you are unaware that the Unity runtime is royalty free, or at least it has been until now. You can distribute it to an unlimited number of people without paying Unity. What Unity charges for is their developer tools, not the runtime. Since developers using Unity with SpatialOS still need Unity's developer tools, it does not threaten Unity's business model in the slightest. That's why this is surprising.


SpatialOS is doing much more than that. It's main goal was bringing a single world spread over multiple server instances instead of individual servers.

It's like atlas vs ark, not like unreal vs unity


Your right. This is about the hosting company running Unity software on the cloud -- something that clearly needs to be licensed by Unity.

From Ars https://arstechnica.com/gaming/2019/01/unity-engine-tos-chan...

> The newly updated clause 2.4 of the Terms of Service now specifically excludes "managed service[s] running on cloud infrastructure" which "install or execute the Unity Runtime on the cloud or a remote server."


Re-distrubuting and hosting on the cloud are 2 completely different things, here Spatial isn't streaming the visuals of their instance or anything alike but making sure there is only one state of the game, a pretty useful tool for multiplayer games (avoid cheating, etc)


Its stuff like this that make me glad I spread client work over Unity and my own studios (important) projects on our own engine (c++). I want to be able to play/port my games in 40+ years. Who knows what else a private company like Unity will introduce in coming years.


Godot is a game engine licensed with the MIT license. Unity just proved that free != yours.


Godot is also behind the curve on content pipeline tools. I love it to death, but I would never be able to convince anyone outside hobbyists to use it because it has no goddamn FBX support, or an easy ECS framework.


Native FBX support is not compatible by license, you are free to make a module that lets Godot use FBX, just with a FBX compatible license.

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.


Without a stable and widely used model format making a game is impossible. You can drag&drop FBX into Unity and Unreal, and its mostly ready for use. Having a broken FBX importer is just a waste of time. You start with a model format, something works, you build a workflow, a system for producing content en masse, and then at some point you must consider throwing away the model format, the workflow and/or the whole engine, because the importer is unreliable. Or you try to rewrite it yourself, further wasting time. Some things must be rock-solid, open-source or not.


Godot doesn't have any broken importers, yet alone FBX which it doesn't have completely for legal reasons. Looking at Collada(.dae) Blender has a super broken exporter, so broken that Godot folks wrote a better one from the frustration. GLTF2 doesn't have enough support, even though it's a good format.

The problem is that everyone is just sitting and using proprietary FBX format and don't work towards new open standards like Collada or GLTF2.


Sorry but saying "Godot is fine, everything else is broken" isn't really acceptable. If I were to start a 3D project only to find out that importing models didn't work in the game engine I chose, I would move on immediately.

In all honesty (without knowing the specifics of what is broken, I've only ever worked on FBX importers), if Godot want to be taken seriously then they need to be able to import without plugins, warts and all.


Fortunately, I have been able to do most of what I want with Blender and Better Collada. But I know that lack of FBX support pretty much makes it a non-starter outside of hobby projects. This also has to factor into a significant labor base that knows Unreal, Unity, CryEngine, Lumberyard...


Is there a blog post that goes into this ECS vs nodes paradigm?


There is this [0] overview that looks into OOP as a whole and puts Godot and other game engines into it

[0] https://willnationsdev.wordpress.com/2018/04/05/godots-node-...


Hopefully some of the Unity exodus helps Godot along with more contributors.


The issue, of course, is most of the people using Unity are using it because they don't have the ability (or time) to write the functionality Unity provides themselves.


There will be higher skilled devs who are using Unity that are appalled by this business practice and will want to move to a more open platform.


Unless there's an incentive for them to share their contributions back to Godot (like a paid plugin store, of which at least one is in development) they won't stay.

And no, I am not talking about the Asset Library.


If that was true, then no open source software would ever get released.


or free = !yours


I sort of find it poetic. If you decide to build on a commercial platform like Unity's you're subject to the whims of Unity Technologies.

It sucks, but game engines are by far one of the riskiest investments I've seen across technical subfields.

You have all of this engine-specific knowledge, and all of a sudden moving engines is near impossible. Tons of common things across major game engines, but in practice it's not so easy to move here or there.

It's not like a database, where maybe some data type quirks are a bit different, and hopefully you can just change the underlying implementation behind your DB abstraction. Change a connector or something of the sort.

With game engines, you'd have to reexport models from sources, textures might be treated a bit differently, map formats might have to be scrapped all together or converted using some at-the-moment nonexistent scene converter. There's a lot involved.


Isn't that always the case with frameworks vs libraries? A database can be seen as a library but you build your entire game on top of the engine which makes it like a framework.


It’s got to be said. I felt unity’s business model was not very friendly to devs because you don’t get access to the source code. Unless you have a very expensive enterprise license. On the other hand, you can get access to unreal engines source code in github for free. Switch to unreal.


Look on Upwork, Freelancer, or other jobs sites. There are 20x as many Unity programmers as Unreal.

C++ is overkill for most tasks. C# is just an easier and safer language to use.

For a small studio, using Unity can be the difference between finding a game programmer or not. Plus there is a much bigger community in case your programmer gets stuck, and more useful assets available on the store.


SpatialOS streaming Unity seems broadly equivalent to AWS hosting MongoDB. Especially in that it undermines Unity’s (i.e. Mongo’s) ability to sell a hosted equivalent product (whether or not that exists yet) and it leverages some of Unity’s value into rent for Improbable. Now there’s a difference in that SpatialOS is adding meaningful value - but it’s not necessarily their’s to take.

Ultimately this is Unity’s platform and they control it and its future direction. I suspect that more value can be delivered to both parties if they reach an agreement - SpatialOS is really cool! What we’re seeing here is presumably a strong negotiation tactic from Unity - they want to continue to own the relationship with their own customers - hopefully we’ll see some kind of agreement in the future.


AWS isn’t using any of MongoDB’s code — merely emulating the protocol and behavior.


Seems like the best path forward for a current cloud Unity provider would be to move from managed Unity to one you can deploy yourself. Make it so it’s trivial to run your own and move the licensed use to the game developer instead of the cloud service.

EDIT: after reading the actual terms it seems like even game developers can’t do this without violating terms. Unity really wants this to be something they wholly own. Yikes


Twitch streaming is pretty important to most gaming markets. This announcement sounds like it also has the result of making twitch streaming against the Unity TOS.

> You may not [distribute Unity or your Unity Project Content via] streaming or broadcasting so that any portion of the Unity Software is primarily executed on or simulated by the cloud or a remote server and transmitted over the Internet or other network to end user devices without a separate license or authorization from Unity.


> streaming or broadcasting so that any portion of the Unity Software is primarily executed on or simulated by the cloud or a remote server and transmitted over the Internet or other network to end user devices

I could be wrong, but the "is primarily executed on" bit sounds to me like it is more aimed at preventing creation of a service like geforce now or playstation now where a user plays the game but it is streamed from the remote system where it is actually running


I guess they're kicking Hearthstone off of Twitch


Illegal is the wrong word, but still, fuck. My game uses dedicated servers built on Unity. Seems this applies even to me. Kinda shitty.


Yes, breach of contract is more accurate. The lesson is make sure your product doesn't depend on clickwrap terms that can be changed at any time.



Here's a discussion on the Unity forum: https://forum.unity.com/threads/recent-tos-update-blocks-the...


Could someone please clarify what SpatialOS actually does? Even in the updated arstechnica link I still don't quite get what is going on and how it breaches the new terms of service.

Are the game clients used by the players running Unity? Is the server running Unity? How is SpatialOS's setup different from other multiplayer games?


It's a server side framework that integrates with other commercial engines ( Unity / Unreal ), what it does is it allows to have a single big map where each small chunks of the map are handled by a gameserver.

For the player it's transparent, you can have huge world with inter connected game server, instead of having one map with 32 players on it.


Consider a traditional MMORPG architecture, using a third party engine rather than an in-house engine. The engine ran on the player's computer, and the game company bought one engine license per copy of the game sold.

If one were to build an MMORPG with SpatialOS instead of following the tradition approach, how does that change the number of copies of the game engine you need to license?

It sounds like the engine runs in the cloud, so do they only need one copy per person who is actually online at the time, or even only one per currently occupied region of the game world, or is it still one per copy of the game sold?


You need an unity engine license per copy of the game? Do you have a source for that?

I can't find any reference to that on their website, they even answer "Yes" in the FAQ on the "Do I own the content I create?" which what you mentions would make it essentially false. How does free game made on Unity works?


It runs in the cloud and on every player's computer.

Not that unity charges per copy in the first place.


I run a multiplayer VR team platform where we run a copy of Unity3d on the linux cloud server and load the the same Unity Asset Bundle on the server as the clients ("The current world"). I chose this method because:

(1) it followed the Unity3d documented approach using UNET server and client architecture (2) it meant we get to simulate the entire scene on the server (physics, meshes, networked objects, etc)

We boot the instances on demand when a team wants to meet in VR.

Sounds like Unity's new T&C's means this architecture is dead in the water.. unless Authorized by Unity3d. :-(


If I was using Unity, I would be immediately looking at other alternatives. This kind of thing just screams shady business that doesn't care about their customers in the least.


I'm not familiar with Unity so I have a few questions which aren't clear to me.

Why is SpatialOS running Unity code in the cloud? Presumably a Unity client can talk to an arbitrary server backend over standard network protocols, right? Was it simply easier to write the backend in the same SDK as the frontend? Does Unity provide a networking layer that works better with both sides running Unity SDK?


Hey look, yet another software rental provider fucking over its customers!

Y'all did this to computing, folks. Should have stuck with perpetual licensing...


Improbable is very well funded, what are the odds they could take Unity to court over this? 500m raised is no small amount, I'm sure their investors want to protect it.

It seems like a Google/Java situation all over, where Improbable are building something to interact with Unity's API, and Unity is using a quasi-legal TOS to try stopping them.


Does anyone know of any cases where this new clause was used to shut down existing games using the unity runtime in their servers? This ToS change has been around for about a month so I figured that there might have been previous activity.


They cleared up this concern in their blog post: https://blogs.unity3d.com/2019/01/10/our-response-to-improba...



So what does the TOS change mean exactly? At first glance it sounds like they want a lince see for every instance of the editor running. This doesn't apply to build code deployed on servers does it?


Just curious, how does the godot engine compare to Unity and UE4? Is it suitable for AAA studios or are there any major pieces missing?


It is not ready imo. Someone correct me if I am wrong about any of this.

Their custom scripting language is extremely slow to the point where I wouldn't consider using it.

You can use C#, but if you download the c# version you get a warning on startup which states that this version isnt production ready.

You can use C++, but I found the workflow here awkward, plus they just introduced it with 3.0. They are about to launch 3.1 but this includes breaking changes to the way you use c++, so if you were using it and wanted to upgrade you'd have to rewrite a portion of your code.


Oh, come on, how many compute-intensive things you need to do in a game scripting language? GDscript is fast enough for scripting, C++ is there for the compute-intensive tasks you might do (though most of them are already implemented by the engine).

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.


Performance is a feature. If you want your game to have as large a playerbase as possible, it needs to perform well even on bad hardware.

I strongly suspect that most people will write their entire game in an engines default language. Especially in this case where the much advertised best alternative (C#) gives you a warning on startup about not being production ready.

Yes, C# is probably integrated due to its success in Unity, but it's a sane choice. I would argue more so than GDScript. C# has better performance, tooling, support, not to mention an existing userbase of people who already know (and I'm sure many of whom like) the language.

Ignoring C#, they cannot be breaking their API for writing native code. I'm not sure if it was a one time thing, or if it will continue going into future releases, but they absolutely need to have stability if they want people to use their engine long term.


GDscript was created to better integrate with Godot's internals, there is a whole section in their FAQ why they didn't use another language[0]

Warnings for C# are there because it's new, and there is not enough resources to support it better. Also C# is not that easy to integrate as it doesn't have most data structures used in game development, so your own have to be made. In the end it changes so drastically that you might just call it a new language.

[0] http://docs.godotengine.org/en/3.0/about/faq.html#gdscript-w...


We don't know yet if it is suitable for AAA studios yet, as no yet tried. But Unity itself for quite a long time was not suitable for AAA studios, and just quite recently AAA games using Unity popped up. I'd say that Godot has got the essentials, and most of what is missing is pretty easy to add yourself. Maybe the last thing that stops AAA studios from using Godot is that it still uses OpenGL ES 3.0 for rendering, but there is plans to use a new renderer based on Vulkan


> most of what is missing is pretty easy to add yourself

What's missing in Godot?


A common complaint is terrain. It's likely it will be added to the roadmap, but there are already plugins that add it [0]

[0] https://github.com/Zylann/godot_heightmap_plugin


Stuff like this is exactly why I stay away from Unity and stick with Unreal.


damn. I was looking forward to playing Worlds Adrift someday. Hopefully they can get this resolved.


From the Worlds Adrift blog, they've apparently heard back from the Unity side:

"Bossa has been informed by Unity that Worlds Adrift should not be affected by the situation between Improbable and Unity. Thus, Worlds Adrift remains live as normal."


You should play it while you can. It's a very fun game and the PVE server is some of the best relaxing gameplay I have experienced (as long as falling into an abyss doesn't stress you out)


Worlds Adrift says they're still up for now.


that remains to be seen for how long. if they are operating against the Unity ToS, I would expect it to be down soon as a result.

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


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: