Why does Scratch have sprite dropdowns?

Wow. I didn't know BYOB started as a Scratch-funded project! My impression was that you'd worked for them in the distant past and you started BYOB just because of me complaining at that Scratch conference. Given that history, I'm surprised it took so long for them to get around to custom blocks in official Scratch. And surprised that when they did get around to it, I had to talk them into blocks with inputs. ("How does this differ from broadcast and wait?" Coming back full circle to that thesis, even though I didn't know about it then.)

History of Snap in 3 paragraphs. Nice.

Definitely. I normally don't have the attention span to read through an 80-page paper (that's YouTube for ya), and even I read through it.

For Snap!, something like that would be a good solution. I like how Snap! extends the broadcasting mechanism, although I still feel uncomfortable about using it due to the lack of message arguments and its thread-restarting/dropping nature.

Scratch, however, is a different story. Sprite references are difficult to deal with, especially without the anonymous lists and higher-order functions implemented by Snap!, and adding those would be yet more features to contend with.

The thesis actually points out the issue with "of" and "touching?", and provides two blocks as a potential solution:

  • A "touching-something-that-listens-for-broadcast" block. The example given is space invaders, where an 'alien' sprite could check for something that listens to 'yellow flag' events rather than specifically for the 'bullet' sprite.
  • A "whisper" block that sends a message only to the nearest sprite that listens for it. The example given for this a jewel collecting game with multiple players; a 'jewel' sprite could check if it's touching something that listens for a 'collect jewel' message, send that message to the nearest sprite that does, and then disappear.

I think both of these blocks have unintuitive behaviour. "Touching-something-that-listens-for-broadcast" is too verbose to explain in a block label. It would be difficult to discover what the "whisper" block actually does unless its block label was similarly verbose, and it would still be unusual.

I don't have much experience with helping kids to learn about programming concepts, but my solution would be a simplified version of the "whisper" block that simply sends messages to all the sprites that are touching the current sprite.

  • In the space invaders game, the 'bullet' sprite could whisper a 'hit' message. If any 'enemy' sprite hears it, it could disappear. For non-piercing bullets, the 'enemy' could whisper a 'hit received' message back, allowing the 'bullet' sprite to respond by disappearing unless a "piercing bullet!" superpower is activated.
  • In the jewel collecting game, the 'player' sprites could whisper 'collect' messages. If a 'jewel' sprite hears it, the 'jewel' can whisper back a 'collected jewel' message before disappearing.

Admittedly, this is less elegant for a few reasons. Reply messages are required for 'bullet's and 'player's to know that something happened. Also, you can't control exactly how many sprites receive the message; a 'jewel' could be collected by several players, or one 'player' can collect several jewels at once and only receive the score for a single one.

Yet, the simplified "whisper" mechanic is far simpler and easier to discover. "Send a message to touching sprites" is the simplest form of local communication between sprites I can think of. The mechanic offers a lot of extra flexibility; for example, you could create a project with interlocking 'gears'. When they receive a 'turn left' message, they turn left and then whisper a 'turn right' message to their neighbouring gears, and vice versa. It only takes 6 blocks to set up that interaction!

In the gear thing, don't you have to do extra work to avoid sending TURN RIGHT to the block that sent youo TURN LEFT? Otherwise you get loops.

This all sounds way complicated. Remeber, they went with BROADCAST rather than procedures to simplify things. Once all these bells and whistles are taken into account, I think procedures turn out simpler!

I just joined, and I found Snap! from a Wordle Solver I found on GitHub. I'm mainly a Scratch user, and when I first discovered this website, I've seen, a lot of similarities to Scratch. There's Gobo, the pen extension, the same variable counter like in Scratch, and even the big, green goblin that everyone loves! I know this is super off-topic to the actual post, but, what is the story behind Snap! and it's relation with Scratch?

I'm interested in what this is, can you send a link?

Hi, welcome to Snap!.

Your question is answered in the FAQ:

Thanks a lot!

Of course!

Link: Snap! Build Your Own Blocks

I think this can be avoided by making the broadcasts atomic and the gears keeping track of whether they've already been turned during the current frame. The alternative is a sort of "remote sprite procedure call" which could work, but IMO boils down to the same thing.

Maybe the dream of having granular sprite interactions and appealing to intuition is just too good to be true?

Thats not gobo,

also @bh why did u message me and then delete it immediately?

I goofed; I then undeleted it.

I'm afraid I don't understand this. So, either maybe wait for Jens to answer or else rephrase this for my simple mind.

The 'whisper' feature I described is simple and good enough for most use cases. Scratch projects often have minor bugs (much more minor than the 'gear loop' issue), but they don't detract from the ability for kids to create cool games and stories and learn programming concepts. I was just being complicated for the sake of it :sweat_smile:

Getting back on topic, I suggested the 'whisper' feature as a replacement for 'of' and other blocks with hard-coded sprite references in Scratch. It enables granular sprite interactions (i.e. sprites can talk only to certain other sprites, not all sprites at once), remains intuitive (i.e. a sprite 'whispering' to nearby sprites is a simple metaphor kids will understand), and doesn't break modularity or encapsulation (i.e. sprites don't access each other's variables or have hard-coded references).

Of course, 'of' and the other blocks won't be removed from Scratch at this point, so it would be mostly redundant for Scratch to add. For new languages in the same vein as Scratch, or Scratch mods, I think it would fit perfectly.

Huh...uh?

Do you mean
untitled script pic
?

I mean 'for each item in my neighbors, if touching it, broadcast something to it'. But essentially, yes.

Well, so, we can do that! :~P

In Snap!, we can. In Scratch or other programming environments in a similar vein, 'whisper' would be a good feature.

Sure.