#What is the vision of the desired end goal for ECS?

1 messages · Page 1 of 1 (latest)

slow rock
#

I have been wondering about this since ECS was announced some years ago. The messaging around has been a bit all over the place.
So I was wondering what is the long term vision for what Unity hopes/wants ECS to be and how it is used?

At first it sounded like a replacement (long term) for GOs, which I thought would be cool. But now it sounds more like just something you would use sometimes and only if you need it lots of things.

I know the plan is/was to have a lot of DOTS specific packages (Cinemachine, Animation, Audio, Physics, etc.), Which while makes sense, seems like some sort of nightmare if you have the GO version of those packages as well.
And how it almost sounds like the plan is to do some of those and some clunky 'bridges' between the two?

To me it feels like as it is now (use it sometimes if you need it), ECS could lead to a mess of multiple versions of the 'same' package in a project which have different APIs, and poor editor tooling and you are constantly jumping from ECS to GO and back.

So, this brings me back around to the question. What is the long term hope for ECS?

worldly sphinx
#

hi @slow rock , our vision for DOTS is to enable creators to build ambitious games with Unity. In the context of immediate focus, we’re building more capabilities (tools and workflows) to support ambitious games exemplified multiplayer, open world and cross platform genres.

As part of this vision, we are delivering many benefits to our users, including streamlined ECS workflows, built with GameObject compatibility. This means users can work across ECS and GameObjects seamlessly, only converting the systems they need to ECS, while retaining their existing expertise/tools with GameObjects.

To that end, users should not need to worry about having to support ECS or GameObjects since they should ultimately be a single cohesive workflow for users to scale up their experiences where required. Where possible we do want to make systems compatible with both ECS and GameObjects out of the box, while preserving to some degree, the familiarity of the authoring experience in Unity. An example of this is SRP.

slow rock
# worldly sphinx hi <@131292153300123648> , our vision for DOTS is to enable creators to build am...

Hey Nicolas, thanks for the answer. So to clarify, the end goal is to be able to easily switch from using GOs to ECS when needed without much change in workflow or surrounding code structure?

With the current setup this seems hard to believe as there are already large intentional differences in workflow. A simple example of this is that with ECS you can switch the editor to 'data' mode (or whatever it was called) while in playmode to see and make changes to the data that persist. This is a very significant and welcome change to iteration workflows imo, but it is not available for GOs.
Not to say it should or shouldn't be, simply pointing out how there are already large differences between an editor with DOTS and one without.
Is the plan to some how make the line between GO and DOTS softer?

worldly sphinx
#

yes, the idea is to slowly integrate both GO and ECS workflow to make them a single cohesive workflow and use each one as required

slow rock
winter forge
worldly sphinx
#

Not necessarily, it's mostly about our focus. Our plans for the next year is to consolidate ECS workflows, enable cross-play multiplayer game creation and enable open-world game creation.

velvet cradle
#

or surrounding code structure?
This part is definitely not the case. If you wrote your game code using Entities, there will be no automatic switch that would allow this to work with GameObjects. Just in case you got this impression, I wanted to clarify.