Feedback DOTS Editor "Systems" window suggestion: System Tags

Hi,

Not sure if something similar already exists or has been suggested yet, but I'd like to suggest a new feature for DOTS Editor's Systems window: The ability to assign "tags" to systems we create, and a menu in the Systems window for selecting which systems tags are visible. Once projects reach dozens/hundreds of different systems in play, I feel like this would be very useful.

Spoiler: Example use cases

• If I make a bunch of systems in my game for handling enemies, I could assign them the "Gameplay" and "Enemies" tags. Similarly, if I have an ItemPickupSystem, I would give it the "Gameplay" and "Items" tags. Then, I can decide what I want to show in the Systems window:
  • just the "Enemy" systems
  • just the "Gameplay" systems
  • all "Gameplay" systems but excluding the "Enemies" systems
  • all systems except the "Gameplay" systems
  • systems that have either "Enemies" or "Items" tags
  • systems that absolutely have both the "Items" and "Enemies" tags at the same time (assuming there is such a thing in the project, like an EnemyLootDrop system)
  • etc....
• Some system tags should be autogenerated. For example, all systems should automatically be assigned a tag corresponding to their assembly name. That would mean that if I make an asset store package named SuperTool, all of the SuperTool systems would automatically have a "SuperTool" tag (or a "SuperTool.Samples" tag). This gives users a quick way to understand all of what my package does in the update loop. This would also work for Unity's own packages, so we'd have a way to do filtering with Unity.Physics systems, core Unity.Entities systems. HybridRenderer systems, etc....

• The various debug systems (like the ones in Unity.Physics) would come pre-packaged with the "Debug" tag, and if we want to not see any of the debug systems, we just disable the "Debug" tag in the Systems window. Or if we want to hide specifically the physics debug systems, we ask the Systems window to hide all systems that have both the "Unity.Physics" AND "Debug" tags

• Let's say you are starting out on an existing project and you want to figure out how input is handled: you go in the Systems window, show exclusively the systems that have the "Input" tag, and now it becomes easy to study how it is handled. Since input would be handled both by DOTS's eventual official input system and our own systems, we would also have a way of differentiating the "Input" systems that have the "Unity.Input" tag from the ones that have the "MyProjectAssemblyName" tag

Spoiler: Example usage in code

Code (CSharp):

1.  
2. public struct GameplaySystemTag : ISystemTag
3. {}
4. public struct EnemiesSystemTag : ISystemTag
5. {}
6. public struct ItemsSystemTag : ISystemTag
7. {}
8.  
9. [SystemTag(GameplaySystemTag )]
10. [SystemTag(EnemiesSystemTag)]
11. [UpdateBefore(typeof(BuildPhysicsSystem))]
12. public class OneOfMyEnemiesSystems : SystemBase
13. {
14. }
15.  
16. [SystemTag(GameplaySystemTag )]
17. [SystemTag(ItemsSystemTag )]
18. public class ItemPickupSystem : SystemBase
19. {
20. }
21.  

Spoiler: Usage in the Systems window

In the Systems window, there would be a little panel where you can have precise control on which tags are shown or hidden. Defining a system visibility query could work similarly to EntityQueries: you define "All", "Any" and "None" tag lists, and only the systems that fit that query are shown in the window

Some extra features:

• Being able to save system visibility queries for re-use later would be great. Especially if they are saved in some kind of favorites bar with a name assigned to them, and you can quickly apply them just by clicking on them
• Systems shown in the Systems window could even be highlighted in different colors based on their SystemTag. There could be an editor window that lets you assign colors to tags in the project, with the ability to clear all
• Once you have selected which tags should be visible, you could also tick a "Show Dependencies" box, which would also show the systems who play a role in the update order of the the systems that you want to display, even if they don't fit the tag requirements. Perhaps these systems could be highlighted in a different color
• Perhaps we could be given the option to completely hide the systems that don't fit our tag requirements, or have them simply grayed out
• It would be great to be able to combine those tag filters with component read/write access filters. For example: if I would like to show systems that are part of the "Enemies" tag, and also have write access to the "Translation" component and read access to the "PhysicsVelocity" component. I feel like this could be of great help when debugging. If something mistakenly moves your entity and you don't know where to start looking; you can narrow it down to systems that have Translation write access and start enabling/disabling systems in the Systems window until the culprit is found!
  • This means SystemTags could just be part of a larger system for filtering what's visible. Our system visibility query could end up looking a bit like this:
    • All: HasTag(Gameplay), HasWriteAccess(Translation), HasReadAccess(PhysicsVelocity)
    • Any: HasTag(Enemies), HasTag(Items)
    • None: HasTag(Debug), IsEditorOnly

 

Sounds Great

 

Indeed. Seems pretty usefull. As projects grow and get "convoluted" a way of filtering is important. Especially the AssetStore / 3rd party aspect seems helpful.
But I would prefer if tags are not just strings. Some help of the compiler (deny misspelled tags) and autocomplete (suggest existing ones) is essential IMO. I would prefer an Enum instead of strings. Or even create a new Type for each tag (from an interface?). Thoughts?
And I think there should be a way to differentiate between entity tags (empty components which control behavior) and system tags (descriptive) to prevent confusion.

 

My suggestion would've been having a class that holds all of your tags as public const strings, but this doesn't prevent people from directly using strings...

So declaring tags as let's say a struct implementing the ISystemTag interface would be a great solution I think. It could maybe allow us to declare extra info about the tag via interface functions, if we can find uses for it, like a IsHiddenByDefault() or a GetDefaultHighlightedColor() maybe

I'll update the first post with this approach