Reply To: Modular Design
Hello and happy new year!
The problem with having macros being modular is (as you may have noticed) that since each macro can have different ports registered, unless the names of the ports remain the same, links will become broken in runtime when/if the macro change to one that does not have the same ports as the one assigned in edit time.
In my opinion, a better way to make a more modular design, would be to create an abstract monobehaviour class (eg “Character”) along with abstract methods of what Characters can do, as well as character derived classes along with their implementations and finally have those methods called from within a flowscript. For example:
|
1 2 3 4 5 6 |
abstract public class Character : MonoBehaviour { abstract public void DoSomething(); } |
|
1 2 3 4 5 6 7 8 |
public class Orc : Character{ public override void DoSomething(){ //... } } |
The Orc script is then attached on the “self” gameobject, but from within a flowscript the base definition of the method DoSomething() is used. As such, each gameobject with a Character derived class will use it’s own implementation of DoSomething().
Please let me know if that makes sense or if you need further explanation.
Thanks!
Join us on Discord: https://discord.gg/97q2Rjh
Attachments:
AbstractCall.png