Dedicated ECS editor?

Are there still plans to have a dedicated ECS editor, or is the Unity team going to stick to the convert to entities workflow? If so is it on the roadmap?

 

I think the conversion workflow is there to stick. it allows authoring in a familar maner to most users.
What they do have in the boxes is additionnal editor windows/view to reflect the DOTS perspective of things (list of components after conversion, list of system that affect each game object,...)

There is a forum thread that request feed back on that. If I find it again, I'll post it here.

Edit : https://forum.unity.com/threads/feedback-request-envisioning-new-ways-to-debug-in-dots.874096/

 

Dropped. It was already working in Project Tiny, then someone decided that the crappy and ancient GameObject system was a great base for editor workflows. I think they said that it might come back, but I highly doubt it; and if so, not anytime soon.

 

I also think that having a separate DOTS-editor would be the best way going forward. This way you can remove a lot of legacy dependencies and start fresh.

 

I'm pretty sure they just decided that re-creating logic already in the editor was not the best use of their time. I'm very happy with this direction and would rather see their resources spent on accelerating getting more of the engine into DOTS.

In the future we'll probably see more editor changes to support DOTS better, just like you're now seeing with the new systems window in the 0.7 DOTS Editor release.

 

You don't have to replace the logic in the editor, as it would behave the same, the only thing that would change would be DOTS/ECS instead of Monobehaviour for the game creator.

 

Ehh... its not that simple. Just grab an old version of Tiny and see for yourself what was the start of a dedicated DOTS editor.

 

I will buy a dedicated DOTS editor. I will not settle for this seemingly overly complex transitional hybrid state Unity is in now.

 

@Nyanpas it does feel like a dedicated DOTS editor might be the best, but the really important thing to remember is how tightly coupled existing workflows are to the current editor. As more and more subsystems get ported to be DOTS compatible it won't make sense having separate editors that now BOTH need to support these subsystems. I believe Unity is still a ways off in having everything DOTS compatible, but once we see the ECS API become verified my expectation would be that we'll see an increase of existing subsystems being ported over. We might even reach a point where the entire engine is running on top of DOTS and they rather provide a way to run the traditional MonoBehaviours from ECS.

I am speculating here, but to me, the big issue of having two editors where workflows need to be supported is going to be the big problem. The conversion workflow does have its faults, but I'm sure with some thought put into everything we should see a good editor that better supports what DOTS can achieve.

Having direct access to the data as it does incur its tax. From a designer perspective having a simpler interface with knobs and dials could be much more productive than having to mentally keep track of how the data relates to one another. It's the whole reason entire systems with nice UIs are built because most users aren't capable of reasoning about their data in table form and keep track of how everything needs to be changed for a seemingly simple change. If you go back to older engines like the DOOM engine it also employed a conversion process, because ultimately having a format that's easier to reason about when authoring your game enables better productivity for actually MAKING the game. Allowing the programmers to transform this data into something that follows a better format for how the program actually works is where the performance of your application can be tuned.

 

Can you elaborate on what problems you are seeing? Gameobjects are design-time only while runtime is entities, and over time the runtime parts will become pure ECS.

We will live in a hybrid state until Unity finishes rewriting enough of the engine to even support a full game. For example pathfinding, vfx graph, audio to name a few that still havent been released even in preview form.

 

Was just wondering this, so just looked it up. The Tiny editor looks great.
I am massively confused about the hybrid thing, as you don't know what components turn into in the code, or indeed which features are ignored or don't exist.
In pure code there's no nice way to assemble objects without pure code (what's the point of something like Unity if we have to do things in pure code?).

Also will entities show up in the heirarchy? They can be coloured differently.

Why can't we drag drop systems on to entities in the inspector like normal? Surely ForEaching through every entity to find a component match is more annoying and inefficient than just telling the system what systems to use on that entity (the system could still internall work the same on all matching entities). It could auto add required components.

People keep on insisting that ECS is great, easy and intuitive and OOP is stupid, dead and messy, but right now I feel the exact opposite. I've been using Unity for 10 years and I literally can't get anything more than a moving box without hours of looking stuff up, to just find not much. I'll just wait it out for something to change.

 

The ECS api is just still in an unstable state. The problem is, there are many bits that actually work just fine, and it's quite hard to figure out where. The only way to keep up with the pace of change is to read this forum on a daily basis, or have a community run wiki somewhere.

 

Fair enough. I assume they want to stablise the API before trying to keep an editor up to date all the time.