Block Coding - high-level, block-based visual programming

dsd_endless

Hi! Here at Endless OS Foundation we have recently started engaging young learners in the world of Godot; our learning programs aim to develop a broad range of 21st century skills in underserved communities, and game creation provides a fantastic environment for that to happen.

We are looking at different ways to ease first-time game developers into Godot. As part of this we have just published our initial learner-oriented block programming plugin prototype for Godot. It is available via the AssetLib. Here is a demo of how it can be used to build a simple game:

More background and getting started info in the README.

Our aim is to reduce the learning curve faced by learners who are on the early part of their journey towards becoming game developers and are starting to use Godot for the first time. These learners face the challenge of learning to code, while simultaneously having to learn their way around the Godot Editor. In this project, we take a step to smoothen that out for the learners: we allow games to be built with high-level visual programming blocks, instead of GDScript. Tools like Scratch and Makecode have demonstrated that block coding can be much more accessible and intuitive to beginners than textual programming. We envision that learners will use block coding as a stepping stone to learn programming concepts while building their first games, simultaneously getting familiar with the rest of the Godot editor, before later progressing onto learning GDScript.

We are making this initial version available seeking feedback from community members, learners and educators. We will then continue development, incorporating such feedback and improving the technical architecture. Please share your feedback!

The Endless team will be at GodotCon 2024 in Berlin - hope to see you there!

CodeSmile

dsd_endless block coding can be much more accessible and intuitive to beginners than textual programming

Here's a though: what about textual block-coding? 😉

Working on that right now. Got the same Scratch-like code working in Godot, and Unity, and Unreal. Currently C# but I aim to expose it to Lua as opt-in for even less clutter and hot reload.

kuligs2 I think better approach for starters is to use simple enough scripting languages. gdscript is pretty simple. you need to teach them to use the docs and rtfm.

This RTFM is part of the problem. Not the doing it, but the attitude. I'm sure back in the 50s parents were still like "Oh no, no. You don't get training wheels, you're going to hurt and bleed just like I did when I learned to ride a bike!"

And then came Scratch ... yet here we are, game engines are still pretty much buzz-off tribal territory. You either got to learn like I did (aka with all the pain), or quit.

There's but one thing to consider: learners don't just learn how to program when they open a game engine for the first time.
They come here, expecting to be able to make games. Then they find they have to learn all of these simultaneously:

learn programming concepts (Scratch may have helped)
learn the (new) programming language syntax
learn the game engine's API semantics and meaning (Godot: 15k keywords, Unity: 25-75k, Unreal: >120k)
learn technical jargon, and possibly also the english language (!)
learn the game engine's architectural concepts (Nodes, GameObjects, Actors ...)
learn how to use the editor
learn asset workflows / pipelines, and where to source / create assets
learn game dev / genre best practices (and limits)
learn game design (aka "fun")

The more we can cut away from these immense learning blocks, the better!

kuligs2

idk, maybe its just me, but these things will more confuse people than help them understand.

When i started out in programming i saw people use some kind gui development thingie where they click buttons and then place objects and stuff happened (game dev), in some early promotional vireos of game studios back in the day, and it confused me when i had to start learning to use code, like write words and stuff to make things happen.

I think better approach for starters is to use simple enough scripting languages. gdscript is pretty simple. you need to teach them to use the docs and rtfm. How to search the problem. How to debug problem. what are functions etc.. this will definitely help to understand programing in general.

in godot you dont have to code the frontend to see results, just move some nodes around and press play and you already see the results. That is more fun to learn than using gcc

xyz

CodeSmile I'll never understand this drive to force coding upon people who don't have inclinations towards it, by using some mickey mouse methods, to make it appear simpler than it is. Why do that? It's not like coding or game dev in particular need even more "popularization" at this point. It's already too popular, resulting in oversaturation of gaming space with low effort crap and slop. Further "popularization" will just make this worse. Besides, you can't really make a good coder out of someone who's not naturally inclined to that way of thinking. People who have the propensity won't need kindergarten style pampering anyway. They'll be perfectly happy to just do it the proper "adult" way.

DaveTheCoder

xyz I'll never understand this drive to force coding upon people who don't have inclinations towards it, by using some mickey mouse methods, to make it appear simpler than it is.

It's analogous to the trend of adding gadgets to cars to make them easier for idiots to drive.

Rear cameras for people who don't understand how to use rear-view mirrors.
Sensors for people who can't keep track of their children and leave them in a hot car.
Remote starters for people who are too impatient to sit in their cars while they're warming up.
Self-driving cars for all of the above.

Tomcat

DaveTheCoder Remote starters for people who are too impatient to sit in their cars while their warming up.

Oh, sure, sitting in your car and waiting for the engine to warm up is a perfectly useful and rational thing to do.

Rear cameras for people who don't understand how to use rear-view mirrors.

Rearview mirrors often have limited visibility and blind spots. Cameras have an advantage in terms of visibility.

xyz It's already too popular, resulting in oversaturation of gaming space with low effort crap and slop.

Indie games are overflowing with titles that are terrible in terms of graphics and aesthetics. A few artists who understand beauty but aren't very good at classical programming can try to dispel this nightmare at least a little.

It's just a concentrated extract of snobbery.

CodeSmile

xyz I'll never understand this drive to force coding upon people who don't have inclinations towards it, by using some mickey mouse methods, to make it appear simpler than it is. Why do that?

For the same reason we don't read Shakespeare to a 5-year old. Language can be beautiful and express complex emotions, but it needs to be learned and understood first. Parents adapt their language to match their kids' cognitive abilities automatically. Apparently we seem to forget about that once we become programmers.

I think Scratch pretty much shows why we need more of that simple programming even in actual game engines. The excited comments on the BlockCoding Youtube videos speak for themselves. And my experience creating and using such a system for designers was also stunningly positive. Onboarding was easy, scripting was reliable, plannable, highly productive and creative, and in the right hands powerful enough to push boundaries of what the system was originally intended to do.

xyz t's already too popular, resulting in oversaturation of gaming space with low effort crap and slop.

Right. Let's put the fences up. Let only total nerds in. 100,000 game developers and not one more!

OR we can accept the fact that gaming is a growing industry that needs the new talent because companies have lots of open positions they can't fill, specifically in programming. And they need to come from somewhere, and the smoother the upramp the more "survive" the journey. Currently, it's more like a giant leap up that only the select few can take. Not too long ago we used to look down on ewww Python that isn't "real" programming! Now Python (and GDScript) aren't just for the entry-level, they're professional tools (and always were).

So what if these young lads create lots of crap? We all did back when we were learning. Only REAL difference is that they can easily publish and find an audience (ie itch) while we simply couldn't or at best put it up on our website with 10 views per month. So the problem isn't about letting more "in" but perhaps rather not allowing everything to get published - but that's really not our problem and has been discussed to death ever since Steam greenlit Greenlight.

xyz People who have the propensity won't need kindergarten style pampering anyway.

Btw that's what I was referring to by "buzz-off tribal territory". Members only. You gotta have what it takes ...

DaveTheCoder It's analogous to the trend of adding gadgets to cars to make them easier for idiots to drive.

That's completely besides the point. These gadgets get added because they can charge customers premium for it, and then charge them even more since the more things that can break, the more money customers leave in the shop over time. Customers buy them because they provide (perceived or real) convenience, comfort, safety, and of course they add value to their status symbol.

xyz

CodeSmile OR we can accept the fact that gaming is a growing industry that needs the new talent because companies have lots of open positions they can't fill, specifically in programming.

See that word you used there - talent. It completely dismantles your position and proves my point.

Nothing to be gained from "visual coding". Developing such systems is fool's errand. They're boring toys at best. It's just a delusion that some coding-minded people have about how non-coding-minded people could be magically turned into coding-minded people. In reality it can't be done, no matter how colorful and full of kittens your boxes are. There's no established educational methodology or serious body of research that supports it. In fact, there is research that shows the cognitive load is the same whether you're learning "visual" or standard textual coding.

CodeSmile You gotta have what it takes ...

You do.
And yeah, I totally am for gatekeeping. It's a good thing, if based on merit.

Tomcat

xyz See that word you used there - talent. It completely dismantles your position and proves my point.

??!! In what way exactly?

It seems that you are only willing to use the term “talent” in relation to programmers. You apparently do not apply it to people from other fields a priori. Even I am deeply shocked by this.

CodeSmile For the same reason we don't read Shakespeare to a 5-year old. Language can be beautiful and express complex emotions, but it needs to be learned and understood first. Parents adapt their language to match their kids' cognitive abilities automatically. Apparently we seem to forget about that once we become programmers.

There may be a homeopathic dose of reason in the insinuations of @xyz and @DaveTheCoder. The problem is that creating games requires programmer's thinking. And programming should be taught in school. In this regard, GDScript is very good — practically ideal as a “first language” (no comparison to BASIC). There are examples of artists mastering a primitive programming language and creating very interesting games. This is Ren'Py. I am surprised at how complex a game can be on it. But translating the entire GDScript into visuals is most likely a hopeless endeavor. The official developers refused to do this for good reason. When this refusal was discussed, it was suggested that the most reasonable option would be for the programmers of each specific project to visualize only the necessary parameters for that project. I find this interesting, specifically in the context of my project — I want to give talented artists the opportunity to create dynamic (interactive) stories (visual novels), and visual programming is ideal for this. But this is only within the project. Therefore, I will follow your project and possibly take something from it (if permissible). But, in general, I view it with regretful skepticism.

Tomcat

xyz The context of the thread is programming. I haven't used that word, the OP did. I used "inclination". And I do think it applies to any field. People who don't have natural propensity for a field, shouldn't be pushed into it or lured by false promises and candy. Nobody benefits from that. By "inclination" I didn't even mean talent is the classical sense, it could just be a strong drive to want to do it.

I will even quote it in full. You are confusing or substituting the terms “talent” and “inclination.” And you are completely omitting the term “opportunity.” I may be a little confused by this wild language, but I tried to check them.

I gave an example of artists learning a simple programming language and creating high-quality, interesting narratives with fairly complex interactions (I could provide a link, but it's NSFW (all good things are NSFW)). So the idea of simplifying programming for game creation is quite productive. Why is it that only programmers who are terrible at art can create games, but artists can't? But translating GDScript into visuals seems like too much of a task to me.

CodeSmile The difficulty also lies in the fact that GDScript is constantly changing, and even after minor changes, a lot of rewriting will be required.

xyz

Tomcat It seems that you are only willing to use the term “talent” in relation to programmers.

The context of the thread is programming. I haven't used that word, the OP did. I used "inclination". By "inclination" I didn't even mean talent is the classical sense, it could just be a strong drive to want to do it. And I do think it applies to any field. People who don't have natural propensity for a field, shouldn't be pushed into it or lured by false promises and candy. Nobody benefits from that.

Tomcat There may be a homeopathic dose of reason...

Come on, there's more than a homeopathic dose 😃

xyz

Tomcat So the idea of simplifying programming for game creation is quite productive

My position is that "visual coding" does not "simplify programming". The notion that programming gets simplified there is a pipe dream. Can you explain in what way it simplifies it and how can we measure the degree of that simplification?

Tomcat The difficulty also lies in the fact that GDScript is constantly changing

The language is not really changing much. The APIs are. And that's a different thing. But the fact that that poses a problem for "visual coding" just shows how clunky and inflexible it is as a way of telling the computer what you want it to do.

Tomcat

xyz Can you explain in what way it simplifies it and how can we measure the degree of that simplification?

Visual representation simplifies perception. Clear arrows instead of magic words — that's the whole idea behind visual programming. The question about the degree of simplification just confirms that you have no idea what we're talking about. “Professor syndrome” — a professional with extensive experience has forgotten how he learned and cannot understand that others may not understand his field.

xyz

Tomcat Visual representation simplifies perception.

Coding is not about perception. And you've yet to prove that the process of coding gets simplified in any way by using boxes and noodles.

The idea that "visual coding" simplifies coding is based on a fallacious, naive analogy that, duh, picture books are "simpler" than regular books ergo less text makes things universally "simpler". The problem with that analogy is that - coding is nothing like reading a book. Replacing text with "pictures" does not simplify it. Neither does replacing typing with clicking because programming is not about entering data into a computer either.

Besides, any box coding system still uses quite a lot of text. It's not really "visual representation". It's a form of textual representation with 2D layout control. Ironically, in many cases the amount of total text displayed by a box system is much higher than the amount of text needed to do the same thing in proper code.

As an example, try to step a component of a vec3 in Godot's visual shader and compare how much text you need to do the same with code. Here, let me do it for you:

vs.

step(0.5, myvector.x)

Do I need to count the characters as well? Oh, ok. The "visual representation" uses 500% more text.

On top of that, when you go beyond typical trivial examples, the node network can become an enormous visual mess and you need to spend additional mental effort on spatial management of your boxes. This can become significant as the complexity of the system increases. Not to mention how much screen estate is wasted on non-functional empty space inside those boxes.

You're insinuating that "visual coding" is somehow a prerequisite to learn proper coding. This is again fallacious. There is no such prerequisite. Millions of people have learned to program without ever seeing any "visual code".

Tomcat

xyz You're insinuating that "visual coding" is somehow a prerequisite to learn proper coding.

I have no such insinuations. You are making this up and attributing it to me.

On top of that, when you go beyond typical trivial examples, the node network can become an enormous visual mess

Yeah, this is a problem of visual programming, so I am trying to convey that completely transferring GDScript there is too difficult a task. However, simplifying it beforehand and limiting it probably makes sense. Well, it's definitely worth a try.

The idea that "visual coding" simplifies coding is based on a fallacious, naive analogy that, duh, picture books are "simpler" than regular books ergo less text makes things universally "simpler". The problem with that analogy is that - coding is nothing like reading a book. Replacing text with "pictures" does not simplify it.

In general, the analogy of picture books is close to this concept. Of course, a book with text undoubtedly carries incomparably more information, but to say that a picture book is absolutely unnecessary and even harmful is utter nonsense. Each approach has its own niche.

Here, let me do it for you:

vs.

step(myvector.x)

This is what I'm talking about — you've already forgotten how you learned, and the line seems easier to you.

xyz And you've yet to prove that the process of coding gets simplified in any way by using boxes and noodles.

Only practice can really prove this. “Practice is the criterion of truth” ©️ Everything else is theoretical reasoning.

xyz

Tomcat This is what I'm talking about — you've already forgotten how you learned, and the line seems easier to you.

It doesn't matter how it seems to me. The textual and visual entropy in the box example is objectively larger. Ask someone who've never seen either which one looks more complex. And it gets worse the more code you need to produce.

In any case, it doesn't really matter what anyone perceives as easier. The fact remains that any program worth its salt is written in textual code, not with boxes and noodles. You may argue that boxes are less scary for beginners in this or that way, but that's inconsequential in the long run of their knowledge acquisition process. Any beginner is better off ditching them as soon as possible. In fact that's often stated as the goal of box systems in the first place. So why start with them at all? They'll just hinder your learning by fencing you off from what's actually happening underneath. Simple code examples are in no way harder to understand than simple box examples that do the same thing. Both require the same amount of basic literacy and the same amount of logical thinking.

Don't worry, using code instead of boxes won't make you any less of an artist 😉

Tomcat

xyz Ask someone who've never seen either which one looks more complex.

I'm going to assume that you didn't conduct this test yourself. 😹

xyz

Tomcat I'm going to assume that you didn't conduct this test yourself. 😹

If you keep pestering me, I just might 😃

Tomcat

xyz If you keep pestering me, I just might 😃

Hmm… and I was sure that you were the one who was pestering everyone here, rudely imposing your deeply mistaken point of view. 😸

All decent progressive game engines have visual scripting as an option. But savages, of course, can program like in the Paleolithic era — with stone axes on cave walls.