New Flowcharts feature in r370

Thanks Scirra I love this new feature! I'm very excited to see what the possibilities are.I'm pretty happy with it as is except for a few things, here's my wishlist.

1. A new node type that allows you to link to a different flowchart (either at start or tag)
2. The ability to create cycles (otherwise FSMs are not possible as they are usually full of cycles, ex: enemyWalk --> enemyTelegraph --> enemyAttack --> enemyWalk)
3. Customize node title, and possibly a description in properties bar (instead of just saying "Flowchart node" in title of node, allow us to customize the title, ex: "Flowchart node - Guard Dialogue Options"
4. Arrow management - right click an arrow and "create arrow node" which can be moved around (it does nothing except make our arrows look nice and not intersect other nodes)

I remember 11 years ago when the Scirra staff said they discourage the use of flowcharts in programming, saying that “they are really inefficient with space, and you quickly end up with a unwieldy spaghetti which hurts more than it helps”, and now they’ve implemented them. I’m curious what changed their minds.

I don't think flowcharts work well for game logic. You tend to end up with what looks like a big pile of spaghetti, and the two-dimensional scrolling makes it hard to review and change. Our approach with flowcharts is, currently, as a data structure only. This is suitable for things like conversation trees which are typically structured in an ordered way, and game logic stays in the Event Sheet View (or coding). I think this is a good way to bring the benefits of a visual designer for tree-like structures without the downsides of spaghetti-logic.

I don't think flowcharts work well for game logic. You tend to end up with what looks like a big pile of spaghetti, and the two-dimensional scrolling makes it hard to review and change. Our approach with flowcharts is, currently, as a data structure only. This is suitable for things like conversation trees which are typically structured in an ordered way, and game logic stays in the Event Sheet View (or coding). I think this is a good way to bring the benefits of a visual designer for tree-like structures without the downsides of spaghetti-logic.

We're not suggesting bad node-based Visual scripting like most softwares are implementing. (Most famous example being Unreal Blueprints)

Node-based visual scripting sucks, especially when each variable or the fact to invert something is a node itself, it indeed looks like Spaghetti and it's an absolute mess.

Event system like C3 is using is far better.

HOWEVER, as i explain in previous posts, i feel like what current Flowcharts features require us to do moves the problem to an other kind of "abstract spaghetti" and coupling mess :

• It requires a bunch of string checks to achieve per-Node-specific Conditions / On Node Enter / On Node Exit / On Node Tick + a lot of manual work every time we add a node (stressful/easy to forget/error-proned)
• The logic split among different assets
• With no navigation/visualisation help. (requires to switch between multiple tabs and find the relevant places of each of them each time, need to scroll every time both on Flowchart and Eventsheet)
• need to painfully parse data contained in huge error-proned token list (avatar frame ? node-specific conditions to pick outputs ? camera settings to change ?), tokens are tedious to deal with on top of that using eventsheet, it requires a bunch of unreadable expressions.

What i'm advocating for is the best of both world : Node-Trees packed with dedicated Event Blocks for each Nodes :

(since i made this mockup, i realized it would be better if all "node sheets" of a flowchart were in fact in the same "Flowchart sheet", one after the other, so the pop-up would just automatically scroll to the relevant Node, but we would still be able to scroll the sheet up/down to find other nodes and potentially easily copy/paste ACE from one to an other)

This is the main point of what i try to explain in all my posts referencing Game Creator 2 (Unity 3rd party tool suite). Node-Tree visual scripting + ability to use Actions/Conditions/Expressions per Node is the most effective way to create :

• Dialogue Systems
• Quest
• State Machines (states machines have infinite usecases : complex player movement behavior, enemy AI, Game States, UI flow)
• Behavior Trees
• Combo System for Combat Game
• Dynamic cinematics

Existing Triggers included in FlowchartController Plugin are great for some purpose : logic shared by multiple Nodes, but not for individual nodes because the workflow involve many step for each Nodes we create, with no UX / Navigation / Visualation help.

However even that last point could be improved thanks to Node Sheets merged with the ability to create "Node Families"

NODE FAMILIES : node variables and overriding default OnEnter / OnTick / OnExit functions

That Node-Tree / ACE hybrid approach i'm suggesting could be even pushed further thanks to the ability to inherit default On Node Enter/Tick/Exit functions and variables from "Custom Node Types" (or Node Families / Node Templates)

We would be able to create "Node Templates" (or Node Family) implementing logic for their NodeEnter/NodeTick/NodeExit eventblocks, and then, in the inheriting Nodes, overriding AND/OR doing "super" call just like Object Family with Custom Actions are allowing us to do.

Node Family could also have "instance variables" in their properties, so it would allow us to easily set an Avatar Frame, or that kind of stuff without needing to parse Data in token lists

This way we could easily create a single Flowchart merging Dialogue + Quest + Cinematic capabilties at the same time.

You would create a Dialogue Node Family, a Camera Node Family and a Quest Task Family and then create inheriting node depending on what you want to happen at what point of your Flowchart

All Dialogues nodes would have a Avatar variable for example, while all Cinematic nodes would have TargetInstance/ZoomScale variables for example.

All Dialogues nodes could do a super call of the common Dialogue Family "OnNodeEnter" logic (which behavior could change depending of the "node instance variable" values) BUT some of them could wait X second before, playing a specific sounds, creating a specific instance after etc.

=> It would allow the user to create its own Node Types (with variables and overridable/extendable logic) depending of the system they want to achieve

Also we would be able to create our own Node Types to choose output based on Conditions as I was suggesting earlier, no need to include Vanilla "Random Output", "Choose First True Output" Node Types, the user would just be able to create it themself thanks to the "Are All Node Conditions True" Condition

Our approach with flowcharts is, currently, as a data structure only. This is suitable for things like conversation trees which are typically structured in an ordered way, and game logic stays in the Event Sheet View (or coding). I think this is a good way to bring the benefits of a visual designer for tree-like structures without the downsides of spaghetti-logic.

If so, it seems there'll be quite a gap between the expectations of this feature and the uses you're building it for (meaning it's setting up a lot of disappointment, looking like it does more than it does).

If it's just a series data structures connected to each other in a linear fashion, couldn't each flowchart just be one big data table? If the nodes aren't going to have conditions/reactions between them, there's no need for all this big empty space between them. The arrows linking node to node could just be index numbers. And there would be no need for scrolling around, looking for a certain node's tiny title, etc; it's all just one big table (like an array, but with fixed content types in each cell).

Context menu to switch between a node and its trigger would be nice, but how would that work if everything is string based ? Usually C3 does it when the engine is able to map efficiently things together like with Functions or Custom Actions.

How would you achieve all the usecases i mentionned with current Flowchart features ?

- Pick output based on conditions proper to each possible output nodes

- Having a specific dialogue node that wait X second before executing the regular Dialogue node condition logic

- Playing different sounds, or putting different actions in every single nodes (let's say you have 5000 nodes as you suggested)

- Having multiple value to handle for each node (avatar image, avatar animation, text animation, related QuestID, including variables within the actual Dialogue text)

(just a few simple examples of stuff we need to be able to do with ease)

Btw i said 2 times it would probably be better if all "Node Sheets" of the same Flowchart would be in fact a single "Flowchart Sheet" opening to the relevant place, as opposed to the mockup I made at first

I think people are also seriously underestimating the downsides of having different places to put logic. If you have 100 flowcharts encompassing 5000 nodes, with bits of event logic distributed all across them, and then you find something isn't working right... how do you even begin to sort that out? You could easily spend hours just trying to figure out which part you ought to be looking at. Keeping things in the same set of event sheets might seem like an inconvenience, but IMO it's actually far better for scalability and organising larger projects.

I don't understand what you mean.

Do you really think having 5000 nodes with string checks in eventsheets, requiring us to manually create multiple trigger blocks (NodeEnter/Exit/Tick) with the right tags 5000 times (so 5K manually writter Node Tags on the Flowchart then 15K manually assigned Triggers with manually written Tags on regular Eventsheets) is better than each flowchart embedding a flowchart sheet with premade functions for each nodes automatically created/assigned and efficiently mapped by the C3 engine ?

The tag-based trigger way we need to do right now is the actual scalability/organization nightmare.

I don't see what would be the difference regarding debugging.

In both scenarios, those are just triggers/functions called when the Node happens.

Except the flowchart sheet suggestion provides QOL, quickly open all Node-specific logic as a pop-up (so Node Conditions + Node Enter + Node Tick + Node exit packed automatically at the same place accessible as a pop-up with just a click), find all references support easily achieved as NodeEnter is a premade function linked to the Node by the engine, not one of the 5000 Eventsheet triggers the user created manually, after manually defining a tag for the node and then writing that tag name in each related trigger blocks with potential mistake. (what if i want to change the tag later btw ?)

As i said, under the hood, the engine could perfectly interprete the Flowchart sheet as regular eventsheet anyway, but each blocks within them would be more restricting, automatically handled when creating/deleting nodes of the related flowchart and flowchart sheet wouldn't be displayed in the Eventsheet list.

I'm gonna give flowcharts a good try once the next beta drops that (presumably) fixes the crashes. I am arguing a little bit in the dark here because I have not yet actually build anything from the ground up or really at all.

I have however exactly in mind what I would want to build and what functionality I'd want. So I'll attempt to do that and see what comes out of it.

I'd personally be ok with keeping the logic in an eventsheet entirely BUT only if there's a good interface between the two.

If there's one thing I can pick I'd want, it's anything that avoids having to glue flowcharts together at runtime. It's probably useful in some cases, but I'd want to avoid it as much as possible.

If I look at a node, I have no idea if I glue a flowchart to it at some point or not. I can probably guess that I do, but I still have to check through the events to see which one. I'd rather have that connection already established in the flowchart view and be able to enable/disable this connection at will (checkbox in the flowchart view maybe?). It would be immediate visual feedback as to what's happening, rather than it being obscured in the eventsheets.

In the same vein, branching connections would be important. If I think a coinflip, I really want to avoid having to do the 50:50, then glue the correct following node/flowchart to the out. I'd rather have this already visually connected and somehow communicate which path I want to take. Maybe something similar to function "set return value" there could be a "set branching value" which is than simply compared against when "go to next node" is called.

- Pick output based on conditions proper to each possible output nodes

An 'On node entered' trigger, with subevents with actions to choose which output to go to.

- Having a specific dialogue node that wait X second before executing the regular Dialogue node condition logic

An 'On node entered' trigger, with a wait action before going to the output. (You could for example have a "wait" node with the same tag in multiple places, and re-use it.)

- Playing different sounds, or putting different actions in every single nodes (let's say you have 5000 nodes as you suggested)

Have an output with a string of the sound to play, e.g. output name "PlayAudio" with value "SFX5", and in 'On node entered', if an output "PlayAudio" exists, play the sound in its value.

- Having multiple value to handle for each node (avatar image, avatar animation, text animation, related QuestID, including variables within the actual Dialogue text)

Outputs are also designed to store data, such as in the prior example I gave, where the sound to play is stored in the node. You can use multiple key-values, essentially using each node as a small Dictionary storage.

So I think all that can be done with the current design. I think it will take some time for people to use it and get familiar with how it works and the patterns you can use with it. Maybe some things will turn out to be a headache to implement, but I think at the moment things are very speculative and everyone needs to try things out in practice and then give us feedback for real-world uses. We also have lots of improvements in the pipeline so the way it is right now isn't necessarily its final form.

Yeah this is the error-proned token list i'm mentionning in every post.

Need to remember the right order of token (is the 17th token in the output data the string-based sound to play when this node is reached ? or it is the wait X second values argh i don't remember, argh i don't have enough space to see all the tokens at once, oops i skipped token 6, mmh i wish i had autompletion for the avatar sprite name) + use tedious token expressions to parse and interprete the data.

And the manual labor of creating a bunch of triggers on eventsheets with strings checks for tags for each Node we create (without Navigation/Visualisation help).

Again every solution you mentionned was already what we did with Array/JSON before, except it was handier on some aspects (except the visual arrows I admit)

I'll keep avoiding the pain of doing games relying on Dialogues/Quests in C3 and anything that looks like State Machines for now then.

I hope someone at Scirra will take the time to check Game Creator 2 Behavior 2 Module or even better, at least try to understand or just consider the tailored suggestions written in this thread that makes sense in the context of C3 and how it is working under the hood. (written by people who most likely already painfully created their own quest/dialogues/FSM systems using C3 and know how tedious it was and still is)

I would definitely like some functionality in each node, in general when I see this, I think of behavior trees and fsms and how useful it could be to visualize. In terms of functions, they could be a drop down selection of all available functions. Passed parameters of inputs and outputs. They could do other actions or override the output. For UI there could be a right click option to jump to the current function definition. On enter is the minimum. On enter, on input could help doing a Behavior Tree. Think selector and sequence nodes. I hope you take a look at behavior trees and visual libraries and implementation. This is a very obvious real world use for AI in games. There are books series on the subject covering real shipping use cases gameaipro.com (you can directly read chapters on this site for free)

I know the functionality of the above is possible with the current ACEs, it is having the visual UI and identifying the functions called per node visually and being able to jump to the function in the event sheet from a node that would up the game of flowcharts.l significantly.