[RESEARCH] Investigate Blueprints and determine best course of action

[jeffcampbellmakesgames]

Is your feature request related to a problem? Please describe.

Blueprints are a feature intended to make it easier to configure Entities in the Unity Editor much like you would a prefab, but are currently too problematic for a variety of reasons to include with the main library of EntitasRedux. There is value in being able to configure Entities in the Unity Editor directly without code or with a minimum of configuration/decoration.

Describe the solution you'd like

Ideally, for a user they would be able to add some sort of component for an Entity of a given context to a GameObject and add/remove/modify components at will. When playing, using this component on an object should automatically create the Entity and add the user-configured components.

Implementation Tasks

Blueprint Entity

• [x] A MonoBehaviour component should be code-generated per context that enables adding or removing components specific to that context.
• [x] A ScriptableObject should be code-generated per context that enables adding or removing components specific to that context.
• [x] A custom inspector should be created to enable adding and removing components specific to that context
• [x] Documentation should be added to the Wiki for using this version of blueprints

[jeffcampbellmakesgames]

Thinking about this more while working on a side project, I'd also like to be able to scaffold systems grouped into a Featureby way of a code attribute and code generation. This would be allow me to easily define several Feature, nest them as appropriate under a Systems in a minimal bootstrap class, and then as those Featuregrew I would no longer need to manually update the bootstrap class unless a new top-level Feature is added

[jeffcampbellmakesgames]

Couple of reference links for better polymorphism support for POCO types in Unity 2019.3 and later

• https://docs.unity3d.com/2019.3/Documentation/ScriptReference/SerializeReference.html
• https://forum.unity.com/threads/serializereference-attribute.678868/
• https://medium.com/@trepala.aleksander/serializereference-in-unity-b4ee10274f48

[jeffcampbellmakesgames]

[SerializeReference] does seem to work well for polymorphic types where the common implementing type is IComponent. To easily enable inspector support for blueprints in the editor, I'm likely going to be refactoring some of the inspector/drawer code into the core EntitasRedux.Editor assembly so that multiple modules (visual debugging, blueprints) can both have access to that functionality without directly relying on each other. Since this is all editor code, this should not have any impact on runtime functionality.

[jeffcampbellmakesgames]

I may want to limit the amount of inspectable/addable types on a blueprint to only those that Unity can serialize as there is inspector support for some types that aren't supported for native serialization by the Unity Editor (looking at you Dictionary<T, TV>).

[jeffcampbellmakesgames]

Making some progress on this; each context now gets their own Monobehaviour-derived blueprint class which using a single inspector can show a list of IComponent and I have some WIP code enabling popup selection of serializable components specific to that context for adding to that list.

Couple of notes for later:

• Components need to be unique in a blueprint's list; each entity has capacity for one of each component that context can provide.
• Component entries already present in a blueprint's collection should not be allowed to be added. At the inspector level this can be controlled by disabling the Add button.
• All of the example content component's that can be serialized natively by Unity should be marked as [Serializable] to illustrate this feature.
• It might also be nice if a blueprint could be defined as a ScriptableObject as this would enable a developer to store blueprints more like asset configs that could be applied to one or more newly created entities in code versus in a scene on a single object or on a prefab. This would only be possible if it were possible to use blueprint's more like settings that could be applied to an entity via deep copying or copying member values rather than the instance data for an entity.
  • Perhaps in this way, it would be better to create a new component config class that would contain the members of a component, not the component itself so that the values could be set into a new component rather than passing an instance of a component. This could be optionally be done for all components or selectively done via its own Blueprint attribute on a component based on a code-gen setting.

[jeffcampbellmakesgames]

Making progress refactoring the previously existing component/type drawer functionality used for visual debugging so that a developer can design what components should exist for an entity or entities based on a blueprint.

[jeffcampbellmakesgames]

Refactored the inspector logic for the blueprint Monobehaviour so it could easily be reused and setup code gen to support both a Monobehaviour-based blueprint as well as a ScriptableObject-based blueprint.

• BlueprintBehaviour => Derives from MonoBehaviour
• Blueprint => Derives from ScriptableObject

[jeffcampbellmakesgames]

Now that there is a solid base for adding/removing components on a blueprint, taking a look at what would be needed to apply those to a component. The goal here is not that these components are used directly, but instead act as the blueprint for components to be set/replaced onto an entity.

ComponentLookup now has a dictionary lookup of component type to index to make it easier to get the appropriate index for a given component in an List<IComponent>.

Entity also has a new method CopyFromXTo that enables copying an existing component to another entity as a new instances of a component. This has the same API flow/events as replacing a component.

[jeffcampbellmakesgames]

Documentation for this feature has been created on the wiki here.

[jeffcampbellmakesgames]

This has been merged to develop.