The future of Game Objects...

In this blog post regarding ECS unity say this about the future of Game Objects...

If we view the OOP Game Objects and Monobehaviours (GOM) as collections of entities and *inverted ECS systems then could we convert a GOM based Unity project to an ECS one or even have it's OOP API run ECS systems under the hood?

The same way that Unity previously ran Jobs and Multi-threading in the engine under the hood.

Also if we start using GOM and ECS will more people want to move to ECS just because it sounds better than GOM?

*Unity is the system but calls each OOPs individual Update function, if we move the Object data into entities then we can run them like ECS systems in theory.

 

I think linked blog describes well, what is going to happen. So why to speculate?
Unity will develop ECS based APIs.
Unity long term goal is to convert OOP based APIs to ECS. But this probably will be much longer process, than developing ECS based API itself.
I expect, OOP based APIs will be ahead with features, what ECS based APIs will be able offer, for quite a while.

I think you need more practical knowledge, instead posting academics all the time.

But to answer, to move blocks (ignoring performance),

• in ECS you can have 10k, or more blocks as entities each and run them by single system.
• Rather than run 10k+ blocks with 10k+ updates, in OOP. But also, you can have single update in OOP and move all the blocks.

And I am sure you know that.
I ignore RigidBodies, as official ECS, don't have pure solution as of yet.

 

For me monobehaviour and gameobjects represent ease of authoring content, while DOTS is a compiled form of that... at least where the gameobject / rendering / scenegraph is concerned.

So you will make stuff as you have always done so, but Unity will compile it to a subscene and stream/render/manage it.

As for behaviour, well that's a different subject to the transform/gameobject concept.

 

In ECS there is a required separation between data and behaviour from the classic component. So, yes the possibility to convert them is there and I also think it can be automated. I have done this separation even with GOM with previous projects. I used MonoBehaviour to just store data (POD) and had separate C# classes as Managers that handle the data Oh, and a final MonoBehaviour to send Start and Update to the non MonoBehaviour managers.

 

Yes, I agree with the ease of authoring content. That is why I would like Entity and ComponentData from ECS to be a first class citizen in the Unity Scene like GameObject and MonoBehaviour are right now. This way you can set data in the scene same way you are used to, but chose where you want GameObjects and wher Entities. This way I think that the ease of use is there and the transition to ECS becomes natural.

 

Great, because that's what's coming with the subscene concept (for benefit of new readers). It remains to be seen about the coding side but I'll port stuff over in good time.

 

From everything Ive seen and read it seems like they're basically gonig to end up building layers - the front end that you author content with and the back end that makes it go fast. I get the impression that the front end will largely stay the same while the back end is getting monolithic overhauls.

 

I think really we're all so far long with the classic authoring approach, and Unity is spending actual millions on making sure that the approach that gave them actual millions doesn't go away

I like it, I'm settled in my own comfort zone with Unity classic workflows so it's unlikely I want to bother deep diving in ECS unless it's to tackle a specific performance issue... so for rendering if Unity can DOT that up for me, I'm good

 

My hope is that Unity Technologies carefully studied what happened with Adobe and Flash when they decided on this direction for the tool. A lot of old-time Flash "developers," many of whom were designers with a bit of coding chops, fell away from the platform when ActionScript 3 dropped, because the change was too radical for them. It wasn't just the language, but the implications for how the language change removed old tools that they previously used to rely on without offering reasonable alternatives.

Lot of destroyed workflows, lots of disaffected users.

 

Even if ECS was to fully replace monobehaviour based development (it likely won't), Unity moves at a pace where you're basically worrying about the possibility of something happening a decade down the line.

 

Most people who think like that finish very little cos they're too busy with the what-ifs.

So far Unity has been cautious about breaking people's stuff, so much so that (as much as Unity tries to deny it) even asset store holds back progress.

 

I’m not sure about that as a universal principle. I recall when they changed the physics engine sometime around the 4.X era that it completely upended a game I made previously. The entire thing would have to be rebuilt if I were still invested in it.

That was a change that had no API updates that I recall, but dramatic impacts on the product. Even though they are doing most of their work under the hood, that doesn’t mean you’re safe. Doubly so if they make a breaking change midstream, and then Apple makes an Origami phone and demands all developers update Xcode, use only the latest iOS sdk, and buy a new MacBook... and then Unity just tells you to solve the problem by upgrading.

 

You shouldn't do an update to an in-progress project unless you have to and the changes to the physics engine and how it worked was pretty well documented before release.

 

I have seen something like that with Project Tiny. I don't like the fact that there is a lot of wrapper code for it to work (redundancy) and What You See Is What You Get gets broken because you can not run the project in the Game view in the Editor and see the changes in the Inspector. But in the end I am sure all of these are on the TODO list for Unity

 

I understand the reasoning behind not upgrading mid project. I didn’t upgrade in that case and the project was completed. In fact that game is the textbook example of not updating unless you are forced to.

And it was forced to. Targey platforms tend to make breaking changes of their own, and you can get stuck in a spot where you can’t update Unity and also can’t reach your build target if you don’t update Unity.

 

The alternative of Unity maintaining two separate physics branches would be just as bad, if not worse.

 

It would be awful, yes. I certainly wasn’t proposing that they do. I was pointing to the fact that their velocity is more rapid than the scale of decades, and what that means regarding development and maintenance for projects, and the line Unity has to walk.

 

Replacing a physics engine is a lot different than the entire way the engine is written. They supported UnityScript far longer than anyone could have expected.

 

What about IL2CPP and the work Unity are doing with the Burst compiler, could GOM code be compiled to ECS code where the objects functions become ECS Systems and each Object could be a ECS micro world or ECS macro system maybe?

 

GOM methods are object specific.
It really need change way of thinking, to follow ECS, rather than trying focus on GO conversion them self.