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!