Hacker News Reader

Comment by andrewstuart | Hacker News Reader

Hopefully this solves some core problems like being able to use it smoothy on multiple platforms outside the browser.

I've found previous version of Scratch to be frustratingly limited unfortunately.

I don't mind, and expect, kids software to be limited but Scratch makes it really hard to do certain things. It's a pity because it holds the number one place in market positioning for free software for educating kids on how to program.

View on HN

Can you provide any examples of something that you think is difficult to do? I’m doing research on similar languages and would like to understand barriers people have.

I helped out with a coder dojo where we used Scratch to teach kids to code. In that setting the biggest barrier was the parents getting in the way of their kids natural exploring. Solve that and you can basically just put a kid in front of scratch and expect them to be productive on their own within a few minutes. Just be there to help them get unstuck. A pre made lab can be helpful though.

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”

I teach Scratch at the MADE (video game museum in Oakland) and I've run into the following:

- 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 wanted to make a simple game where using arrow keyws you move around a top down map display and kill monsters and shoot arrows and find treasure, with trees scattered about.

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.

The Adobe Flash issue is actually the main thing that Scratch 3.0 solved - it's now all Javascript.

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?

You certainly have to write several logic yourself like making the physics engine (minimal one), object detection, resource loading hiding logic etc, which is not trivial in scratch. There may be other built for games platform that provide these features for free..

You can't have shared code between sprites (IIUC), so the only sharing is via copy paste, which is unmanageable.

You can, however, make "clones" - essentially instances in OOP except that there has to be one initial instance.

It really never occurred to me to try that for sharing code as opposed to just having multiple of the same sprite (bullets, enemies and the like). Still it's not hugely satisfactory because it implies a single common sprite, loss of the intuitive wysiwyg aspect (such as it is), refactoring to utilise, and then presumably large 'switch' statements to recover the difference in behaviour between the clones.

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).

Reply on news.ycombinator.com