Godot: Event Sheet style visual scripting

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.
Godot's visual scripting was mentioned on their forums and the users there still prefer event sheets. I personally transitioned to gdscript and prefer to use gdscript instead of blueprints- because gdscript is closer in its advantages to the event sheets than blueprints are.

It's like telling someone who likes bananas to eat tomatoes instead- its a matter of taste :)

@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

In any case, I am posting this here for documentation - to outline the event sheet system - what it does and how it differs from blueprints. If anybody else is interested to implement it in godot or as an addon, please let us know. I would definitely roll my sleeves and help out, spread the news and get feedback from clickteam/construct users .

So far I don't even know how to implement its interface with godot's GUI class properly. You have to be able to drag logic blocks between cells of the same column. Copy/paste blocks/rows too - nest rows and
other unique things. I don't think it's a small task

@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. Please link to it if you make it

My post here is a proposal for an alternative approach, not for a change of the currently implemented one. Event sheets are much too different anyway

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++)?
Can this just be implemented as a gdscript addon?

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 - games on many platforms. People like to use this approach in visual programming - even professional teams. 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 learning transition 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

It is easier to explain to someone how an event sheet works, than it is to explain the same example in a blueprint - they have to learn much less concepts - no need to be taught the type of connections between nodes, types of inputs and outputs - how to set the flow.
Instead the events flow from top to bottom , left is condition and right is action. You have to connect nothing.

Does this

look as hard to understand as this?

Sure, godot would use more event blocks to achieve, but it would still be clearer than a node graph.
Even gdscript looks clearer to me than that. Our current visual script system looks complicated at a first glimpse

I speak as someone who has used both systems and is now comparing them - both are equaly powerful, one is clearly simpler to learn and get into
Give it a try please. You can try construct3 in your web browser for free here:
https://www.scirra.com/
If you have a son or a younger sibling, ask them to try it, then try godot's - see what they can do and how long it takes them to do it without given instructions - there is a potential market for more schools to adopt godot here - make visual scripting better for learning programming concepts and we will get a younger demographic using the engine

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 and basic programming concepts get even more complicated with additional nodegraph centric rules on top.

Experienced programmers are really not the best audience to sell this to- because they would see the event sheet 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.

I would love to try to write a basic event sheet addon in gdscript, I am really not experienced enough to make a native script addon. If that is possible and you have some pointers where to start - I would love to hear them
Maybe if there is enough interest somebody might make it in nativescript

because its approach is purely state machine centric

What ? 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

You are not the right target audience - you are an experienced c++ programmer. Please test this with people who are non-programmers and you will start to see what I mean.

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 the blueprint system. The blueprint system already has it - but I dont see any plugins made for it..

Again - construct2 is way ahead of us. Their community has created many many many easy to install plugins that add custom conditions and actions - and their api to register an action and a condition is super simple
https://www.scirra.com/forum/completed-addons_f153
https://www.scirra.com/manual/19/actions-conditions-and-expressions

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 / confusing to read than simple gdscript code? that's the entire crux of this feature suggestion isn't it

@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 makes 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 additions (since the majority of godot devs could already benefit greatly from it). and the potential use cases of VS/Event Sheets are pretty low currently. so all 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.
It is not even on the road map, yet you jump at it as if it's here to eat your breakfast. :p
Exploring an idea is not quite the same as demanding time.

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.
https://www.scirra.com/
it's literally three clicks away

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.

Gdscript can tie in beautifully with any visual scripting system - event sheets or blueprints.
As noted in my first post - the event sheet approach also uses expressions - for which gdscript can already be used. Higher level logic blocks could be created via gdscript and godot's plugin system too- it ties in beautifully with a visual script 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 text field input. If you want do do 1+1- use a node. If you want to address a simple variable in an expression- use another node. You end up with a spaghetti mess of a billion basic nodes for a simple expression that could just as easily and much more clearly be written in a tiny 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 - a line of code instead of 10 nodes and 100 connections.

That is basically the other advantage of an event sheet system- you can just write your expressions inside code block input fields. 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 - but those expressions are laid in a simple spreadsheet structure.

Imagine a method in godot- as a logic block. Just as its method- that block takes the same parameters- but you dont need to hook it to nodes. You can just type in some gdscript in its input field.
Nodes in godot can act as the behaviors in construct2 and an event sheet in godot would be way more flexible and powerful than construct2's. It will have none of the disadvantages that their engine has

Construct's approach to pairing objects is horrible - among other things- but that has nothing to do with the event sheet design

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. yes, i know this is not replacing it, but i'm saying more about dev time.

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 - somethings along the same lines 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. Blueprints are not unfortunatelly

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 as an addon - I keep thinking that godot's event sheet objects should in the end be translated to gdscript. The event sheet can be 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 list of built in node methods/members

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

In that sense- Godot's implementation of an Event Sheet system can have as a main goal to introduce non-coders to gdscript and basic programming concepts without boggling them with any syntax - it will then put Godot in more schools teaching programming to pre-teens. As they advance, they will learn gdscript and godot's api, instead of construct2 or game maker

I think i did 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 scripting

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 - but blueprints will still have the added design complexity that we discissed.
It would take much less work to create and maintain higher level functions for the current blueprint system, than it would be to write higher level functions event sheet functionality AND an entirely new Event Sheet base system from scratch as a plugin.

If we had a low level implementation of an event sheet system, it would be much easier to create and maintain higher level actions/conditions for it.
I guess even as an addon - I would first make the base Event Sheet addon with just low level access and an interface - that follows godot's architecture without bloating it with any new methods. Then sepparate optional addons for higher level stuff can be written on top in other plugins.

The asset repository could have a special section for visual script addons

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 the 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 of 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 said, that will means lot of 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 - we could for example have a clearer event order than construct's. We can attach event sheets to any node - allowing better organisation than construct'2.
For types/families- in godot we have "groups" - godot's groups implementation is actually better than construct's.
For attaching behaviours to objects - You can just attach child nodes and use them as the behaviour of the root parent node that contains the attached event sheet. This is actually better than Construct again.
In godot, you have to make a collision shape node a child of the node that has the collision. It's not rocket science and is actually better for teaching kids about programming

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/learning platform than construct's - because godot allows for much more flexibility in coding styles and has a better architecture. Expanding 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. Please don't try to make godot exactly the same as construct2 though. It is in many ways better.

@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 needs to be changed. If you want other construct2 features, you can make some addons

Even as an addon implementation- an event sheet in godot should do nothing else than just create another interface for generating gdscript files imo

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

@matriax the feedback is a good idea. You are right on that point.
It would be good to ask a target group of people - not just anyone on the internet. A target group could be young students and teachers - that would actually be the perfect target for an event sheet system.
teachers would know very well what their students are struggling with, and will at the same time know Godot and Construct. Students and non-coders could give good feedback

If you just ask on the godot tracker here- 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 and the engine needs- naturally because we already know how to write code in gdscript and see more important goals for the engine than this. It's true that there are more important goals.
If you are lucky,some of them would have started with construct/game maker/clickteam fusion before coming to godot, and will know where its value lies for people who don't know any programming languages yet.

Someone made a good point that 3d artists like blueprints, because they already know how to make shaders. That is a very good point -a 3d artist is not a programmer- but still a technical individual who has learned the concepts of a node graph system.

Going back to the value in this- wouldn't it be wonderful if Godot , maybe some day in the future becomes the first engine of more kids?
Why not try to replace Construct in schools :) Scirra devs are having it too easy right now. Look at how they brag about collaborating with schools
https://www.construct.net/gb/blogs/construct-official-blog-1/construct-3-a-year-in-review-947?utm_campaign=blog1postemailsub&utm_medium=email&utm_source=947&utm_term=txt4-read-laura_d%2527s-post&utm_campaign=marketing&utm_source=sendgrid&utm_medium=email

In terms of trying out the idea as an addon, I made a WIP proof of concept gui. 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. Not sure how to do drag to shuffle elements inside the cells and indenting yet

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 :)
The actions/conditions editor would be the tool to edit cells/logic blocks. I am thinking of somethings similar to Construct2's approach with godot's internal code editor as the expression editor.
Maybe some helper aids could be added later on - like the ones in construct2 or fusion

Once an interface is made, the rest is just getting it to save/store the data inside the scene and to be able to generate clean gdscript- but I might be missing something

@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 out.

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?

@DrZanuff Thank you for the feedback
@Zireael07 Thank you :)
Yes 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

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/quirks. We can actually make a better event sheet than theirs that is as user friendly and teaches programming better - without quirks.

As I see it - a lot of the work is in creating the interface to edit event sheets - I have some more ideas how to make this better in taking advantage of godot's perks- but it will take me some time to develop the proof of concept that explains it. Some times a picture is worth more than words. An addon - more than a picture

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 Of course that you can - and I will actually love it if you guys poke around with it. Just need some time to make it more presentable. :)

I am in the process of integrating the gui into godot's editor as a gdscript plugin -it's not interactive enough yet :)

Will publish it on github when I get the basic GUI working interactively to communicate the design ideas :) Today I got the event sheet gui to load as a tab - taking some inspiration from the sketchfab plugin:

Perhaps the event sheet should be accessed from elsewhere?

Will post more update screenshots and eventually a link to the github- updated my first post with some planning notes and links to online demos of other event sheet engines

• Do you guys know an easy way to display godot node icons inside the rich text label node via bbcode?
  In my previous mockup I used the [img] tags - but that is a pretty poor approach as it will require me to download all of the node icons that godot editor uses and store them with the addon

• I am also struggling to figure out how to register a new eventsheet script type resource via the addon api

@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 via a plugin,addon, gdnative, etc.) then, no harm, no foul. Otherwise, I agree that visual scripting can be improved making this superfluous. GDscript is easy, really easy. And probably more useful to teach kids than some janky visual scripting (even blueprint based) If someone needs construct, then I say, encourage them to 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.
The goal of this is not to replace gdscript or the current blueprint system- but on the contrary - give kids a way to learn gdscript by aiding them. This is how yoyo games uses their DnD visual scripting system to gradually introduce non-programmers to Gml btw.
I don't think there is any harm in having a visual scripting system that is more accessible to non-programmers and is better designed to transition them to gdscript. Why do you?

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 scripting resource type and I want to inject my event sheet editor inside the scripts tab - for editing myscript.es files.
Does anyone know how this can be done- or has an example of it being done?
It having its own tab is ugly imo, and not following the editor's original design- I want my addon to be integrated in a way that is seamless with godot's design.

@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 yet. Might have to come up with a more godot centric way to do that. Still exploring it and am open for ideas :)

In any case, we might never have a fully functional addon. This is just for exploring the idea of how it could be done in a godot centric way here - at least for now

The assumption that visual script cannot (or will not) be greatly improved 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 mention as a primary demographic for Godot)_ is that large, let them use construct or some other focused kid solution 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? If so, how can it be improved to be a better tool to teach people about programming?

@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 - one that is just more enjoyable to use. I don't like Construct2- so it is not true I want to turn Godot into it. As I mentioned earlier- I find its design and quirks to be pretty bad. Thats why its so frustrating to me that the only places to find event sheets are not as good as Godot.

I honestly think that even if blueprints are improved, they will never be as clear and as fast to build as an event sheet - in that respect event sheets are a great tool for rapid prototyping that is often under-estimated. But titles created by Clickteam fusion should talk for themselves. Some may see it as a toy - but to me it's just fun to build game logic this way :)

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 - without the flaws of the engines that inspire it.
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 know Godot really well, so good ideas might arise from the discussion.

I actually have an idea for the event sheet system that will give us a slight edge over just using gdscript - even for experienced users. It's supposed to be used with gdscript, not instead of gdscript- don't forget that

I look forward to the inevitable Visual Scripting improvements that will (because they are fully integrated/supported) be more useful (and likely more popular) than any janky "construct-lite" kiddie-centric 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 (useless I feel that might ultimately be) as they wish, however non conducive to the core design of Godot as that might be.

In the interest of civility (though "kiddie centric" is _exactly_ what the OP is asking for here!) 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.

Why bother recreating construct within Godot _when the actual construct engine already provides that functionality in a robust manner?_

Is the 7 year old kiddie demographic really screaming for that kind of duplication?

@mhilbrunner answering his post feels like replying to a 7 year old troll :D
He thumbed down most of my posts here- all of the thumb downs actually are his.
There seems to be no point in arguing with him, because he doesnt actually reply to questions - I did ask him a few valid questions that could help me get some feedback. What I got in return is more of the same

Does github have a way of blocking people from posting if they are abusive?

Wow, while I have certainly 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 upside in to duplicating 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?

Is there some legit reason to assume that kids couldn't move to gdscript or visual scripting once they outgrow construct?

@spyres you are using generally offensive terms to describe people who use event sheets and event sheets.
They are not "kiddies" and the system is not "janky". Have some respect for those communities for gods sake. Where is this elitist attitude coming from?

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 fusion made games greatly outnumber Godot made games on steam, kickstarter and even app stores in terms of number and revenue they make. That is an entirely event sheet based engine, used by 10- 80 year olds. It's a mixture of all ages. Some of the users are film makers, others are artists - people with jobs who spend money on licenses, exporters and so on. Heck, I made more money selling stuff on their asset store than anything else to do with godot so far.
Here some examples - Alonso Martin, film maker decides to make a game:
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia
A bunch of 7 years old make a game
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game

have a look here
http://indiegames.clickteam.com/
Those seven year olds sure know how to make games and make money eh
https://thinkgaming.com/app-sales-data/publisher/3107/scott-cawthon/

My angle of selling this as a better tool for teaching programming should not be a reason to mislabel it like that. With a wider demographic of users- you end up with more people making games with the engine. Shouldnt that be obvious? Why is this not obvious :D

How many times do you need me to repeat that I am not asking for a carbon copy of Construct2? It's like you repeat the same message without actually reading anything. What I am proposing is a Godot centric event sheet, not a copy of the one in construct2

Now how is reading your posts about the system being "janky" going to motivate me to make a free addon for godot? Think about this a little

Whoa! Shifting goalposts notwithstanding...

Let me clarify.

Construct is pretty successful at what it does. So 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, code.org 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 has only been released 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 be either for 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.

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

The idea is evolving into something more than just a teaching tool. I think I can offer some actually time saving useful functionality to people who already know and love gdscript, but it will take me some more time to develop this to a point where I can present to you how.

Thanks to everyone for the support

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 questions here, but so far nobody has really told me any answers or shown examples:

• How do we register a new script resource type in godot editor and allow the user to attach it to any node? At the moment the addon is operating from the root of the scene and its hacky.
• How do we then make it so that godot opens my event sheet gui - as integrated as the current blueprint system
• 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 yet

So far I can just keep pushing the design concepts and learn more about the api, but cannot firmly guarantee that this can be turned into an addon that actually works fully. People seem to like it alot so far

For stuff like this, I prefer to honor the wishes of the developers:

https://godot.readthedocs.io/en/3.0/about/faq.html

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 about things I cant find in the documentation - trying to make a contribution to godot.
What are you doing here?

You are the only person thumbing down everything and repeating the same stuff in every post. That is awful lot like what a troll does, wouldnt you agree? You are side tracking the conversation away from discussing the design ideas

@blurymind One man's "contribution" is another man's (or engine's) distraction. Sorry that the concept of differing opinions (even those of the devs that they felt important enough to post as part of the official docs) seems so objectionable to you.

Best of luck with your add-on. :grin:

@spyres but have you actually made anything? Have you ever created an addon for godot? Do you use godot?

Why are you here? You are not trying to contribute to the discussion

@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. At least nitpick on design and specific things? I asked you some questions earlier- you never answered anything

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 5 more times. There is one of you .. but so many times

@blurymind And it somehow seems to bother you? Wow, alternative opinions and such.

I suppose _you_ haven't repeated anything at all correct? (Who are you, Why are you here, Justify yourself dagnabbit!). :grinning:

I guess that bit of official documentation comments written by the devs caused a bit of indigestion eh?

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.

@mhilbrunner If my differing opinions distress you so, please click on my avatar and then select "block user". Any pain caused by reading my comments will immediately cease. :smiley:

@spyres I have noted in previous posts that this addon aims to use gdscript, not serve as an alternative language. And yes, nobody is moderating this tracker it seems

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. It's tough 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. I'm sure if there is some overwhelming groundswell of public support, you'll soon have all the information/help you need.

In the words of a wise man, "Don't worry, Be happy". :grinning:

Or "It's all fun and games until someone shoots their eye out!" (um, wait, I don't think that was the quote I was looking for...)

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 and actually begane developing an addon 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

I have been Construct user for past 6 years and I can definetely say it's the best way to approach fastest and simplest visual scripting.

Excellent idea!

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

Brillant idea, collaborate with SnailOn.

1. He is genius.
2. He using Godot around 3 years.
3. He used Clickteam engines since TGF
4. ideal candidate.

@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 presented in update 1 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 of an event sheet. There is a little bit of Game maker too - in the way visual script can seamlessly switch to actual script - something that more advanced users might appreciate

Thanks to everyone for following progress on this addon. The initial reaction is overwhelmingly positive
This greatly motivates me to keep pushing the idea further, while also trying to keep it simple and elegant.

Without inline comments it's hard to keep the easy switching between gdscript and visualscript, but I have a few ideas on howto get over that and experimenting - so I am working on that atm.
I need some way to define in gdscript an empty placeholder where an expression is expected.
Since expressions will return a type of value, I thought of just using the value conversion method in godot for marking the placeholder:
float() ## this will turn into a bbcode item that expects an expression resulting in a float
But that could be somewhat ugly as it will generate many many needless variable type conversion methods inside the final generated gdscript

If godot could do inline comments I would be able to parse them to the method that creates bbcode from the gdscript instead. This would allow me to feed it with some extra information

The best approach really is to just make my damn gdscript to bbcode parser method smarter- which is what I am trying to do now

@blurymind i dunno about git-account. btw, he opened videos again. I've sended few pm to him via, youtube 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 many uses for this for many people working 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. Throw a bunch of stock images, click here and there a bit and you can check if your idea is fun right now. 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 tool 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 despite 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 indie Clickteam fusion made games greatly outnumber successful indie Godot made games.
Games being published, number of sales on steam and mobile and kickstarter titles meeting their goal.
That should be enough proof that professional artists and designers 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 porting the ide to javascript- making it very accessible to non c++ developers to contribute to. I have been actually contributing to it with small fixes so far- just to play and learn. This weekend I am going to try to make some steps to integrate piskel into it 😃 - if all is ok it might be getting a built in pixel editor.
The main dev recently merged a contribution by another dev- adding support of dragonbones out of the box. If you want to, try the newest release from github- not the online demo. It has the goods
https://github.com/4ian/GD/releases

I am also still making a slow progress 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. I did not know that he is a godot user too.

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 IF/THEN in nature, and 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 - it's that extra clarity they add to game logic

I am also noticing trends in the event sheet game engine community atm, that godot could really take advantage of to expand its userbase:

• 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 scene editing capability- they were hacks to get event sheets to work with 3d engines - put ontop 2d engine editor not designed for 3d games. You can only construct a 3d scene with event logic in them - making it a pain to put objects, set materials, etc.
• 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

On a side note, I managed to get Piskel bundled and integrated with Gdevelop. This was keeping me busy in the last few weeks. You can give it a try if you want to :)
I have been looking at how event sheets are done in gdevelop too

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

So what if no middle ground can be achieved. Something will just die off. 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.

1. Unity: 4011
2. Unreal: 316
3. Gamemaker: 274
4. Construct: 223
5. 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 if you try Construct's event system, notably including other event sheets and using 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.

@swarnimarun 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 have already won and are now 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.

Hell even when looking at other visual programming engine forums you can see the negative reactions to any new blueprints system engine:
https://rpgmaker.net/forums/topics/23922/?post=857285#post857285

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 and rapidly prototype with granular logic and blueprints to organize it in state machines.
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. But that doesn't mean that another idea must be killed. Both ideas are widely liked or disliked.

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 their 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. This is my main pitch here- both to pro devs and fans of visual programming. But also lets not forget that it is a matter of personal taste. I am not going to try and make blueprint devs fans of this. I will instead point out that many visual programming developers dont like blueprints and prefer event sheets.

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 be the first proper 3d game engine to support event sheets. This by definition will elevate it above all the other event sheet engines at the moment.
As I mentioned before, this has been attempted before in both Clickteam fusion and in Construct - as plugins, even in game maker. And it is a clunky mess there because the editors of those engines have zero 3d capabilities.

Clickteam fusion - Firefly engine:
http://clickstore.clickteam.com/firefly
https://store.steampowered.com/app/267655/Firefly/
It's getting panned on Steam - as it is an awful buggy addon

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 just as much programming knowledge as 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(will help me learn Godot API), 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,colors, 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- removing the noise of syntax makes it much clearer to read
• 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's documentation. 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. The ability to collapse blocks of logic you decided should be collapsible is very nice to have when you are organizing your code and want to hide parts of it you are not working on.

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 guess if I have to summarize the perks:
for newbies- the code is much clearer at first glimpse, its more inviting because of how the api of the engine is presented to them and the logic they put down has visual hints (icons of nodes)

for more experienced- you can still write gdscript in all expression fields, but now you can also have some parts of the process be faster (like no need to navigate to other nodes with typing code), ability to drag logic around to change its execution order or requirements (no need to cut and paste)

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

I agree with @mhilbrunner that it should be its own system, but it would be great if its possible to combine it with the blueprints system- the way you can combine gdscript with blueprints in a project

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

i was starting to work on this, but your code seems to be more advanced than mine, i'm afraid i cant be helpfull, but i would like to try it anyway

@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.
Eventsheets are a way to get around that hump whenever you've taken a leave of absence from programming (because as artists it is expected that you won't spend continuous time just coding).. 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.
So yeah.. you can just be like.. oh whatever- sucks to be you.. too bad you don't dedicate your time to being a fulltime programmer, etc. which would alienate a lot of people that will never be full-time programmers or as technically minded. 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
new 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
Code with autocompletion 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 it 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. Again this is just experimenting in how it could work. This is far from being anything usable atm..

On Wed, 30 May 2018 22:59 Daven Bigelow, notifications@github.com 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

@blurymind I recommend not shooting for tutorials but learning from actual practice or other developers.
No one really helped me. I didn't needed much help either. I am sort of good at picking stuff up, so it all worked out fine. Still I am only getting started, that is compared to the experienced devs.

And I believe that you are using GDScript to do all the programming, or are you using C++.
Cause there are no modules that let you do anything by default or when starting out. You have to learn from what is already there. And create your own.

Converting to Typed GDScript should be simple if you are using GDScript and if you are using C++ little porting will be required. And as far as I know, the PR should be merged any time now. It's been reviewed and seems fine. Haven't tried it yet but really excited.

And let me guess currently, you are using GDScript with get_method_list() and get_property_list() likely. But I would recommend you to use signals and groups too, signals are the Godot event firing mechanism. I don't really know about the EventSystem but if you want to create something like that in Godot. Make sure you use Godot to the fullest.

And lastly if you want help just message me on Twitter or Discord. I will be free for a few days right now.

@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

The typed gdscript is what the helper menus will generate for expression mode - its just better for converting to bbcode to render the ui with a rich text label

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

@blurymind - Excellent work. I literally just started learning C++ because of the performance improvement in Godot when compared to GDScript (3 to 4 times faster, depending on your metric - see bunnymark). If it's at all possible I would recommend going straight for gold and using C++ for this, even if it means a learning-on-the-job - it'll be worth it. Give me a few weeks to get a feel for C++ and I'd be up for helping as well if you'd like.

@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 easier to learn 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
Everyone is free to fork or do pull requests 👍

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 rendering are the things that might 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 thing is a mess atm code wise, so having more experienced programmers would be of great help to me.

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 them and if a node is deleted by the user and not found by the event sheet's logic- it can be re-linked

In any case, please share if you have something - even if its basic. I will try to learn a bit more C++ and join you in writing it as a module :)

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

For example, the new Visual Shader looks very good and promises great things for the future. I did some tests and I like it very much as an idea. But to realize the logic of a videogame, Visual Scripting is a trap.

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 fully executing my vision of this as an addon. Even If I get it to a functional state - it will probably have limitations.

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 whenever there is time.

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.

Unfortunately I have a full time job that takes the majority of my time at the moment :(
Sorry for the slow updates

To add to this discussion, I would like to present to everyone here 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
It is somewhat similar to https://www.reddit.com/r/unrealengine/comments/4nt0up/need_help_debugging_this_blueprint/

Note the alternatives Gamesfromscratch presents

One thing I want to avoid here in this design proposition is predefining behavior that is outside of what nodes already do in godot - also creating a lot of tabs and gui .
A godot event sheet should work exactly as gdscript code- only in a more tactile/visual way
It shouldnt try to build an easy to use game engine on top of godot, but rather make what godot has more accessible and faster to put together

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, notifications@github.com 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.

It is a great idea! I never really understood these blueprints, but event-based approach is well-known, especially in modding communities, such as Warcraft III World Editor.

Example screens:


Categories and clean list of triggers look great, at least for me. It is easier to perceive them than screens from the first post.

It is mostly the same as you said, but with possibility to add conditions as actions and nest further actions in them.

@Wiadomy
this image is too small to see/ read anything

@Elmapul
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.

@swarnimarun really the best thing to do is use the engines for a while and think about how this can be done in a more godot way. Construct classic and gdevelop are great examples imo.

From my point of view signals in godot are just like built in function events. Connecting signals is already visual in godot :)

Setting a signal from an event sheet is just an action available in the helper menu - under the hood that is just a setter method. So it would be the same as with gdscript.

If a node contains built in methods, that should be available in the menu you'd get when clicking on 'Add built in function'

I strongly think we should keep it simple and be a wrapper for typed gdscript, but if thats not possible or practical - could be a different API. It would be worth investigating how the current visual script implemented in godot works as an abstraction.

If you wonder how custom functions are made in construct, here is a link to their doc
https://www.scirra.com/tutorials/823/creating-function
:)

@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. It does not get any more bloated than standard code.

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 :)
You do not have to script everything from scratch.

What is even cooler is that you can nest these nodes 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.
It has a lot of potential that is untapped.

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.

Is this project dead now?

@Amr512 I don't think it is dead. There is certainly a lot of desire to bring this functionality to godot.
@reduz has even taken some interest in gdevelop recently on twitter
https://twitter.com/reduzio/status/1085206844275081218

While I haven't worked on the addon for a while, I decided to actually go and start contributing to gdevelop itself- in order to learn more about how it's event sheet is programmed- as well as help make it a better alternative to the paid options.
https://github.com/4ian/GDevelop/

Some universities have started picking up gdevelop to teach programming courses
https://github.com/4ian/GDevelop/issues/882

My buggy godot addon is currently just for presentation purposes and needs a lot of work before it can be functional. Anyone is free to fork it and try to push it further of course.
One big thing that my addon is currently missing is a sortable tree gui element for the event rows. There is also no functionality to actually render event sheets to gdscript yet, nor is there a proper expression text editor with syntax autocompletion and coloring (the idea is to use standard gdscript for syntax). It's missing a lot of key elements that would make an event sheet, but the main goal is to present how an event sheet can be used in combination with gdscript for expression syntax. I think the two would make a very powerful combination for prototyping games - even for experienced devs

@blurymind I left a ticket on your project (errors on Godot 3.1beta3).
I totally love the idea.

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

Perhaps my implementation could be deemed as something akin to DSL so that's where the differences may come. Many rules are just sandboxed implementations of functions tailored for specific game play requirements. In essence conditions and actions just inherit these small scripts with the methods which must be implemented in child classes:

class_name SchemeCondition extends Node

func is_met(object): # override
    return true

class_name SchemeAction extends Node

func perform(object): # override
    pass

The rules are just a collection of those conditions and actions and are executed based on whether all or any conditions are met, nothing too fancy in fact.

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

You use the richtextlabel to render each cell, these cells are nested in left and right column, which is then a child of a row. Rows are managed by a sortable tree. Each row contains actual gdscript which an interpreter renders into simple short descriptions with thumbnails and clickable areas to enter expressions.
This is actually what game maker does. Their visual programming data gets stored as actual gml.

The tricky part I found when i started doing it as a gdscript extension was doing the expression fields. How do we put a code editor in an input field and let it do autocompletion for us? How do we give it completion and validation context? Without validated autocompleted expression fields, this is dead in the water.

We have all the UI parts to build this in godot, but we have literaly not a single experienced dev doing anything on it. I havent seen any work done so far

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 still pretty confidently vouch for event sheets.

Construct 2 was in fact my very first exposure to many fundamental programming concepts, through a class I took back in high school. I feel that it massively simplified and expedited the learning process for me--both the engine in specific as well as programming in general--while also translating closely enough to actual code that I didn't feel totally lost in the transition from event sheets to regular old text scripting. While I can't be 100% sure of this, 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. A solid visual scripting system could make a huge difference in how approachable Godot is, and could mean getting the support and adoption of a lot more people, who otherwise would not have considered Godot.

Actually, the main reason I originally switched away from Construct 2 was simply because I wanted to get into 3D already. I ended up trying Unity, Unreal, Godot, and Amazon Lumberyard, and ended up going with Godot pretty much just because it felt snappier to open and use and the import process felt better. But if Godot had the event sheet-style system, I would've probably immediately defaulted to Godot. Granted, it really doesn't make a difference to me now personally, but again, this is about making Godot as friendly to non-programmers (i.e. a significant portion of new/aspiring game devs) as possible.

I haven't read the 112 posts that are now hidden, so I apologize if I've repeated or missed anything, but I'd totally be 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 first, then the code would already be mostly done, and it would just be a question of whether we want to switch over to that system 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 notifications@github.com 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. For example, 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 would rather that the Godot dev heroes focused their time and effort on adding other engine improvements.

I pretty much agree. I think the ideal way to go about this would be for anyone interested to try and get a working prototype together, and then from there the community can try and figure out if it's worth switching to that as the main visual scripting system or not. I wouldn't ask for any main development time on this idea until a decision is made or at least near.

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 notifications@github.com 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.

It will teach you about execution order and how to read code.

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. Both companies have flaws and their community has no control over what happens to the software. This is where open source shines

@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.)

Still, this thread contains a lot of valuable discussion, so thanks anyway :slightly_smiling_face:

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.

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

@prominentdetail Here's my anti-bump notice message, I forgot to paste it :slightly_smiling_face:

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

(I wish GitHub had a way to send private messages, or at least specify a custom reason for hiding, so I wouldn't have to litter the comment thread with this.)

PS: This is typical etiquette on GitHub; it's not specific to this repository.

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.

Was worth a try and the discussion was interesting for sure :)

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