I took some notes while building my first game. I’m sharing these in the hopes that they are helpful to the team. Just because this is a list of critical feedback doesn’t mean I’m not thrilled about the platform. If this isn’t helpful (or isn’t the right forum for sharing these observations), please let me know!
remove value at returns the removed value (the block is an oval; not a puzzle piece). This makes the block not useful for situations where you just want to remove an item without reading its value. Working around this is awkward.
Getting the tile location for a sprite is more involved than I’d like. After placing sprite on random tile of type, I needed to update the tile so I didn’t place another sprite there later. A block for getting the tile location for a sprite would be nice. Maybe after functions support return values, this won’t be as bad.
Camera gives us
camera top and
camera left but only lets us
center camera at x/y. So if you want to move the camera 10px to the left, you have read the top / left; adjust by the offset; and then compute the new desired center of the screen.
It also takes a bit more math than I’d like to compute whether a sprite is onscreen or not. A block for this would be nice, but functions with return values will probably help here too.
The sprite lifespan trick is so handy! I also probably never would have thought of it if I hadn’t seen it demonstrated. I wonder if a first-class block feature could be built to support this scenario? Or maybe the technique could be showcased in one of the tutorials.
set sprite list to array of sprites of kind… is, in my experience, most often used for the inner
array of sprites of kind… piece. Could that be added as a separate top-level block? It looks like there’s precedent for a similar block with
array of all _ locations.
Nice to have but probably not desirable for the target audience: I find myself really wanting a separate type of block for constants. The variable list already gets long enough without support for local variables. If constants could be a distinct type that didn’t get listed in that list, I think I’d be happier. Even better, if constants could be declared + initialized outside of
on start; maybe just as top-level blocks on the design surface, that could clean up start up logic as well. Constants could even pair really nicely with the sprite data extension, where you could declare constants for the data keys, and not have to worry about mistyping them… I could go on, but I know this one’s pretty far out there.
A box select mode for selecting multiple blocks to move would be incredible. Is there any way to select multiple blocks to move?
Nice to have: it might be nice if you could actually draw persistent boxes on the editor surface and put blocks within those boxes for better organization. (The boxes would have their own Format code context, and at the top level Format code would only format the top level blocks and boxes, not box contents.)
A find feature in the design surface that highlighted matching blocks by dimming the unmatched ones. (Similar to the existing Search feature but without filtering.)
Rectangle selection tool rectangle disappears if, while making a selection, the cursor moves off the edge of the sprite.
Copy + paste / duplicate support would be amazing.
Flip / rotate 90° support would be amazing; especially if they can be applied to a selection.