Will DOTS replace monobehaviour?

Similar to this thread but different in context => https://forum.unity.com/threads/will-lwrp-hdrp-replace-the-built-in-pipeline.688909/

I wonder if I can use monobehaviour for 4-5 years after this without worry about it's going to be deprecated. Let's pretends that I just start using Unity today.

 

We've been told it won't be replacing MonoBehaviour, and that it's intended to be used alongside MonoBehaviour, but in my opinion the jury is out on that. We need to wait and see how DOTS and it's visual scripting system evolve and how popular they become before we can draw conclusions.

That said don't worry about feeling locked in on old ways of development. Games have a finite lifespan. You can always decide to use a different approach with a new game and lock the old game into the old approach. This is how the game industry has done it for decades and we definitely aren't on the original systems now.

 

TL;DR: If people keep using it, it helps Unity users and/or Unity to keep it, and is not so much of a burden to make it not worth it, Unity will keep MonoBehaviours until that no longer is the case.

Spoiler

It depends on several factors

1) How much extra effort is it for Unity to maintain both solutions, vs reducing to a single solution?
2) Does maintaining the legacy feature provide a significant benefit to Unity users and Unity themselves?
3) What percentage of the user base is continuing to use the legacy feature?

We can look at two major legacy features which were dropped over the last few years as examples.

32 Bit editor support dropped
1) Undoubtedly this was a significant burden on Unity QA, as double the builds means double the automation runs, double the investigations, etc.
2) No benefit to Unity, but a large benefit to the small number of game developers who haven't purchased a computer in almost 2 decades
3) The user base was extremely small

UnityScript support dropped
1) Significant burden on Unity developers and QA to maintain both solutions
2) Moderate benefit to Unity in attracting web developers familiar with JS to Unity, significant benefit to those who know UnityScript but not C#
3) Single digit percentage user base

In both cases Unity was expending lots of resources to maintain the legacy features, and the user base was pretty small. When we look at MonoBehaviours 5 years from now I expect those answers to be the following (just my speculation)

1) Significant burden on Unity dev and QA to maintain both
2) Significant benefit to small projects who don't need the performance benefits of DOTS, much easier for new developers to understand, much easier for Unity to attract new developers to Unity having an easy to explain way of using the software
3) 50%+ of the user base using MonoBehaviours

If that is the case I'd expect MonoBehaviours to stay.

 

MB won't be deprecated anytime soon it's part of the DOTS authoring workflows. But the real question is how long can you keep making competitive games without using DOTS. DOTS raises the bar considerably over a pretty large surface area.

DOTS isn't like SRP in terms of how stable is it and when can you realistically use it in production. It's stabilized a lot faster for a bunch of reasons I won't detail here.

 

[QUOTE="snacktime, post: 5048684, member: 251810"[...] But the real question is how long can you keep making competitive games without using DOTS.[...][/QUOTE]

I'm not seeing that. The most popular genres seem to require very little processing power -- idle games, clash royale clones, match-3, hidden object, collectable heroes. Game of War is basically a browser game.

I remember when Unity's biggest criticism -- this was when it was making PC games and mobile wasn't so big -- was it could never make an AAA game -- designers needed to be able to modify the C++ backend for that. I see ECM and whatnot as trying to fix that. Unity's big thing was always that it could make any genre.

 

Are you positive those are still the most popular genres? A quick search for "most popular mobile game genres" is coming up with completely different results for me and they're very consistent results at that. PUBG mobile is supposedly the most popular mobile game right now.

https://www.thejakartapost.com/life...-mobile-game-earns-more-than-146-million.html

You could make the case that if we added up every game belonging to those genres that they are the most popular but just having a large number of games in a genre doesn't mean anything and right now the most popular games don't fit too many of those genres.

https://www.ranker.com/list/most-popular-mobile-games-today/ranker-games

 

Yeah I'm not sure everyone is up to speed on this.

My understanding is that originally Unity were looking to offer direct DOTS authoring stuff. But now the plan is that the MonoBehaviours, components, GameObjects etc that we are used to will remain the way to do authoring/editing in the editor, and conversion workflows will do the heavy lifting turning this stuff into the runtime data for DOTS.

So yes, in this important sense MonoBehaviours are not going to go away. And it will take time for them to vanish from most areas of runtime stuff too.

Lots of devilish detail, and might be easier to judge the state of the mission some more months down the line, when tools evolve a bit and the recently demonstrated improved conversion workflows & reduced boilerplate code will have been in our hands for a while.

If I change the opening question a bit, I find it easier to answer. eg if question becomes 'can I carry on for the next 4-5 years as if none of this DOTS stuff is happening?' then I would say in most cases its an easy 'no!', but perhaps still with some exceptions here and there.

 

I've only seen the one blog post about ECS, which has the same ending by a different route. Says the plan was always to have ECS run invisibly, behind the scenes. But to test it now, before it's done, you need to explicitly do X, Y, and Z.

"DOTS" also includes multi-threading. That can't be done automatically, but people have been trying that for quite a while. The net effect is that searches for "unity multithread" will give nicer results.

 

I dont really understand that. Yes conversion of gameobjects world to ECS world is supposed to be made easy, yes they are working to reduce the amount of boilerplate code. But ECS was never supposed to be invisible, since you need to be aware of data oriented design and make the right design and data decisions, and the scripting/programming required to use ECS at runtime is really different to the old ways.

 

As fas as I am aware, you can now just build using Monobehaviours and then convert to entities using conversion tools which I imagine would be the definitive go to way to do this. This will not get around the fact that the way you write code for the two techniques are completely different etc etc, but at least helps the "should I use MB or ECS" problem a lot of users have.

But the info has changed a lot since conception so again this could now not be the case (last I heard it still was though!)

 

An example from that blog post is how ECS physically groups gameObjects by which components they have, and attempts to(?) run Updates for each group. That seems as if it would be invisible to us (unless we set script execution order). Later it mentions you might flag certain scripts as using the Transform, but never changing it. The system could use that for parallelism. But seems even then you'd write your scripts the normal way, then add that on if you like.

It feels like that question will be "I'm using the regular/only system, do I also need to work on the new optimizations, or is it fast enough, I want to release now, and I can always add them later?"