DOTS is awesome, but what will happen to Monobehaviours?

Are they going to get deprecated? There's so much talk from Unity about DOTS, but this is all work in progress. All the documentation is still in monobehaviours. This makes me feel like even for a brand new project, with the latest (non-beta/preview version) of Unity, I'm already writing deprecated code which will need to be re-written for DOTS. Is this true? If Unity could shed some light on it, it would be great.

 

Nothing is happening to monobehaviours, and this is a fact. You can code your games as you have always done.

Feel free to ask any more questions but it's a regular question

 

Wow that's a relief! Thanks Is there any statement from Unity about this?

 

Yup, staff repeat it often in the DOTS forum. Probably on blog too if you want to poke about

There's no real fanfare announcement because... nothing changed! Actually told a lie... I think they plan to improve the monobehaviour performance a bit here and there as they do.

TLDR: mono is in ALL of the hundreds of thousands of Unity projects in the wilds. I don't even think it's quite possible to make the game you want without mono just yet.

But best of all, you can use Jobs, and part of DOTS if you want. You don't need to be all or nothing. You can go... well this bit with 1000 small critters attacking the player is slow, so lets convert just this bit to DOTS, and that's OK, and boom problem solved.

So it's a tool you can use as little of or as much as you want, and I think that's pretty amazing.

 

^this

And even if something on that matter would changed, anyone can stay on older version of Unity, if can not adapt to evolution. Is not that it will stop working there.

 

Cool thanks @hippocoder !
and @Antypodish

 

Dont worry, a ton of us would kick up a storm if monobehaviours was going If that ever is the long term plan, unity are well aware that it would have to be a very very very gradual switchover, and even then as mentioned above by others you can always use an older version of unity

 

Why? There's nothing special about them, and quite a bit of uh... stuff that could be updated.

I agree that a simple way to attach a plain old custom class to a GameObject with ways to hook into the update loop and game events is important. I'm not sentimental towards the current MonoBehaviour class because it's just a tool to do a job, and I can easily imagine it being replaced with a different, better tool.

 

Since I'm a person who love to constantly learn and try new things, for a long time I couldn't imagine that there are people who really doesn't want to learn, who always have the "just keep the existing one, it's working" attitude.
Over the years I learned that such people exist, moreover there are the majority.

So if you change anything for them, they will grab the pitchforks and torches very quickly.

 

Oh yeah, I totally get why random internet people would whinge about any change in general. I was deliberately challenging that as a default position.

 

Why? Because some of us have spent a (literal) decade building up a codebase based on Monobehavior and the traditional Unity way of doing things. Some of us don't need the performance improvements that ECS brings because we already know how to optimize our game to suit our needs.
And lastly, some of us simply don't like the ECS style of coding and prefer Monobehavior.

 

No for me its nothing to do with that, its because at work we have major client projects worth millions of £ that are built on monobehaviour and updating them all will require us to literally hire a ton of staff, yet we also have clients that would love to leverage the newer unity features, so if monobehaviours are removed it would make my life at work infinitely harder. Many others would be in the same situation in the professional sphere.

If theres a good justifiable reason to remove it that can be shown to have enough benefits to warrant removal of monobehaviours, then I will be first to be rooting for it. So far I havent seen a reason for them to be removed that makes sense, its not like having them stops you using ECS if thats what you want to use.

But as I also said in the above comment, its simple to stay on the current version of unity, hence why you dont really see me moaning on the subject anywhere

Its great that you want to learn new things, and I like learning new things too, but that doesnt mean others should lose a tool that is useful to them - not when it literally has 0 impact on your ability to continue to use the newer systems.

I dont see why we cant have a world where mono and ECS live together, and tbh based on latest developments on ECS over last 6 months it seems unity agree as they have doubled down on the conversion workflow showing they probably wont remove monobehaviours for a very long time.

 

Personally I had already moved away from MonoBehaviours before Unity's ECS was a thing. MonoBehaviours will probably stick around for a long time to come though. Unity's popularity is partly attributed, at least I think, to its simplicity in getting something working for the first time. People come in not even knowing C# and get something moving via MonoBehaviours. This is good but obviously it sucks for professional studios I guess.

Unity3D ECS, in the iterations I've seen, will never been for those people who come to Unity for the first time with nearly no knowledge of programming or C#. Admittedly the newer ECS API just shown at 2019 Unite does look easier to consume but it's not going to be something those people can make use of.

If they removed MonoBehaviours they'd remove an entire section of their customerbase and probably discourage anyone new from touching Unity3D because they will not really be able to make sense of the ECS approach and API.

 

This is literally what the ECS based visual scripting thing is meant to solve.

 

While MB's won't be taken away I think their plan is very much new users will start with DOTS. It doesn't really make sense any other way. Certain things have to be in place but once they are I think new users won't even be aware of the old way without digging around, DOTS will be presented as this is how it works.

They have made it very clear that DOTS/SRP is replacing what we have now. And they seem rather intent on making that happen asap.

 

Sounds miserable. "Oh, you want to move some cubes up? Sorry, you'll need to know lambdas/delegates, generics, understand fluent style APIs and more!" There are beginner programmers who use Unity3D, and will continue to come to use it for the first time, who deserve a reasonable and simple API for them to start developing games with. ECS is NOT that and never will be and Visual Scripting should never be pointed to as a replacement for software development.

Source: https://github.com/Unity-Technologies/EntityComponentSystemSamples/blob/master/ECSSamples/Assets/HelloCube/1b. ForEachWithEntityChanges/MovementSystem_ForEachWithEntityChanges.cs

 

I never said it was a replacement. If you're new to development, visual scripting is a great choice. If you aren't new to development, DOTS becomes easier to use every update.

The idea that ECS will never be that, especially when the last Unite had a whole thing about how there's a massive focus on removing boilerplate code and things like this, is pretty ridiculous and assumes ECS is just done.

 

How exactly is visual scripting a great choice for starting? Seems the best way to learn about writing software is to write software, not play with designer tools which will be incredibly unproductive for real projects solo. That's what visual scripting is, a tool for larger teams that have dedicated designers and developers who expose composition/complex nodes for more functionality or established patterns.

I don't think Unity Technologies is making Visual Scripting and ECS for the typical solo developer. They know the customer base they currently lack are those of larger teams and console developers, and AAA studios. Those who need the performance that DOD yields. Who needs a 1st party system that allows developers and designers to work together for content creation AKA extendable visual scripting that won't compromise on the performance either. It's what Unreal has had over Unity for awhile and no, it's not because Jimmy the newbie could pick up Unreal and hackily make something. It's about real studios imo.

I continue to watch the large churn and changes of Unity ECS yes, they improved abit. But I don't watch it with hawk-eyes because I already use my own ECS, for my own reasons and needs that are unrelated to DOD/performance. To me, unless they're going to pull a C# 5 and actually implement the complexities at the language/compiler level, just as MS did with async/await, and generate the tedious/boilerplate MSIL required I'm doubtful it's going to reach the point where the API is easy for most to consume.

 

This thread sounds like MB is being removed tomorrow, with no good alternative.
Definitely should stay with machine code. In the end, there are people with decades of experience in it. Non need for MB, or DOTS.

 

Okay, I think there are many misunderstandings here. And I think I wasn't that clear I should have been. I have no problem having MonoBehaviours, I don't really use them unless I have no other option, but whatever.
For me it more like about that we do not have null-conditional operator on unity objects for example, because Unity does not have the balls to step up and break the backwards compatibility at major version changes.
Because "a ton of you would kick up a storm if...".

Again, my comment wasn't about the MonoBehaviour reality. It was about the "what would happen". And you started it with your imaginary storm-kicking .

That would be fun. I always liked those times when we wrote Turbo Pascal and we put assembly inlays in it.

 

In all honesty the fault is with me because I was rushing to leave work at the time so didnt actually read your post properly, now that I have its pretty clear what you meant

Forgive me senpai!

 

Clearly you've not taken the time to watch any of the videos showing off Unity DOTS VS. Before you start discussing it you need to completely abandon everything you know about the current visual scripting systems. DOTS VS is visual and it is node-based but that's where the similarities end. It's not just another clone of Blueprint.

I have been programming as a hobby and now as a profession for more than two decades, and I'm excited for DOTS VS.

 

Technically GameObejcts and attaching MB script as components, is like visual scripting.
We drop object into scene, we set position drag drop materials, etc. Do a bit of scripting and thing got moving.

 

I mean, sure, if you really squint and turn out the lights and also only use things that were already written.

 

The scenario I'm rooting for is that, once DOTS is stable and mature, they will tackle a new OOP API, less dependant on C++, pluggable as a package, and that will be used to right many wrongs of the past.

I know it's unlikely but hey, daydreaming is free

 

Why? ECS is a dramatic improvement in the context of a game engine over traditional OOP.

 

Because ECS is not a silver bullet, and they said they still need a design time representation of ECS data. If I'm making 10 thousand boids, I'm if course gonna look at ECS. But why would I want to ECS my player controller, for example? There still is a place for more traditional, straightforward way to get stuff done. I honestly just would like to see some modernization on the API. they've carried too much dirt over the years

 

Every indication from them is that they are trying to make it into a silver bullet, and that you will want to use it for more than just the low hanging fruit.

Check the Unite Copenhagen roadmap. Very early on they show ECS data being displayed and manipulated in the Inspector.

 

Why is it that every time an ECS thread comes up, there's loads of people talking about ECS like it hasn't changed at all since like 0.0.1 or whatever and never will change?

 

It doesn't really work like that. Why you would want your player controller in DOTS is because it uses other DOTS features like physics, animation, and pathfinding.

It's all tied together mixing and matching has some serious downsides actually. In our game our player controller is one of the few things that is not DOTS yet. And it forces us to maintain duplicate colliders for example, a Physx collider and a Unity.Physics collider. Dots terrain isn't out yet, so we have a Unity.Physics terrain collider in addition to a Physx one.

And that's just one example, a hybrid system has a lot of little things like that which increase complexity and make things more difficult. It's definitely a case of it works better if you go all one way or another. In between is a pain. Right now hybrid is necessary a lot of time as it just takes one major feature that is not DOTS or job system friendly to cascade out into other areas.

I think a lot of people who talk negatively about DOTS haven't actually used it much. The upsides to using it are substantial and most of the arguments you see against it are rather hand wavy and vague. Which just cements my opinion that they come from a point of no actual experience with it.

 

I've spent over a decade using and writing code with and for MonoBehaviour, too. I'd still welcome an improved system. There's no fundamental reason a compatibility layer (or other approach) couldn't be provided to support existing code moving forward.

When it comes to writing new code, I'd be all for an updated system which, for instance, doesn't rely on magically named methods and does support some modern programming practices that couldn't be supported back in 2005.

My question wasn't about moving to any specific replacement solution, it was about people wanting to stick with an existing, flawed solution despite the potential for improvements.

It's 2019, and basically every Unity programmer is relying on a class designed back in 2005, based on circumstances and technical limitations of the time. How much longer do we want to carry that forward?

Please note that MonoBehaviour doesn't stop us from getting the job done, and I'm not claiming that it does. What I am saying is that it could be improved significantly in ways that would benefit many developers, rather than having those developers implement their own solutions on top of it.

Edit: To clarify, I'm not advocating for MonoBehaviour to be ripped out tomorrow, or necessarily ever. I'm just saying that it's not a perfect system and there's room for improvement, and if Unity decided that the best way to do that was to replace it then I'd be all for it.

I haven't used DOTS to know if anything there is a good replacement, but I've long been an advocate for data-oriented design and am glad Unity is embracing that at a core level, regardless of whether that ends up taking over MonoBehaviour's current role or not. Any which way, I also agree that something needs to be in place which fills MonoBehaviour's current role - but it's the role I care about, not the implementation.

 

That's not really how it works, though. As Unity explained when they removed support for UnityScript, maintaining stuff has a behind-the-scenes cost which may not be apparent to us as users but can still have an impact on us. It takes developer time to keep something tested and working as other things change around it, and it can place constraints on other systems which could impact their design or implementation.

 

So I've been reading through the documentation on DOTS. Sounds like it would take ten minutes to write a MonoBehaviour system in DOTS. So even if MonoBehaviour gets deprecated (which seems super unlikely), you can still run MonoBehavious.

I get that having to write your own compatibility layer would suck. But it doesn't seem super difficult or time consuming. Heck, it wouldn't surprise me if Unity itself retools the engine internally so that MonoBehaviours run on an invisible DOTS system.

Correct me if I'm wrong, but I don't see anything fundamentally incompatible between the two systems.

 

Unity team works on DOTS, or more toward data oriented design at least since Unity 5.
First visible results were Jobs.

There were some discussion while ago, indicating that Unity will aim progressively but slowly, convert internals toward data oriented paradigm. As result we see already performance improvements and even multithreading supports in many cases. That even without touching DOTS by us game developers. Hence it isn't any new concept.

So as already mentioned, MB probably will stay (at least for a long while), even it will mean, it will be top layer above whole DOTSified internals.

 

I was looking into DOTS and have implemented a few systems but keep getting bogged down in fairly basic things like implementing a decent sprite rendering system and tilemaps. There are user projects for sprite rendering in DOTS but how is this thing realistically taking over any time soon when all of these basic systems are missing? Maybe it has changed since the last time I played with it a month or two ago but did not seem usable to an average joe like me.

 

If you don't roll your own, then not "soon".

They are working on a lot of things, but they cannot work on everything at once. They chose to cater the 3D connected-type games first, just because those are the ones which can benefit the most out of the DOTS. And networking and physics and stuff.

If you want to play around with your own (or other users' shared) 2D systems, feel free to sink in, but if you have deadlines and/or you don't want to develop a lot of things for your 2D game, then I think you're better off developing your game with the "old ways" and roll some DOTS if and when needed.

 

Yeah I decided to scrap my ambitions of using it for anything graphical and just stick to using the ECS for gameplay logic. Writing systems to process components on npc's/player is great, but I don't want to get into anything involving rendering, was just too awkward for me.