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

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

[ghost]

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

[ghost]

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

[DrZanuff]

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!

[groud]

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.

[blurymind]

@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

[64Forever]

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

[blurymind]

@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

[VitorDiasBode]

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.

[ghost]

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.

[blurymind]

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

[ghost]

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

[blurymind]

@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

[ghost]

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

[blurymind]

@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

[blurymind]

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

[DrZanuff]

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

[Zireael07]

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?

[blurymind]

@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

[mhilbrunner]

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.

[blurymind]

@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