This system was quite a pain to make in such a short time as it was my first foray into tools engineering and I had never touched Unity's suite for UI and I also had very little time to do everything so anything visual was thrown out the window which is why the UI looks so bad.

​

Engineering wise I'm taking advantage of abstract classes which I'm not the biggest fan of but if I used interfaces I would have to write an entirely custom serialization system which time constraints prevented. The abstract class would define function signatures for saving and displaying the contents of that node, however, not for actually executing the story. I regret doing it that way though as it made me have to create else if chains which aren't pretty as there is too much dependency that makes the system harder than I would like to add more nodes too even if it is possible. If I were to revisit this project right now that's the first thing I'm improving.

 

Pretending I was still under time constraints and had to use abstract classes I would create a new abstract class that would be used to define UI Layout (class EventNodeLayoutManager), another abstract class that would define load/saving (class EventNodeSaveLoadManager), and one more abstract class that would define content (class EventNode). I would probably only define getter/setter behavior in Event Node such as if values would need to be edited at runtime and not behavior of what the nodes would do at all. That would be separated into EventNodeBehaviorManager and I would extend from that abstract class to define how the contents of a specific node should display. This would get rid of a lot of the dependcies I currently have though obviously not as well as abstracting behavior to interfaces. But this would make my life easier as this is just an implementation of the MVC programming pattern and is known for decoupling in situations like these :D