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 :
- No more string checks for everything
- 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).
- 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.
- 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
- 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)
- 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)