New Flowcharts feature in r370

As an average skill-level user, I'm still struggling to understand the superior roles flowcharts play in game design. It seems like a series of lists that have links to other lists?

The conversation here makes it sound like a lot of the things you'd expect to do with a flowchart (state machines, AI behaviours) aren't possible. For users down at my level, I'd love to see the Command & Construct approach taken here. Developer videos walking through how to build whatever components of games flowcharts are designed for.

Now that we can try them without crashes, some feedback if it matters:

• There's a lot concepts (flowcharts, nodes, controllers, names, outputs, parents, values...), and using them can be confusing (is the controller the same as the flowchart? is the node value field the same as flowchartcontroller.outputvalue?)
• The language is also a bit much: things like renaming the "FlowchartController" to "Flowchart" (like the Timeline object), and letting me rename each node instead of everything being called "Flowchart node", would help.
• I wish there was at least a variable check before each data point a node. Assuming you're supposed to make dialogue with this, something like "Hero.HP < Hero.HPMAX" before the option "I need healing." would make that possible.
• I'm also not sure what "name" means on the node columns. In the questionnaire example, everything under "name" is a "type" (message, link, etc). Is this just a string-based reference to the value, like the index number?
• I don't find the UI user-friendly, (no grid snap, small node windows, resizing the nodes only stretches the "out" column, no zooming). Hopefully this gets an overhaul before release.
• It would be great if the C3 stylesheet for nodes matched the stylesheets for timelines. Currently, some existing construct themes break (see picture below).

Maybe I'm not used to the feature or good enough to grasp it. And none of these points are as important as the comments above from more experienced users. This feature doesn't feel like a beginner tool at all, so if they don't find it useful, there doesn't seem much point in doing it!

Overboy I went back and read through your whole suggestion. I agree with a lot of it.

Arrow management, definitely.

Conditions in the node options so they can transition automatically if condition is true, hell yes.

Nodes with multiple inputs, I'm pretty sure it can already do that.

A few different node types like link to other flowchart, random, and potentially sequence, yes

I just don't like each node having it's own event sheet. I think it would encourage spreading logic around too thin, which would make issues harder to debug. If Scirra decides to implement that then cool, I won't complain, but I won't use it either.

Overboy I went back and read through your whole suggestion. I agree with a lot of it.

Arrow management, definitely.

A. Conditions in the node options so they can transition automatically if condition is true, hell yes.

B. Nodes with multiple inputs, I'm pretty sure it can already do that.

C. A few different node types like link to other flowchart, random, and potentially sequence, yes

D. I just don't like each node having it's own event sheet. I think it would encourage spreading logic around too thin, which would make issues harder to debug. If Scirra decides to implement that then cool, I won't complain, but I won't use it either.

Just a few precisions of what i had in mind

A. Node Conditions are not meant to 100% automatically and immediately go to output node which verify those (most of the time we want to wait something to happen before changing node, like a user input for Dialog or some other conditions for State Machines). But thanks to a new "Are Node Conditions True ?" condition, it would allow us to easily create any system we'd like that use Node Conditions using a Node Template feature. For example you would create a "Random True Ouput" Node Templates. In its Node Tick function, you would create a subevent checking for a user Input (On A Gamepad button press), then it checks all output nodes with Conditions that are true, pick a random one that is true and enter this output node. We would still be able to create Nodes that 100% automatically and immediately choose a output node via Node Enter or Node Tick functions if we want, but it should be flexible.

B. Nodes can't have multiple inputs AFAIK (edit : my bad they can)

C. The only 2 actual different Node Type would be to link other Flowchart (so it could include button to switch to referenced flowchart) AND "tiny Arrow Nodes" that does noything but help with arrow management, IMO everything else like Random or Sequence would be best achieved thanks to "Node Templates" allowing to have variable and default overridable/extendable functions OnEnter/OnTick/On update. So the user would create its own Random Output Node Template or Quest Task Node Template thanks to the shared logic that act differently depending on Node instance variables and even be overriden or extanded via additional ACE + super call on Node instance functions.

D. It would be 1 flowchart sheet per flowchart with a group containing 4 premade blocks for each node, not 1 node sheet per node. (So we could easily find all nodes by scrolling up/down and copy paste ACE from one to another but the Open Node in Flowchart Sheet button would automatically focus the relevant place on the Sheet opened as pop-up, so no need to switch tabs)

(The two last points changed from my first posts as I realized they would be more powerful/pleasant/simple ways to achieve similar stuff in later posts)

Some advantages of a automatically handled Flowchart Sheet with premades Blocks vs Event Sheet with Triggers :

1. No more string checks for everything
2. Easy way for construct to open a relevant place with all the logic of a specific node in one place (Node Enter/Tick/Exit but also Node Conditions).
3. Would allow to implement the Node Conditions feature there as I don't see any way to implement this in the regular Eventsheets while it's maybe one of the biggest must-have of flowcharts.
4. As Node Enter/Tick/Exit are like Functions/CustomActions instead of Triggers, it would allow the potential Node Template feature to do the override/extand function for instances as Custom Actions allow to do between Family and Family Members
5. No manual labor of creating a bunch of Trigger eventblocks for every single node we create which also require to write the exact string tag of the node (error-proned/tedious)
6. Best organisation possible by default, automatically handled by the engine (no polution of regular Eventsheet for no reason, everything contained in a single asset at the user level, 1 sheet per flowchart, same logic disposition for every single node)

They can, it's just that you can't link an input with a value the same way you can with outputs

Oh yeah they can ! cool, I probably failed my input when i tried doing so on last update r370 (when we didn't have feedback for linking nodes)

It wouldn't make sense to link an input to a value, so the way it works right now is good, a whole Node can have different input Nodes !

I maintain there should be properties in a Node to override the corresponding values in all parent Nodes. Because while it can make sense in a Dialogue System to have different values connected to the same node, in some other situation it would be a pain to make sure all corresponding values in Input Nodes are exactly the same. (If a node has overriden properties, then the corresponding input values would be grayed out with those overriden values so the user understand he can't edit it there but must go in Output Node properties instead)

EDIT : Ooooh i realized why i didn't manage to link multiple Inputs, we can't link multiple Values from the same Input Node to the same Output Node. We only can link 2 different Input Nodes to the same Node Output

I don't understand why there is this restriction tbh, it's confusing because it can make people think multiple Input isn't supported

I think linking inputs to "IDs" would let you get a parent by ID, instead of by whatever is already there.

I can see a few reasons why this would be cool, but it's mainly for UX and just letting things be more open IMO.

Just in general, having more control over how the input field works is good.

Could also make it so we can write graph structures where instead of seeing this as a node structure, we treat everything as siblings and so any node can be linked to from either side.

Let's say I use this as an FSM, having every single link go out from the node from the left side can be pretty painful.

I still don't understand how it would help 🤔

Being able to do FSM by linking later nodes to first nodes would be indeed very useful, as the posts of the first page of this thread explain.

But what would be the benefit to connect a value to an other value rather than a node ? I can't find any example of usecase. You can already get any value from an output node anyway

Also even if they are usecases, wouldn't it be unreadable and confusing ? let's say you have some stuff that have the whole Node as output and some other stuff that have values of this Node as output.

Alright so I had some time to tinker a little bit more with it.

- For my usecase which would probably be some kind of text adventure, this seems actually pretty ok to use. I don't know how unwieldy it gets if there's a ton of nodes.

- On node enter does a lot of heavy lifting since most logic has to happen there. This would also include all the checks for "player health < 5...."

- Branching is also possible with this by just adding a node that executes the branching logic on node enter and sends to the according next node

- Some way to switch from flowchart node to associated triggers and back wouldn't be the worst idea

One thing that I still think would be huge (this has been suggested already) are some kind of instance variables. 1. For the nodes themselves and 2. for each individual option. The current way to put extra data in is to add more outputs, even though the data is not an output. Imo this adds at the very least a bunch of visual clutter. It also has no way to associate the datapoints with the options. Something like "Option 1 has value 5 and Option 2 has value 10". I think this would fit in the properties bar just as it does for sprites. On the node, it could be hidden in some kind of dropdown, especially if you have many variables there.

And I think it fits perfectly in line with the idea of flowcharts just being a type of data object. With the classic variable options to set/add/toggle/ + expressions

FlowchartController.currentNode.variablename
FlowchartController.currentNode.option("foobar").variablename

To be clear Overboy, I don't mean having them linked to the same values Outputs use. I mean having a second list for inputs like this

This is a super quick mockup, as long as we can "name" inputs I think it's good enough

Isn't it already how it works ?

(it looks like a bit redundant with how it works right now + it would be a bit confusing and it involves the fact we need to manually add Input Value in addition to Output value which could lead to "misclicks")

Ok I think I understand now. You want to create systems where some Nodes require to have multiple In Nodes like usual Shader Node Systems or Unreal Blueprints are working.

I dismissed that kind of nodal usecase because I thought anything that looks like nodal visual scripting would be best achieved via regular top-down eventsheets.

Do you have some ideas of cool systems it would allow us to build more easily than what we already had with existing features ? (given the limitations and the fact everything related to Nodes, and their in/out values would require long expressions and id or string checks ?)

Im mostly thinking about the Flowchart feature has a way to create branching logic for things such as Quests/Dialogs/TalentTrees/StateMachines/BehaviorTrees/Cinematics, where each node could implement custom logic, which have always very tedious to deal with in C3 in my experience, because it doesn't scale well (and the issue persist with current Flowchart features).

And in that kind of systems it makes no sense to limit the number of possible in or output nodes.

This is why I want so much Nodes supporting Node Conditions and NodeEnter/Tick/Exit to be able to implement specific logic for each node via "Flowchart Sheet" (by overriding/extending their Node Template Logic and with better Node instance variable support) without the pain of error-prone manual work with many steps for every nodes we create + no quick Visualisation/Navigation help. (The Flowsheet as pop-up suggestion would allow to see both side-to-side, especially if we are currently creating a bunch of Nodes while building a Dialog)

As a test I am building a dialogue system with the new nodes trying to recreate something similar to how I am usually doing dialogues with JSON.

I am building them out of reusable node parts and these are fairly granular, for example: node with tag "speech", "choice", "portraitChange", "randomWeightedOut", "closeDialogue" etc. So in the end I can write more and more dialogues without ever needing to touch the logic again (unless I need to add or extend a node archetype).

For this workflow it's very frustrating that I have to recreate each of those node archetypes again and again as they all have specific options with specific names, others have suggested some kind of node templating system, while that would be really awesome, just being able to copy paste nodes would relieve a lot of the pain while also being useful in other cases.

Second pain point is I wish there was a new node type that just has an in and leads to a different flowchart, ideally with a way to directly jump into that flowchart. this would help keeping the flowchart more clean and maintainable without requiring to glue them together via a string reference in events.

I guess these have already been brought up by others in some way, but I just wanted to bring up what I noticed as the most annoying in a real world test.

edit:

- currently I can't select a node or option and press delete on the keyboard, I always need to delete through the context menu.

- Nothing in the flowcharts is searchable via the find window, while this isn't a problem in my little test, this would make using the flowchart in a large project where you might have hundreds of dialogues super painful.