Building a Numberblocks Blueberry Project in Scratch
I spent about three evenings last month trying to get a Numberblocks-style blueberry inflation mechanic working in Scratch for a kid's coding workshop. The concept sounds simple — blueberries grow bigger when you click them, blocks arrange themselves into number formations — but the implementation has a few quiet gotchas that will eat your afternoon if you don't expect them. The first thing to understand is that Scratch doesn't natively support smooth scaling animations the way a game engine does. When you stretch a sprite using the size block, everything attached to it — costumes, clones, position references — shifts in ways that can break your layout logic. I learned this the hard way when my Numberblock character started teleporting to random coordinates every time the inflation reached size 200. The fix was to separate the inflation visual from the logical position tracker. I used a custom variable called inflation_factor that only controlled the scale, while the sprite's actual x/y position stayed locked to a grid calculated before any scaling happened. The core loop is straightforward: a player clicks a blueberry sprite, it increments a counter, and both the counter and the sprite size increase together. Where people usually stumble is in the transition between number representations. Numberblocks isn't just big berries — it's about showing that 5 blueberries arranged in a row equal the Numberblock 5 character. That transformation requires costume swaps and careful layer ordering.
Here's what I actually built. The project uses three sprite layers: the background blueberry patch, the individual blueberry clickable sprites, and the Numberblock overlay that appears after inflation reaches certain thresholds. Each blueberry runs this script: when green flag clicked
forever
if clicked then
change [blueberry_count] by (1)
set size to ((blueberry_count / 5) * 100)%
end
wait (0.2) seconds The .2 second wait is not arbitrary. Without it, rapid clicking causes the size to overshoot and the Numberblock reveal to fire at the wrong count. I watched six kids do this in the first ten minutes of the workshop and their projects all looked broken until I added that tiny delay.
Common Pitfalls You Should Avoid
Using nested broadcasts for the Numberblock transformation. When the blueberry count hits a multiple of 5, you need to trigger the Numberblock reveal. A lot of tutorials tell you to broadcast from every single blueberry sprite, which means five copies of the same broadcast fire simultaneously. Scratch handles this fine, but it creates a timing race condition where the Numberblock sprite sometimes tries to position itself before all five blueberries have finished moving to their formation spots. The workaround is a single controller sprite that polls the counter variable instead of listening for broadcasts. It runs this every frame: forever
if (blueberry_count mod 5) = 0 and (blueberry_count > 0) then
show_numberblock_for [blueberry_count]
end Another issue that catches people off guard: the default Scratch coordinate system places (0,0) in the center of the stage. When you're arranging blueberries in a grid formation to match a Numberblock display, your positioning math needs to account for this. I calculated grid positions using this formula — x equals (column - 1) times 60 minus half the total width times 60, and y equals negative ((row - 1) times 60). The negative y because Scratch's y-axis goes up from the bottom, which is the opposite of most spreadsheet-style thinking.
Get the Full Details
Adding Smooth Inflation Instead of Instant Size Changes
Instant size jumps look crude. Smooth inflation uses a glide or a gradual size increase over several frames. The trick is storing the target size and animating toward it rather than setting it directly. Here's the pattern: set [target_size] to (blueberry_count * 20)
repeat (10)
set size to ((size + target_size) / 2)
wait (0.05) seconds
end
set size to target_size This creates a mild ease-out effect without requiring custom easing functions. The average project file size stays under 500KB with this approach, which matters if you're sharing it on Scratch's servers where large projects load noticeably slower on weaker machines.
What This Approach Doesn't Handle Well
Responsive design. Scratch projects are fixed at 480 by 360 pixels unless you use the newer full-stage mode, and even then, blueberry sprite sizes don't adapt to different screen ratios. If a student opens this on a tablet, the Numberblock formations will look squashed or oversized. There's no real fix inside Scratch other than testing on the target device and manually adjusting positions, which takes another thirty to forty-five minutes per project. Also, the clone-based approach for managing multiple blueberries — while efficient for performance — makes debugging significantly harder. Each clone shares the same scripts but has its own variable state, and when something goes wrong with clone positioning, the error messages in Scratch are notoriously unhelpful. I recommend keeping a debug mode that prints sprite and clone coordinates to the stage using a hidden text sprite. It added maybe five minutes to development but saved me an hour of trial and error.
Where to Find a Working Template
The Scratch community hosts several Numberblocks-inspired projects that you can study or fork directly. Searching "Numberblocks Blueberry" on the Scratch website will surface community projects with open source code you can examine. Some of these use more advanced techniques like motion interpolation and custom block libraries that go beyond what I've covered here. If your goal is just a functional classroom demo, the basic approach above gets you there in under an hour. If you want something polished enough to show at a school assembly, plan for a weekend of refinement including costume animation, sound effects synced to each inflation step, and a clean end-state where the Numberblock holds its formation for a few seconds before resetting. The real educational value in this project isn't the final animation. It's the moment a kid realizes that clicking something to make it grow involves actual logic — counters, conditions, variables, and coordinate math — all wrapped in something that looks and feels like play. That click-to-inflate mechanic is where abstract programming concepts become tangible. Everything after that is just making it look decent.
