Most problems I’ve seen them run into are basic algorithmic issues. “I want the ball to change direction when it reaches the wall” we’ll “perhaps we can let the ball test if it is at the wall? Here’s a block that does tests”
- Mutual sprite collision (think a projectile hitting another sprite, and wanting it to both disappear and do damage to the thing that got hit) can easily have race conditions unless you take special care to avoid them - Scrolling games are hard to do for a number of reasons (backgrounds don't natively scroll, sprites have fairly hard size limits and can't be fully moved off the edge of the stage) - As others have mentioned, the inability to share code between sprites outside of clones is a bummer - The heuristic for waiting for the next frame in a loop works well for simple stuff, but gets in the way for more complicated things. You can work around this by defining your own block and enabling the "run without screen refresh" option, but if you accidentally create an infinite loop in that block, the entire UI becomes unresponsive (at least in Scratch 2, perhaps they've fixed that in Scratch 3)
I didn't find this easy at all and it seems like something that shouldn't be hard.
Also it is/was based on Adobe Flash and none of my systems or browsers have Flash.
Your example project should be relatively simple in Scratch. Certainly many users have done similar things. Perhaps you're trying to do it in ways that work in common programming languages while it requires using different idioms in Scratch?
Also found communicating between scratch objects via the asynchronous message passing to be seemingly too slow and it would have been nice to be able to call methods on another sprite (although I assume they are trying to limit the potential for uninteruptible infinite loops and the like by having each sprite execute separately).