Overboy's Forum Posts

  • yeah ok so all X first output are "node instances variables" and everything after ID = 5 are actually out nodes ?

    yeah this is a cool hacky trick, but there are still all the other deal breakers for me

    Also it still assumes feature that are not yet included in Flowchart features :

    -indeed it would require us to be able to duplicate Nodes to avoid the pain of manually creating every single variable every time in the right order, with the right name etc...

    But then, if you want to expend the system of this "node type", you would need to manually add that Variable in all existing nodes (right index + right string name) + change the index where output are actual node links instead of variables.

    For me, it only solve 10% of the problem at most while still requiring new features and hacky tricks even if I admit this is a smart trick.

    I still prefer the tricks I found with older features to achieve Dialogue System or FSM.

  • piranha305

    I don't understand what you're meaning with this screenshot ?

    Why are you setting the "variables" as node outputs, how would you branch this Dialog node to other Dialog nodes. Outputs is supposed to store other nodes, not the "variables" of the current node.

    The Dialog Node should be linked to other Dialogue Nodes.

  • Fib Yeah but this means we have to recreate every single ACE that already exist in Construct 3 to create our own awful node-based Unreal-like Blueprints ?

    Where each action and condition is replaced by a Node Type, that we need to define in other eventsheet via a bunch of strings checks on top of that ?

    This is exactly what sucks about Blueprint. A Variable is a node, a trigger is a node, a condition is a node, an action is a node, an inversion is a node.

    Also it still doesn't solve the Node Data issue i keep mentionning. What about the avatar sprite, the avatar animation, the text animation and so on ?

    I'm all for being able to create Custom Node Types and i perfectly know it can be achieve this way with current features but it doesn't scale.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • What tokens are you talking about and why would you have to remember them all? If youre just talking about node tags then I don't see the issue. C3 has tag systems everywhere, audio, timers, tweens, solid collision filter, etc. Why would node tags be any more cumbersome than those?

    I already explained this several times. Tokenlist aren't related to Node Tags but to Node data. What if you have a Dialogue System where each Dialogue node has a different Dialog Text but also Avatar sprite, Avatar animation, Text animation, pacing data (wait for X seconds) ect... then you have 2 bad options (well in fact even more but they all suck) :

    1. either you put all the Data in a big token list as the Node value

    "my text dialog text or id that can already be a long string, myAvatarSpriteName, myAvatarAnimation, TextAnimationKind, WaitXSecondValue" that will be interpreted in a "OnAnyNodeEnter" that use ACE based on those tokens

    ACTION : wait tokenat(MyDialogData, 5, ",") seconds

    2. or you create a new trigger for each node via the "OnSpecificNodeEnter" but then you need to copy past the WHOLE logic of your dialog nodes in every single Trigger for every single Node and if you want to expand the capabilities of your Dialog System you'll need to painfully add/remove ACE in every single Trigger Block (imagine you have 5000 as Ashley suggested)

    ACTION : wait HardcodedValueOfSepcificNode seconds

    (but that action need to be copy paste in all specific Dialog Node Trigger)

    (I know there would be other hacky tricks to achieve that kind of thing but they all suck)

    The example i provided is extremely simple, most system would need far more data for each node.

    Which is why I suggested a Node Template feature that would allow Node Instance to inherit variables (each instances would be able to have different values for those variables like instance of an ObjectTypes) + have default OnNodeEnter/Tick/Exit functions that can be overriden or extanded via super Call for each Instances

    This would work perfectly with the Flowchart Sheet feature i suggested with Node Condiditions + automatically created On Node Enter/Tick/Exit eventblocks on the Flowchart Sheet for each nodes.

  • 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)

  • 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 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

  • 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.

  • 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)

  • 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 :

  • This is a very exciting feature, thank you for the hard work on this.

    IMO the biggest issue right now is that it still requires us to create a tedious/complex backend using Eventsheets to actually use this new data formats.

    It requires us to create a bunch of Functions, use a lot of different ACE etc...

    Usually branching tools kinda automates some stuff for you

    Also we need to painfully handle infinite else if statements on triggers to do some special logic on each Nodes (playing sounds/displaying an avatar etc...), everything being a string and it's a spaghetti mess between eventsheet and flowcharts

    By coincidence, I very recently wrote a long forum posts explaining my thoughts about it with a detailed benchmark of other tools merging Action/Conditions with Node Trees.

    construct.net/en/forum/construct-3/general-discussion-7/ace-based-node-trees-creating-179570

    Especially Unity's 3rd Party tool suite called Game Creator 2 and not-yet-announced official Unity Tool called Muse Behavior.

    The excellent thing with the implementation you chose is that it's very versatile so it would be possible for Scirra to build very cool stuff/options to just make some of it works "immediatly" without requiring us to create all the complex backend (as the current example is doing).

    I know both the release note and this post present this new feature as a data-oriented feature but I do think the true potentail of that kind of feature would be achieved if it also allowed us to implement game-logic per node.

    ALLOW TO ADD A EMBED FUNCTION FOR EACH NODE

    • Basically each node would have a "Add Node Function" or "Open Node Function" button. (it can only have 1)
    • A node function is a "mini-eventsheet" directly embed in the Flowchart asset and that is executed as soon as this node is reached in the flowchart. In fact it's a Function-like single eventblock with its children. It can have any number of actions/Condtions/Subevents, but can't have any parameters. Under the hood it would be exactly the same implementation as a function except it can't be called via "call Function" action, it's only automatically called when the node is reached.
    • When we click "open node function" it would open a pop-up that looks like a more restrictive mini-eventsheet only displaying the Node Function.

    It would allow us to do crazy stuff with ease.

    Like playing a particular sound when the node is reached/setting a global variable or anything useful for any Quest/Dynamic Cutscenes/Dialogue/AI/Movement system.

    And it would avoid the need to handle the cases with Triggers events placed on Eventsheets that would create dependancies everywhere between actual Eventsheets and Flowcharts using Triggers that would ends up being a mess for big projects (Triggers are also useful but really embedding logic per Node would be amazing).

    NODE CONDITIONS (And node Types)

    this suggestion is built upon the previous Node Function suggestion

    • All conditions that are directly under the Node Function (so not in its own subevent but directly at the root) are the "Node conditions".
    • They could be the only ACE of the related Node Function that are also displayed directly in the flowchart. So it's more readable for state machines or conditional flowcharts.
    • There would be a condition to check if the current Node Condition are true (so no need to handle every single cases manually in Eventsheets), it's just done "automatically" by default.
    • 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.
    • 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.

    Even if it's NOT what i'm describing here is a visual representation of the Quests Module of Game Creator 2

    EDIT : Node Conditions and On Node Enter should be 2 seperate Blocks on a "Node Sheet", along side with On Node Tick and On Node Exit, everything is detailed on a mockup on my next post here : construct.net/en/forum/construct-3/general-discussion-7/new-flowcharts-feature-r370-179833/page-2

  • "Infinite loops" (looping Flowcharts) make sense for all kind of State Machines/FSM that could be used for AI Behaviors, Game States, and UI state. (but also for creating complex Platformer/Movement behavior or that kind of stuff)

    Great to know backlinking nodes and referencing flowcharts directly are considered for future updates !

    Here are a few screenshot of a cool Node-tree tools using Actions and Conditions called Game Creator 2 (and its module Behaviors), I think those would be inspiring for C3 Flowcharts

  • Would it be possible to create a special "Linked Flowchart" Node ? with a clickable button to open the referenced other flowchart.

    Currently, the way we have to do it is creating a custom logic with ACE. Everything is string based and it's difficult to navigate from one flowhcart to an other within the editor, must go to the bottom of project view everytime, looking for the right flowchart etc. Here is how it is in the example.

    Would be cool if we could actually reference actual flowcharts directly in a new Node Type.

    Referenced flowcharts could also have a list of all the backlinks of other flowcharts referencing them.

    So we could easily naviguate from one flowchart to an other (from referencing to referenced AND from referenced to referencing), it would enhance the UX a bunch.

    HOWEVER : We should still be able to change those new "flowcharts output" by name/string at runtime thanks to new ACE for more flexibility, in addition to new dropdown list ACE

  • CONSTRUCT IMPLEMENTATION SUGGESTION (Wip)

    (I'll edit this post to add C3 Mockups later)

    I beg Construct Team to deeply look into those tools if they ever consider adding such a Node-Tree feature :

    • 1. Game Creator 2 and its modules (Unity 3rd party)
    • 2. Muse Behavior (Unity official)
    • 3. Dialogic 2 (Godot 3rd party)

    All potential use-case should be taken into consideration (from State Machine/BehaviorTree to Utility AI and Dialogue Systems), it should be versatile enough to be able to do everything.

    EDIT I refined this suggestion in this post based on the Flowchart feature C3 Team just released

    construct.net/en/forum/construct-3/general-discussion-7/new-flowcharts-feature-r370-179833/page-2

  • EDIT : Flowchart feature was released in r370 by Construct Team.

    I detailed here the suggestions about how it could be enhanced to become a powerful addition to handle Game Logic to create Dialogues / Quests / Combos / States Machines and Behavior Trees.

    construct.net/en/forum/construct-3/general-discussion-7/new-flowcharts-feature-r370-179833/page-2

    I created this thread to discuss about a "ACE-Based Node Tree" suggestion that would allow us to decuplate the visual scriptings capabilities of Construct. (to create State Machines/Behavior Trees/Dialogues/Quests)

    First post is the explanation of the full potential of Node Tree in C3 and a benchmark of the best implementations of "ACE-Based Node Trees" in the game engine market, second post will be more about how this feature could be implemented in the context of C3 (still didn't have time to write it and do quick mockups)

    TLDR :

    • Eventsheets-based visual scripting is awesome
    • [Top-to-bottom visual scripting like C3, using Actions, Conditions and Expression (ACE), executing logic contained in Plugins and Behaviors under the hood]
    • Node-based visual scripting is bad
    • [by that I mean Blueprint-like nodal system which quicly become very messy]
    • NodeTrees built upon Eventsheet is INCREDIBLE.

    Yesterday, I randomly stumbled upon a <100 views hidden Video of an upcoming Unity feature called “Muse Behaviors” : it’s basically a mix of something similar to the Actions & Conditions we’re using in Construct 3 with a Node Tree. To be honest it's mindblowing, and it looks like they plan to use Actions/Conditions for more systems (maybe Unity Eventsheets ?)

    Subscribe to Construct videos now

    When i saw this video, it gave me the urge to suggest something i’ve been thinking about from quite a long time : “ACE-Based Node Tree” or “Node Tree Eventsheets” in Construct. It would probably require a huge amount of work but I think this is a perfect match for Construct 3, which would be the best engine on the market to integrate that kind of stuff thanks to his amazing Eventsheets and all the Action/Condition/Expression features that exist thanks to all official and 3rd party plugins and behavior.

    If done right, it would allow us to create all kind of extremely powerful systems :

    • Behavior Trees
    • States Machines
    • (Behavior Tree and State Machine, other kind of Trees could be useful not only for AI but also to create the global flow of our Game, like a Game Manager but also advanced user interface system)
    • Utility AI
    • G.O.A.P
    • Dialogue System
    • Quest System
    • And even more : Combat System ?

    Game Creator 2 and its modules

    The reason I’ve been thinking about that is because i’ve been playing for a few years with a wonderful 3rd party Unity tool suite called Game Creator 2. I’m 100% sure Game Creator 2 is inspired by C3, and then the Unity Team was inspired by Game Creator 2 and its innovative tools to create their own “Muse Behaviors” they’re about to announce.

    I’m talking about those tools because they help to understand the full potential of Node-Tree using ACES and it’s the closest possible implementation that could be done for Construct 3.

    Game Creator 2 for Unity is a suite including a base tool and a bunch of modules.

    The Game Creator 2 basically implements a ACE (Action/Condition/Expression) system very similar to how Construct 3 works, but in the Unity context.

    With base GC2 you can create your "eventsheets" directly on your objects using the Unity Inspector (not as cool and easy to use as C3's global eventsheets, but still the best visual scripting system ever created for Unity - ugh i hate Unreal Blueprint-like nodal systems that most softwares implement for game-logic)

    However GC2 additional modules also allow you to create logic as seperated assets that are composed by "Tasks" (= Mini Eventsheet blocks composed by Actions/Conditions), there are 2 main categories of "Task Trees" :

    • GC2 TASK TREES (used in Behavior Module)
    • GC2 TASK HIERARCHIES (far more pleasant to use for stuff like Dialogues/Quests/Combo)

    1. GC2 TASK TREES: BEHAVIORS MODULE

    (State Machine, Behavior Tree, Utility AI and G.O.A.P)

    GC2 built Node-Tree systems on top of Actions, Conditions and Expressions to achieve the 4 Main type of AI systems used in the Game Industry. (they can in fact be used in far most situation besides just AI)

    Those are basically like "Trees of Eventsheets" made of "mini-Eventsheets"

    Official GC2 Behavior documentation: (worth a read)

    Showcase video: (go to 13min10 to this it in action even if the explanations before are really interesting)

    Subscribe to Construct videos now

    If you want to understand the incredible potential of those 4 Node Tree AI system, i also totally recommend to watch this wonderful Gamer Maker’s Toolkit video explaining how each of those type of AI, and especially Utility AI, were used to create one of the most innovative and fun gave ever : The SIMS. Awesomesauce.

    Subscribe to Construct videos now

    Utility AI : Basically you define the "needs" of a character and it automatically picks the correct goal based on what should be prioritized. It’s used very cleverly and at different scale in the Sims to handle the behavior of each character but also for more abstract concept such as neighborhood in the Sims, to create powerful story machines constantly creating emerging gameplay and situations.

    2. GC2 TASK HIERARCHIES :

    Dialogues, Quests, Combo etc...

    GC2 use a different king of "Task Tree" for its Dialogue/Quest/Combat Combo modules, they looks more like a Hierarchy of "mini eventsheets" (=Tasks) that is far more readable and useable for that kind of purpose.

    It's also the kind of system used by Dialogic 2 for Godot (the last cool visual scripting tool I wanted to mention in this benchmark)

    It's basically like an "Super-Eventsheets" made of "mini-Eventsheets"