That's more of a logical grid, all the logic is made around 32px size main " plugable blocks", for art and math and all . Each blocks is effectively, a unique sprite/obj, with its variable and all. It's overly under optimized I think, that why you can sometimes read +1000 obj on the top right, near a "60fps" I hope. On early prototype the blocks were able to spawn without following any kind of grid placement and that was more ... complicated and chaotic, both from a dev or art perspective. You got the recipe. Here for example you have the very famous frame n°16 of the animation "BLOCK10" :
And here you have the frame n°11 of the object "SHIP", the USS... Callister :)
Yeah, that's about it, a bunch of sprites, some rulesets and RNGesus put into the equation. Amen.
If you talk about the draw call render technique. The engine do that natively. The perf seem ok on my side considering the number of moving shit on the screen. Stable 60 fps on HTML and + on desktop. But I really don't know if the engine does the job correctly in this case considering the astronomical number of animation frames spread on multiple spritesheet. I also considered the use of tilemap at early dev, a giant texture atlas for everything, but I finally used this method.