Event Sheet style visual scripting

[blurymind]

NOTE:
Here is the test repo that I added the prototype project to
https://github.com/blurymind/Godot-eventSheetPrototype
Everyone is free to fork or do pull requests 👍

IDEA:
We currently have a visual scripting system similar to blueprints in Unreal - connecting nodes.
The proposal here is for a second visual scripting system, that is similar to event sheets in Construct 2 (proprietary), Multimedia fusion (proprietary) and Gdevelop (open source)

It is a very different approach from the one with blueprints and people learning to program are still requesting it on facebook and other godot community forums

What is an event sheet visual script in the other engines:
https://www.scirra.com/manual/44/event-sheet-view
The event sheet is pretty much a spreadsheet with two columns - a conditions column and an actions column. Both columns can be populated with logic blocks from nodes and their children that the sheet is attached to (node methods). On the left column the user can only attach conditional methods, on the right - only action methods. This clear divide makes for a very easy to learn way of setting game logic.
On top of that the user can use expressions in both columns - so potentially use gdscript for more specific instructions.

Rows can be nested under other rows (called sub-events), can be commented, disabled or re-enabled (just like commenting code)
https://www.scirra.com/manual/128/sub-events

Some actions/condition blocks can be negated

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

So What are the advantages over our current visual script:

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

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

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

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

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

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

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

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

Addon progress report 0

Here is a crude mockup so far:

Demos of event sheet style systems that you can try online(no log in required):
https://editor.gdevelop-app.com/
https://editor.construct.net/

Event Sheet System Possible Structure:

|_Event sheet established variables and connections tab
|_Event sheet script tab
  |_Function(built in or custom)
      |_event sheet row (can be parented to another event sheet row or an event sheet group)
          |_Actions column
               |_Action cell (richtex label) (click to open another window to edit)
          |_ Conditions Column
               |_Condition Cell (richtex label)(click to open another window to edit)
|_Action/Condition Cell Expression Editor
  |_Gdscript editor instance - to be used for expressions
  |_Easy Click interface to access the available subnodes - their nodepaths and methods- clicks bring up menu that populates the expression editor - similar to Clickteam Fusion's

Inner workflow:
Event sheet resource can be attached to node -->on runtime it generates a gdscript and that is used by the game

Addon progress report 1

I did some work on the addon's most important building block- the event sheet cell

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

So an event sheet cell has 2 modes:

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

When clicked away, switches to view mode.

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

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

Note that this is still full of bugs and not even half complete to share, but hopefully makes it clearer what I am proposing

Progress report 2
Made some planning on how it can work. Also looked into what needs to be refactored before presenting the concept addon

I made this flowchart to explain how it works at the moment
https://www.draw.io/#Hblurymind%2FGodot-eventSheetPrototype%2Fmaster%2FEventSheetDiagramPlan.xml

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

[mhilbrunner]

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?

[groud]

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

[blurymind]

@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

[mhilbrunner]

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

[blurymind]

@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

[groud]

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.

[blurymind]

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

[mhilbrunner]

@blurymind Yeah got you, working on such a list for VS and will do, but will take some time.

Need to investigate NativeScript :)

[blurymind]

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?

[groud]

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.

[blurymind]

@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

[groud]

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.

[blurymind]

@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

[groud]

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.

[blurymind]

@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

[groud]

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.

[blurymind]

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

[groud]

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.

[blurymind]

@groud can we even group visualscript nodes like in blender? I don't remember seeing that . Perhaps @mhilbrunner should add it to his list
godotengine/godot#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

[64Forever]

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

[ghost]

lol how is this more easier to read than gdscript

[groud]

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

[ghost]

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

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

[ghost]

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

[blurymind]

@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

[groud]

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.

[ghost]

@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

[blurymind]

@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

[mhilbrunner]

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.

[AnidemDex]

You actually don't need to generate GDScript as the initial concept was, just define the "interpreter" with gdscript (or your favorite language) 🤔

[pietru2004]

I got referenced here from DC, Cause I have yet another idea how to add VS Scripting

Basically have functions displayed as graph blocks and have ability to edit functions in side view.
Under the hood it just parses gdscript to find functions definitions and place them as blocks. Also this one is meant to help in cases of having too many functions in scripts to see them better by just helping you focus on one, also if you save while there are 2 functions defined it just adds new graph node to graph edit.

Only 2 things missing in here are ability to reload code/notify of code change and ability to have gdscript code interpreter work in code edit... IDK how to make it work...

I hope I didn't misunderstand issue/post...

[starry-abyss]

I like the idea of tables or trees + transpiling them to GDScript under the hood. That's how scripting in Warcraft 3 was done (with their own scripting language instead of GDScript of course).

I think what a lot programmers miss is that such visual scripting languages completely remove the layer of compiler yelling at the user. It's just impossible to make mistakes that are later caught by the compiler, because the UI checks all the names and types and just won't allow user to make those mistakes in the first place. As in, you can't input a value of wrong type at all.

[Raiguri]

Someone made plugin for Godot 4 that adds Construct-like event sheets
https://t.me/wladekhack/60

[DrZanuff]

@Raiguri any chance they have a link other than Telegram?

[Raiguri]

@Raiguri any chance they have a link other than Telegram?

I don't think so, he didn't upload it anywhere, except his telegram.
Oi, my bad he uploaded it to mega

Translation of his telegram post:

Implemented a plugin for Godot 4 that adds a event sheets as in Construct 3.

The plugin is just a visual shell with a little functionality, but it can't execute the code itself when the game starts. It has a basic implementation of code execution from the event table, but it is very simple. If there are experts in Godot 4 and willing to refine this plugin I am ready to share the project (source code).

In my opinion - the full implementation of such a plugin can be a good competition to Construct 3 and open more opportunities for development than in Construct 3.

There are 3 plugins in the addons folder:

• event_sheet - this is the main plugin.
• plugin_refresher - plugin for development, it is needed to update the main plugin without restarting the project.
• explore-editor-theme - plugin for development, it helps to find out the names of standard Godot 4 icons and theme colours.

The folder ‘demo_project’ stores demo scene and object.

The folder ‘event_sheet’ stores the saves of the event table.

Source code: download (https://mega.nz/file/VCtU0CLR#AbN2kn_wgPtRwL_7hFDg6WNUNLLmA0oBYWtJG9KYQA4)

[DrZanuff]

@Raiguri does it have a repo? Or they intent to make this something paid/closed source. As I don't have access to Telegram I kind of blind here. If you could share any news here it would be nice.

[Raiguri]

@Raiguri does it have a repo? Or they intent to make this something paid/closed source. As I don't have access to Telegram I kind of blind here. If you could share any news here it would be nice.

He said in his post:

If there are experts in Godot 4 and willing to refine this plugin I am ready to share the project (source code).

[DrZanuff]

Hope this gains some traction. Thanks for sharing.

[WladekProd]

@Raiguri any chance they have a link other than Telegram?

I don't think so, he didn't upload it anywhere, except his telegram. Oi, my bad he uploaded it to mega

Translation of his telegram post:

Implemented a plugin for Godot 4 that adds a event sheets as in Construct 3.
The plugin is just a visual shell with a little functionality, but it can't execute the code itself when the game starts. It has a basic implementation of code execution from the event table, but it is very simple. If there are experts in Godot 4 and willing to refine this plugin I am ready to share the project (source code).
In my opinion - the full implementation of such a plugin can be a good competition to Construct 3 and open more opportunities for development than in Construct 3.
There are 3 plugins in the addons folder:

• event_sheet - this is the main plugin.
• plugin_refresher - plugin for development, it is needed to update the main plugin without restarting the project.
• explore-editor-theme - plugin for development, it helps to find out the names of standard Godot 4 icons and theme colours.

The folder ‘demo_project’ stores demo scene and object.
The folder ‘event_sheet’ stores the saves of the event table.
Source code: download (https://mega.nz/file/VCtU0CLR#AbN2kn_wgPtRwL_7hFDg6WNUNLLmA0oBYWtJG9KYQA4)

https://github.com/WladekProd/EventSheet

[AnidemDex]

@WladekProd the repository is private

[WladekProd]

@WladekProd the repository is private

Fixed

[St3fanos]

@Raiguri any chance they have a link other than Telegram?

I don't think so, he didn't upload it anywhere, except his telegram. Oi, my bad he uploaded it to mega
Translation of his telegram post:

Implemented a plugin for Godot 4 that adds a event sheets as in Construct 3.
The plugin is just a visual shell with a little functionality, but it can't execute the code itself when the game starts. It has a basic implementation of code execution from the event table, but it is very simple. If there are experts in Godot 4 and willing to refine this plugin I am ready to share the project (source code).
In my opinion - the full implementation of such a plugin can be a good competition to Construct 3 and open more opportunities for development than in Construct 3.
There are 3 plugins in the addons folder:

• event_sheet - this is the main plugin.
• plugin_refresher - plugin for development, it is needed to update the main plugin without restarting the project.
• explore-editor-theme - plugin for development, it helps to find out the names of standard Godot 4 icons and theme colours.

The folder ‘demo_project’ stores demo scene and object.
The folder ‘event_sheet’ stores the saves of the event table.
Source code: download (https://mega.nz/file/VCtU0CLR#AbN2kn_wgPtRwL_7hFDg6WNUNLLmA0oBYWtJG9KYQA4)

https://github.com/WladekProd/EventSheet

hopefully this takes off, seems great!! fingers crossed

[blurymind]

one thing I found challenging when trying to do a proof of concept ages ago was getting expressions fields with gdscript autocompletion to work.

They are quite an important element of both construct and gdevelop when it comes to the event sheet.

How does one even do a mini input field similar to a textarea alement - with syntax autocompletion, coloring that has both gdscript and custom context mixed. Expressions need to indicate when wrong (linting) - just the same as the code editor works. You need to basically create many usable mini gdscript editors - customised to know if they are expressions for condition or action or ones supposed to return a type of value (boolen, number, string, etc) and tell you when they are not returning that type of value. They need to have correct validation in place depending on the context they are used.

Then you need to convert all of that to actual gdscript when building/playtesting - thats another huge hurdle

[AnidemDex]

I still don't like the whole idea of converting that behavior into gdscript, that would limit the capability of the system itself just trying to preserve the 1:1 scripting to gdscript.

That said, Godot now has a code edit node, that includes autocompletion, I guess it would be easy to implement gdscript completion if somehow you got access to the script server 🤔

[blurymind]

In my opinion this should try to be as close as possible to the engine's functionality and not attempt to add any special abstractions to the runtime.

That way:

• less likely to loose compatibility when godot updates - easier to maintain and less likely to become a dead project
• fewer gotchas when something in your game doesnt work - is it my event sheet or my gdscript
• better learning transition for anyone starting with the event sheet to moving to gdscript - once you use expresions, you can apply that knowledge to gdscript
• very much like how game maker does it - their visual programming system transitions to gml on the fly - it uses gml under the hood
• godot is not architected like gdevelop and construct from the ground up to be event sheet first engine. It is closer to game maker in that regard - game maker has its own scripting language (gml) and a UI coding frontend to it

The event sheet system can aid the developer the same way the other engines do it:

• visual hints (such as object icons) in the code
• scaffolding that gives simple representation of the code and very good overview of the available methods and available objects that can be affected
• gui aid when building an expression - giving you good overview of whats available for use in said expression - Construct, Gdevelop both took that idea from Clickteam fusion btw

Why object icons are good - they are almost like emoji representations of your nodes and game objects - when you look at them its much faster to read at a glance than their word representation. For generic types - you can completely remove the word representation and eliminate alot of noise in how logic is represented on the screen

[WladekProd]

At the moment I am rewriting the plugin completely, I decided to change the code completely to achieve easier extensibility and get rid of crutches of the old code. If there will be success - will report.

I rewrote the compiler of the event table according to the new scheme: Event Sheet -> GDScript -> Run Code.

That is, first you build the logic in the Event Sheet and when you start the project the engine creates a GD script from it and runs it. Also decided to implement adding Event Sheet for any scene instead of one generic one. So far, there's been a little success. After completing the logical part, I will start the visual part.

[WladekProd]

If there will be success - will report.

Generating code from the event table works even better than I imagined. There is no visual part of the event table yet, but I will start working on that once the tests are complete.

[DrZanuff]

Nice!

[AnidemDex]

Godot now has a code edit node, that includes autocompletion, I guess it would be easy to implement gdscript completion if somehow you got access to the script server (#27 (comment))

Mandatory mention to: godotengine/godot#95764

[WladekProd]

2024-10-23.00-25-40.mp4

Innovations:

• Minor bug fixes to the Event and Event Selection window (now when pressing “back” and “next” buttons, previously entered parameters will be saved for each Event and Event).
• Adding events and events to Event Sheet (all this works recursively, my brain was boiling while I was dealing with it - but I'm happy with the result).
• Sub Events system (yes, you heard me, now you can create sub-blocks, move them, change order and so on).

[DrZanuff]

Very nice man! I know maybe it is too early, but how do plan to handle created objects and pick then aftewards in conditions?

[WladekProd]

Very nice man! I know maybe it is too early, but how do plan to handle created objects and pick then aftewards in conditions?

I'm still thinking about it, but the first draft is already there and it looks like this.

3407728732894939038.mp4

[DrZanuff]

I see what you’re aiming for here, but I think it could become too cluttered when dealing with a large number of nodes and nested structures.

Perhaps each node in the tree could have a checkbox in the inspector to mark it as "pickable" by the eventsheet? Additionally, objects created by the eventsheet could have this option enabled by default. Just brainstorming ways to handle potential challenges.

[WladekProd]

Perhaps each node in the tree could have a checkbox in the inspector to mark it as "pickable" by the eventsheet? Additionally, objects created by the eventsheet could have this option enabled by default. Just brainstorming ways to handle potential challenges.

I have plans to do something similar, but I haven't done it yet. I made a temporary solution that simply takes objects from the scene to see how it will look in the event and event adding window. The idea is that I created 2 objects "VNode2D" and "VNode3D" that store "event_sheet_data" from which the script will be generated and executed specifically on this object. Perhaps over time I will change or improve the approach to this, but for now this is it.

[prominentdetail]

This is looking very nice. It has been a while since I used construct, but I can definitely see the similarity. It has a familiar, comfortable feeling to me, and hope to see more progress!

[WladekProd]

2024-11-04.01-13-39.mp4

[blurymind]

This is very cool, but wouldnt you prefer something that requires less steps? I think Gdevelop is a better example of this being streamlined where you can add items without even opening the wizard and its a single step.
When you use the dialog way - it has a search field that takes you directly to what you need and its a single screen to set up, not a wizard like construct's