Clean up [AddComponent] and [CreateAssetMenu] usage

[jeffcampbellmakesgames]

Summary

Making it easier for users to find and add the appropriate component or create the appropriate ScriptableObject derived unity-atom asset can make this library much easier for new users. There is some consistency with the context menu creation for SO assets, but I think some reorganization could help there as well. There is a bit more cleanup to do in order to get these AddComponent menus more organized.

As of the latest on canary, these seem to be mostly organized around the type they revolve around versus the type of thing they are. This can lead to making these menus less navigable for a user if there is growth of atoms revolving around a particular type.

For example, everything dealing with an GameObject value is organized for the context menu into a single scope including actions, events, variables, lists, etc... Right now as far as I can see there is only a single GameObject action of type GetUnusedGameObject, but presumably this list could grow to be very large as the number of actions/events revolving around GameObject(s) is subject to a lot of growth.

For both SO asset creation and AddComponent menus, I believe a more helpful structure would be to organize these into the type of thing they are versus what they revolve around or use. Instead of a structure looking like this:

• Unity Atoms
  • Int
  • Vector3
  • GameObject
    • Variable
    • Event
    • List
    • GameObjectAction1
    • GameObjectAction2
    • GameObjectAction3
    • ...

you would have something that looked like this:

• Unity Atoms
  • Variable
    • Int
    • Vector3
    • GameObject
  • List
  • Event
  • Conditional
  • Action
    • GameObject
      • GameObjectAction1
      • GameObjectAction2
      • GameObjectAction3

This is also more in-line with the UX for other popular game development tools like Bolt or PlayMaker and can lead to a more consistent development experience and quicker onboarding for new users.

Making these changes would not result in any breaking API changes for end-users as these affect the Unity Editor UX only and would be a general UX improvement with little downsides.

[AdamRamberg]

The library was actually in the beginning following the pattern that you propose. After having tried both approaches I actually believe that you are right, it makes more sense to group on its function rather than on what type it is.

When doing this change the folder structure in the project should resemble the UI changes. That said, this becomes a pretty large change. I think this is something we definitely should do, but think we should wait a little before doing it.

[mbryne]

+1 for organising by Type of thing rather than underlying data type,

So Unity Atoms > Variable > Int / Vector3 etc

[AdamRamberg]

Implemented in b33b2b8 and in 0e896f1.