Monobehaviour (Mono) is the old pre DOTS API, that was the way to use the Unity original game engine. It allowed component/objects to be combined into game objects and for those objects to respond to events that the engine/API generated.
As Unity moves to a more package based setup could we see Mono becoming a package that is none-essential to Unity games e.g. a game could be completely DOTS based and not need Mono.
PROS: Reduced code size and build times for non-Mono projects. Possible complexity reduction with the engine/editor providing services for both APIs without being entangled in one or the other.
CONS: Completely separate game engine API systems that would require twice the development and support from Unity (although Unity are already doing this).
Or could separating the game engine from the API improve Unity, divide and conquer or would it increase the complexity of the engine?
What are you on about? There’s like 5 people that are using DOTS for anything real. MonoBehaviour is going to stay the main way of creating games in Unity until DOTS is ready for general use, which is, idk, at least a few years away.
Nah. You can perfectly fine write 1980’s C code that allocates objects (ie. what C refers to as objects) at random on the heap. It’s always been possible to write code like that, and a lot of people have, but I don’t think it’s ever been the standard?
The thing is Mono and Unity come with some baggage, aspects of the systems and sub-systems that are known performance hot spots e.g. Trees, Invoke and other deeper sub-systems that you will find only when you hit a performance problem and deep profile.
And you will probably only find these hot spots when your trying to push the envelope of what Unity can do specifically for your game.
With a fully modular DOTS/Mono set of packaged systems you could in theory replace sub optimal standard (Mono) systems for your games with more performant ones.
In an ideal world then you could have your game running it’s 80% of Mono for most things and 20% DOTS for the most performant needed elements.
I don’t see MonoBehaviour ever going away. DOTS, ECS, Jobs, etc, shine in large scale projects with requirements that exceed the capabilities of main thread bound MonoBehaviours, but those projects are the exception rather than the rule for Unity projects. The vast majority of Unity projects are perfectly fine using MonoBehaviours, and you’ll see them remain the dominant way of utilizing Unity for the foreseeable future, even after DOTS is finished.
The problem is, that MB are tied too deep into UnityEngine to just be “externalized” in a package. ECS comes with C# source code and thus can be easily made a package. But the whole engine works around monobehaviors since the beginning. If you “rip them out” what is left? Also the Monobehaviors are mainly in native (C++) code of Unity. So it is not this easy to make them independant from the engine and it would require much effort/time. And the use for this is also not clear to me (what do you expect from this move?). Your Pros are a little slim for this effort IMO.
If MB are too slow for you just don’t use them. But many things have no replacement in pure ECS yet (Animation?, Sound, Cameras, Particles) so you probably NEED to use MB at one point or the other. And this situation will probably remain for some years. So what is the point of ripping MB out when almost every user has to import them back in. I think this will give a huge shitstorm and that development time is spent better elsewhere.
I wonder if it would make more sense to built a pure ECS engine from the ground up. But that would take even longer than how it looks its taking now.
I think Joachim said somewhere that ECS is not usefull/meaningfull in every context and that it’s not a tool that can do everything in GameDev. There are still usecases where MB is advantageous or even required.
And this move would alienate a large part of the users who use Unity because the ease of use part. ECS is a good paradigm but future has to show first if it can be used for any type of game. And there need to be some “patterns” established of how certain mechanics can be implemented in ECS. Until there is a broader understanding of that, the acceptance will be low and thus any effort to “force” ECS onto users will backfire.
So don’t “waste” your time speculating about this. Just try to “win” ECS.
That used to be the case but look at how many things are now packages rendering, physics, input, 2D, addressables, AR, Burst, Cinemachine, Editor Coroutines, Mathematics, Editor Tools, Scriptable Build Pipeline, UI, FX.
What does MB have that is not in a package, and could MB be improved as a modular set of packages?
MB would be just a default set of packages that you start with and use with the option of adding and removing them.
Longer term I think it will be a case of adapt or die for MB, there will come a time if it does not divide and conquer it’s own complexity that it will become a large bloated heavy and slow legacy that Unity will carry around a bit before depreciation begins.
Look at Tiny it started out as a Scripted ECS system in it’s own right and very quickly managed to do very effective 2D games. Then it was rolled into DOTS and restarted. So now it’s an example of a DOTS only* WebGL game engine within Unity.
*Not sure how much code from the Unity game engine is used but a Tiny build is way smaller than a Unity WebGL build of the same content.
I think over the next few years the 80/20 rule works out as:
80% of projects include exactly zero DOTS related content, instead exclusively MonoBehaviour
20% of projects include DOTS - 80% of those projects still use MonoBehaviours for the majority of the project, while 20% use DOTS extensively across the entire project
I think the Unity programming landscape is more complex we have:
Monobehaviour (MB)
Burst
Mathermatics
Jobs/Multithreading
DOTS
So you can start with MB and profile your game for performance issues then apply more advanced optimisations or even start higher up the Optimisation pyramid e.g. Burst/Mathematics.
Side Note: What if packages came in versions/flavours e.g.
Vanilla basic version minimal optimisation Monobehviour style.
Burst enabled.
Mathermatics enabled.
Jobs/Multhithreaded.
Full DOTS subsystems.
In theory you could have versions of the packages that provide optimisation/compatibility levels the trade off would probably be in internal complexity and code size.