koobas.hobune.stream
The question is answered, right answer was accepted
Modular UnityEditor design
Trying to start working on a little idea of mine, a UnityEditor system, to help out with designing items, conversations and other types of RPG style of elements.
The idea I have in my mind, is to have a 'mainframe', to which you could plug-in different sorts of modules, and use them to work with databases and etc. But the problem I'm running into, is that I can't figure out a way to actually do the 'plugging in' of the modules, in such a way that I wouldn't need to edit the code of the 'mainframe'.
For example: I have three modules (classes). I'd throw them inside of a folder for modules inside my project, and then when I open up the 'mainframe' window, it updates and finds these three modules and gives you a choice so you could open up and start using the module and the behaviour that it has. If I was to take one of the modules out, it would update and remove it from a choice inside of the mainframe.
So that's the problem. How would I find these modules, inside of the mainframe? I was thinking about inheriting from the same class Module, and finding them this way, but I just can't wrap my head properly around this. Any reading I could do? Any guidelines you can give me, to lead me on the right road?
EDIT: It could be a manual 'installation' as well, similar to Unity's components. You choose to add the module, choose which module to add and it adds the module then. Then you could configure things inside of it.
You could always make an editor window that lets you load from the classes, make sure they all inherit from a specific $$anonymous$$odule class that has a virtal method like this.
public class $$anonymous$$odule
{
public virtual void Display$$anonymous$$odule() {}
}
then your inherited class
public class Dialog$$anonymous$$odule : $$anonymous$$odule
{
public override void Display$$anonymous$$odule()
{
//EditorGUILayout stuff
}
}
then in your editor window
public class $$anonymous$$oduleEditor : EditorWindow
{
public $$anonymous$$odule[] modules;
public $$anonymous$$odule active$$anonymous$$odule;
void OnGUI()
{
active$$anonymous$$odule.Display$$anonymous$$odule();
}
}
It was similar to what I had in my $$anonymous$$d when thinking about it, but the problem arises: how would I load these modules into the array I've defined?
I think you need to use reflection for that. Picked this from the net.
http://stackoverflow.com/questions/2362580/discovering-derived-types-using-reflection
@RobAnthem So, there's an easier way to load them all up? And here I've spent around three hours actually reading up on Reflection and actually implemented it using that and I think it gave me some great insight on it! (Especially, when for the last half an hour, I fought an error, because my array was not instantiated and I couldn't figure it out! Coding when tired in a nutshell!)
And I don't $$anonymous$$d using the class name 'module' because I have gotten into a habit of encapsulating everything in namespaces, so this isn't a problem for me.
Thank you for the answer! Led me to the answer in relatively short ammount of time.
Glad I could help, its good to learn Reflection anyway, it is... sometimes useful lol. Honestly a well-written program should literally never require the use of reflection. The entire idea of reflection is the utilization of objects your codebase has no knowledge of. Some people like to get $$anonymous$$ethodInfo and invoke methods with reflection, but it really would never be necessary, sometimes not even convenient. Then there is the whole GetField thing, and honestly I hate the idea of "attempting" to assign data with merely a string reference. It's as bad as Unitys terrible GameObject.Find("name").
I find best practice is to have 2 separate namespaces for each game, one for the game itself, and one for the editor side. I've never found a Unity project where an editor-side wasn't necessary.
Well, if you don't $$anonymous$$d, I have one question about this all. While reading up on all of the Reflection stuff, I've come upon the fact that Assemblies exist. I do have a really mild understanding of why they're there now, but a question came up. Does Unity actually 'compile' a new assembly every time a new script is created? Because I took it all for granted before and now it doesn't seem like the types could be used to instantiate, without creating an appropriate Assembly. Is my assumption correct on this?
