New Flowcharts feature in r370

Good work so far DiegoM, and interesting ideas from the rest of you.

yours

winkr7

1. NODE SHEETS (Node Conditions + On Enter / On Update / On Exit)

Here is a mockup and a refinement of the Node Sheet and Node Conditions features I was suggesting

Everything is explained on the mockup

Basically each Node would be able to open its own "Node Sheet" as a Pop-up (which data is embed in the Flowchart asset).

Node Sheets are restrictive eventsheets with 4 premade blocks :

Conditions

• they are also displayed directly on the Node is the flowchart
• could be checked all at once thanks to a "Are Node {MyNode} conditions True"
• would be used by special Node Types like Sequence/Choice/Random to automatically pick an output based on various rules and conditions as explained in part 4.

On Node Enter

On Node Update ("every tick" runiing when this Node is currently playing)

On Node Exit

Other suggestions in addition to what have been said before :

2. Nodes should be able to have multiple different "Ins" Node

It is very useful for all kind of branching system where a node can be reached from multiple places (like Dialogue but really any branching system)

However it might be an issue with how it works right now because the Node Name and Node Value are in fact stored on the "parent In Node". So it would mean the same Node would have a different Name and Value depending on the parent In Node.

Not sure if it would be that much an issue as it could make sense to have different name and values for the same node in the context of the Dialog System.

However there should probably be a boolean option on a Node to guarantee its Name and Values would be the same whatever its Parent In Node is. Like a "Override Name and Value" boolean that gray out those fields on all the parent In node output corresponding to this node and that let you choose those values on the Node itself.

3. Allow flowcharts to have "local variables"

(in fact something similar to both local variables and instance variables at the same time as we should have ACE to be able to get/set them on the Flowchart Controller with dropdownlist depending on the chosen Flowchart. If it's too complicated then just a set/get Flowchart variable by name would be good enough).

Those local variables would allow use to do many things including passing the UID of an instance and retrieving it in the Node Sheets. Would be really useful to use Flowcharts as State Machines or Behavior Trees for entities for example.

It would also allow us to change the behavior of specific Flowchart instance dynamically at runtime by changing a local variable. For example setting a TargetUID local variable or changing the boolean of a Flowchart from a regular Eventsheet

4. NODE TYPES

• There could also be different kind of nodes depending on how to choose the output.
• The current default would be the "Manual" Node.
• But there would also be other kind of Nodes such as "Choose" Node, that automatically finds the first Output Node which "Node Conditions" are true and play it immediatly (and/or waiting for a Choose Node action to be called, but it's processed automatically on called).
• There could be other cool stuff to think about regarding Node Types and Node conditions to automate some stuff.
• Maybe also a "Sequence" Node ? that would execute each output node and it's branching in order until it reaches an end and then do the same for the next output node.
• Maybe a "Random" Node, that picks a random node output which conditions are true
• (It could be a Node dropdown property "Output Choose Methode" to choose between Manual/Random etc instead of actual different node types)

5. BETTER NODE CONNECTIONS/ARROW

As it looks like Nodes wille be able to link back to previous Nodes, i think it's very important that the arrows still looks clean, otherwise it will quickly look like a spaghetti mess. Maybe letting the user choose the shape of the arrow by creating and moving an intermediate point (mini node doing nothing) and making sure it draws a clean softened right-angled corner. Something similar to this :

1. I wish there was a way to jump to the event that handles the nodes logic and jump to the node from the event. Sadly not really possible with it using string tags though.

This would make it much better to use as right now it always requires searching in two places.

2. Also I would love to have the conditions slightly changes to:

• "on node enter"
• "on node exit"
• "on any node change"[/li
• "compare current node"
• "compare previous node"

And get the expression:

• "GetPreviousNodeTag/Index"

3. To read the Flowchart at a glance I wish the name/tag of the node would be larger and in the header, this would make searching and reading the tree much easier as right now they are not really discernible.

(A color settings for the node header would be cool too, similar how we can color code comments and tabs, but that would be more of a cherry on top)

4. output cell should not be resizable, as there cannot be any content wider than the circle.

On the seemingly controversial topic of enacting logic within nodes, would a possible solution be to restrict this to just being able to trigger Functions in nodes? That way, all logic can sit in the Event Sheet and the nodes would just reference it, instead of creating 'pseudo event sheets' or resulting in the flowcharts competing with Event logic (which I fully agree is something to be avoided).

Interested to hear your thoughts on this, DiegoM?

I don't agree with the "competing with event sheet" counter-argument besides the fact it would maybe involve more work for Scirra. It term of UX Node Sheets would be just better as it would just avoid the pain to manually create 3 Functions for every single node for every single flowchart we'll create, that would pollute actual eventsheets and already huge Function list for no reasons and that would require to endlessly jump between a big number of tabs. (How would we be able to jump from a Node to a Function and to a Function back to its Node ?)

It's like saying Timelines is competing with Tweens and it's something we want to avoid while they are for different purpose (I think the comparaison between Timelines VS Tweens and Flowchart Node Sheets vs Eventsheets is fair, and there could be other counter example like Custom Actions vs Functions)

Also it wouldn't solve the Node Conditions feature that I think is a must. Would be a shame to not take full advantages of all existing Conditions (Vanilla + 3rd party add-ons) for the visual scripting capabilities of such a system to help picking the right output on a Flowchart

HOWEVER I guess an intermediate alternative would work to still keep most of the advantages of the Node Sheet suggestion :

- automate the creation of the Node Enter / Node Update / Node Exit Functions on an desired Eventsheet (and automatically create a Group for each flowchart and a subgroup for each node).

- There would be Eventsheet name and Group name properties for each Flowchart and Subgroup name property for each node that allow us to override the default places where those are created (Flowchart/Node names are the default names of the Groups, changing the properties automatically renames related groups because they would be effectively mapped)

- Could also have a Project property "default Flowchart Eventsheet" where every Node related Functions are stored.

- as the engine created the Node-related Eventsheet function and group itself, it could restrict the rules for them (showed by a slightly different logo or wording in the sheets), like don't let us call those Functions via regular function call action (at least by default), don't let us move Node Function blocks.

- This way it wouldn't be a string spaghetti mess and the engine would be able to efficiently map the exact single place in eventsheets that is related to each node so it should be able to open the desired Eventsheet at the desired place directly when clicking on a "open this Nodes Event Group" (as a pop preferrabily, and/or at least the Node Group would itself have a button to open back the flowchart back to the right node position - but I think pop-up would be the best for ease of use in that case and we could still open them as any other tab if they're regular eventsheets)

That being said, I think what I just described (automatically creating Node Event Groups containing premade Functions on regular eventsheets) could just be how the Node Sheet feature I was describing would work under the hood even if the C3 user couldn't tell because all of this is hidden and is presented in the most pleasant and user-friendly way. It would also be a better base to create other Node related features like Node Conditions in single place and to make it clear those events follow more restrictive rules

Anyway there would still be the Node Conditions feature to solve and I can't see myself going to the pain of manually creating 3 functions for every single nodes and referencing them with strings, jumping from a tab to another without help etc.. That would be the actual spaghetti mess the Node Sheet feature would solve among other benefits. Also having Flowchart Data + Node conditions + Node Functions contained in a single asset (at least at the user level in project view) just seems to be the most elegant and pleasant way of managing things.

(Writing this last post also makes me think it would be great if the Node sheet pop-up I described with the mockup on my previous post would in fact contain all the Node Events of current Flowchart in a single place (it just automatically opens to the relevant Node Event blocks but we would be able to scroll up/down to find the other Nodes to easily copy paste some ACE from one Node to an other)

would a possible solution be to restrict this to just being able to trigger Functions in nodes?

I think that is already possible with 'On tagged node change' in the Flowchart Controller object. Give the node a unique tag, and then that trigger fires when the node is reached, where you can then place any special logic for it. (Correct me if I'm wrong @DiegoM)

With the conditions available right now, if you use unique tags, you can use the On tagged node change trigger and perform your actions or functions when a specific node is reached.

You can also use the On any node change trigger coupled with the GetCurrentNodeTag expression to achieve the same effect.

Even though the current feature set is pretty bare bones, most of the things suggested up until now, can already be achieved.

Whatever method you choose to determine what node has been reached on a trigger, it is reasonable to have a unique event sheet that just checks which node has been reached and depending on that execute additional conditions and actions.

On a different note, there is a feature which the current example doesn't explore. The Flowchart Controller plugin is not single global, that means it can be added to a container, that means you can have unique flowcharts instances for a bunch of instances and manage them relatively easily. I was thinking of creating a different example showing a possible way to use that.

I don't think most of the things suggested in this thread can be achieved currently. Well at least for almost all of them, the UX would be painful and it would feel very hacky.

Regarding Node Enter/Tick/Exit using the exisiting Triggers, yes I agree it could be done that way, I thought about this and then thought about how to improve it. I find the worklow unpleasant, because it means creating manually a bunch of events with strings check everywhere, potential big else if statement, no easy way to jump from the Flowchart to the eventsheet etc.

(Those are still great to have, but more for logic shared by several Nodes of a flowchart, not for Node-sepcific logic)

IMO for that kind of tool, UX is equally important with functionnality. (Visualisation, Naviagation, QOL)

The current workflow needed to achieve this is stressful and annoying, while it could be such a breeze if Flowcharts allowed to implement Game Logic.

As someone who enjoyed Game Creator 2's Behavior module, I can safely say it is totally amazing and powerful to be able to merge Node Trees with Actions and Conditions with ease. (GameCreator2 Base Tool plugin adds some kind of "eventsheets", yet its additional paid modules adds extra way to use Actions and Conditions and it totally makes sense, they don't compete with each other they synergyze very well and the community is happy about it).

I feel like it's a missed opportunity because Construct 3 has the best Actions and Conditions system out there, (and a huge number of Vanilla and 3rd Party ACES) but yet Unity (upcoming Muse Behavior) and its third party tools (GameCreator2) use their own ACE system in a better way.

If using Flowchart we need to implement our own logic to create the whole backend for how flowcharts are executed, as the first example shows, how to go from one node to another, need to navigate through a bunch of tabs, manually implement several triggers via strings for each node in every flowcharts etc, potentially painfully contains visual data (avatar animation/text wave effects) and conditions data (why would this out node be chosen ?) in big token strings (that then need to be parsed and intepreted by ACE instead of just using ACE directly), then it means the only thing Flowcharts allows to do is linking array entries visually. (which is cool i admit !)

Currently implementing Dialogues/Quest/StateMachine/BehaviorTrees with Flowcharts require exactly the same amount of work (tedious work) as it was before using an array (or JSON) where each entry would represent a node for example.

The only difference is that the array entries aren't linked by arrows, but each array entries could store a token list of the ID of out Nodes.

However the Array method would be much more flexible because it would allow us to link any Node to any other Node (multiple Ins support, possible to link back to previous nodes).

To be honest, with the current set of features, i'm not sure why i would go with the Flowchart instead of the Arrays (or JSON). Because Array would also allow us to store any number of values ("unlimited column numbers", while Flowchart are just more retrictive and require to parse data contained in just a 3 values max - Name/Value/Tag, it means potential huge token list which are not always very pleasant to deal with).

JSON would even allow us to nest and manipulate any amount of Data/arrays/Dictionaries for each nodes.

So IMO right now Flowcharts try to compete with more flexible and powerful Data Plugins while they could become something new that synergize well with Eventsheets

I just love the work you did so far on Flowcharts, very promising and exciting, and really hope the full potential will be exploited. So far nothing in its current implemention prevents it to become the best NodeTree/ACE hybrid tool out there, both it term of ergonomy and functionality, that could be used for Quest/Combo/Dialogues/StatesMachines/BehaviorTrees and enhancing the "instant and easy powerful visual scripting" features of C3 we love.