Eventbus

[upost]

Dear team,

Scratch has a message system which allows objects to be losely coupled by just sending or receiving messages. This is also a widespread software design pattern (publisher-subscriber) and I find it very helpful also in game development and very easy to understand for kids who just started learning how to code.

There even is a plugin for Godot:
https://godotengine.org/asset-library/asset/3477

That said, it's so easy you don't need a plugin. Defining events can also happen in a preloaded node named Eventbus like so:
extends Node signal started signal levelup signal died ...
To send an event from anywhere:
Eventbus.started.emit()

To listen to an event in any other node script:
`Eventbus.started.connect(_on_started)

func _on_started():
...
`

What do you think about adding this to block coding like in Scratch, hiding the need to create the Eventbus node and the connect calls, just having one block which sends messages and one reacting on receiving a certain message? (and of course required stuff like creating/editing message, like variables)

Thanks for reading!
Uwe

[manuq]

@upost we have Godot groups support. What would be the difference between the described EventBus and using groups? We already have blocks for calling a function in a group. The way to subscribe is by adding the node to the group. For example in the top-down spaceship demo:

[upost]

The difference is that calling a method does not reflect the publisher subscriber pattern, where the sender does not need to know who will process a message, does not need to wait for completion for example and so on. There are quite some differences, I mean there's a reason for having MessageQueues present everywhere in the industry ;-)

And for educational purposes, I'd like to teach it to the kids the right way from the start - and they already know it from Scratch!

So if we think of Scratch as the first step and Godot Block Coding as second, I think most blocks from Scratch should be there!

If you like I can try to implement this idea.

[manuq]

@upost honestly I don't see any difference between the current "define method / call method in group" and "when I receive / broadcast message". Except for:

• The labels change
• The dropdown to select the message

Fun fact, we had the labels very similar before in the beginning, inspired by Scratch. Back then we had a mix of Godot jargon and natural language in labels. Then we switched all labels to Godot terminology (like "on ready"). And then after feedback we switched all to natural language (like "when starting"). Regardless of the labels, the implementation has always been the same, with Godot groups. So we may revisit this if learners feedback says that "broadcast something" is better than "call method in group".

The difference is that calling a method does not reflect the publisher subscriber pattern, where the sender does not need to know who will process a message,

Using "call method in group" is the same, the sender does not know who will process the message.

does not need to wait for completion for example and so on.

Ditto, the sender doesn't wait for completion using "call method in group".

The dropdown to select the method name (or message) would be a very nice addition. Unfortunately it is not possible right now because each BlockCode node works independently, so a BlockCode can't inspect the methods defined in other BlockCode nodes to display a dropdown with options.

Finally, ramping from Scratch to BlockCoding is not a goal. This is a layer on top of Godot teaching Godot concepts. I would say that groups is such one concept. It looks like it does the job without having to implement a custom message broadcasting. See https://github.com/endlessm/godot-block-coding/blob/main/docs/PEDAGOGY.md

[manuq]

For the record, here are the commits that removed the previous iteration, which looked very similar to what you want:

• Category factory: Rename signals to methods 95ea003
• Remove SignalManager autoload 124a7cf

[upost]

citing: "it will be redone soon when things stabilize."
Maybe soon is soon as that commit is half a year old? Is there any way to put this onto the roadmap?

[manuq]

citing: "it will be redone soon when things stabilize." Maybe soon is soon as that commit is half a year old? Is there any way to put this onto the roadmap?

It was in reference to the Pong demo. Which has been redone a few days after, and it is working.