koobas.hobune.stream
Patterns for Unity Editor Friendly Extensions
My core question is: What are some good design patterns to use when creating Unity Editor extensions that need to permit further extensions?
I've been working on a project that includes a pipeline-like build process and I want the end-user (coders) to be able to plug in components of their own making at different points, and keep it Unity Editor friendly.
An example: The beginning of the pipeline requires a mesh. I provide several components that gather and aggregate scene meshes, but the end-user may want to create their own and still be able to assign it to the fields in my custom editors.
Right now I'm using an inheritance approach. It works OK. But it bothers me a bit from a design perspective.
Continuing with the above example: I have an abstract DSGeometry class that extends MonoBehaviour. My custom editor requires a DSGeometry object, so anyone can create their own concrete class via scripting and assign it to my editor.
Any suggestions on other approaches?
I think inheritance is one of the best/easiest way. You can use interfaces as well, but at some points you need some workarounds because most of the built-in functions in Unity works only with classes that are derived from UnityEngine.Object.
For example if you want to offer a drag&drop field where the user can plugin only a certain interface you can do that in a custom inspector:
private IMyInterface m_SomeComponent = null;
public override void OnInspectorGUI()
{
m_SomeComponent = (IMyInterface)EditorGUILayout.ObjectField((MonoBehaviour)m_SomeComponent,typeof(IMyInterface));
}
Since the editor only allows objects of type IMyInterface to be assigned to the object field you can be sure it has to be a Monobehaviour script that implements your interface.
Another way would be to attach the MonoBehaviours as normal components and use GetComponent to get a component that supports a certain interface. Again the same problem, you can't use the generic version of GetComponent because of the constraint to "Component". The type-version works ;)
IMyInterface component = (IMyInterface)GetComponent(typeof(IMyInterface));
I would say you can use any design pattern in Unity, but you may have to adjust it a bit. It's kinda useless to implement your own strategy-pattern since the whole component system of unity provides already everything.
The first solution is nice, but it doesn't appear to work. The pattern compiles fine, and the object field will display the correct value if one is already assigned. ($$anonymous$$g. If it was assigned via code first.) But the GUI field in the inspector won't accept new assignments. It just blocks everything as invalid. Have you been able to get the first solution to work in Unity 3.x?
