Scratch is an educational programming language designed to make it easy for kids to create stories, animations and games. They've done a pretty good job, but there's a notable blind spot when it comes to games specifically - many common and simple game mechanics require lists, advanced coding tricks or repetition to pull off which could be simplified by the following suggestions.

1. `creator of this clone` Option

go to [creator of this clone v]
([direction v] of [creator of this clone v])

Currently, if you want multiple enemies to shoot bullets, swing swords, or gemstones to generate particles when collected, you need some hacky solution involving either lists or sprites cloning themselves to become the bullets/swords/sparkles. Allowing clones to access properties from the sprite that created them with `create clone of` would make these features much less painful to implement.

2. Sprite Tags

Sprite tags are labels you can apply to and remove from sprites to identify them dynamically.

add tag [#enemy v] :: sensing
remove tag [#enemy v] :: sensing

<touching [#enemy v] ?>
([x position v] of [closest #enemy v])

If you want your player sprite to detect collisions with a number of enemies or platforms, your only options are a long chain of `touching` & `or` blocks, or coding all enemies/platforms into a single messy sprite. Sprite tags would streamline this significantly: just give each one a tag and have the player check for that tag. Also, if you construct tag names with reporters, you can recreate Snap!'s first-class sprites

3. Hide Other Sprites

hide [closest #coin v] :: looks

when this sprite is hidden :: looks hat

Scratch's main ways for sprites to communicate include broadcasts (and with this suggestion implemented, sprite tags), and this is usually perfect. However, there are cases where it's not quite enough. In a multiplayer game, if multiple players collect the same powerup, you can have a situation where both players get the powerup before it has a chance to disappear.

Being able to hide the powerup directly prevents other player sprites from picking it up by accident, while `when this sprite is hidden` gives the powerup an opportunity to delete itself, reshow after a cooldown, create particles etc.

Lists of suggestions aren’t allowed
(not responding for a while cuz I’m going to bed)

Zack_39450 wrote:

Lists of suggestions aren’t allowed
(not responding for a while cuz I’m going to bed)

Lists of related suggestions are OK.

rdococ wrote:

Zack_39450 wrote:

Lists of suggestions aren’t allowed
(not responding for a while cuz I’m going to bed)

Lists of related suggestions are OK.

Only if they can't function fully without each other.

gem1001 wrote:

rdococ wrote:

Zack_39450 wrote:

Lists of suggestions aren’t allowed
(not responding for a while cuz I’m going to bed)

Lists of related suggestions are OK.

Only if they can't function fully without each other.

That's true for the second and third suggestions, I guess I could split the first one into its own thread.

Please create a separate topic for each suggestion you have, rather than creating a list of suggestions. That way, the conversation stays focused and each idea can get the attention it needs.

Before making a new topic, please check out the following:

• The Official List of Rejected Suggestions. If your suggestion is in this list, please do not make a new topic about it, as it will not be implemented anyway.
  
  
• The Suggestions Directory. If your suggestion is in this list, please continue the discussion in the existing topic, rather than making a new topic.
  

Thank you!