DOTS would be better as a separate editor

Unity Engine
, ,
1

I understand that saying this will have little to no impact, but I guess I just want to share my thoughts.

I would vastly prefer DOTS to be a standalone DOTS only editor, than to be shoe horned in to the current editor.
DOTS already requires custom handling for Input, UI, and graphics, and custom implementations of multiplayer, audio, animation, physics, and Visual Scripting*. Along with this, things like Cinemachine will be completely rewritten to have a DOTS specific version.
To me, this seems like a massive nightmare in the making trying to manage packages. Even if a bunch of it is imported automatically for you, all the MonoBehavior specific implementations are still just there for a lot of it, cluttering the APIs. And that is combined with all of the current legacy-ish features already in Unity.

As a separate editor, backwards compatibility wouldn’t be an issue, and only the new systems could be included. Only SRPs for rendering, with any entities specific things just baked in, UIToolkit for UI, the new input system for input, all the DOTS specific packages for their own things (animation, physics, audio etc.)

This would provide a cleaner and more straight forward environment, without all of the old systems, or having to look at feature comparison charts to decide on what system to use. And without having to do some sort of GameObject conversion thing.
Some of the systems may not be fully at feature parody yet with what they are replacing (like UIToolkit), but given how long DOTS is taking I think that is okay, most if not all of them will be by the time DOTS is production ready. And this would help push those other packages and systems further.

I also fear with the current approach that some of the current packages will start to have DOTS specific things and MonoBehavior specific things, making the APIs more convoluted.

So this is my plea in to the void for DOTS to be a separate editor. Thanks for taking the time to read. If anyone has any other thoughts on this subject I would be interested in reading them!

17 Likes
2

That would instantly kill any interoperability between Entities and MonoBehaviours. Cut off all Entities project from 10+ years of Unity development and a ton of working code and assets.
You don’t have to have clean ECS code for everything in an average project, many times you can have a bunch of things in the traditional GameObject world. Separating ECS into a separate editor without the current features would instantly cut the throat of all of those opportunities.

In my opinion, it is a big no-no. It should never ever happen.

6 Likes
3

The prolem I see is that hybrid projects are a bit of an intermediary/temporary solution that exist specifically in this era where DOTS is only half-done. And it could be argued that it’s not worth it to cripple the entire future of the tech just for the sake of offering long term support for this workflow that only a few present-day projects are using

If you want to preserve support for most existing assets/libraries, you’ll almost definitely just be cut off from most of the best aspects of DOTS forever. So either way it seems to me like the sooner we make our peace with abandoning them, the better

I’d at least say that the entities package could remain available in gameobject projects as it is right now, but Unity should have some kind of “dots mode” where all this stuff disappears

10 Likes
4

I highly recommend disabling a bunch of built-in packages from the package manager. This reduces the exposed types and API quite a bit.

1 Like
5

I will never understand the urge to deprive other people of choices just because you find some choices useless for yourself. It’s kind of a strange and brutalist stance in life.

2 Likes
6

In this case the reason is to provide a more stable, cleaner, and straight forward experience. Choices can be good, but they can also be just as bad. I know at least I am not arguing that choices are bad or I don’t see the usefulness of them in this case.
I just believe that benefits of the clear separation between the two systems are worth any potential downsides.
Entities and MonoBehaviours for all intents and purposes do the same thing, sure both do somethings more efficiently than the other, but they solve the same base problem.
The impression I always got from when they first announced Entities is that it was a replacement/evolution of the GameObject and MonoBehavior system. And that is how I have always viewed it.
They didn’t add the conversion workflow until about a year after Entities was announced.

If you look at the actual amount of systems that both DOTS and MonoBehaviour can both use, it is a comparatively small list.
And if DOTS was it’s own editor it could also be more tightly integrated in.

4 Likes
7

I’m assuming you’re working on a hybrid project, and perhaps from your perspective things are working fine

But from the perspective people working on full DOTS projects, many of us are noticing that the current workflows simply won’t cut it as a long-term, accessible solution that the entire community could use. Things are confusing and clunky, and we can see how the attempts at making both GOs & Entities work at the same time could be to blame for this.

Right now the DOTS editor workflow is a minefield that only power users can navigate through. It’s a real problem that needs a solution. It’s nearly impossible to imagine a real future for DOTS if this doesn’t change

13 Likes
8

Well, there is Project Tiny but that’s basically useless from what I know. Should’ve could’ve been the DOTS editor from scratch.

Of course I would wish a Unity DOTS Editor exist but that would also mean starting at basically zero for most things. Not even SRP could exist in a strictly DOTS editor. Same goes for the new input system, audio, editor itself, etc…

@PhilSA What’s your current gripe with the workflow? I’m not having much trouble with it except from the bug with references that should work, but don’t when using GenerateAuthoringComponent and referencing a GameObject in Entity.

2 Likes
9

Its possible to work with both MonoBehaviour and Entities in the same project just fine.
I’ve done it multiple times already, and its great.

Reason for that - you can re-create only systems you need, and receive major performance boost without much of a time loss. Otherwise, re-creating whole projects would be an insane timeloss. Which makes no sense at all.

Hybrid approach is pretty good as long as you’re willing to build systems on your own, and not rely on hybrid renderer, or Transforms systems.

But at the same time, I don’t use conversion at all, so my experience may vary. With custom authoring tools (e.g. authoring from MonoBehaviours / ScriptableObjects directly) its quite nice though. No subscene / conversion headache. Data arranged exactly how its designed.

As for the new projects and completely blank environment - it would be a real challenge.
With risks as high as moving to the different engine. Not to mention lack of assets, and requirements to rebuild everything.

4 Likes
10

Yes: my entire menu system (main menu, pause menu, etc) is in UGUI (game objects) as well as the overhead camera and all my audio.

Which wouldn’t be possible without the hybrid approach. And frankly, my project wouldn’t be better as pure ECS project. (and currently it would be impossible too, lack of UI, proper audio and camera)

1 Like
11

To be clear, we are talking about the future, not DOTS in its current state. Sure right now it wouldn’t make sense to be a separate editor because it lacks features.
But in the future everything that is possible with MonoBehaviour would be (and should be) possible with DOTS. In this case, UI Toolkit would be used for UI.
This is Unity’s plan anyway, to add DOTS audio, and DOTS camera, an DOTS animation, etc. In the future you will have no need to do a hybrid project because both DOTS and MonoBehaviour would be capable of doing the same thing.

2 Likes
12

Yes, but again, you would break my project (alongside of many more), just because you don’t like a bunch of menu points being there and a handful of APIs hanging in the autocomplete in your code editor.

Again: you always have the option to ignore the entire game object world if they remain in the same editor, I won’t have the option to choose game objects for some things if they are separated. Hence you would be making things worse.

3 Likes
13

It’s also worth noting that not every problem should be (attempted to be) solved with ECS, as Joachim said here .
In the end, you just want the editor to provide you with the option to make the best possible solutions for your problems, which does not seem possible by separating the contexts.

3 Likes
14

It is too early to tell.

ECS/DOTS is not a silver bullet. There are some great efficiency bonuses that come from it. OOP code is still more flexible to develop with. Especially with serialization in the Editor. Until I studied ECS this hard, I had taken OOP for granted to some extent. By studying ECS so much for the Unity Engine, I now have a new-found respect for OOP… ECS requires a lot of rigidity to get that efficiency.

ECS is not, in my opinion, a great stand-alone option for building a game right now in the Unity Engine. Unity has too many other strengths and tools they offer, that work outside DOTS and ECS. ECS is still in an experimental stage, and as this thread has pointed out so far, the waters are still muddled as to how much of the engine experience they want to wrap around ECS.

ECS DOES, however, provide a GREAT support option for leveraging maximal hardware efficiency, when a problem arises that needs it. If you see ECS as your saving grace, to solve all your problems… it will never be good enough… If you see ECS as a very powerful support tool, to be leveraged at the correct time when necessary… You will find it a useful tool in your Unity developer toolbox.

We will have to see what they do moving forward, of course. But it already feels like they are working towards preserving the basic workflows of the Unity Editor, while finding a more elaborate way to provide ECS efficiency by default somehow. Or, at least, through a much more streamlined process, that doesn’t require diving into DOTS documentation and theory to implement it ;P…

And if this is the case, a stand-alone ECS Editor may end up being irrelevant.

15

A DOTS-focused editor workflow doesn’t mean throwing away OOP. You can do OOP in managed components. It’s similar to monobehaviours, except it allows you to not split your data representation into 2 different unrelated systems; everything lives on Entities and everything is coherent.

So the goal would not be to force ECS on everything; instead it would be to have a workflow where you can’t do things that don’t work. The workflow for creating entities must guide you and educate you. It must not let you put a monobehaviour on whatever authoring tool is used for authoring Entities. It must not let you place a non-conversion GameObject in a dots scene. If anything, that doesn’t necessarily mean GameObjects must be thrown out, but it means the Entities authoring tool should probably be a separate thing from the GameObjects authoring tool

I’m looking at this problem from the perspective of a Unity newcomer that would start a new project after DOTS 1.0 was released. If it’s still using the GameObjects-based editor we have now, they’d wonder:

  • Why are there 2 different components for rigidbodies?
  • Why are there all kinds of components that just don’t do anything & disappear into the void at runtime (like the “Animator” component, or almost all Monobehaviours in my project)?
  • What is this “tags” dropdown and this “static” checkbox at the top of the inspector, which don’t seem to have any effect at all in entities?
  • Why do some GameObjects only work in “Scenes”, while others only work in “Subscenes”?
  • Why is it that I can assign a GameObject as a camera target to a Cinemachine camera in the inspector, but my GameObjects aren’t even supposed to still exist at runtime?
  • Etc…

All these problems & learning obstacles go away the second you have a clear-cut separation between GameObject scenes/tooling and Entity scenes/tooling

11 Likes
16

You said that much better than I could!
The SRP like fragmentation is something that I am really worried about. Along with learning resources being confusing in the future.

Even if they don’t make it a separate editor, at least having some sort of ‘switch/toggle’ between DOTS and GameObject when you create a project is needed imo. (Which in the end would mostly make it a separate editor.)
If/When DOTS gets more common I can see problems starting to arise on the AssetStore, trying to figure out which assets/tools support your workflow (DOTS vs GameObject). It will be like SRP, but worse.

17

Well, people love to complain and apparently don’t like to make choices. I never understood the SRP hysteria either. It is very easy to choose based on what you’re doing. But of course, you need to know what you’re doing at the first place.

4 Likes
18

As an amateur developper I would have also prefer using dots exclusively if I’m using it at all. It makes more sense to stick to one deisgn workflow to keep things simple (especially when they are complicated enough trying to learn DOTS), and a single purpose editor for DOTS would be great.

But realisticly speaking, since they already chose to make the integration of DOTS with Unity monobehaviour, it’s hard to see them backtrack that decision and make a seperate editor altogether after they spent so much time working on the current workflow that admitedly needs a lot of work still.

19

I agree to an extent, some people do complain about more than I think is actually realistic. However I do feel that the problem is three fold.

  1. You have the problem for AssetStore developers having to either support multiple pipelines or picking one. Both of which have downsides.
  2. Neither HDRP or URP are A. Feature complete, or B. Good for mid level graphics(which is changing), which a lot of games target imo. So choosing which to use is made more difficult than it otherwise should be.
  3. Learning resources are made for one SRP which may not work in the other SRP, so again either the resource needs to be made for both, or pick one. (I mean both official and unofficial learning resources)

Both 1. and 3. and potential problems that DOTS will face too.

1 Like
20

Agree with 1

But for 3 it can be different:
If Unity make DOTS to be backend of GameObjects that you will have only one system to work with. Where GameObjects will be high level Polymorphic OOP style to do game and pure Entities will be just low level engine part that rule all this.

So if you want to go low level to get best perfomance possible than you go deeper otherwise stick to old good GameObjects. Either way you will actually work with entites.