Event Sheet style visual scripting

NOTE:
Here is the test repo that I added the prototype project to
https://github.com/blurymind/Godot-eventSheetPrototype
Everyone is free to fork or do pull requests 👍
IDEA:
We currently have a visual scripting system similar to blueprints in Unreal - connecting nodes.
The proposal here is for a second visual scripting system, that is similar to event sheets in Construct 2 (proprietary), Multimedia fusion (proprietary) and Gdevelop (open source)

It is a very different approach from the one with blueprints and people learning to program are still requesting it on facebook and other godot community forums
What is an event sheet visual script in the other engines:
https://www.scirra.com/manual/44/event-sheet-view
The event sheet is pretty much a spreadsheet with two columns - a conditions column and an actions column. Both columns can be populated with logic blocks from nodes and their children that the sheet is attached to (node methods). On the left column the user can only attach conditional methods, on the right - only action methods. This clear divide makes for a very easy to learn way of setting game logic.
On top of that the user can use expressions in both columns - so potentially use gdscript for more specific instructions.
Rows can be nested under other rows (called sub-events), can be commented, disabled or re-enabled (just like commenting code)
https://www.scirra.com/manual/128/sub-events

Some actions/condition blocks can be negated
Functions that can take parameters can be used as well, by using a special function condition block and nesting conditions/actions under its row

So What are the advantages over our current visual script:

It is an alternative style of visual scripting with a big following - a quick look at the number of users of construct 2 and the number of succesful 2d games made with clickteam fusion should be a good enough indicator. It has also been requested on Unity forums too
https://feedback.unity3d.com/suggestions/create-a-visual-scripting-for-begginer-like-construct-2-or-behavior-machine
https://feedback.unity3d.com/suggestions/visual-scripting-based-in-event-sheets-as-construct-2

It is easier to learn and arguably clearer for non-programmers

An event sheet can pack much more information of the game logic on one screen than blueprints - less scrolling and panning to get the information. Less wasted empty space between logic blocks. You can technically just take a screenshot of an event sheet and share it to show someone else how to do something.

It is easier to transition learning from event sheets to scripting - because it's more similar to scripting    than blueprints

Why is it easier to learn than blueprints - the clear divide of condition and action and obvious order of execution. The user gets a filtered list of things to do on the two columns.

Logic blocks are easy to quickly read/find because they have icons. Most nodes in godot also have icons - they can be reused for the event sheet implementation

Less clicks needed to get things working - no need to connect nodes or move nodes on the blueprint table.  You just add or drop logic blocks in the cells. No need to pan at all- you only scroll and its much less.

In any case, I am writing this proposal not to say that one system is better than the other - but more with the hope of sparking interest in developing an alternative to our custom visual scripting approach - an alternative that is popular amongst people learning to code and that is a great transition to gdscript - as I found out from first hand experience
Addon progress report 0
Here is a crude mockup so far:

Demos of event sheet style systems that you can try online(no log in required):
https://editor.gdevelop-app.com/
https://editor.construct.net/
Event Sheet System Possible Structure:
|_Event sheet established variables and connections tab
|_Event sheet script tab
  |_Function(built in or custom)
      |_event sheet row (can be parented to another event sheet row or an event sheet group)
          |_Actions column
               |_Action cell (richtex label) (click to open another window to edit)
          |_ Conditions Column
               |_Condition Cell (richtex label)(click to open another window to edit)
|_Action/Condition Cell Expression Editor
  |_Gdscript editor instance - to be used for expressions
  |_Easy Click interface to access the available subnodes - their nodepaths and methods- clicks bring up menu that populates the expression editor - similar to Clickteam Fusion's

Inner workflow:
Event sheet resource can be attached to node -->on runtime it generates a gdscript and that is used by the game
Addon progress report 1
I did some work on the addon's most important building block- the event sheet cell

Some background in what it does - Basically the event sheet is made out of cells. A cell can contain either conditions (getters/expressions) or actions (setters that can be fed with getters/expressions).
On the GUI side, the event cell is created via a richtextlabel node and bbcode that is generated from gdscript. When you double click on it, the richtextlabel turns into an editbox node containing the actual gdscript expression.
So an event sheet cell has 2 modes:

edit mode - textEdit node that can be typed into with gdscript.
The only difference is that the user does not need to type in If/else/while - that is context sensitive to the parent container as seen in the screenshot. Every line is a new condition, so if the user hasnt started the line with "or" or somethind else, the parser automatically knows that a new line has "and" pretext

When clicked away, switches to view mode.

view mode - richtext label - When switching to view mode, a bbCode gets parsed from the gdscript that is in edit mode and presented via an interactive richtext label. Apart of being interactive and easy to change , the goal is to present the gdscript code in a clearer way. This means showing the node's name and icon only (not the entire path) and getting rid of some words, when its obvious (such as get_ and set_). Since every clickable part is actually a url tag, when hovering over a node name for example - the user can get some information, such as the full path of the node.

About the Add new condition/Action menu:
This is what creates a new gdscript line of code for a condition or an action. Whats great about it is that it lets you easily browse all of the nodes inside a scene and their methods - it sort of works in an inverted way to how autocompletion works in gdscript's editor. It shows all nodes and all of their setter, getter or both methods. You can then narrow down to what you want via a filter.
If callend from a condition cell, this menu shows only getters, if called from an actions cell, it shows both setter and getter methods.
Note that this is still full of bugs and not even half complete to share, but hopefully makes it clearer what I am proposing
Progress report 2
Made some planning on how it can work. Also looked into what needs to be refactored before presenting the concept addon
I made this flowchart to explain how it works at the moment
https://www.draw.io/#Hblurymind%2FGodot-eventSheetPrototype%2Fmaster%2FEventSheetDiagramPlan.xml

Decided to refactor it to generate typed gdscript
#19264
Its much easier to create bbcode links for further helper menus when its typed

Couldn't a lot of this be alleviated by empowering the current Visual Scripting with more and better functions?
A lot of the examples are trivial in UE4's blueprint. "On keypress W, move this actor forward".
You could build most of these in a very similar way in blueprint and even the visual differences (which would be the only ones) would be minimal.
We should focus on making the Visual Script we have usable and work in a intuitive, smooth way, IMO. As is, the Visual Script we already have feels a little forgotten and doesn't seem to get much love. How would having two Visual Scripting systems improve this situation at all?

A good idea for a plugin. But officially maintaining two visual scripting systems would be a pain, and for little gain.

@mhilbrunner unfortunately no , Blueprints are a completely different approach to visual scripting. To you they are trivial, but I dare you to say that on clickteam's forum or on construct's forum. Those guys are stuck with the engines they use because of how much they love this approach and believe me - many of them have tried blueprints in Unity , unreal and other engines- including godot. They are still stuck with construct2 or clickteam fusion because they prefer event sheets to Blueprints. They still request event sheet approach on unity's forum
@groud I thought the same for a while, but I'm not even sure where to start - and even as a plugin- someone will have to maintain the plugin.
@reduz seemed to feel warmer towards the idea on facebook, but I understand that he has his hands full with more important things

@blurymind Yeah, and thanks definitely for pointing this out and taking the time for the detailed write-up. Still think this would maybe be better as a plugin.
@devs: What is the best way to add this with minimal complexity? Maybe I'll find some time to look into how current visual scripting works. Wonder if it is possible to mostly just replace Visual Scripting UI or generate GDScript or some other way of dynamically doing this.
Haven't looked into any of this yet though, so pointers welcome. :) No nil pointers, please!

@mhilbrunner we can perhaps open another issue on the tracker with a list of things the blueprint system in godot needs in order to be more intuitive

I believe such event sheet could be implemented via Nativescript, but I don't see any reason why it would need to rely on the same codebase as visualscripting.

@groud that is a good point actually. How much of the current visualscripting codebase can be reused? How specific is it to the nodegraph interface?

@blurymind Yeah got you, working on such a list for VS and will do, but will take some time.
Need to investigate NativeScript :)

We now have multiple choices for scripting languages (C++,C#, even python). Why not also have more than one choice for visual scripting :)
I guess this could also depend on how flexible godot's api is for building visual scripting interfaces.
Should the visualscripting codebase be reused - or should a completely alternative one be written with Nativescript (c++)?

Why not also have more than one choice for visual scripting :)

Because we already support too many languages as built-in. Most use cases are already covered, so there not a lot of reason to add on new language to maintain. We have a language for basic programming (GDscript), two for performances (C# and C/C++) and one for artists/game designer (visual scripts). There's no reason to add another language as built-in just because some people can't handle learning a new language.
Honestly, I definitely don't think this should be added to the core. It would be better added via a plugin like any other language binding. We already have enough work on maintaining the current languages.
And no, I don't think we can reuse the visualscripting's code.

@groud That is a good point , but consider the ratio of programmers to artists in gamedev. Some of the greatest, most beautiful retro 2d games have been made with fusion 2 by artists who wanted to make games in an intuitive way that fits their way of thinking. Here is a bit outdated showreel of Fusion made games:
https://www.youtube.com/watch?v=3Zq1yo0lxOU
They have many many succesful kickstarter projects and games on steam. People like to use this approach in visual programming. I wouldn't be presenting it here if I didn't see potential of expanding the userbase

Well maybe, but how many of them are able to understand Event Sheets but not VisualScripting ? You're saying that "those guys are stuck with the engines they use because of how much they love this approach and believe me - many of them have tried blueprints in Unity , unreal and other engines- including godot", but you're actually the first one to ask that.
If this is a popular demand, yes we could add it to the core. But until now it's not.
For me, we already cover all the use cases. At least for a state-of-the-art and professional game engine. And as we don't target kids or hobbyists but companies, it's not worth spending time on it. Fusion 2, Construct or even RPGMaker focus on another audience, even if beautiful game have been made with them only a tiny part of them are professional projects.

@groud these stats are hard to come by. How many are using the current visual script?
I am also making points of why the event sheet approach has advantages over blueprints - such as less clicks to get things working, clearer presentation and better transitioning to gdscript.
The rpg maker engine is really a level editor if you ask me. It doesnt have the same level of flexibility as Fusion and construct2

How many are using the current visual script?

I have no clue, but I believe not a lot for now. Most people seem to use GDScript for now, since I don't see a lot of questions/content regarding VisualScripting on Facebook or Youtube. Adding Event Sheets before being sure that VisualScripting does not answers all use cases would be an audacious bet. Let's just see for now if VisualScripting is enough, and if people massively ask for another system, we might add it later on.

@groud would be great if we could test godot's visual script in a school environment - with kids learning basic coding concepts.
One of construct2's biggest selling points has been to teach kids coding and they have been selling a special educational license for years.
My argument is that visual script in godot at the moment is not very inviting to non-coders and doesn't really help people learn how to code - because its approach is purely state machine centric.
Experienced programmers are really not the best audience to sell this to- because they would see it as a simplification of what we already have - gdscript and will see blueprints as a new tool that could be used as a state machine by designers.
Which is simpler to use at the moment - Blueprints or Gdscript?  I have no idea why you would think that. VisualScripting has nothing to do with state machines.

Which is simpler to use at the moment - Blueprints or Gdscript? What the goal of visual scripting is and who the target user is

VisualScripting should be simpler than GDscript for artists/game devs. I have to admit it is not really for now, probably that a bunch of nodes might be simplified / made more appealing. But honestly, you are wrong thinking that Events Sheets are easier to understand than VisualScript, to me they are not.
The only thing that actually makes the difference in the examples you show are the text and the icons that make things a lot more understandable. It's the text and icons that make things more explicit and straightforward, not the vertical organization. VisualScripting would be as understandable if we added such icons, if we made a better GUI for most common actions, and group the functions into pertinent categories.

@groud its also the order of execution and the types of connections. There are way more concepts to look out for in the nodegraph than the event sheet. Even if you add icons to nodes, you still have to explain that the order of events is dictated by the white lines, also what the other colors mean. You still end up with a spaghetti graph that is harder to read - your eyes have to travel all over the place to figure out what's going on in someone else's graph

Come'on that is not that hard to understand, once again we're not targeting kids.
And regarding the code organization, the problem is the same for event sheets. If you don't bother grouping nodes and organizing your code you end up with unreadable code, whether it is due to lengthy event sheets or huge node graphs.

@groud can we even group visualscript nodes like in blender? I don't remember seeing that . Perhaps @mhilbrunner should add it to his list
https://github.com/godotengine/godot/issues/12418
Another important point is made there- ability to create reusable higher level action/condition logic blocks via gdscript would be very beneficial for an event sheet system or a blueprint system.
If an event sheet system was a part of godot, collections of custom logic blocks could be shared as actual addons on the asset repository to enrich it. That would make it extremely easy for the community to expand the built in visual scripting via addons that add higher level logic control.
Again - construct2 is way ahead of us. Their community has created many many many easy to install plugins that add custom conditions and actions to be attached to an event sheet
https://www.scirra.com/forum/completed-addons_f153
Has anyone created any custom visualscript nodes via an addon yet?

Totally in accordance with blurymind
For me it is much easier to understand the Construct and Fusion event system, which also offers much faster to develop any game than a system full of lines

lol how is this more easier to read than gdscript

@groud can we even group visualscript nodes like in blender? I don't remember seeing that

I don't know. But if it's not implemented, I think it should be.

lol how is this more easier to read than gdscript

This is not the point here.

@groud yeah it is. why would a game dev want to use event sheets when it's far more disorganized than simple gdscript code?

@groud yeah it is. why would a game dev want to use event sheets when it's far more disorganized than simple gdscript code?

No it's not, VisualScripting (or Event Sheets) and GDscript does not target the same people. VisualScripting (or event sheets) are for artists or game/level designers while gdscript requires programming experience.
Comparing Event Sheets and GDscript has no sense.

Comparing Event Sheets and GDscript has no sense.

well, that's where we differ :P because i think it's more than reasonable to compare them. especially since gdscript does everything they do, at a much more simpler level.
also, i disagree about the "requires programming experience". if a level designer is creating blocks of actions in an event sheet or visual scripting already, they already have the fundamental building blocks to use gdscript.
with that said: JIT-compiled gdscript is on the roadmap, and would be far more beneficial than event sheets or visual scripting (since the majority of godot devs could benefit greatly from it). and the potential use cases of VS/Event Sheets are pretty low currently. so I am asking please be cautious about lead dev time, as your recent post has already alluded to

@girng at what point did you decide that I am trying to steal priority of other important features on the roadmap? This post is exploring the benefits of visual scripting via an alternative method to the one we have at the moment.

You have obviously never touched construct or clickteam fusion , if you want to have a discussion about it - at least use the event sheet for a while- make a platformer with it.
I linked to an online demo of construct3, which doesnt require you to register an account or log in.
Try the event sheet, make something with it. Then use the visualscript blueprints that godot has
Gdscript is simple- yes I agree and love it too. A jit-compiled gdscript would be awesome! Agreed its more important too.
But this discussion is not about those things at all

well, that's where we differ :P because i think it's more than reasonable to compare them. especially since gdscript does everything they do, at a much more simpler level.

What you don't understand is that for a lot of people there's a mind barrier between coding and not coding. I have to admit that VS is a little bit hard to get into for now, but in the future it should be easier than GDScript since a lot of learning material might have been created and several VS improvements should be done.

also, i disagree about the "requires programming experience". if a level designer is creating blocks of actions in an event sheet or visual scripting already, they already have the fundamental building blocks to use gdscript.

Yeah, I quite of agree too as a programmer, but this is not what experience shows.
Unreal is the perfect example: a lot of people use blueprints with Unreal, especially in professional area, since they allow non-programmer writing code in a more welcoming fashion. Even if it's not that different from actual code (in my opinion), it makes the differences in people minds. If professionals use it, it means it's a real need, not a gadget we should drop because we think they are the same thing. That's why it makes no sense to compare them, both should be available and working correctly.
Anyway, I'll stop this discussion here. The bikeshedding about VS or not VS has been already treated.

@blurymind i admire your energy and you make good points. i've tried event sheets in construct  before and they are were cool at first, but the more advanced my game became, i instantly wanted to go back to code.  so yes, i have tried them in the past.
@groud  makes a good argument about them, as Marvel Heroes was a AAA aRPG and they used blueprints w/ Unreal.
i don't disagree they have their use cases, i just think it will be hard to justify, based on the following criteria:

limited dev manpower
amount of current issues already
disorganization / hard to read (see here)
i feel most godot developers would rather use gdscript
gdscript ties so nicely with godot already
if added to core, new issues could arise surrounding the event sheets, which could take away from gdscript issues
not fair to the current 90% of godot devs using gdscript already (if dev time could be used for jit-compiled gdscript, which fulfills active use cases)

as a plugin i could  fully support, but my heart is saying it might not be a good idea if it's officially supported

@girng thank you. Once again - this is not a request to replace gdscript or visual script.
It's more of an observation on visual scripting in general and how godot's visual scripting at the moment is really not user friendly to non-coders. Nor are blueprints.
Gdscript can tie in beautifully with any visual scripting system - event sheets or blueprints.
As noted in my first post - the event sheet approach uses expressions - for which gdscript can be used. Higher level logic blocks could be created via gdscript and godot's plugin system.
In fact an event sheet system can be much better married to gdscript than the current blueprint system- where expressions are done with a billion node graphs rather than simple expressions. If you want do do 1+1- use another node. If you want to address a simple variable in an expression- another node. You end up with a spaghetti mess of a billion basic nodes for a simple expression that could just as easily and clearly be written in a text field with much less effort and verbosity.
The current visual script we have takes way too many clicks, nodes and verbosity to do the simplest things. Thats another reason gdscript is more straightforward imo.
That is basically the other advantage of an event sheet system- you can just write your expressions. Both construct2 and fusion even have autocomplete and expression editors with easy access to all of the methods that a node has with a list of all of the nodes the sheet has access to in scope.

Godot could very easily simply use gdscript for expressions when doing the same thing

The current visual script we have takes way too many clicks, nodes and verbosity to do the simplest things.

That is not a inherent flaw of VS, but of its currently limited implementation. This should be fixed, not be used as an argument for implementing another visual scripting method next to it. Otherwise, the current VS should be scrapped.
Also, discussing JIT for GDscript is offtopic. The merit of a feature can only be measured by:

it's usefulness versus other, similar features that may be useful for the same use case
it's usefulness versus the complexity it brings to the table, the added technical debt and maintenance burden for Godot

So whether or not this should be done has nothing to do with whether or not we implement JIT for GDScript. Otherwise, we should close 99% of all feature requests until all major bugs are fixed, i.e. forever. Those are even more important than JIT for GDScript.

@mhilbrunner JIT for GDScript is actually going to happen though, it's already on the official roadmap :P. i was just saying this could take away development time from that. and it's hard to justify that since  90% of the godot developers already use gdscript (and a lot of people think its better than event sheets, and have their own feelings).  sorry if i didn't convey myself properly
with that said, @blurymind i can't disagree with anything you have said because they are really good points. would having event sheets in Godot be a nice feature to have? sure, but is it something that will happen in reality soon? i'm not really sure.  (just an avid user since 2014, and this is just my opinion)

Having used Action Game Maker and Game Maker event sheet previously myself, I agree that it's easier to use and understand than VisualScript (you read from top to bottom, not following lines), doesn't take as much screen space, and can implement finite state machine more easily (by filtering which events can be triggered after an event finishes).
It'd be a very nice addition. I probably won't use it myself as GDScript is enough for me, but I can imagine myself using it just fine if GDScript is not an option (which beginners and non-programmers are probably experiencing).

Well, i'm a Godot user for about a year. I love GDScript and it's simple syntax.
But i've used Construct for more than 8 years and i can say i never saw a easier Visual Script than Event Sheets.I don't like Blueprint and i used some others VS Blue Prints styles, like blender's and Unity's, and i don't get it how people can say Blue Print are easier than Event Sheets.Maybe it's because artists are used to use nodes to setup shaders and graphics, they are used to this aesthetic. But i bet if you put an event sheet system in a engine like Unreal, people would drop Blueprints.
I work at a school that teaches programming logic to kids and teens. For kids we use Construct 2 because it's painfully easy to them create something with Event Sheets. For teens we use GDScript and we had good results with it. When Godot 3.0 came out, we studied the idea to drop Construct 2 to use Godot VS, but we abandoned the idea because right now VS is harder than GDScript, very complicated to understand and to use. If Godot had something like Event Sheet we would made our course fully based in Godot, because we tend to favor Open Source solutions at the school.
Other benefit i think Event Sheets would bring, it would increase Godot userbase, since in GDC we saw medium to big studios prefer Godot, but small ones prefer Unity and other solutions. I think users from Construct, Fusion and Game Maker would start to migrate to Godot.
Well, as a teacher i see a great value in Event Sheets, because it's very eays to grasp and when the students move to GDscript, they already developed a logical thinking and events Sheets structure are more like code than Blue Prints.
Anyway, i love what Godot is doing and love GDscript, i just wanted to throw my experience, as i use both Event Sheet and GDscript to teach. Keep the great work!

When Godot 3.0 came out, we studied the idea to drop Construct 2 to use Godot VS, but we abandoned the idea because right now VS is harder than GDScript, very complicated to understand and to use

That's quite an interesting feedback. :)
The fact is that Event Sheets, in the Construct2 form, are a lot less low level than VS or GDscript. Indeed they can help kids to get into game programming but it's not Godot's target. I believe such system should not be shipped as built-in, but available via a plugin. I guess this comment from reduz expresses this too.

@DrZanuff  thank you for bringing up this really important point - it has also been noted by the kidscancode youtube channel and @NinkuX  - event sheets are great for a school environment and a great transition to something like gdscript.
Perhaps Godot can approach this in the way game maker does - their drag and drop visual code is directly translated into gml code that can even be previewed in real time. That way non-coders can learn gml while they are using the visual scripting system of the engine - it's the exact strategy yoyo games employs to get non-coders introduced gradually to gml
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

Both when using some gml for expressions and as they preview what their visual programming is doing
Even when planning to implement it as an addon - I kept thinking that godot's event sheet objects should in the end be translated to gdscript. In that sense- the event sheet can also be perceived as a tool to teach non-coders how to use gdscript- by giving them an easy interface that still allows the use of gdscript for expressions and in the end generates and previews gdscript anyways.
Godot's API has a method to generate gdscript files and attach them to nodes. So  an event sheet can either be translated to gdscript when running the game, or even while editing the event sheet- like game maker does.
The added learning aid that both clickteam fusion and construct2 employ is a click based menu of built in node methods

As the student clicks on any of the items in the list, the appropriate syntax is added to the input field. When they start learning they click, but as they click they learn and memorize the syntax and the methods. Later on instead of clicking, they are typing with autocompletion and without realizing have learned the api

I think it does not explain well ... :(
When I say lines, I refer to visual scripting, to the lines that connect the nodes
The construct and fusion event system is much more intuitive, easy and quick to create a game, than the Godot visual scipting
It would be good to explore an alternative of this type

@groud higher level features in godot's visual script blueprints can also be written as plugins.
It would take much less work to create and maintain higher level functions for the current blueprint system, than it would be to write functions AND an entirely different Event Sheet system as a plugin.

I teach programing for kids between 7 years old to 17 years old. Currently the younger students are using the Cosntruct and the olders are using Godot, but if all my students could use de Godot would be trully gratefull for the kids be using the Godot from the begning of theirs journey on this world of game developers.

Is not only the event sheet system. Is also how the plugins/behaviours/families , the UIDs and objects properties works.
For example in C2 in one object sprite i can have all the game art, including static/animations of decoration, player, enemies,etc... all with their collisions,etc... and place in the layout selecting what frame at start and using an instance variable on the object called "type=" to tell if is a enemy, player, object, breakable,etc... to in events set his behaviour. Also for each sprite you have some basic paint program, animator properties,etc...
In Godot i tried the Pong example in visual scripting and when i saw it uses one sprite for the player and other sprite object for the collision, and i was like , WHat!? . Also C2 have a "guess polygon shape" that with one click makes the collision of your sprite using 8 points. After that you can add more point and adjust to be more precise or use some plugins or tricks to get pixel-precision.
I mean, if godot apply the event sheet system like in C2, but not follow the same philosophy to make it all easy to use, will be a waste of time because not will work. And well, do all this in the actual Godot engine can be a really crazy work.
In case to go ahead maybe they should ask/hire to the big guys lof C2 like RexRainbow, R0j0hound,etc... that knows what are the best and worst things and make a really good event sheet system without all the C2/C3 mistakes. But as i sais, that will means lot fo work and money.

@matriax I don't think you are correct here.
Godot has a much more flexible and straightforward architecture than Construct2.
As noted object pairing is a pain in construct, among many other things.
Some of the things you are requesting should be done as addons and have already been made as addons (guess polygon shape for example)
Implementing an event sheet system in godot that fits with godot's current architecture would result in a better event sheet system than construct's - because godot allows for much more flexibility in coding styles. Exanding that system with higher level functionality via plugins would make it as user friendly as construct2's.
Making godot as user friendly as Construct 2 would need to be a joined effort imo - of both of godot's core developers and it's community. The community would need to create the higher level functionality via event sheet addons

@blurymind I'm not saying about apply the same architechture than in C2, that is no sense, also i don't know all the stuff Godot already have like the groups, child nodes,etc.. you said.
What i mean is that add an event sheet system on Godot without follow the same philosophy to achieve all work in a easy way like in C2/C3 will be a waste of time. Like as i said, having one object for sprites/collisions or all gameart instead one object for each thing.
Maybe they should ask to the community how many people is using the actual visual scripting, and how many people will prefer the event sheet system then take a decision.

@matriax you need to learn Godot before making such claims :)
The proposal here is for an event sheet, not for an entire engine copy of construct2.
Knowing both engines- I strongly believe that an event sheet can be done in a godot centric way and it would make godot as good if not better tool for teaching younger kids about programming.
In that sense an event sheet entity would be equal to a script file - similar to what DND in game maker does, nothing in the engine or how it works should be changed.

@blurymind And again with the same thing, ok forgot it .

@matriax It would be good to ask a target group of people - not just anyone on the internet. A target group could be students and teachers - that would actually be the perfect target for an event sheet system.
If you just ask on the godot tracker- you are going to get mostly experienced to mid programmers- people who already know and love gdscript, the engine's api and even c++
They will react protectively - as you can see in the start of the post- thinking that what you are proposing is not what they need- naturally because they already know how to write code in gdscript.

I've been trying to come up with a proof of concept addon. It doesn't do anything at the moment - it's just to figure out how the interface could work and tie with godot's architecture

It would be cool if the richtextlabel node in godot could use internal godot editor icons
I will make another mockup for an conditions/actions editor when I get the time :)

@blurymind Nice, i liked the concept.
Maybe the buttons to add actions and conditions should be without the background button, like in construct 2

And i think it would be nice a line to separate the condition from the action

I like the way this is turning ou.

That's a really neat mockup. At first I didn't really understand what you were getting at. Now it's really clear... sort of an intermediate step between programming and the kind of visual scripting that we already have?

@Zireael07 exactly - a tool that would help us replace Construct2 completely with Godot in Schools that use both engines to teach programming.
Underneath it is just a visual interface for generating gdscript files - similar to how DnD is used in Game maker 2. I am not requesting any changes to godot's excellent architecture.
Event sheets can be a visual scripting option in Godot that is user friendly for non coders (blueprints are not) and young children learning programming concepts - easing them into gdscript
In this case we are targetting people with no programming experience and children learning programming concepts.
Godot already has a lot of the elements to make this work btw, but it cannot be exactly the same as in Construct2. In godot's way it will be better in a number of ways if it happens. Construct2's event sheet allows some really bad code organisation practices and has some awful limitations. We can actually make a better event sheet than theirs that is as user friendly

Love your work on this. Would you be willing to make it available in a repo as you work on it (if you do)? Would like to have a look and poke at it and play around.

@mhilbrunner I am in the process of integrating the gui into godot's editor as a gdscript plugin
Will publish it on github when I get the basic GUI working interactively to communicate my design ideas :)  Today I got the event sheet gui to load as a tab - taking some inspiration from the sketchfab plugin:

Will post more update screenshots and eventually a link to the github

@blurymind very good! Now it's more readable. We need the to think how the action list will show to the user.

One thing i liked from the old Construct Classic was the option to edit the values from the event sheet without open the action or the condition, but double click over the value to edit it:

If someone wants to add this (on their own as a plugin) then, no harm, no foul.  Otherwise, I agree that visual scripting can be improved.  If someone needs construct, then I say, continue to use construct.  Godot doesn't need to emulate every other system out there in it's core.   Let the software keep its focus and not become a "jack of all trades, master of none" due to diffused focus.

@spyres depends on whether @reduz and godot team wants to target younger students in schools.
I personally think we can replace construct in schools with godot completely.
The current blueprint system is not going to work for that. It's more complicated to use than gdscript and as mentioned earlier- not the best way to introduce someone to programming paradigms- because it has it's own set  of rules.
Btw I am trying to make it as an addon, but I am hitting some limitations in terms of lack of documentation or api. I want to register a new resource type and I want to inject my event sheet editor inside the scripts tab.
@DrZanuff Godot has a way of listing all the methods that exist in a node, but I am not sure yet how to filter them to actions or conditions. Might have to come up with a more godot centric way to do that. Still exploring it and am open for ideas :)

The assumption that visual script cannot (or will not) be greatly improved seems... Or that younger kids won't be able to use it, or grow into gdscript from construct) seems kinda dumb really.  Especially as visual script is pretty new.
If the solution for very young kids (which I have never seen the devs say is their demographic) is that large, let them use construct and then move on to a actual programming via GDscript when they're ready.
If you want to create it as an add-on and support that add-on, then bully for you.  But as something duplicative, bloating up the core and (likely) wasting limited official dev time with future support, integration, etc., no thanks.

@spyres are you a developer yourself? Or a teacher? Have you actually used godot's visual script on any of your own projects?

@blurymind I think your idea is good. Plus, you seems already have pretty solid vision of it.
But, I think "replacing construct in schools with Godot" is not valid reason to have this feature. I do not remember Godot have vision to replace other engine like Unity, Unreal, etc. Godot is not trying to crush other tools. If the reason is to increase productivity, I am agree with it.
I also agree with @spyres that Godot does not have to target education segment. If Godot is unsuitable to be a programming (not even game dev) teaching tool, so be it. It never meant to be in the first place. But if someone can somehow use/transform godot to be a programming teaching tool, I have no problem with that.
Still, I think this event sheet is an interesting idea to see.

@blurymind I think you are forgetting that godot is not a teaching tool, godot is a game engine. If you want to implement something like construct as an external module that's fine and up to you, but please don't try to transform something meant for game dev into a toy for kids. Why try to transform godot into construct if  what you really want is construct? why not use it instead of godot?

@zaniar @ni-code You are right. It's true that I am personally more interested in creating a visual scripting tool that is more efficient and clear than our current blueprint approach.
I honestly think that even if blueprints are improved, they will never be as clear and as fast to build as an event sheet.
As someone who has used both construct2 and Fusion, I love the event sheet approach and see in godot's api a beautiful candidate for an event sheet system.
Godot's node nesting design will work really well with that, combined with gdscript's clarity for expressions.
I am not expecting it to be implemented in godot, but I will continue to share progress of the plugin here, with the hope of getting useful feedback and help with the api. Some of the developers here have used Construct2 and known Godot really well, so good ideas might arise from the discussion

I look forward to Visual Scripting improvements that will (because they are fully integrated/supported) be more useful (and likely more popular) than any janky "construct-lite" kiddie plugin.

@spyres Please keep the tone civil. You don't need to tell others their assumptions are "dumb" or that the potential plugin they are investing (free!) work in is just going to be a "*janky construct-lite kiddie-centric" thing.

Sure, folks are free to spend their time (however useless I feel it might ultimately be) however they wish, however non conducive to the core design of Godot as those wishes might be.
Instead of Janky (which is certainly accurate in my view), and in the interest of civility, let's go with describing construct style design sheets as awkward, not focused on Godot's core demographic, something that is hoped will not waste core developer time, etc.
If there's a desire on focusing the 7 year old kid demographic, there's already construct for that.  Why re-invent the wheel?

@mhilbrunner answering his post feels like replying to a 7 year old troll :D
Not sure if it's worth posting here anymore , if every time I write an update he shows up with zero useful feedback or specific arguments

Wow, while I certainl questioned some ideas, I've never actually called someone names.  That is pretty abusive I'd say.
What would duplicating construct's functionality within Godot provide that isn't already well provided by er... Construct.
Is there a legit desire to duplicate Construct's feature set (probably in a lesser) way into godot simply to appeal to 7 year olds?
Why wouldn't you just use construct?  Is their setup (which some seem keen to duplicate) really that lacking?

@spyres you are using generally offensive terms to describe people who use event sheets.
They are not "kiddies" and the system is not "janky".
Construct2 has a lot of very experienced javascript programmers- which should have been evident to you if you have gone through the trouble to actually read what I write and follow the links I provided. Some of the addons they have made integrate it with 3d engines such as babylon and three.js even- so yes- experienced developers also enjoy using event sheets and make games with that.
Clickteam made games greatly outnumber Godot made  games on steam, kickstarter and even app stores in terms of revenue. That is an entirely event sheet based engine, used by 10- 80 year olds. It's a mixture of all ages.
My angle of selling this as a better tool for teaching programming should not be a reason to mislabel it like that.

Whoa! Shifting goalposts notwithstanding...
Let me clarify.
Construct is very good at what it does.  So good, in fact, that the need(?!) to graft /duplicate its feature set (in whole or part) in an entirely different engine (to no discernible benefit) escapes me.
The questions concerning actual benefits remain the same, though some might (inexplicably) find them "offensive".
Is the suggestion that an add-on grafted onto a completely different engine is going to be somehow better than using construct? Of that having something incorporated (even via add-on) is something that we'd expect a lot of people to use over the robust solution (i.e. construct)?  I doubt that.
But  hey, why stop there?  Excellent tools (beyond construct)  exist to teach kids programming (e.g. Scratch , Styncl, etc.)  Why not incorporate them into Godot also!
Or perhaps not...  ;-)

Is there anyone who has used Godot's visual scripting and it seems so good that he is only using Godot's Visual Scripting?

@Zonacas I don't think that Godot's Visual Scripting is mature enough for that yet, but I may be wrong. Keep in mind VS is only release for like two months at this point. :)

@Zonacas try looking at VS channel on the discord server, I have seen one or 2 self proclaimed non programmers that liked it (but is also full of programmers that say that it is not good for non programmers).

Hi everyone, I have a progress update on my proof of concept addon.
Here is a fresh gif for you:

Some background in what it does - Basically the event sheet is made out of cells. A cell can contain either conditions (getters/expressions) or actions (setters that can be fed with getters/expressions).
On the GUI side, the event cell is created via a richtextlabel node and bbcode that is generated from gdscript. When you double click on it, the richtextlabel turns into an editbox node containing the actual gdscript expression.
So an event sheet cell has 2 modes:

edit mode - textEdit node that can be typed into with gdscript.
The only difference is that the user does not need to type in If/else/while - that is context sensitive to the parent container as seen in the screenshot. Every line is a new condition, so if the user hasnt started the line with "or" or somethind else, the parser automatically knows that a new line has "and" pretext

When clicked away, switches to view mode.

view mode - richtext label - When switching to view mode, a bbCode gets parsed from the gdscript that is in edit mode and presented via an interactive richtext label. Apart of being interactive and easy to change , the goal is to present the gdscript code in a clearer way. This means showing the node's name and icon only (not the entire path) and getting rid of some words, when its obvious (such as get_ and set_). Since every clickable part is actually a url tag, when hovering over a node name for example - the user can get some infurmation, such as the full path of the node.

About the Add new condition/Action menu:
This is what creates a new gdscript line of code for a condition or an action. Whats great about it is that it lets you easily browse all of the nodes inside a scene and their methods - it sort of works in an inverted way to how autocompletion works in gdscript's editor. It shows all nodes and all of their setter, getter or both methods. You can then narrow down to what you want via a filter.
If callend from a condition cell, this menu shows only getters, if called from an actions cell, it shows both setter and getter methods.
What's next todo to get this to work:

I need to figure out a way to do dragging of cells - to be able to easily change order of events.
Also copying and pasting in preview mode.
Next on I have to create an expressions editor that pops up when a specific type of preview mode cell url is clicked on
figure out how to deal with placeholder items. I thought about putting comments, but unfortunatelly godot doesnt support inline comments : https://github.com/godotengine/godot/pull/18258  so I might have to go back to the drawing board on that one

A good idea for a plugin. But officially maintaining two visual scripting systems would be a pain, and for little gain.

XKCD:Standards
I don't see why this can't be an actual addon/plugin rather than just a proof of concept. Not everything has to be bundled with the engine by default. I mean isn't that why GDNative was developed?

@Megalomaniak That is true and believe me when I say that if I had enough knowledge about godot's api, I would rewrite this as a gdnative addon. But even getting this far I had struggled and I am actually missing some key elements to turn this into an actual usable tool. I have raised the question here, but so far nobody has really told me:

How do we register a new script resource type in godot editor and allow the user to attach it to any node?
How do we then make it so that godot opens my event sheet gui - as integrated as the current node system that almost nobody is using
How do we make  the editText node act like godot's gdscript editor- enable syntax coloring and autocompletion. Moreover how do we give it custom context?

Somebody with really low level knowledge of the API can do this. That kind of stuff is not in the documentation- there are no existing examples of it either.
I have the design ideas, but not the complete picture to pull it off.
It's not another standard for the same thing either- it is very very different from the current blueprint system in terms of how it approaches visual scripting. It allows more typing and less clicking

For stuff like this, I always take the wishes of the developers to heart:
**I have a great idea that will make Godot better. What do you think?
Your idea will most certainly be ignored. Examples of stuff that is ignored by the developers**:
**Let’s do this because it will make Godot better
Let’s do this in Godot because another game engine does it**
Let’s remove this because I think it’s not needed
Let’s remove clutter and bloat and make Godot look nicer
**Let’s add an alternative workflow for people who prefer it**

@spyres I am actually making this and seeking support from other godot users on the API - making a contribution to godot.
What are you doing here?

One man's "contribution" is another man's (or engine's) distraction.  Sorry that the concept of differing opinions seems so objectionable to you. :grinning:

@spyres  but have you actually made anything? Have you ever created an addon for godot?
Why are you here?

@blurymind Wow, different opinions really bother you that much?  How sad for you.

@spyres everyone here can see your opinion- you are spamming the thread with it. Every single thumb down here is yours. Its not the opinion- its the spam

To be clear, I totally support anyone using their time however they wish to create  something like this as an add-on which can be peacefully ignored by folks like me who don't find value in it.
As an alternative workflow actually integrated into godot core?  Ugh, please, no.  I'm with the devs opinion of that sort of thing.

@spyres yes, you said that already. Scroll up and read it 3 more times

yeah, its super heartwarming

@blurymind Thanks, hugs all around then!
I truly with you the best of luck implementing this via gdnative, at which point it'll be there for those (very few I suspect) who will want something unofficial like that.
However, if you can't get the information, assistance you need to make this happen, perhaps it might be time to re-evaluate how much the availability of this alternative language really means to you.

@spyres Please stop spamming. I don't need these emails and notifications. You voiced your opinion, which is fine, but you don't need to keep repeating it.

@blurymind  Yeah, no.

@spyres I have noted in previous posts that this addon aims to use gdscript, not serve as an alternative language

No, I have asked some basic questions about the addon api. The only reason gdnative is even mentioned is that people who suggested to make it as an addon repeatedly promoted it being written in gdnative.

Well the sooner you finish, the happier we'll all be right?  I'm sure it'll be great for a few people who actually want it, just like a lot of other add-ons.  I don't want to see this causing you too much undue pain, so please take care of yourself and don't let lack of information/progress get you down.
In the words of a wise man, "Don' worry, Be happy". :grinning:

WOW. Gonna be honest, this is amazing!
When I first read your post I agreed but was a little worried there'd be a huge argument but when you came along and showed you weren't all bark and no bite I was impressed.
I LOVE the interaction with GDScript as that was a big feature in gamemaker studio (Interchangability of visual and proper scripting) that wasn't really feasable with a node based system.
Once this gets finished it's gonna help a TON of people

This is gonna be very useful. I can't wait until it's released!

Brillant idea, collaborate with SnailOn.

He is genius.
He using Godot around 3 years.
He used Clickteam engines since TGF

@boruok I have been a fan of snailon's yt channel since the early days. 😄 His tutorials have helped me learn fusion long ago. Does he have a github account? I would love to pick up his mind on some things.
Btw I must admit that I am leaning toward a more Fusion like click menu than what Construct2 is using to decide on how to populate cells.  The helper menu is definitely influenced by Clickteam's design. In this addon you will see that I am not creating a carbon copy of any engine, but rather borrowing ideas that would work better for a godotesque approach
Thanks to everyone for following progress on this addon. It looks like a lot of people like it here and other social networks. The initial reaction is overwhelmingly positive, with one exception of course.
This greatly motivates me to keep pushing the idea further, while also trying to keep it simple and elegant.

@blurymind i dunno about git-account. btw, he opened videos again. I've sended few pm to him via, google and facebook. Let's hope he will appear here.

@blurymind  I support this 100%!
(Sorry in advance for the English)
If we give a proper look at the about page beyond what can be used to troll people, this is what we can see:

Developers are interested in (for example):
Your experience using the software and the problems you have (we care about this much more than ideas on how to improve it).
The features you would like to see implemented because you need them for your project.
The concepts that were difficult to understand in order to learn the software.
The parts of your workflow you would like to see optimized.
Parts where you missed clear tutorials or where the documentation wasn’t up to par.

Keeping this in mind:

The current visual scripting can only be used if you know how to code for real. And gets real quick messier than hard code. Who is that helping? And blueprints are not that helpful either, unless you have very specific technical background.

Higher-level event sheets do work well. As seen with the success of all the above-mentionned apps. If well done they really are more simple to grasp and use for non-coders.

Why would Godot cater to non-coders?
I see a use for this for many people wanting to work on professional projects.
In lots of projects, small, medium & big, a part of the team will do the coding, and another will to its own thing. Music & sounds, visuals/animations/SFX/UI, game design, writers, etc...
Sometimes it's even one-man teams, or people from outside the industry like this film maker doing a pretty successful game.
Some people even want to do programming but not coding for many different reasons.
For exemple issues like having dislexia makes code a nightmare, yet programming would still be possible  via a more visual approach like event sheets.
Most of the time these people have other things to do than coding while they produce things needed in the game.
An event sheet would allow a graphist, a sound or game designer to test or implement his work super easily without diving into raw code.
It would also allow for some super quick prototyping, to test one's proof of concept.  Even good coders and big names/studios use the simplest stuff possible to iterate at the start of a project.
More feedback and discussions about all that here, and I strongly agree with the OP.
(Github's not the best place for feedback on this, people who come here are usually deep into coding and cant' see the need, despite actually being a minority.)

Conclusion: Giving people simple yet efficient tools to interact with Godot would be a godsend on many different levels for a large number of serious grownups working on professionnal projects.
(Not just kids & schools, even if it would indeed help them as well.)

By the way, there is another project called GDevelop that uses event sheets if you want to look at more exemples. The previous interface (version 4) is pretty nice, the current one (v 5) is kinda bad though, the app has some good ideas, but some downsides, and its direction is a bit unclear as of yet too but it may give you some ideas, or at least another point of comparaison.

Congratulation for the work already done, for staying positive and motivated despire certain reactions, and for believing in your idea. I too confirm it would indeed be crucially useful and would fix major issues for me.

@TheGoklayeh Thank you for the kind words of encouragement. I know exactly what you mean. As noted previously here- successful Clickteam fusion made games greatly outnumber Godot made games. That should be enough proof that professional artists use it- not just "kiddies"
On the topic of Gdevelop's new IDE, I think that it is great, but not feature complete. One smart move that the main developer made was posting the ide to javascript- making it very accessible to developers to contribute to. I have been actually contributing to it with small fixes. This weekend I am going to try to integrate piskel into it 😃
I am also still making a slowprogress on this addon. Some things need to be refactored before I can move further with it.
Perhaps it would be a good idea to get all fusion users and construct2 users who also use godot here. Show them this thread and get them for feedback on the design.
Snailon hasn't contacted me yet- but yes- he is a very experienced programmer when it comes to event sheets

This looks amazing! Thanks for developing/pushing this, blurymind.
I've done gamedev for 23 or so years, basically tried everything- all the popular gamedev tools/engines, program languages, etc.. and I prefer event sheets at the end of the day because it lets me finish games. :)
Having it in a top-down listed approach split between conditions and actions makes it more orderly and concise than any other system. As I am more visually oriented, having a rigid structure that is verticle/horizontal allows me to flow through the program/events at ease.
Other visual scripting that requires spaghetti connections is very messy and distracting- the visual detail is  scattered in a noisy aesthetic which breaks concentration for visual-minded people (the same people visual scripting is suppose to be aimed for).
Event sheets are the best for me. I've spent 23 years, using everything- blitzbasic, gamesfactory, unity, c++, javascript, etc, and I am certain of this- I love event sheets!!

Just wanted to chime in, Blueprints / node style editing is extremely difficult to organize / avoid "Spaghetti code". To anyone who thinks it's the same as Clickteam/Construct/GDevelop style events then I'm sorry but they are radically different, and event sheets are objectively better (games are rule based, you can much more easily transition from events to code, but events in general are faster than coding the game logic anyway).
I am sure there are moments where node based editing is handy, but event based editing would quickly become the preferred option if it was included in base Godot Visual Scripting.

@bigelod @prominentdetail thank you for providing more feedback as to what makes event sheets so good - not just for those who are learning to code- but also for more experienced programmers.
I think that you are absolutely right. Much like @prominentdetail I have started with event sheets in fusion and then went through many different engines. Learned python, then gdscript, then javascript. Still event sheets draw me back as a prefered way to prototype games.
I am also noticing trends in the event sheet game engine community atm, that godot could really take advantage of:

The community of developers who use event sheets is craving for a 3d engine that uses event sheets. Both clickteam fusion community tried to integrate that as an addon (firefly) and Construct (numerous plugins tried) - but those addons did not provide any 3d editing capability- they were hacks to get event sheets to work with 3d engines - put ontop 2d engine editor not designed for 3d games.
Both learning and experienced programmers still like event sheets and do use them for prototyping - not just teaching.
Many indie teams have succesfully used (and still use) event sheets to make succesful titles - kicktarter, steam and other platforms - but very few are 3d projects because of the first point

Now getting this to work as an addon in godot is tricky, because of some things in the engine that I am not sure how to access. The current implementation I have is quick and messy and doesnt do anything beyond demonstrating parts of how the gui can be done. I will try to get it to a more presentable state and will post it here

@blurymind Ok let's just say I tried to ignore this post here, cause I didn't like the idea of two Visual Scripts.
But it has finally been enough I think that it's finally time to start some discussion. I Believe you must have used the docs to build the GUI. Mockup is pretty good work, I wanted to ask if there is a repo I might be able to look at the code a little. Probably might be able to do something about making it more like the EventSystem, and more workable.
I was planning on doing some work on the current Visual Scripting system. And when I ran into GDevelop and liked it, I came here to ask. After an hour of reading the conclusion is clear we need to find a middle ground.
Maintaining two different Visual Scripting systems is just not possible, one of them has to die. But nobody including me wants to part ways with the Blueprints node structure.
But this EventSystem is too delicious(atleast for basic prototyping) to not eat.
I wanted VisualScripting to be more of a prototyping tool. Limited features don't matter if it can actually increase the user base.
More users also equals more donations if nobody has noticed this before then it should be considered.
But Blueprints is an industry level tool so it has it's uses and might bring in the bigger fish for Godot which is important for Godot as well. And I said might don't know much about it as well.
So the question is simple, what to do? - Choosing both is just not a possibility.
But a hybrid might make Godot more popular.
As you are experienced with both Visual Scripting styles atleast more than me.(I am more of a coder than artist so like to code my way through) Why not try to come up with a solution.
This will likely bring in more people than just EventSystem alone could. And keeping the node system alive will also be a good move.
But, as far as I have searched it doesn't seem possible to create a hybrid. EventSystem is like programming with Scratch to some level. Where as the Blueprint is completely unique but it is more powerful than EventSystem cause EventSystems get more confusing with depth and have lesser readability. While Blueprint is something that loves complex stuff and is actually quite capable like Godot's VS. But it's just not as simple to pick up if you aren't familiar with it.
So what if no middle ground can be achieved.  No matter what it is.
Personally I might vote for Blueprints because I have previous experience with it, and I would like the bigger fish Unreal to be compared with.
But just for comparison, I picked up GDevelop in under 15 minutes. GDScript under few hours on separate days and Blueprint twice that of GDScript for sure.
Although it also shows my experience level as a programmer.
I just can't decide. Here see.

Unity: 4011
Unreal: 316
Gamemaker: 274
Construct: 223
Godot: 75
List from Reduz's tweet number of games per engine in Global Jam.

I want Godot at top. So hopefully some VS love will help achieve that.
But Unreal + Godot + GameMaker + Construct still doesn't cut it. But makes it number 2 at least.
I am confused as hell what to plan for the future of Godot's Visual Scripting. Cause waiting on the current system or mindlessly trying to improve something that's broken is not gonna help.

"EventSystem is like programming with Scratch to some level. Where as the Blueprint is completely unique but it is more powerful than EventSystem cause EventSystems get more confusing with depth and have lesser readability."
What?? It's the exact opposite of you try Construct's event system and groups.
The best node system will always be a code spaghetti compared to an average EventSystem.

@bigelod True it should not be said like that. I thought it was similar. I wrote that comment over a period of 2hours while learning EventSystems. Sorry about that will fix it.
Yes I know best is blueprints and it's just awesome to have something like that but an event system adds more beginner friendly stuff. And also helps in learning Programming.

@warnimarun many years ago I pitched the event sheets to the godot devs on this very same tracker. But I didn't do a great job back then and there was already more support for blueprints, because many godot users were also ex unity/Unreal users. Blueprints already won and is in Godot.
Now many users who actually come from engines such as clickteam fusion, game maker and construct are in support of event sheets and dislike using blueprints very much. They will say the opposite of what you are saying and explain what was already explained- why blueprints are confusing when compared to an event sheet and even scripting. I already did too.
Now in the end of the day I dont see a reason why both systems can not exist. They can work together - the way blueprints can work together with gdscript nodes.
In fact in an ideal world, you would want event sheets to build granular logic and blueprints to organize state machines with it.
Why? Because both systems have pros and cons.
Godot's blueprints can very quickly become a mess when you start making a simple expression with nodes. This same expression can be much clearer in an event sheet or a script.
Open source projects are democratic- the more a community supports an idea, the more likely it is that it will become real.
Everyone here must realize that with both event sheets and blueprints- they will be programming from scratch. What is most important is how clearly is the system allowing them to structure the logic. With blueprints order of execution can become a mess- making debugging hard. It also takes way more clicks and steps to set up when compared to an event sheet.
The event sheet can use gdscript for its expressions and in that way actually help those who come from an event sheet type engine learn it very fast

Probably event systems can be used as a custom node creating tool.

Just would like to raise a point about something- honestly, I don't feel that eventsheets are just for prototypes. I think part of the problem with the mindset that evensheets are only for prototyping is because a lot of the tools that use them push the concept that it makes it easier to create stuff without knowing how to program. Anyone who actually uses the eventsheets for a considerable amount of time knows that it is a real way to program that requires understanding fundamental programming concepts, and that you can create fully complete and feature-rich games with it.
Part of the problem is that the tools that use eventsheets try to downplay the technical nature of it in an attempt to attract amateurs and people that don't have much experience developing games. This in effect hurts the image of eventsheets and makes it seem not as capable to other people that have more experience using other tools. You also then have a lot of people using eventsheets that aren't sure what they're doing because they were told they don't need any understanding of programming- so the examples that people create with it don't represent it that well. That doesn't mean there aren't great examples. It's just that it has developed a certain preconception.

..A hybrid might be a way to break that preconception- allowing people to interpret it in a new way that perhaps has a more serious tone. You'd perhaps have an opportunity to solve the problems of the previous systems, and make the hybrid appear to be better than the systems it was inspired from.

@prominentdetail raises a very good point.
To add to it I will just say this:
Godot has the opportunity to become the first proper 3d game engine to support event sheets. This by definition will elevate it above all the others at the moment.
As I mentioned before, this has been attempted before in both Clickteam fusion and in construct - as plugins. And it  is clunky there because the editors of those engines have zero 3d capabilities.
Clickteam fusion - Firefly engine:
http://clickstore.clickteam.com/firefly
construct2 - q3d
https://www.scirra.com/tutorials/9456/building-your-first-3d-game-with-the-q3d-plugin
Just look at what hassle it is to set up a simple 3d scene without having a 3d scene editor
https://youtu.be/VUGsTdBpRCQ?t=6m17s

IMHO a hybrid sounds like a great way to get the downsides of both.
Approach should be to create a event sheet prototype to show its value and get feedback.

After testing out the system for about more than an hour it does seem quite capable. And the interesting part it is, it probably uses more programming knowledge than GDscript to create most things, other than movement or most basic stuff for which helper features have been added.
I believe that people too scared to try out programming are probably the only ones who might have a need for it in the presence of GDScript.
Eventsheet can easily be a tool for learning programming, especially with the Godot API. As Godot already has many of the same helper functions. So implementing EventSheet might actually be able to use GDScript.
Cause you can essentially create a system that converts the EventSheet to GDScript and stores in a separate hidden folder, which is updated at compile time and can be used by the engine. Atleast thats what I have figured out. This could be the simplest solution.
Although I can see that it just can't take the place of Visual Scripting/Blueprints cause well to be true, it's not very visual mostly code in to column making the thing easier to understand.
I don't get why it's publicised the way it is, unless some-one has basic knowledge of programming using EventSheet might prove to be more of a hassle.
Currently while waiting for the Visual Scripting side fixed I might try to create something with this if I find time. It might be fun, to trying to implement a basic version of EventSheet. If I make any progress will make sure to update here.

How event sheets differ from gdscript/scripting languages?
For newbies (things that make it more inviting than coding):

There is some visual representation of the logic - using icons, and as little text as possible
Conditions are depicted in the left column, actions in the right - In coding both conditions and actions are on one column- making it harder for some to distinguish between the two when reading another person's logic.
Instead of a long string of text ,methods are shown as simple words- in english and syntax signs are stripped when possible
Intelisense/autocompletion presents the user with the entire API- so they can see all of the available setters or getters and filter down the ones they want - inverted to how it works in coding IDE- where autocompletion shows after you start typing and the entire api is still hidden in the engine'sdocumentation. It also has visual clues to find things ( icons ). It shows directly the type of variables returned or expected
Grouping logic lets you make your own folder of it that you can collapse/uncollapse and move around

For more experienced users:

You have the ability to very easily change the order of event execution by dragging and dropping populated cells. What does this mean? When while coding in an ide- we can do this by ctrl+x and ctrl+v. In an event sheet system you can reorder simply with drag and drop a logic row or cells from one row to another.
Already established logic is visually clearer to find and read than code- again due to the visual clues and the layout of left and right column - on top of the color coding.This is really great when you are prototyping something
The event sheet can take care of node paths for the user automatically by default- so when putting together and event sheet you wont have to access other nodes (parent or children) by figuring out their paths relative to something. You still have the option for code flexibility, but the system takes care of this for you for cases where nodes are not going to be dynamically changing their parent-child relationships.
All you do to get to a node is you select it from the helper menu. This speeds things up
Its still very much like gdscript - because all the expressions are in gdscript, but it gives you some extra productivity perks. I think that if done well, this is something that gdscript users will love- experienced or not.

I kind of got sidetracked with some javascript stuff and would love it if others give this a go :) But will come back to it

@blurymind
so, you said you were working on a plugin like that?
what is the name of the repo? its already on your github?
i can confirm that eventshee is easier to understand, i learned it when i was about 10~11 years old and had an poor english (i'm not an native speaker)  while it took me much more time and english knowledge to learn how to code.
some times it can be faster than writing code, when you get used to it you can click as fast as you can think.
the only down side that i see is that you get lazy when you have to learn traditional code.

@Elmapul I don't think that his repo will help much.
And coding is much faster in reality if you have a thinking like that then it means that you aren't really a good programmer who has worked with languages like Python.
Although EventSheet are more helpful and lenient for beginners so that is that.

Just thought I would mention something- since I have dabbled in various tools through the years..
I'm an artist foremost, so I spend most my time creating art. It is what I commit most my time towards and is what my mind has been strengthened to favor. There have been a lot of instances where I take extended breaks away from coding, while I do other artistic things, like freelance, etc.
As an artist, this makes it difficult to stay sharp at any particular gamedev tool which requires specific syntax patterns- patterns that you must consistently do to maintain a grasp on.
So as artists- it is expected that artists will most likely not have the same consistency and priority to the syntax based coding style.
 Event sheets are easier to jump back into because it requires less memory of the syntax structure and patterns that you become familiar with in coding.
Because of this, I favor eventsheeting because I can be more productive instead of having to relearn constantly.. I just jump back in after using my mind on more artistic tasks and projects- it is an easier flow mentally.

..So basically, what I want to stress, is that yes- coding is faster if you dedicate all your time to that occupation and built up the mental faculties that favor that line of thinking. They just simply type it up and go- they don't ever really get averted from this lifestyle/behavior. For others, this will never be a realistic choice, because they've dedicated their life doing other lines of work which have strengthened a different pattern of behavior and practice.
 And sure that is the developer's right to do so..
But if you want to invite other types of individuals and get more people actually using the tool, regardless of their technical potential, then it helps being more open to things and trying to help those who aren't capable of matching your preferred system/workflow, etc..
I only keep responding, because I feel eventsheeting helps a lot in actually making progress with developing games, without the drop-out effects that occur whenever a person goes away and comes back, etc. There is less preventing a person like me from giving up, and just going back to his/her normal line of work. So in the end, I actually accomplish more, even if it takes slightly longer or is slightly less impressive on a technical level.

@prominentdetail For all intents and purposes Visual Scripting can do just that so no need to worry once the implementation is more complete it will solve most of artistic issues of remembering syntax.
I used Blueprints after leaving coding for a whole tear and it still felt natural and proper within a couple minutes. So I think most people will be fine with it.

It doesn't matter what language you know, visual scripting with properly grouped event and action options will be faster than the time it takes unless you're typing very short variable names and data types.
That said, if the events were mapped to keyboard shortcuts, then it would indeed be faster to "type" again, but still it's the events/actions that are faster than standard code from scratch (as actions and conditions often represent a whole complex function, pre-made and flexible for most uses).

My argument remains that the event sheet is both easier to learn than
blueprints and faster to set up. Moreover it is better at transitioning
people to actual scripting languages.
If designed well an event sheet system can be just as fast as writing
gdscript. If you look at my mockup gif- it is pretty similar to just typing
scripts when using the helper menu filtering.
Anyways, I am still figuring out how to do this and thankfully godot
gdscript is going to be getting typed scripting, which is better suitable
for generating bbcode for my event sheet. For example one of the niceties
of an expression field in an event sheet system is that it gives you a
clear indication of the type of variable ot expects and even lights up in
green when valid (see clickteam fusion's).
I am currently trying to figure out how to do an expression field that can
take gdscript but also use the helper menu i made
On Wed, 30 May 2018 22:59 Daven Bigelow<EMAIL_ADDRESS>wrote:

It doesn't matter what language you know, visual scripting with properly
grouped event and action options will be faster than the time it takes
unless you're typing very short variable names and data types.
That said, if the events were mapped to keyboard shortcuts, then it would
indeed be faster to "type" again, but still it's the events/actions that
are faster than standard code from scratch (as actions and conditions often
represent a whole complex function, pre-made and flexible for most uses).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-393333602,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGMbVT30aPs63RYwxtFqDTHWVqclenRBks5t3xZTgaJpZM4S8wyr
.

@blurymind I did recommend doing it with C++, it will both be better suited and more complete using that method. Even I who started C++ a few weeks ago is now able to use it, create bug fixes and new features. So it's not that hard, probably a little. I still need to use stackoverflow though.
But if you are looking for staying and using GDScript and just create a prototype for others to convert into a full tool, I think you should share the repository here no matter how incomplete.
I will be happy to help. I really like the idea of EventSystem. And VisualScripting is currently broken so not much for me to do.
The problem is event system can be a hassle to implement, in Godot you are likely implementing it as a Scripting Language. But that's not it's intent it's event manager so it should be global or should be able to handle the whole scene alone, and then use groups to separate work into sections.
All of this is possible, and should not be a problem to implement either.

@swarnimarun is there a hello world module that creates new ui or alters the existing one?
Can you recomend any good getting started tutorials that helped you?
In any case I am thinking now of changing the gdscript syntax the helper menu would generate to typed gdscript:
https://github.com/godotengine/godot/pull/19264
Then that gets converted to bbcode that renders the interactive event sheet cell interface
I made this flowchart to explain how it works at the moment
https://www.draw.io/#Hblurymind%2FGodot-eventSheetPrototype%2Fmaster%2FEventSheetDiagramPlan.xml

@swarnimarun I am using gdscript to write the addon, there is some use of signals in it already for things like triggering events.
Yes I do use get_method_list() and get_property_list() to render the helper menu as well
Do you have the same handle on twitter and discord?
For now my plan is to prototype the gui in gdscript as its what I know more than c++.
I do have some experience in javascrit too, but that wont help much here

@blurymind Thats very good then. I didn't see that in the gifs above. So I assumed some things.
As for my handle the one on Discord is Swarnim. And I think you know my twitter one already.

@colludium The 3 to 4 times faster speed isn't worth the effort of learning C++. If you want to learn to make more optimised games learn C# instead(will get faster as it matures in Godot). And also now that typed GDScript is coming along it will make GDScript waay faster than before. Close to C# is believe.
C++ is a pain. Trust me. Pointer and Refs and compiling code is all nothing but pain. Unless you want to make a future as a game developer for a big company or are in college studying it or you are so smart that you know GDScript completely or are on a pro level as a programmer.
If you still want to continue try learning to create GDScript code dynamically while you are at it cause as we know creating an export system for a language is a pain so directly generating GDScript code will make the whole thing that much easier to do.
And as an added bonus you will be able to do a view for view code and help newbies learn coding faster.
@blurymind Wanted to ask which version of EventSystem you are using as a base cause I wanted to create a prototype of the system as a C++ module so I would like to have it in sync with yours at least at the base level.

@swarnimarun - thanks for the advice re: C++.  I'm just a hobby programmer coming over from JavaScript, so a minimum-pain / maximum-performance transition is what I am looking for.  I wasn't aware of the planned improvements to make GDScript's much faster - good to know.  Now I have a quandary - C# or the much GDScript...

@colludium Let's say that whatever you find easier, seeing your background to be Javascript I recommend GDScript for it also has dynamic typing, and with the incoming static typing it should be the perfect companion.
And let me tell you if you are ever to think that C++ is a language you should learn just go and checkout Rust vs C++ page of some forum.

@swarnimarun I am using godot 3.0.2
Here is the test repo that I added the project to
https://github.com/blurymind/Godot-eventSheetPrototype
Please feel free to start writing a c++ module. What I have functional so far is just the core building block of the interface -the logic cell container.
The bbcode parser (it just uses regular expressions) and helper menu generator are the things that would be of most use to you, although I am personally thinking of changing how they work - they were bashed together in my free time between work and other projects.
The rest is just static interface put in place for screenshot purposes
One thing that is very important to do is creating some sort of editable dictionary that keeps track of all the nodes in the scene and their paths,so instead of static node paths- the helper menu should be generating gdscript that uses paths from a dictionary that automatically updates the node paths and a node is deleted by the user and not found by the event sheet's logic- it can be re-linked

@blurymind Finally! someone who understood very clearly that Godot Engine 3.x visual scripting is useless (too complex for beginners, useless for experts).
The GDevelop event system is magnificent! it is very useful especially for creating complete 2D games templates, and then later to add more advanced features via GDScript. This will make Godot Game Engine much more inviting, popular, and widespread!
I sincerely love Godot Engine but to make 2D games for mobile devices is not the easiest and most immediate solution. It could offer much more with a simplified system / event system). Godot has an excellent animation editor, it's really nice and functional, it only needs a more user-friendly system if I want to create a 2D platformer without having to write thousands of lines of code (which I find useless to create a basic super-style template mario bros for NES).
I find that the idea of @blurymind is fantastic! the Godot community has grown enormously and I'm happy with that. I have no doubt that the event system is implemented with the next releases. Visual Scripting (I repeat) is absolutely useless at present (I can not even find tutorials, and nobody uses it from what I can see on the web).
Greetings, and thank you for your fantastic job!

@XenonCoder  You make an interesting point at the end

Visual Scripting (I repeat) is absolutely useless at present (I can not even find tutorials, and nobody uses it from what I can see on the web).

This is a good example of where something is difficult to use by nature, then later on will be used as a self-fulfilling prophecy to explain why it shouldn't be done (eg: "SEE! Nobody wants visual scripting!"), rather than admitting that it was simply not done in an appealing or beginner friendly way.
It's like a half-gift, because without the follow-through, it is indeed useless.
The same will be true of any addition to the engine that isn't well documented or provided with examples.

@bigelod Absolutely agree with you. I'm glad you did not misunderstand my intentions, and you understood perfectly what I meant.
Godot Game Engine is simply fantastic! It has an incredible potential. To make 2D games, it's number 1! For years I have experimented with all the existing Game Engine and frameworks and I can say with absolute certainty that Godot is a project that promises great things.
We need tutorials, documentation in general, and above all a simplified system in the style of Build 3, GDevelop, Game Maker Studio 2. Initially as an addon to achieve mainly 2D games, in the future it improves and is officially implemented. I realize it's not an easy task, it's just an idea to make Godot Game Engine the ideal solution for enthusiasts, students, and videogames professionals.
Thank you all.

Around the game engines formed stores. It became normal - to write add-ons on a commercial basis. For Construct including. All the last significant C2 plug-ins are commercial. This is due not only to the formation of the market, but also to the complication of products, a large expenditure of time for testing and fixing compatibility errors.
I think... Godot is in another niche, and if Juan does not write and support the application of simplified programming, it is unlikely that someone else will bring this work to the end.

I've grown up with Klik 'n Play, The Games Factory and Multimedia Fusion, and use Construct 2 these days. Visual scripting with event sheets is totally different to using blueprints-style state-machiney nodes connected to each other, and for people who are used to event sheets, it is the easiest and most efficient way of programming. I'd happily welcome a way of scripting in GoDot with event sheets.

I have hit some limitations in gdscript, the documentation and the plugin api that prevent me from executing my vision of this as an addon.
One thing that will immencely help me get there is the optional typed gdscript - which is why I stopped working on this until that is in godot. Now that is merged - I will get back to working on this as a proof of concept addon.
The idea is that the generated gdscript of the event sheet will be typed. The typed data will then give the event sheet gui extra contextual data as to what type of parameters are expected.
If there is interest in this as a proper c++ module or a gdnative addon - everyone is free to try to implement this.
Seeing as to how many people want it, nothing will make me happier than getting this to be a part of godot - or at least work as a part of godot

To add to this discussion, I would like to present to everyone here with a fantastic example of a visual scripting engine using a node connections based visual programming approach that is currently failing it's targeted demographic
https://youtu.be/b8GZ21YCh50?t=4m12s
Note the alternatives Gamesfromscratch presents

maybe with visual script it could be acessible even ou touch screens?

Indeed, event sheet style visual scripting is very well suited for touch
screens
On Wed, 1 Aug 2018 06:46 Elmapul<EMAIL_ADDRESS>wrote:

maybe with visual script it could be acessible even ou touch screens?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-409456475,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGMbVdqoa3AdMNfiM986iwIpNeqzqjVLks5uMUCvgaJpZM4S8wyr
.

@blurymind if the plugin system needs improvements for this, open an issue, it was modified already because other plugins needed something in particular.

@Wiadomy
this image is too small to read anything

Sorry, something was wrong with it. Updated.

@Elmapul while my concept addon can not do nesting yet, the event sheet that I am proposing includes nesting. Both gdevelop and construct support row nesting - you can try it right now if you want to :)

@blurymind finally started to work on the Event Sheet implementation, do you know of any resources that discuss it's implementation in detail something like a research paper or an article about it's working and implementation?
That will be a big help. To get me started at designing the Event Sheet System for Godot.
Cause it would not be accurate to use the Construct or GDevelop method as the workings of Godot is quite different and we have things called signals which also need to be integrated and then some more.

there's some info about construct's event sheeting here if you need general information: https://www.scirra.com/manual/74/events
different companies implement their eventsheets a bit differently to each other, and so they each have their own quirks..
Maybe I can create a video that sums up the various parts of the construct method (since that is probably the best way currently).. I don't know of any research papers- though that would be interesting to find.

@prominentdetail Thanks for the link, seems like I will have to see how to make the events more easy to use like constructs system.
My first idea was to have something similar to the addon from @blurymind but now it's more likely we should have a different API for Event Sheet which makes it easier to code and is not a version of GDScript in visual form.
So what do you guys think should the Event System have a different API to add to ease of use or just be a wrapper to GDScript.

@blurymind It's actually much easier and much less work to keep it as a wrapper for GDScript but the thing is many of the features from Event Sheet will become more tedious that way at least that's how I understand it.
So I think I will keep it the same for the starters and later add things if need be.

@swarnimarun thank you for taking the time to give this a try

I think the biggest problem is that VisualScript, as all other languages you can use to script Godot, tries to be as close to GDscript's functionality as possible, with functions, variables, signals and everything else. You could not achieve this with a event sheet system, because you would loose a lot of functionality. (I know it is possible, but it would get bloated fast)

@Jummit except you completely can, try Construct 2

And it could have all functionality of GDscript? Then what are we waiting for? Lets get event sheets in Godot!

@Jummit godot has all the functionality you want in the form of 'Nodes'
'Nodes' in godot are like 'Behaviors' in construct2
The platformer behavior in construct2 is like a less powerful kintematicbody2d node :)
What is even cooler is that you can nest them in a parent child relationship, while behaviors are restrained to be attached like modules to a single game object.
I strongly believe that a godot with a built in event sheet capability and a few additional plugins from the community can become a faster engine for prototyping than construct2 or 3

The rapidity of prototyping in C2 is largely determined by the interactivity of cells - they can be dragged, copied and changed with hotkeys, including condition objects, while drop-down lists almost completely eliminate the error.

@swarnimarun , I created a generic overview of various construct stuff: https://www.youtube.com/watch?v=ioz3gHtA-Lg
It's basically for anyone that isn't too familiar with construct to get a feel for it. I probably overlooked various things since I didn't plan out everything, but it might provide some basic understanding. I should probably make some videos where I actually do more developing in them, to show off the workflow side of it instead of rambling about various things. Let me know if you'd like anything covered or explored.

That's ugly as f**k to me. I mean, scripts in the video.

@Wiadomy  it's much better in use than in that video. Event sheets in the end always look cleaner and more readable than any node-based system

@Wiadomy , due to screen recording, I had to use one monitor and also keep the text size relatively large. Construct formats the text so that some things can become bunched up due to screen space if you type out a long continuous expression.
To solve some of that, you can zoom out the text and also use another monitor to free up some space to list the events better.
I also could of split the expressions up a bit to make it more neat too, but this is an older project of mine and also a bit more experimental.
Also, you get familiar with the visual cues and pattern in the structure of the eventsheets, so it becomes easier to trace all the various parts in the events. Having a standard structure like this is very useful in terms of being able to adapt to any project and makes the workflow become very quick.

Stumbled upon this issue by accident, I was completely unaware that this stuff is already commonly used in other engine/frameworks so I had to kinda write my own, looks very similar don't you think? 👀

Rule = Event
Event Sheet = Scheme
The previous implementation did use quite "low-level" property checks and respective actions, but I figured that this kind of a system is actually more useful for defining gameplay "building blocks" by extending conditions/actions base scripts which are more "high-level" in abstraction. So that's actually the reason why I picked the "Rule" terminology in the first place.
You must have the gameplay and game framework already established to make use of this to full extent, so it doesn't serve the out-of-the-box experience for writing a game without coding, but actually complements it in a way which allows you to combine existing functionality in a variety of ways and efficiently organize it, just compose new rules with different conditions and actions using your plain GDScripts.
And yeah, allowing players to create their own game modes/missions/challenges via modding is another reason for using such a system.

@Xrayez can you share git repo? I think you are right that my implementation is too granular, but it is true to how gdscript and godot's api works.
Also just by looking at the screenshot, I think  you are missing the point - it should be only two columns, not three. Left= conditions, right= actions. Also you should be able to drag and drop events  between cells, and also drag and drop rows and nest them. To build this we need to use a sortable tree. Have a play with gdevelop and construct, you will get  better idea of what makes these event sheets so nice

I get that the people who contribute and implement things like to code and don't all see the appeal of no-coding programming, but many others are in fact interested by it.
Construct, Gdevelop, Stencyl, Game Maker, Playmaker, Bolt, Fungus for Unity, Blueprints in Unreal, Flow Graph and Schematyc in CryEngine, etc...
Many tools for non-coders are being made and used. Lots of good games are made thanks to these.
Hollow Knight was done with playmaker for example.
You even have stuff like Dreams making quite some noise.
This kind of tool would bring lots of attractibility and accessibility, and therefore new people to Godot.

I recently implemented a way in gdevelop to add new instructions to its event sheet via a dropdown like this

It is kind of what I think could work well for gdevelop.
You use the richtextlabel component to render cells, these cells are nested in left and right column, which is then a child of a row. Rows are managed by a sortable tree.
The tricky part I found when i started doing it as a godot extension was doing the expression fields. How do we put a code editor in an input field and let it do autocompletion for us?
Anyways, if my c++ knowledge was better I would have given it a try :) But I know javascript, so my contributions go to gdevelop instead

Would love to see an event based solution in godot. I tried godot in the past, but I couldn't get comfortable with its workflow. My mind is more suited for event sheets if I'm going to be developing a game.

I'm a programmer now, and I'm even starting to get into engine development. But I can 100% get behind event sheets.
Construct 2 was my first exposure to many programming concepts, with a class I took back in high school. I feel that it massively simplified and expedited the learning process for me, while also translating closely enough to actual code that I didn't feel totally lost transition from event sheets to regular old text scripting. While I can't be 100% sure, I really don't think I could've gotten either of those benefits to the same extent, were it the spaghetti-type of visual scripting instead.
But I do agree that maintaining two different visual scripting systems is probably a bad idea. That said, I don't think we should stick with the current system just because it's what we already got. I think we should really consider switching to the other system, if data warrants it. That is, I think we should try and get a better idea of how much more approachable the event sheet system is vs our current system. The goal of visual scripting should be to make the engine more friendly to people unfamiliar or not confident with regular scripting. So I think if the visual scripting system could be improved, such by changing to the event sheet system, it could make a huge different in expanding Godot's reach and support.
I haven't read the 112 posts that are now hidden, so I apologize if I've repeated or missed anything, but I'd be totally interested in prototyping the idea, or otherwise helping to test out and consider it.

I think we should really consider switching to the other system, if data warrants it. That is, I think we should try and get a better idea of how much more approachable the event sheet system is vs our current system.

We already have very few maintainers for the current visual scripting system. I don't think a complete switch would ever be completed in our lifetime :slightly_smiling_face:

We already have very few maintainers for the current visual scripting system. I don't think a complete switch would ever be completed in our lifetime 🙂

Well assuming we get a working prototype of the event sheet, then the code would already be mostly done, it would just be a question of whether we want to switch over to that instead, right?

I also started with Construct 2 and found event sheets are great to solve 2
problems:

LIke any visual scripting, you expose all possibilities of any
module/plugin/add-on/function, this is very useful to learn new code.
Visual nodes turn to spaghetti code pretty quick though (I'm a blender guy,
I know about spaghetti in compositor and shaders).
Event sheet is like swagger for Rest API, you start with well documented
code that populate the event sheet drop down menu and you get a clean GUI
way to consume your code, you can extend with getting messy, and, you may
generate code from it (JS from Construct2), hence my question: Could we
generate code from it?

If yes, I think event sheet should become a priority, for ease of use for
everyone and optimized low level code generation.
If Godot could be used to transform a python/C#/... API into a clean set of
events, then user build events, then Godot generates code from it, you're
solving a very very hard user problem: learn how to code from a simple UI.
I know event sheet don't solve all problems but at least you can code 500
events like you're doing in a spreadsheet without being lost in visual
links everywhere.
On Wed, Apr 8, 2020 at 7:44 PM Jay<EMAIL_ADDRESS>wrote:

We already have very few maintainers for the current visual scripting
system. I don't think a complete switch would ever be completed in our
lifetime 🙂
Well assuming we get a working prototype of the event sheet, then the code
would already be mostly done, it would just be a question of whether we
want to switch over to that instead, right?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-611096608,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAP6LM4PU6RYLO5NK5IL23RLSZWHANCNFSM4EXTBSVQ
.

I started using Construct 2 and eventually moved on to developing plugins using JavaScript, so event sheets have a place in my heart. They were easy and intuitive to the uninitiated, with most of the magic from the easy visualisation of available methods (actions and conditions) for each class (plugin). Honestly, GDScript in VSCode is just as good now, with full-up intellisense and auto-completion making life a breeze. Although I was a big fan of this idea 2 years ago, I've now changed my mind. I would rather that the Godot dev heroes focused their time and effort on adding other engine improvements.

Could we generate code from it?

I'd have to look into it more, but I honestly think it would be pretty trivial to do so, and in fact it's probably the best way to do it. That is, I think the best way to handle an event sheet style thing is to basically have it act as a graphical front-end for a regular gdscript file. Actions taken in the event sheet editor would simply edit the gdscript file. Moving a block from one place to another in the event sheet editor would basically under the hood be doing like a virtual cut+paste to the gdscript file. And any gdscript file can be viewed and edited either in script editor or in event sheet editor. This seems like the best way to do it, both from a usability standpoint and from an implementation standpoint. That said I'm not very knowledgeable about engine development yet, so I may be mistaken.

I'm not in Gdscript or Godot enough too.
But what I developed as a VS Code extension is also going in this broad way
(https://github.com/j2l/blocklight).
Visually understanding the code by playing with a chunk of it and visually
linking the variables and results (nodes in most visual scripts, or colors
in my extension) is the missing corner stone for many.
Actually, we understand code when we finished learning it, while we should
see the variables and the links of the chunks before getting all of the
code.
Design before coding :)
On Wed, Apr 8, 2020 at 8:08 PM Jay<EMAIL_ADDRESS>wrote:

Could we generate code from it?
I'd have to look into it more, but I honestly think it would be pretty
trivial to do so, and in fact it's probably the best way to do it. That is,
I think the best way to handle an event sheet style thing is to basically
have it act as a graphical front-end for a regular gdscript file. Actions
taken in the event sheet editor would simply edit the gdscript file. Moving
a block from one place to another in the event sheet editor would basically
under the hood be doing like a virtual cut+paste to the gdscript file. And
any gdscript file can be viewed and edited either in script editor or in
event sheet editor. This seems like the best way to do it, both from a
usability standpoint and from an implementation standpoint. That said I'm
not very knowledgeable about engine development yet, so I may be mistaken.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-611108712,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAP6LN7GFGSBDZ537XXA6DRLS4Q5ANCNFSM4EXTBSVQ
.

I love the idea that it would generate a regular Gdscript file. Would be really great for learning
When I started making games Klik & Play's event system was a really great way for me to get my head round programming logic, and I still love going back to it.

I love the idea that it would generate a regular Gdscript file. Would be really great for learning
When I started making games Klik & Play's event system was a really great way for me to get my head round programming logic, and I still love going back to it.

I think that is potentially one of its greatest advantages over the current spaghetti system - due to its design it will ease people into learning programming and gdscript/godot's api.
Some people here commented- but why bother doing it- its too similar to scripting in  presentation.
My answer to that is - precisely. You learn spaghetti, you are left with spaghetti. You learn the event sheet, you will know gdscript by seeing what it generates and using those expression fields.
See what convert to GML does in game maker
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

Really interesting blurymind! I had the same idea and I am completely supporting this.
I am still making extensions for Clickteam Fusion 2.5 but all what I want to add in Fusion is in Godot.
All I need is to put one more abstraction layer (event sheet) in Godot to make the development easier.
I did not read the whole thread but the main difference from my point of view between visual scripting in Godot and event-sheets in other game engines is that visual scripting is "just" a visual view of the code and event sheets are an abstraction of the code with a simplified view. It is more human readable, is factorizing things that needs several lines of code in one line and signal/slots linking is done automatically.
Actually, adding some templates (predefined scenes) to abstract CF2.5 built-in object and still use GDScript would do most of the job for me but event sheet will definitely makes me more efficient in Godot than what I am doing in CF2.5 now.

Really interesting blurymind! I had the same idea and I am completely supporting this.
I am still making extensions for Clickteam Fusion 2.5 but all what I want to add in Fusion is in Godot.
All I need is to put one more abstraction layer (event sheet) in Godot to make the development easier.
I did not read the whole thread but the main difference from my point of view between visual scripting in Godot and event-sheets in other game engines is that visual scripting is "just" a visual view of the code and event sheets are an abstraction of the code with a simplified view. It is more human readable, is factorizing things that needs several lines of code in one line and signal/slots linking is done automatically.
Actually, adding some templates (predefined scenes) to abstract CF2.5 built-in object and still use GDScript would do most of the job for me but event sheet will definitely makes me more efficient in Godot than what I am doing in CF2.5 now.

i used to use CF back in the days it was called multimedia fusion, it was easy enough to learn as an kid who didnt speak english, and after praticing with it, you can be very fast, depending on what you're doing it can be faster than typing.
construct and CF are reference of what an good visual scripting looks like (gdevelop is geting there)

Thank you
I support this wonderful idea
They say construct 2 will retire !
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
I wonder if it is possible to negotiate with the developer of construct 2 in order to opensource of the event system, and use it in godot, unity etc.
It's a loss that construct 2 event system is neglected on the shelves unused

Thank you
I support this wonderful idea
They say construct 2 will retire !
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
I wonder if it is possible to negotiate with the developer of construct 2 in order to opensource of the event system, and use it in godot, unity etc.
It's a loss that construct 2 event system is neglected on the shelves unused

I doubt we can use any code from construct2 on godot - they are a completely different codebase.
Your best bet for an open source alternative is moving to gdevelop
https://github.com/4ian/GDevelop
This issue ticket will likely get closed soon, so if there is any interest in this event sheet in godot - we might soon have to move it elsewhere :) (or to gdevelop)

This issue ticket will likely get closed soon, so if there is any interest in this event sheet in godot - we might soon have to move it elsewhere :)

What? Why?

@TheGoklayeh It may be closed as we are migrating feature proposals to godot-proposals.
That said, @blurymind could edit the first post to match the proposal template. We could then move this issue to the proposals repository.

We really need a 3d engine utilizing event sheets.

Thank you
I support this wonderful idea
They say construct 2 will retire !
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
I wonder if it is possible to negotiate with the developer of construct 2 in order to opensource of the event system, and use it in godot, unity etc.
It's a loss that construct 2 event system is neglected on the shelves unused

That might be ruin their business. and clickteam in addition.

Thank you
I support this wonderful idea
They say construct 2 will retire !
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
I wonder if it is possible to negotiate with the developer of construct 2 in order to opensource of the event system, and use it in godot, unity etc.
It's a loss that construct 2 event system is neglected on the shelves unused

That might be ruin their business. and clickteam in addition.

If anything kills them - clickteam would be due to lack of updates to their software (last one being in 2019), Scirra would be for forcing their users to switch to a rent-the-software license that forces them to pay every year or get locked out

@TheGoklayeh It may be closed as we are migrating feature proposals to godot-proposals.
That said, @blurymind could edit the first post to match the proposal template. We could then move this issue to the proposals repository.

Can somebody do that instead of me? :)
I kind of lost hope for this feature to ever reach godot natively (not an extension). The spaghetti approach has won over godot users and devs

@blurymind If you no longer support this proposal, then I think it's better to close it. Someone else who's interested in working on an event sheet approach could then open a new proposal on godot-proposals. (Due to the sheer amount of work required, I don't think it would make sense to open a proposal if nobody is technically able to fulfill it.)

I think this proposal is very silly :)
But can we create the event system with construct 3 engine ?!
I think the game can generate codes and send them in a text file to the godot engine via node.js
This is ridiculous .. but I think construct 3 is strong enough to make an event system
This is better than nothing at the moment

Yes hopefully at least we managed to reach an idea about such system in godot, its advantages over the current visual coding system and opinions about other engines using it

I honestly like, how GDevelop does it, but Godot doing event script is not
something I am in favour of now(these days).
I tried to implement it once, and I was hit with the realization that Godot
has an extremely granular/low-level API for it to be exposed directly from
a Visual Scripting system.
The current visual scripting system included and why I would prefer for it
to have a custom abstraction layer but still be robust.
Such an implementation is insanely hard to write for event script unless
you go with multiple DSL like sub-event-script languages, where each is
used for a specific part of the engine.
A generalized visual scripting system which is simple and easy to use would
be quite hard to achieve and is what I consider a "Unicorn Project".
As the increase in generalization would very likely lead to a much greater
increase in complexity of the said system.
I plan to take Visual Scripting gradually towards a direction where it can
have specialized interfaces for all parts of the Engine.
Imagine a different way of editing for each type of primitive complex node,
like in Blueprints, having an expression node.
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/MathNode/index.html

But just to be clear, I am not against Event Scripting, I would like to see
someone come up with a proposal that can cover some specific systems of the
Godot, and why and how it can be useful. Personally I find it quite nice
for programming Behaviours, how GDevelop does it.
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors/events-based-behaviors
I won't use it for writing a proper game but if we have simple behaviours
we can drop down and play with, I see it as quite a fun way to optimize the
project for kids learning to make games.
Or someone not used to programming using it for game jams.
Though the same can be said about VisualScript and modularity is probably
going to be much easier to achieve with it. The problem would be
unification and consistency(Visual Shader and VisualScript use completely
different codebases, only similarity being the UI Nodes used).
Still, we can surely try to have an Event Script system as a Plugin(C++
Plugin, hopefully, it becomes easy to do after 4.0) that can be maintained
by the community and added into Godot when needed. (I am sorta biased
towards a modular Game Engine)
Anyways that's just my 2cents.
On Thu, May 28, 2020 at 6:05 PM Todor Imreorov<EMAIL_ADDRESS>wrote:

Yes hopefully at least we managed to reach an idea about such system in
godot, its advantages over the current visual coding system and opinions
about other engines using it
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-635321646,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEYB55QLICI3FIYU2F7ZBSTRTZK7PANCNFSM4EXTBSVQ
.

--
Swarnim ArunGithub https://github.com/swarnimarun| Twitter
https://twitter.com/swarnimarun
@swarnimarun
YouTube: Steincodes

I honestly like, how GDevelop does it, but Godot doing event script is not something I am in favour of now(these days).
I tried to implement it once, and I was hit with the realization that Godot has an extremely granular/low-level API for it to be exposed directly from a Visual Scripting system.
The current visual scripting system included and why I would prefer for it to have a custom abstraction layer but still be robust.
Such an implementation is insanely hard to write for event script unless you go with multiple DSL like sub-event-script languages, where each is used for a specific part of the engine.
A generalized visual scripting system which is simple and easy to use would be quite hard to achieve and is what I consider a "Unicorn Project".
As the increase in generalization would very likely lead to a much greater increase in complexity of the said system.
I plan to take Visual Scripting gradually towards a direction where it can have specialized interfaces for all parts of the Engine.
Imagine a different way of editing for each type of primitive complex node, like in Blueprints, having an expression node.
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/MathNode/index.html

But just to be clear, I am not against Event Scripting, I would like to see someone come up with a proposal that can cover some specific systems of the Godot, and why and how it can be useful. Personally I find it quite nice for programming Behaviours, how GDevelop does it.
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors/events-based-behaviors
I won't use it for writing a proper game but if we have simple behaviours we can drop down and play with, I see it as quite a fun way to optimize the project for kids learning to make games.
Or someone not used to programming using it for game jams.
Though the same can be said about VisualScript and modularity is probably going to be much easier to achieve with it. The problem would be unification and consistency(Visual Shader and VisualScript use completely different codebases, only similarity being the UI Nodes used).
Still, we can surely try to have an Event Script system as a Plugin(C++ Plugin, hopefully, it becomes easy to do after 4.0) that can be maintained by the community and added into Godot when needed. (I am sorta biased towards a modular Game Engine)
Anyways that's just my 2cents.

Why was my comment marked as offtopic? Is someone censoring the community? That doesn't bode well. There are other comments besides mine that are more off-topic.

@prominentdetail Here's my anti-bump notice message then :slightly_smiling_face:

Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.

I do support this proposal, just don't think anyone would put the time into implementing it.
It doesnt have strong enough support from developers who can actually make it happen

@blurymind if you still support the proposal and are willing to take the time to write it up in the format required for GIPs. It's worth doing IMO.
The way things get added in Godot is when someone interested in a feature takes the time to implement it. It is very random and sporadic. But we rely almost completely on contributors randomly deciding to add features.
So just because the current set of active developers haven't taken interest in your proposal, doesn't mean that someone won't come along and implement it.

I've noticed a plugin which accomplishes something like discussed here:

Event System: https://godotengine.org/asset-library/asset/1163

Perhaps @AnidemDex would like to share some thoughts.

the plugin looks very cool, but its not spilling the condition/action logic into a two column layout like most event sheet systems do.
Now this is actually a huge part of what I am trying to convince developers here of - the detail of the 2 column layout actually is an important one. It makes it much easier to read the code in a more intuitive way than traditional scripting.

the plugin looks very cool, but its not spilling the condition/action logic into a two column layout like most event sheet systems do.

You're right. The visual part of the plugin is being remade to accomplish this (and other things related to readability and easy of use of the plugin) @blurymind . I've investigated a little and that approach seems like a better one in vertical list of events, it gives a better look of how the events will flow.
Never though that this was something useful for the visual scripting part of the engine to be honest. I'm not saying that is not possible to use it there, I simply never though on it.
Thanks for the mention @Xrayez

Since the logic part and the visual part of event system are two sepparated things, I think is possible to adapt the plugin to solve this issue (no matter if it's already closed, seems like never got a definitive solution), and even use GDNative to make some integrations with VisualScripting (never used it to be honest).

Another note, I discovered via a Youtube video that a looot of things can be done via the animation player node - including calling functions.

Now this is actually a huge part of what I am trying to convince developers here of - the detail of the 2 column layout actually is an important one. It makes it much easier to read the code in a more intuitive way than traditional scripting.

Construct3, clickteam fusion and gdevelop all do that for a good reason. You can still nest event rows under other events too, just the way the conditions are displayed in a different part of the layout helps intuition

Yeah- Having the conditions displayed on the left and the actions displayed on the right, along with the ability to nest events inside other events, allows everything to be more legible.
I took a look at the plugin, but I'm a bit confused how it works, since I see what looks like events, but then there is coded stuff too.. So it looks more complicated than it should be. I don't know much about Godot though.. The less scripting stuff there is, the better I think.

Now this is actually a huge part of what I am trying to convince developers here of - the detail of the 2 column layout actually

Event System integrates well with Textalog, which is a dialog plugin that allows you to create text in any style of game such as Visual Novels, RPG's, platformers, whatever has text in it basically.
The idea behind it is that you do not need to know scripting period to make dialog in it, so making something like a VN with branching paths and meaningful choices would be a breeze even in its current early state.
The event system design comes from how you would expect to read or write a book or any text - so top to bottom, same as if you were using Word or Google Docs to write up a script for your game. The logic how it functions also resembles "choose-your-own-adventure" books, so when you make a choice, you can "flip to page 15, line 13" which in our case would be "change to timeline 15, event number 13".

Is this worth reopening now that Godot has decided to remove Visual Scripting in 4.0?
Seems like part of the argument against event sheets was because visual scripting already existed- so it'd be good to get an update on people's opinions now that visual scripting is going away.

Yeah, I think we should bring back the discussion. I think the main problem of the attempt of Visual Scripting, it was trying to mirror Gdscript 1:1. We should move away from it. As people stated before, this should be a layer of abstraction.
My preferred  visual scripting is event based.  I used to teach programming for kids and teens , using both Godot and Construct. To archive this layer of abstraction we should have some kind of "High Level Nodes" like Construct and GDvelop does. For example, we could have a Plaform2D Node, that would have Conditions and Actions.
This Plaform2D should have hidden from the user the basic structure of a platform movement. It would have an Area2D, a KinematicBody2D, an AnimatedSprite2D etc. So, the events could handle basic stuff: On Collision with Another 2D Node, trigger the kinematic movement, Destroy the Object (queue_free) etc.
And if you check GDvelop, they have a neat feature that allows you to code in JavaScript, create behaviors and plugins using JavaScript. You can pass an object as reference to the event, then proceed with JavaScript how do you want to handle with it.
Take a look:
https://wiki.gdevelop.io/gdevelop5/events/js-code
https://wiki.gdevelop.io/gdevelop5/behaviors/events-based-behaviors