When, if ever, are Pure ECS/Dots editor tools coming?

In the pinned thread titled "New SubScene & ConvertToEntity workflows" It seems to be mentioned that tools for working for pure ECS, e.g. not the convert workflow, would be coming and the last comment expressing this i could find said 'soon' but that was back in late April. Is there any news or updates on the current state of the tools? The convert workflow, at least for me, seems like a round about way of doing things so a set of dedicated tools would be nice.

 

You can get an idea of what they're considering looking at the latest project tiny: https://forum.unity.com/threads/project-tiny-c-preview-0-15-3-available.688969/

 

"Soon" in terms of any development, may mean anything from months to years.
In terms of Unity releases time frames, that probably at least few releases ahead. Which considering each release per 3 months on average, that gives quite a bit of time ...

 

So if I'm reading correctly if I install project tiny I can use the dots tools for normal development or only Project Tiny based projects? If so that'd be perfect for now and if not guess I'm working on my own to use until Unity's soon rolls around.

 

It is just for Project Tiny at the moment. The direct DOTS editor doesn't have the tooling yet to scale to larger games. GameObjectConversion scales surprisingly well. Actually I prefer it in some sense because it keeps my authoring representation separate from my runtime data, and I personally find it easier to customize the inspector fields using a MonoBehaviour than a custom editor script. The lack of playmode iteration can be a little annoying, but there are workarounds if you know what you are doing.

 

I haven't tried to Project Tiny DOTS editor yet so excuse me if this is a dumb question but are you saying that the dot's editor doesn't allow you to edit your component data without a custom editor script? Or just not while the game is running?

 

DOTs doesn't have same editor tooling as Project Tiny. Yes, DOTs, is much more raw in terms of editor. Project Tiny probably could say, is more exploring way for the editor, with this new paradigm. When that will be solid, will be transferred as well to DOTs. Or something like that.

 

GameObjectConversion limitation. Tiny DOTS has different issues which are bigger show-stoppers for me. Tiny DOTS doesn't have prefabs (though you can kinda fake them), and the inspectors for components and buffers expose the runtime data directly which makes for a rather awkward authoring workflow. I know Unity is working on tools to address those issues, and likely when those tools reach a state Unity feels comfortable sharing, that's when we will likely see the Tiny DOTS editor become the not-Tiny DOTS editor too.

 

Tiny's DOTS editor is called DOTS Mode, it's not Tiny Mode and according the staff comments, it will eventually work for all DOTS related things.

Do note that you CAN use some of the full ECS packages in current DOTS editor but since most are currently designed to be used with the conversion workflow, that's not going to help much. Nor is the fact that you can't use hybrid renderer or 3D cameras on DOTS Mode atm.

 

Any ETA when will it be possible to serialize scenes for 32 bit os? Requirement support for Arm-v7 devices prevents us from using the SceneConversion workflow in production.

 

@Joachim_Ante
Please tell me that Entities is not going to be released until there's a stable pure entity editor. The plan for leaving preview is 2020.1, right?

 

Well, what I mean here is a two-way link between the authoring GameObject and the entity. e.g. The entity's transform is updated and that change is reflected in the authoring GameObject's transform. Also, for that, the entity not being destroyed if its subscene is opened for editing in play mode.

 

Will the normal Unity Editor api still be used for creating custom editors with full access to C#? We have an extensive suite of custom editors here spanning years of work, and I cant see us being able to make a switch to dots someday unless we can still do everything our current editors do (besides game related stuff like dialogs and quests we also use services like Amazon Polly to auto create placeholder VO, etc). Im using the editors to create c# files, so im hoping the editors can roughly stay the same but write appropriate dots files instead.

If we can still use the old EditorGuiLayout stuff Ill be thrilled since I could probably just change our save/load code and reuse the editors as is.

 

In the Tiny talk from Unite 2019, they mention they are changing Project Tiny to use the conversion workflow in their next release.. so I guess "DOTS mode" editor has been cancelled and they are going full steam towards the conversion pipeline.

 

@Joachim_Ante
Are there any plans on improving editor tools for directly manipulate entities? Two things I dream about are:
1. Better entity inspector. Right now when you select entity in editor all its values are read-only in the inspector, would be very helpful to be able to tweak data in the inspector, and also to be able to add/remove entity components
2. Single entity serialization. Are there plans to have serialized entity-prefab-files?

 

I think this is fairly easy to achieve. I'm doing it with Odin right now as standalone tooling in addition to the Entity Debugger. It supports querying entities, adding/removing/setting componentData, creating/destroying entities on the fly, and multiple Worlds. With Odin, it's very straightforward to implement.

Direct Entity Debugger support will ofc still be nice.

 

IMHO the problem with conversion workflow is that entities data is a mirror of authoring game objects, but that is a one-way mirror, you can't convert back from entity to a game object. For example, if I created an entity with code, or want to use the current runtime entity state later, there is no way to save it as a prefab file.

What I imagine is a way to serialize selected in the inspector entity to the file and later on to be able to load it to the world. Together with non-read-only entity inspector, this will create pure entities authoring with the following workflow:
- you define your data components with code
- you construct and configure an entity with entity inspector
- save configured entity to file (or a subset of entities)
- load entity from file
- ...
- profit

 

1. transparency: to configure an entity you edit entity data directly - no hidden logic with proxy objects involved
2. live modification: you change something - you see the result instantly, without the need to go through conversion after each change
3. consistency: the same approach for both runtime and authoring time manipulations - you can tweak not only the initial state but the current state as well, and you can write current state to file (for example if you have an in-game level editor you can save levels the right same way you do during authoring time)

 

conceptually this is very similar to presets, you can write state data to file and load that state whenever you need

 

can be done now

just add authoring attribute so Unity create monobeh for it and you can configure with inspector

save sub scene (use like netity prefab of just scene)

load subscene and may be instantiate entity prefab from it.

I think I'm one step closer to understand entities authoring in future Unity
One thing from everyday work is modify entity state in runtime for debugging purposes (including add/delete components because tags make a magic) and copy found runtime state back to authoring.

 

@Jes28 I know how to use subscenes and conversion workflow, it is a great approach to migrate existing scenes to ECS...

but I'm talking about a workflow that does not use MonoBehaviours at all

 

I think currently authoring a super big subscene like megacity it's still super lag. I guess the super big subscene also needs dots performance authoring. Long time ago you mention about dedicated entity authoring. Any plan to continue the development of the dedicated entity authoring after Game Object with Monobehavior authoring near to solid state?

 

Possibility to transform and optimize data from human-friendly to computer-friendly is a very good reason to go conversion way, and i'm 100% agree that this is necessary for great performance in some cases, as well as it is necessary to migrate existing projects.

But I don't see any reason why direct data manipulation workflow can't coexist with the conversion workflow. In many cases, there is no need for any data optimization or transformation and data can be used as-is, so why not to allow defining it directly?

And the ability to tweak game state data at runtime is a very important thing for productivity IMHO.

Data flow from authoring to runtime for sure vital thing, but the ability to bring data back from runtime to authoring is important as well I think.

 

When you say there wont be a world anymore ... What does this mean for existing software / frameworks built in the pre dots era? Our company makes educational games that goes into schools and has years of code already set up for this. Outside of the file size for webgl, we dont really gain anything from dots since we cant make anything pushing performance anyway. So having the option to switch is great ... but being forced to would be worrisome.

Should we be expecting this to stop working in the foreseeable future of unity? Meaning, as I add to the existing code base to allow it to handle additional types of games, am I writing for something whose forceful deprecation is already planned? I'll note that I can easily see this code base continuing to push out games for at least another ten years if not more (it has nothing to do with visuals so it can flow with the SRP changes, and stuff like that), so even five years from now would require us to start thinking about it ... soon.

Thanks! (Sorry if this has been answered else where, feel free to just tell me that ... only asking because of the forcefulness of that statement )

 

It means monobehaviour is here to stay. Looking forward to .net 5.0

Personally, my sim will all be dots. But gui, networking, animation, particles and sound will all be .net

Honestly, I have no idea what the future of physx will be. I bet monobehaviour physics will become a wrapper for dots physics by 2021-2022.

 

Ya. I need tweaks that are not persisted on components at runtime. I really want the feature that in play mode, I can see all the runtime data at Hierarchy after conversion from authoring and I can select the runtime entity that I want to inspect its components directly and tweak the value of components at Inspector. Currently at Entity Debugger, it's quite hard to understand which runtime entity correspond to which authored game object and the name of authored game object does not carry over to runtime entity. Entity Debugger also not allow you to tweak the value of components. With runtime entity selected, there is a button at the Inspector that can directly open the original authoring game object. Another nice to have feature is able to move around entity and changing its position component value just like moving around game object and changing its position of transform.

 

And please show my given entity name to converted subscene entities in the Entity Debugger.
I give every entity a proper name but see hundreds of Entity XXX, that's so boring and chaotic.
I know strings and component data are not compatible, but you could keep a name map somewhere on the subscene file just for the editor.

 

This is something I appreciate, I have been doing this for mobile for a while, since 2010, where I massage the scene into something completely different via the build preprocessor.. I can be as destructive as I want with the build scene because it doesn't affect editor scene. It's the perfect place for me to optimise, make new meshes, strip redundant stuff.. I do this for so many years because it saves the artists a lot of pain, they don't need to have all that interfere with the creative processes.

I quoted Joe's post just because I wanted to add my real world use case for others to read. DOTS workflow only makes it much much easier for me, I can likely remove my own work because Unity is doing a much better job than I am at it for the future.

 

Sorry, I know I'm reviving an old thread here, but I have to say this is disappointing to read. One of the things I was most excited for with DOTS was the ability to never have to touch a MB again. I know they will need to be supported for legacy reasons, but I had hoped and assumed that new projects going forward could stay well away from them.

I don't mean to be rude, but MBs are horrible. The early design decisions that we're stuck with today are not appropriate for a modern engine. I'm particularly thinking of the magic name / messaging thing, and the serialisation mess. The MB development practices contradict good C# practices. As somebody who cares about writing good C#, I actively hate writing MBs. They make me feel anxious and dirty.

I completely understand and support the decision to have the authoring representation be separate from the runtime representation, but had hoped and expected that that would eventually be a new type that doesn't inherit all of the problems of MBs. I thought DOTS was the fresh start we needed and that these MB conversions were only a temporary stopgap.

Is is still the case today that you're planning to build everything on top of MBs and that all of these old design issues will continue on?

Sorry this sounds so negative! I'm very excited about DOTS generally, I just have some very strong feelings about MBs.

 

@SamOld you can use DOTS already, without touching Monebehaviour, and write a game.

So far you can rapid prototype using GameObejcts and Monobehaviour. Then convert to pure ECS, if you feel.
That is why, one does not collide with other, but they can be complementary.

 

@Antypodish Oh I know that, I am. But as I understand this thread, MBs are going to continue to power the authoring tools. Have I got that wrong?

 

That is optional. Moreover, it is built on existing utility, so why not use it and let Unity focus on some more important stuff, regarding DOTS. IF time will come, they could switch, if needed. Probably not sooner than halve decade (being very optimistic)? . But nice to have such utility never the less.

But question would be, why you are concerned about it?
Is not that you are forced, or something to use that utility.
What are your expectation and project needs?

 

Unity is choosing to use MBs as an authoring solution because they believe it is a good enough solution (and certainly better than no solution) and are instead focusing development efforts on improving the runtime and adding features. Once Unity gets the runtime near feature-parity with the classical approach, they may start looking at replacing the authoring mechanism.

However, most of the issues with MBs only affect the runtime and are a lot less problematic in the editor. I used to always get frustrated because I wanted to write my editor tools using MBs because it required much less code to do simple things due to OnValidate and the attributes. I tried not to because it made it difficult to decipher what was authoring and what was runtime. Now I have what I wanted.

Good C# practices contradict good game development practices. Good C# practices are founded on stability, correctness, and reducing development time because employees are more expensive than servers, so performance is sacrificed. Game development cares about performance, so good C# practices need to be sacrificed. That doesn't mean that Unity can't be more consistent with naming conventions and things, but ultimately comes down to using the right tool for the job.

So let me ask you this: What problems have you encountered using MBs for authoring that makes you think they are not a good tool for the job of authoring?

 

Perhaps I'm fundamentally misunderstanding something, because I don't see them as optional. While it's technically possible to do everything from code, building things up in the editor is a standard part of the process for most games.

My understanding is that this means our scenes will continue to be stored using the existing serialisation mechanisms. I had hoped that this moment of change was Unity's opportunity to put those legacy things in the past and put more robust solutions in place. We have a cool new way of storing data now, let's use it.

That's more like what I always thought the plan was. I'm okay with that. I thought that the implication of this thread was that MBs continue to be the long term plan.

I don't agree with you about C# practices. Obviously OOP is not well suited for a lot of things, but that doesn't mean that correctness and maintainability concerns are invalid. From what I've seen so far, DOTS C# is going in the right direction.

MBs are implemented with a lot of reflection weirdness that makes them behave unlike you would expect of C#. In an attempt to make things easy for inexperienced programmers, they make things weird and difficult for experienced programmers. If I write MBs using my standard C# practices, they will often break because of the serialisation.

Another obvious example of MB weirdness is the messaging system. Accessibility is broken, and there's a time bomb bug baked into every MB, because given infinite time, somebody will eventually send a message that happens to match one of your method names. I know that may not come up a lot practically, but if you're trying to write code that could potentially sit alongside other code that you don't control, it's just unfixable. This isn't a necessary evil from games having different requirements, it's just a bad design. If they needed to do it this way for some reason, they could have at least required a

[Message]

attribute on the receiving method to manage the risks.

I understand why all of these things are the way they are for historical reasons, I had just hoped and assumed that now would be the moment we could put them behind us. My primary concern is not specific problems, it's choosing to build the future on an unstable foundation and missing out on this opportunity to make these changes during this moment of upheaval.

I believe that Unity made a (completely understandable) mistake when they originally designed the C# experience in the hacky scripting form. They're fixing that now, but I worry that we're seeing a similar mistake where they're taping the new onto the old rather than building wholly new. We've had lots of things that can't be fixed for backwards compatibility reasons, and it feels like this is the introduction of the next decade's things we wish we could change but can't.

I feel that I should apologise again for being negative. What Unity are doing with DOTS is fantastic and I don't want to appear negative overall, I just have concerns because I care. Unity seem to be making very good design decisions these days, so I'm hoping that they have a plan that renders my concerns moot. That's why reading this thread surprised me.

 

As far as I know MB are not going anywhere. The messaging has been very clear that the conversion workflow is here to stay. They put years of work into editors and prefabs and gameobjects, now they are choosing to leverage them for authoring so they can focus on performance at runtime.

Are people out there making gratuitous use of SendMessage? SendMessage is truly absurdly slow, in my opinion no one should be using it for anything ever so I agree with you on that much at least. I guess I don't really see it being used that much in the wild, I think it's pretty well known as this point it's just not a good idea. As far as I know Unity has pruned most of it's usage internally as well, the only time I ever see it come up is from OnValidate related stuff which is editor only anyways.

I'm 100% with you on the serialization woes though. Still no support for generics and somehow it took them 15 years to let us serialize a basic reference type with inheritance...and even still it's incredibly limited. But I suppose that's getting off topic.

 

- Any time you rename or move an MB, the game objects of a scene lose their reference to them. For large projects, this is nightmare to fix. Thus it makes it really hard and costly to refactor and iterate on your code.
- Searching MB components in scenes is horrible and very limiting. This affects the readability of your scene data.

Because of these issues I have been completely avoiding the MB conversation workflow in favor of authoring my game via code. And also I believe that authoring via an editor is great for prototyping, but horrible for large scale games. I come from a background of building complex web apps, and in the web development industry all complex web projects are build via code (using frameworks such as React.js) while simple websites can be built with editor authoring tools such as WordPress and Squarespace. You wouldn't want to build a complex web app using WordPress. So in the same light, authoring a complex game via the editor with MB authoring tools is like building complex web app with WordPress. It's hell.

Personally, I would love to see Unity put more focus on building DOTS editor tools that are used during play mode, such as allowing us to tweak entity data via the editor for prototyping and debugging purposes. In this thread, @SubPixelPerfect asked whether there will be support for it a few months ago:

But sad to see @Joachim_Ante response on there being no plans for that. I feel like allowing us to edit entity data via the entity inspector would be a low effort implementation with a lot of value.

 

I recently renamed an MB and was surprised that unity hadn't lost the references. I Think the key is first rename the class, and afterwards rename the filename in Unity.

 

Renaming a MB class never lead to the loss of references, simply because when MBs are to game objects they are referenced by asset GUID (which is in the .meta file). So you can rename, move an MB class however you like w/o anything being broken. I think Vacummus probably meant something else?

I agree that MBs are a mess. In a ECS-focused project I tend to treat MBs simply as a means to interface with the engine. And as an authoring tool. Having any kind of game logic directly within MB classes (instead of regular C# classes that are composited inside MBs) was always a bad idea even before ECS came out. Outside of learning the basics and prototyping of course.

I wish Unity would at least remove the long deprecated stuff from MonoBehaviour class like "renderer" and stuff like that. It's still annoying when the name of your local variables collides with a field that was deprecated like 6+ years ago, but still not removed?! Also stuff like SendMessage, and StartCoroutine with a string arguments needs to go.

Removing legacy crap that has no valid use case, confuses beginners and annoys experienced developers is a way to go IMHO.

 

I thinks that MB (may be stripped down to basics) is good for authoring, but mostly for save load authoring scenes and editor tools not for actual logic code only editor code.

So everything inside editor will always run on ECS and be fast, and thus authoring components will be mostly copy of IComponentData ones.

I think it will be good to have IComponentStoreMB than can be puted onto GameObject and store IComponentData array and just traverse it on conversion. Additionaly it can show all ICompomemt data on converted object in runtime and allow to modify it in runtime.

When we want different data layout on on authoring component we just want to create custom AuthoringMB and on ISerializationCallback deserialize it right into IComponentData componentn in array inside IComponentStoreMB.

So comversion must be done right on loading now on saving subscene.

 

I guess he renames the classes in VS including the file name, which of course Unity doesn't like.