Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

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

Discussion in 'Data Oriented Technology Stack' started by thedrok_, Jun 27, 2019.

  1. thedrok_

    thedrok_

    Joined:
    Apr 24, 2017
    Posts:
    14
    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.
     
    phobos2077 likes this.
  2. Ferazel

    Ferazel

    Joined:
    Apr 18, 2010
    Posts:
    443
  3. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    7,365
    "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 ...
     
  4. thedrok_

    thedrok_

    Joined:
    Apr 24, 2017
    Posts:
    14
    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.
     
    foxnne likes this.
  5. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    1,661
    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.
     
    phobos2077 likes this.
  6. thedrok_

    thedrok_

    Joined:
    Apr 24, 2017
    Posts:
    14
    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?
     
  7. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    7,365
    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.
     
  8. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    1,661
    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.
     
    phobos2077 likes this.
  9. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    1,735
    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.
     
  10. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,084
    Our focus is on making the GameObject -> Entity conversion workflow production ready.

    We will do a lot with visualizing converted state, warnings / error overlays in inspector, live conversion, asset database caching, player live connect over the next half year.
     
  11. alexnown

    alexnown

    Joined:
    Oct 25, 2018
    Posts:
    21
    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.
     
    ZhavShaw and psuong like this.
  12. Ramobo

    Ramobo

    Joined:
    Dec 26, 2018
    Posts:
    166
    @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?
     
  13. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,084
    Our editing tools are game objects with a conversion pipeline. We are heavily investing into integrating all that deep into the editor, with visualization, picking, live link etc. As well as a lot of work to reduce boilerplate from the conversion workflow.

    The authoring scene format for DOTS remains the same game object based scenes we have today. If you are judging it based on what is there today, what we are talking about is a very different workflow.
     
    Zoey_O likes this.
  14. Ramobo

    Ramobo

    Joined:
    Dec 26, 2018
    Posts:
    166
    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.
     
  15. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,084
    Both of those things are planned. The second one is how it works in the next release.
     
    Ramobo likes this.
  16. DGordon

    DGordon

    Joined:
    Dec 8, 2013
    Posts:
    465
    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.
     
    Last edited: Oct 10, 2019
  17. siggigg

    siggigg

    Joined:
    Apr 11, 2018
    Posts:
    247
    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.
     
  18. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,084
    thats accurate.

    Inspectors or any editor code is thus pretty much entirely unaffected by anything DOTS related. The same is true for the MonoBehaviours that are used as the authoring representation. Commonly you would use the MonoBehaviour representation that was used as the runtime representation in the existing Unity, as the authoring representation for DOTS. This makes it so you wouldn't even have to change any prefabs / scene data...
     
  19. SubPixelPerfect

    SubPixelPerfect

    Joined:
    Oct 14, 2015
    Posts:
    224
    @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?
     
    phobos2077, Vacummus, Cynicat and 2 others like this.
  20. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,084
    There are no plans for that. Our authoring format is game objects and it already supports add / remove component.

    Being able to do tweaks that are not persisted on components could make sense.
     
  21. Creepgin

    Creepgin

    Joined:
    Dec 14, 2010
    Posts:
    370
    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.
     
    phobos2077 likes this.
  22. SubPixelPerfect

    SubPixelPerfect

    Joined:
    Oct 14, 2015
    Posts:
    224
    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
     
    JoNax97, Cynicat, Jes28 and 2 others like this.
  23. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,084
    i don't understand why that is useful?
     
  24. SubPixelPerfect

    SubPixelPerfect

    Joined:
    Oct 14, 2015
    Posts:
    224
    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)
     
  25. SubPixelPerfect

    SubPixelPerfect

    Joined:
    Oct 14, 2015
    Posts:
    224
    conceptually this is very similar to presets, you can write state data to file and load that state whenever you need
     
  26. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    621
    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.
     
    phobos2077 likes this.
  27. SubPixelPerfect

    SubPixelPerfect

    Joined:
    Oct 14, 2015
    Posts:
    224
    @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
     
  28. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,084
    What we are doing is building a live conversion workflow.

    The concept of directly editing the runtime data itself, independent of what tech is used for it, is in fact exactly the problem we are trying to solve. The concept of runtime data and editing data being the same is simply a bad idea. It took me 14 years to figure that out (Sorry it took so long...)

    But tying the data so closely together prevents us from making independent choices based on whats good for performance and whats good for authoring data. These are totally different optimisation axes. Eg. At edit time you always want a hierarchy. At runtime for example if objects are marked static, you definately dont, you just want everything baked out...

    There is not going to be a world anymore where unity will have the same data at runtime as it has at edit time. Better get used to it. We will do everything to make this transformation live, visible and with zero boiler plate entry points graduating to advanced data transformations when you need to optimise your data at conversion time.
     
  29. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    591
    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?

     
    Last edited: Oct 12, 2019
  30. SubPixelPerfect

    SubPixelPerfect

    Joined:
    Oct 14, 2015
    Posts:
    224
    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.
     
  31. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,084
    Yes, I am not claiming that we are done. Our goal is that you can edit a megacity sized level with 200k game objects and it can live convert and live link to the player at 30 FPS. I am quite confident that we can do this on top of game object based conversion and that we can likely hit that around end of year'ish.
     
  32. DGordon

    DGordon

    Joined:
    Dec 8, 2013
    Posts:
    465
    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 :))
     
    Last edited: Oct 13, 2019
  33. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    122
    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.
     
    Last edited: Oct 13, 2019
  34. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    591
    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.
     
    Last edited: Oct 13, 2019
    phobos2077 likes this.
  35. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,084
    Sorry I didn't actually mean to there won't be a world anymore. I am sometimes stuck in the new paradigms we are working with.

    What I meant is that for DOTS and any code/data/features depending on it, everything always goes through an authoring representation, converted to entity data.

    For game object / monobehaviour workflows nothing at all will change. In line with what we have said before, MonoBehaviours & GameObjects are here to stay. It would be unimaginable that we would really change anything significant there, since it would break almost every unity project...
     
    phobos2077, vadersb_ru, Jes28 and 2 others like this.
  36. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    5,084
    Yes so i agree. Being able to tweak runtime values is useful. I'll bring it back to the editor team.

    They are not going to affect the authoring state and will not be persisted. If the authoring state changes later on, they will be overwritten as well.
     
  37. rsodre

    rsodre

    Joined:
    May 9, 2012
    Posts:
    217
    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.
     
    phobos2077 and Jes28 like this.
  38. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,726
    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.
     
    phobos2077 likes this.
  39. SamOld

    SamOld

    Joined:
    Aug 17, 2018
    Posts:
    220
    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.
     
    lclemens, phobos2077, Jes28 and 2 others like this.
  40. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    7,365
    @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.
     
  41. SamOld

    SamOld

    Joined:
    Aug 17, 2018
    Posts:
    220
    @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?
     
    phobos2077 likes this.
  42. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    7,365
    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?
     
  43. DreamingImLatios

    DreamingImLatios

    Joined:
    Jun 3, 2017
    Posts:
    1,661
    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?
     
    phobos2077 likes this.
  44. SamOld

    SamOld

    Joined:
    Aug 17, 2018
    Posts:
    220
    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.
     
  45. Sarkahn

    Sarkahn

    Joined:
    Jan 9, 2013
    Posts:
    277
    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.
     
    phobos2077 likes this.
  46. Vacummus

    Vacummus

    Joined:
    Dec 18, 2013
    Posts:
    136
    - 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.
     
  47. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    251
    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.
     
  48. phobos2077

    phobos2077

    Joined:
    Feb 10, 2018
    Posts:
    224
    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.
     
    Last edited: Feb 21, 2020
    SamOld and Vacummus like this.
  49. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    621
    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.
     
  50. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    251
    I guess he renames the classes in VS including the file name, which of course Unity doesn't like.
     
unityunity