ECS patent

But we can't blame Unity for this. The only thing to blame is the thing that accepted it as a patent in the first place. If Unity didn't file it, a squatter can or any number of irritants. Put simply, the patent system, for software is an absurdity that copyright can cover just fine.

So really, the patent office has to butt out and just end software patents. That's the magic trick. Let copyright do it's job in a much more sane place.

 

To get that fixed, you have to change the US patent system. I'm affected by this, but I'm not even in the US. It should be fixed, but that doesn't help me today. Given how US policy gets made, and the business interests involved, it probably won't be fixed any time soon.

The best thing we can do about this today is to put enough public pressure on Unity that they make a clear public commitment to only use this defensively. Well, I assume that's possible, but I don't actually know anything about US patent law.

 

Which means the patent won't affect you in the slightest. Unity's patent only applies to Unity's implementation and if for some bizarre reason this patent covers a generic implementation the fact that ECS has existed long before this patent would likely invalidate this patent.

https://en.wikipedia.org/wiki/Prior_art

Additionally you can't patent an existing product or work but you can patent an improvement to that work.

https://ocpatentlawyer.com/can-you-get-patent/#1-can-you-patent-an-existing-product

I'm not a lawyer but I do read into the subject extensively because it affects my work and worst case if I don't understand a subject asking a lawyer is only a phone call or email away. Which is what people should be doing rather than uninformed panicking.

 

I'm not panicking, but I am expressing concern. I'm less concerned that if affects me - my project is unlikely to go anywhere anyway - and more concerned that if affects people like me, and the industry tools of the future. I'm using myself as an example of how unknowns can create a chilling effect.

People who know more than I do seem to be concerned that this is an overly broad patent. It appears to cover the chunking and archetyping mechanism, which are fairly obvious and necessary components of a high performance SIMD friendly implementation. It's too dense for me as a layman to confidently understand what it covers.

I'm aware of how prior art works, but there are very few people or companies who can afford to take this to court to resolve that.

 

Yes, this is why my first post in this thread was really just resigned to it being "so what" - I mean what can be done? nothing hehe.

 

One thing that we could do is get Unity to clarify their position and intentions with this patent. If they say that they will only use it defensively and will not strong arm or sue competitors, then the problems go away.

I don't know if that's something they can legally clarify though - maybe that compromises their rights somehow.

 

What is there to clarify though? I mean if you're somehow looking for a sign that Unity is a good company I will put you straight on that right now: Yes, they're the good guys!

But, they absolutely 100% will go out and make serious cash. They're public and they mean business. I haven't got a single share at the moment! I can't afford any! So that's not actually biased, but just straight talk. Any smart business has to make as much money as it can, while it can, all the time. That's how it works.

All the people I know and have chatted to at Unity have been lovely people. So maybe your morals don't align - it's not godot - but it is really good tech made by good people - who want money too. So that's just what it is, I guess.

 

Yes and no. One method to dispute a patent is known as Inter Partes Review (IPR). A rough estimate places the cost of this procedure between $300,000 and $600,000. While expensive this is much lower than an alternative such as a litigation battle which can and most likely will be in the millions.

https://www.upcounsel.com/cost-of-inter-partes-review

 

I'm not looking for some sign of morality. I'm looking for a sign that it's safe to build ECS engines in whichever way the performance requirements lead, without worrying about getting a cease and desist which I would have no resources to fight.

At first look and to a non expert eye, this patent seems to claim ownership of obvious implementation choices that come from following basic high performance engineering principles. If they enforce that ownership, then people can no longer build an ECS engine in the obvious and best way. That's a problem for the industry.

 

Even at those prices, that means that indie teams can't fight it, open source projects can't fight it, and startups probably wouldn't risk basing a model on fighting it. That's a huge chilling effect. Yes, Epic could do it easily if they wanted to, but they're not who I'm worried about.

The reason that I'm so concerned about this is that I strongly believe that a DOTS style engine should be the future of the industry, but I'm currently not feeling positive about the state and direction of Unity. I don't believe that adding an extra DOTS layer to Unity's already precarious technology stack is the right way to go about building that engine. A good DOTS engine needs to be designed and built that way from the ground up.

My own experimentation with building something like this is mostly just for fun, but if Unity is able to shut down that competition with moves like this, that could be a very bad thing for the next couple of decades for the industry.

 

My recommendation from earlier stands for people who are concerned and want a "sign that it's safe". You need to contact a lawyer and ask them. Ideally one that is knowledgeable about video games. I have linked the lawyer the company I am contracted to uses but he's by no means the only one out there.

You should do this even if you are making it for giggles as nothing we can say will legally qualify as that sign.

https://strebecklaw.com/

 

I agree that the patent system is a dinosaur that isn't up to date with software, and probably other modern stuff as well. But I disagree that copyright is "just fine" for this, as it solves an almost entirely different problem.

Copyright is about the right to reproduce something, and it's often very possible to rip off research / inventions / discoveries in software (and elsewhere) without ever copying the resulting product itself.

 

I have seen too many cases where too many people - myself included have arrived at solutions that infringe software patents. It even happened to a guy on this board recently.

It can't be patentable any more than dance is or patenting artwork. It's like patenting a shopping list. It's logical copyrights will cover source code but not the technique. So patents prevent the source and the technique, even though its trivial to arrive at the same technique. I also don't know any discoveries in software that demonstrably wouldn't be found anyway.

You are talking about patenting things inside patented things, it's just insanity at best, but everyone thinks it's acceptable.

 

As I said, "I agree that the patent system is a dinosaur that isn't up to date with software".

Importantly, a patent shouldn't be awarded where "its trivial to arrive at the same technique". Patents are only supposed to be awarded where there is a novel solution being applied. <edit> And just because a patent is registered does not mean that it is defendable. </edit>

No, I'm merely pointing out that patents and copyright are attempts to solve fundamentally different problems, with similarities only at a superficial level.

 

So long as Unity doesn't go all Wizards of the Coast and sue people for turning pieces of cardboard sideways, I'm largely indifferent to this.

 

Patents are generally stupid and irrational. The only reality in which their logic works is the alternate reality of bureaucracy. At most a patent should get you a few years head start, after that you're just wasting everyone else's time.

 

I don't understand what you're trying to say then. Either you agree with Unity's decisions and you will end up at the same place as them (so you will violate their patent in theory) or you don't and you will end up with a substantially different tech and you have no reason to fear that you will violate their patent.

 

He can agree with some decisions, disagree with other decisions, and have a general impression of unity's behavior. It is not all or nothing thing.

 

Yes, and patent violation only applies when there are substantial similarities.

 

I think the basic data oriented ideas underpinning DOTS are a good design for an engine.

• I don't think that the messy compilation and transpilation pipeline Unity has going on is a good or sustainable thing.
• I love C#, but I don't think it's the right language for the industry when others could do the memory management side of things significantly better. I don't think that compiler hacks on top of C# to make it do those things are a good solution either. Recompilation is already 10x slower than is acceptable for an engine of the future.
• I don't think that basing the DOTS authoring experience on MonoBehaviours and inheriting all of that mess is a good or sustainable thing.
• I think that the way the editor is tightly tied into the runtime domain is a mistake, and will make it impossible to ever get that instantaneous code recompilation and reload that we need. Whether or not it's theoretically possible in the future, Unity certainly isn't doing a good job of this today and I have no indication that they actually will soon. The infamous 500ms thing was a long time ago and they've gone very quiet on that front.
• SRP has been a disaster.
• The package situation is a mess.
• I don't have enough confidence in Unity as a company to say that I'm happy with them being the only people making a DOTS style engine for the next couple of decades, without even having the pressures of competition.

My ideal engine is data oriented from the ground up, and well engineered specifically to be that. Unity is a mishmash of questionable historical design decisions and changing goals. Many major features feel broken when you try to do anything interesting with them.

It's possible that Unity decide to do a ground up rebuild like that, and they end up being the company that builds the engine that I want. But I don't want them to be the only people able to even try.

 

By developing your engine from the ground up for ECS you've already eliminated one of the core concepts of the patent: the automatic conversation of traditional OOP-based game objects and components into entities.

It's completely possible but likewise completely irrelevant in my opinion because at least in the US patents are fixed in stone and cannot be amended. If Unity wants to keep their implementation patented they will have to make new patents for it with each new major change.

https://www.neustel.com/can-amend-patent/

 

With C# you has also the ability to manage the Memory by yourself. Unity uses unmanaged code and pointer almost everywhere in ECS. The only compiler hacks (IL postprocessing) are actually only there for us to reduce boilerplate code.

 

No you don't. No RAII. And you can't even delete a managed object.

Manual memory management in C# has convenience level of programming in assembly. It is thoroughly awful, and it is one of the weakest parts of the language.

 

@neginfinity already answered this well, although I wouldn't say that it's quite as bad as writing assembly! It's possible to do, but it's not a good experience compared to languages that cater to it.

 

When it comes to the management of unmanaged data memory, this is basically the same as C++, and with Span <T> also a simple handling.

In the case of ECS, all component data, archetypes and entities are managed with pointers.

 

We're dragging this thread very far off track and I'd rather we didn't. There are various ways in which doing more complicated low level memory management in C# is not as nice an experience as it could be. We're not saying that it can't be done. We don't need to go into this in any more detail, that was just one point out of a list.

The crux of my post was to say that there are various reasons why I think a competitor engine designed from the ground up to be data oriented is preferable to Unity's current mishmash over the coming decades. I'd rather not quibble the semantics of each bullet point and drag the thread off topic.

 

Nope. That's not C++ memory management. C++ has automatic memory management without GC and with deteministic object lifetimes. You decide what dies, when and how. You do not manually release resources. Having pointers does not mean having C++ ability to deal with unmanagement memory.

Try running this:

Code (csharp):

1.  
2. // Example program
3. #include <iostream>
4. #include <string>
5. #include <memory>
6. class Test{
7. public:
8.     std::string name;
9.     Test(std::string name_)
10.     :name(name_){
11.         std::cout << "Hi!" << name << std::endl;
12.     }
13.     ~Test(){
14.         std::cout << "bye!" << name << std::endl;
15.     }
16. };
17. void testFunc(){
18.     auto arg3 = std::make_shared<Test>("arg3");
19.     std::cout << "testfunc" << std::endl;
20. }
21. int main()
22. {
23.     auto arg1 = std::make_shared<Test>("arg1");
24.     testFunc();
25.     auto arg2 = std::make_shared<Test>("arg2");
26.     std::cout << "test" << std::endl;
27. }
28.  

 

It's still C++, maybe old-style, but still C++ style.
If you use old or C libraries in C ++, you stuck again with raw pointers.
An in some cases you has the using statment

Code (CSharp):

1. {
2.     using var myVar = new ObjectWithResources();
3.  
4.    // do some stuff
5. }

But memory management is not just about the life cycle. Unity also uses its own allocators for ECS.

 

No, it is C/assembly style. Not C++. RAII was introduced in 1984.

You cannot use using to prevent garbage from being created. It is also manual, and has to be manually specified in every statement.

It is about the life cycle. To be precise it is about being able to nuke an object when you want so it doesn't turn into garbage collector fodder that is going to slow down your application at some non-deterministic point of time.

C# lacks this ability comletely. And that's why Memory Management is the weakest part of the language.

 

I feel for you and do see DOTS longevity certainly as being somewhat temperamental, which sucks and I will be sure to make backups of the software.

I'm wondering what are your takes on how much of an improvement would DOTS be for specifically online multi-player.

We see DOTSNET and the potential there, so I'm thinking DOTS' future lies somewhere within the category of networking improvements some to degree.

At least that is how I've always envisioned it.

 

TBH without the patent Unity would probably find themselves being abused by Improbable and other parties. It's not like that hasn't already happened.

 

std::unique_ptr and std::shared_ptr are relatively "new" (C++11).

In simple applications / examples, memory management is only the life cycle, but much more important than that is the allocation and management of HOW the data is stored in the memory.

If you manually manage memory in C#, then you use unmanaged structs, there is no garbage.

Modern C # has already done a lot to minimize GC allocation, e.g. Span <T> with stackalloc to allocate arrays on the stack without GC and no need to manually free the resourses.

Actually, this discussion could be split to another thread.

 

Boost says hi. Smart pointer library was released in 1999 and the concept of RAII predates C++11.

RAII does not require shared_ptr. It is a convenience method for wrapping thing automatically, but you can do without it. Its main point is stack unwind guarantee which determines when things die.

What modern C# "has already done" is not good enough, as it does not give you full control over every single allocation. And you'd really want to have this kind of feature in video games.

C# does have interesting features. However, anything related to memory management is awful. The language wants you to spam allocations. However every allocation you do contirbutes at a possible hiccup at some unknown point of time, and that is a bad thing.

Going back to unity, one amazing thing unity could do woudl be providing C++ api. Obviously they're going to be stubborn about it and hell is going to freeze over before that happens.

 

Strictly speaking, automatic lifecycle management is the complete opposite of full memory control. An in case in unmanaged struct, you have the option of taking full control of the memory management, but that also means that you have to take control of the life cycle yourself.

For reference types, I agree with you, there is only limited control, which is why it is also important not to use reference types for short-lived or simple data objects.

 

In my opinion, the point of the language is to empower users, and that means given the user the power when the user needs it. C++ actually handles that fairly well. You can use high level constructs without ever worrying what's happening under the hood, but you absolutely can go under the hood as far as you want. And automated memory management features in C++ are STRICTLY defined, unlike GC which is non-deterministic.

Except that's wrong. The majority of stuff in C# is reference types, and it WANTS you to use reference types everywhere. The language even uses immutable strings, plus it spawns anonymous reference types.

So in order to use the language efficiently, you'll need to lock yourself out of powerful language features.

And that's the reason why I say that C# has poor memory management facilities.

 

If you want to discuss C#'s memory management, you should make a separate thread for that. I didn't mean to drag things off track with my comment, and I would like this thread to remain on topic to the patent please.

 

That also depends on the software and the developers, Unity basically uses structs for all data types, and the .NET library also uses structs for pure data types. I have to shake my head every time someone uses classes for pure data types.

.NET Core/5+ Garbage collector work different from the old on in Unity, short lived classes often are destroyed bevor GC come to work. I have already observed this myself in a test (.NET 5 vs Unity), where I constantly created new class instances, but in the .NET5 version the GC never did anything and the memory consumption remained consistently low. The same test with Unity filled my Ram and Unity froze.

 

A mod could split the discussion?