(This is a highly edited form of “allow broadcast and wait to perform recursion”. Not a dupe, it just is. )

Currently, Scratch has two custom ways to make things happen.

• Broadcasts, where any sprite can broadcast an event message to all sprites. Every sprite can respond in their own way, or not at all. This is used for communication in stories, or switching between screens in a video game.
  
• Custom blocks, where a sprite can define a local procedure for it to run through in sync with another script. In most projects this is used simply for organization and reducing code repetition. For advanced projects, recursion and argument passing are great to have.
  

However, for intermediate and advanced projects, it is very useful for sprites to communicate with each other in sync, the way a custom block runs. Examples of this include:

• Pong balls: When a ball touches another ball, you want them to bounce away from each other. This is very tricky if you want to have multiple ball collisions per frame; ideally, the balls should just be able to tell each other “I'm at X, Y, bounce away from me!”.
  
• Logic circuits: When an output to a circuit turns off, you want all connected wires to test if they're still touching an active output; if any of them are, you want every connected wire to remain ON, otherwise, you want them to turn OFF. The wires need to tell each other, “I might have lost power, so check if you still have it!”.
  

Without some way for sprites to communicate in sync with each other, you have to use a combination of careful broadcasting and lists storing clone data, and you may have to perform all the computation in one sprite; none of these are fun or intuitive things to do! In the language of the Scratch design goals, the floor for intermediate users to create simulation and game projects is higher than it should be.

The “broadcast and wait” block is a limited form of “in sync” sprite communication, suggesting that Scratch was thinking about this issue at some point. There are three problems with trying to use it, however:

• “Broadcast and wait” takes a tick, as does every other broadcast. This is a big issue if other sprites are moving in the meantime, because Scratch will perform screen refreshes instead of processing the broadcasts as fast as possible.
  
• It doesn't support non-tail recursion, i.e. a broadcast activating itself and continuing on after it finishes. This is an issue with the logic circuit example given above, where wires may need to ignore nested broadcasts without terminating the current script.
  
• There's no way to pass arguments into them!
  

I think the least intrusive way to add these capabilities to Scratch is extending “broadcast and wait” with support for recursion; this would be almost invisible for the average novice who uses broadcasts for stage events, while giving intermediate and advanced users more ways for their sprites to communicate. Data passing would be great as well, but it would stick out like a sore thumb to novices.

Bonus: There are parallels between this kind of “broadcasted procedure call” and object-oriented programming. Advanced users could give each sprite and clone a unique number and use the numbers as references, programming each sprite to ignore messages not meant for them to perform method calls.

Bump, added some clarification on what ‘recursion’ is just in case

Bump 2, just made it a lot more clear this time around.

Advanced projects use one sprite for a whole portion of a project. It's much easier to manage and any shared code will not be duplicated. To create “other sprites”, the cloning feature can be used. Broadcasts become unnecessary except when it's used for clone manipulation because custom blocks handle most of the logic.

For communication between multiple sprites, a variable can be set before sending the broadcast. This could act as a parameter.

Essentially, multiple sprites = bad, one sprite = good.

Support! This would make sprite communication a lot less complicated!

Great topic!

Spentine wrote:

Advanced projects use one sprite for a whole portion of a project. It's much easier to manage and any shared code will not be duplicated. To create “other sprites”, the cloning feature can be used. Broadcasts become unnecessary except when it's used for clone manipulation because custom blocks handle most of the logic.

I see your point and have created projects this way before. That said, projects using a single sprite are a pain to edit as well as harder to understand for novices, leading to scarcely any remixing of these kinds of projects. The people creating these projects are exclusively established Scratchers who went on to learn traditional programming, and it seems like a wasted opportunity!

I think making it easier to create simulation and game projects with complex interactions is a worthwhile goal.

Spentine also wrote:

For communication between multiple sprites, a variable can be set before sending the broadcast. This could act as a parameter.

Yes, and I've done this before too. Even right now it's a bit annoying to create a new global variable whenever you want sprites to communicate non-trivially, but it gets trickier when you have recursive broadcasts.

Spentine even wrote:

Essentially, multiple sprites = bad, one sprite = good.

It doesn't have to be this way

This has been done in many games! EX.

when green flag clicked
broadcast [message1 v]
when I receive [message1 v]
broadcast [message2 v]
when I receive [message2 v]
broadcast [message3 v]
when I receive [message3 v]
stop [all v]

Most are usually ending games or animations.

Ooh, I really like this suggestion! You've outlined how it would work very clearly and I can't see any obvious issues with it. It would make complex sprite communication so much easier for those who want to use it. In particular I like this:

rdococ wrote:

I think the least intrusive way to add these capabilities to Scratch is extending “broadcast and wait” with support for recursion; this would be almost invisible for the average novice who uses broadcasts for stage events, while giving intermediate and advanced users more ways for their sprites to communicate.

…because it wouldn't clutter the editor or confuse newer / less experienced Scratchers.

Spentine wrote:

Advanced projects use one sprite for a whole portion of a project. It's much easier to manage and any shared code will not be duplicated. To create “other sprites”, the cloning feature can be used. Broadcasts become unnecessary except when it's used for clone manipulation because custom blocks handle most of the logic.

Yeah, but this can get ugly real quick. Keeping track of clones like this often means lots and lots of variables and/or lists. Speaking from experience, it's also really daunting to click “see inside” on another persons project that's been made in this way, because it's almost always impossible to tell what's actually going on unless the user has helpfully commented their own code (rare). Therefore I think recursive broadcasts would be a great community learning mechanism too. @rdococ ‘s point about global variables being a nuisance is another reason why the the variable workaround isn’t great.

Also:

rdococ wrote:

Bonus: There are parallels between this kind of “broadcasted procedure call” and object-oriented programming. Advanced users could give each sprite and clone a unique number and use the numbers as references, programming each sprite to ignore messages not meant for them to perform method calls.

NEED