Modular Design

[stuffses]

I’m using FlowCanvas for AI in my game, and it’s working very well for that. However it gets a bit tricky when I want to give characters modular behaviour using FlowCanvas.

This could be done pretty easily if there was a way to swap out Macros at runtime. A character might have an “idle behaviour” Macro that could be swapped between “Wander” and “Follow Waypoints” depending on the situation. If Macros could be set in a Blackboard Variable and used on the graph, that would be perfect.

Is there any way to achieve this currently? Right now I’m just using big switch statements all over the canvas, but it’s pretty messy compared to a modular macro system.

[stuffses]

I ended up implementing Modular Macros myself, although I’m not very proud of the code. It’s a janky mess and I’m not even sure how it works, but hey it gets the job done for now!

Here’s the code for my Modular Macro Node:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86

using FlowCanvas; using FlowCanvas.Macros; using NodeCanvas.Framework; using UnityEngine;   namespace Assets.External.ParadoxNotion.FlowCanvas.Module.Nodes { public class ModularMacro : MacroNodeWrapper { private Macro currentInstance; private Macro currentSerialized;   public override Macro macro { get { if (!Application.isPlaying || useAbstractMacro) return _macro;   if (macroInput.value == null) return null; if (currentInstance != null && currentSerialized == macroInput.value) return currentInstance;   currentSerialized = macroInput.value; currentInstance = Graph.Clone(macroInput.value);   for (int i = 0; i < currentInstance.inputDefinitions.Count; i++) { var abstractIn = _macro.inputDefinitions<em class="d4pbbc-italic"></em>; var instanceIn = currentInstance.inputDefinitions<em class="d4pbbc-italic"></em>; if (abstractIn.type != typeof (Flow)) { currentInstance.entryFunctionMap[instanceIn.ID] = _macro.entryFunctionMap[abstractIn.ID]; } else { currentInstance.entryActionMap[abstractIn.ID] = currentInstance.entryActionMap[instanceIn.ID]; } }   for (int i = 0; i < currentInstance.outputDefinitions.Count; i++) { var abstractOut = _macro.outputDefinitions<em class="d4pbbc-italic"></em>; var instanceOut = currentInstance.outputDefinitions<em class="d4pbbc-italic"></em>; if (abstractOut.type != typeof (Flow)) { currentInstance.exitFunctionMap[abstractOut.ID] = currentInstance.exitFunctionMap[instanceOut.ID]; } else { currentInstance.exitActionMap[instanceOut.ID] = _macro.exitActionMap[abstractOut.ID]; } }   currentInstance.entry.BindPorts(); currentInstance.exit.BindPorts(); currentInstance.StartGraph(graphAgent, graphBlackboard, false, null);   return currentInstance; } set { if (!Application.isPlaying) _macro = value; } }   private bool useAbstractMacro; private ValueInput<Macro> macroInput;   protected override void RegisterPorts() { macroInput = AddValueInput<Macro>("Macro");   useAbstractMacro = true; base.RegisterPorts(); useAbstractMacro = false; } } }

The script will require some minor changes to the parent class, MacroNodeWrapper. I think it’s just marking some methods as virtual.

To use it, place the above node on your blackboard, and in the first “Macro” slot, provide it with the “Interface” macro. This “interface” Macro works much like a C# interface, in that it only defines the functions (or in this case, flow and value nodes for the macro) and should have no actual logic inside.

Once you’ve set the interface macro, refresh the ports.

To load modular macros, duplicate your interface macro and add logic to those new macros. You can then provide those new macros to the Modular Macro Node with a Blackboard variable.

[Gavalakis]

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:

You must be logged in to view attached files.

[stuffses]

Thanks for the response. That’s certainly a much more elegant solution to the problem, I think I’ll be using it a lot!

I can see why modular macros are tricky. Still it would be nice to have some clean way to have modular FlowScript.

[Gavalakis]

Hey,

Sorry for the late reply and I am glad you found this solution useful.
As for modular flowscripts other than this, another way would be to use Blackboard Variables, but I can see what you are after here 🙂
I will take a look at this regard and see what can be done.
One possible way I can think of is the ability to create “abstract macros” where one can only define the inputs/outputs and then create derived macros of abstract macros where one defines the only contents/nodes (with inputs/outputs being fixed by the abstract parent).
I can’t tell for sure if that will work though right now, but I will take a look at this :).

Thank you.

Join us on Discord: https://discord.gg/97q2Rjh

[stuffses]

Yeah, some sort of abstract Macro is exactly what I’m thinking of.

My code above basically does that, although it’s horribly hacky and isn’t very reliable. Seems to break when you have more than one on a blackboard at the same time…

[Author]

Posts