Requirement based conversion workflow

Hello,

I love the fact that unity work on simplicity of use to avoid us writting boillerplate code for every components.

I however don't like the fact that I have to add indivual authoring component to a game object and have to have the knowladeg of what component are requiered for the entity to behave a certain way. It's ok for a developper but as a disigner, I would be confused.

So I came up with the following workflow :
- Fore each data type I have an authoring component (the result of the [GenerateAuthoringComponent] intriduced at unite) (for instance Health or Attack)
- Then for each system, I create a custom authoring component with the necessary [RequireComponent()] with the authoring composent type that represent the IComponentData used by the system.
- Then I could have even higer level authoring component that reference the "system" authoring components in the [RequireComponent()]

If you are interested, please check it out an dleave your comments and feed back here.

https://github.com/WAYNGROUP/AutoringWorkflowDemo

ConversionWorkflowWithGeneratedAuthoring
Pros

  • Great granularity
  • Not duplicate components

Cons

  • Data component don't provide any hint to the underlying systems

ConversionWorkflowWithCustomAuthoring
Pros

  • Custom authoring components give hint to the underlying systems and what can be expected in term of behaviour

Cons

  • Require lots of additional coding.
  • Introduce the possibility to have duplicate data components.

ConversionWorkflowWithRequireAuthoring
Pros

  • Custom authoring components give hint to the underlying systems and what can be expected in term of behaviour
  • Very little coding required (just the system itself and a simple monobehaviour)
  • The Require attribute take care of avoiding duplicate component data

Cons

  • Add additional components to the game object
  • Can be hard to clean up gameobject as inspector don't remove unnecessary data component when removing the Custom authoring ones.

Solution to Cons:

  • Open the Windows > AuthoringComponentInspector :

  • this will provide a list of all data component with editable properties (synch with the classic inspector)

  • The AuthoringComponentInspector has a button to synchronize the authoring components of the game object with this inspector. It take into account newly added data component, removing the non required data component from the game object itself and add missing one if and existing custom authoring component was updated.

  • The sync can be made automatic within the Project Settings > Authoring Component Inspector Settings > Automatically sychronize data component

  • To clean the classic inspector, you can HideInInspector the generated data components using the toggle in Project Settings > Authoring Component Inspector Settings > Hide/Show data component in the inspector

Updated the demo to allow the autosync feature to be controled through project settings

The sync can be made automatic, just edit the script Editor > AuthoringComponentInspector to set autoSync = true.
The sync can be made automatic within the Project Settings > Authoring Component Inspector Settings > Automaticaly sychronize data component

Also added a setting to hide/show data components :

  • To clean the calssic inspector, you can HideInInspector the generated data components using the toggle in Project Settings > Authoring Component Inspector Settings > Hide/Show data component in the inspector

Updated the github repository.

Loads of refactoring
Added a base class RequirementBasedAuthoringComponent with a custom inspector to display the required component data.
Made any update to a field also update otehr field targeting the same data component on hte game object so wherever you edit the data values, they are always synched in the GUIs.


Don't mind the exception at the end of the video. It's most likely due to how I handle the damage in this demo, I did not use a buffer but just an entity to convey the damage information so it does not support multiple damage per target.
I'll fix it in a later udapte.

1 Like

Extracted the functionality to a git hosted unity pacakge.
You can now import it through the package manager using this git URL :
https://github.com/WAYNGROUP/UnityPackage-RequirementBasedAuthoringWorkflow.git

The demo repository has been updated to reference this package.

Upcoming changes will include :
- proper namesapce for all scripts
- refactoring to allow easy suport of additionnal data types like bool or lists for buffered elements.

https://github.com/WAYNGROUP/AutoringWorkflowDemo/pull/1


@twobob Thanks you for your contribution, the pull request is merged. I also took the oportunity to edit the initial post with your cointribution.

1 Like

Great. Might I also request you update the repo description at some point.
From: "A repository to demonstrate how the require authoring conversion workflow word "
To: "A repository to demonstrate how the Require authoring conversion workflow works "

Enjoy your day


Done.

1 Like

Added partial support for List. for now, editing value of hte list elements are not applied.

New issue found :
- The workflow is not compatible with the prefabs, when editing data Unity does not register them as variants, so they are not applied by the conversion workflow.
- Still need to expend coverage to other types like Color and stuff.

Updated the packaged version.

Move away from Visual element to go "back" to IMGUI.
Used Serialized Object and Properties to get support for all data types (list, color, objects, primitives, ...)

Need to figure out how to support object multi edit, if possible.

Added support for auto generated authoring component with [GenerateAuthoringComponent]