Scratch

Think of layers as like a deck of cards or a bunch of transparencies with one sprite on each.  The number of layers is the number of sprites (including the background).  You can move a layer (sprite) to the front or you can move it back, though never behind the background.

Send to back can be accomplished with "move back 1000 layers" since moving back more layers than there are sprites just moves to the back.

I agree that the layer metaphor is not a very clear one---it took me a couple of days to be convinced I had it right.  Controlling the layering of sprites is quite difficult in the current system, since the execution order of "move to front" and "move back x layers" commands changes their effects.

My son was really looking for a z-axis system, where each sprite had a depth value and you could move to a specific depth.  This would make ordering sprites much simpler for the programmer, but a simple sort of the z-values would allow the same sort of layering as is currently used for rendering the sprites.  Instead of "move to front" and "move back n layers", the blocks would be "set z to <>" and "<z>"

Two problems with a "z" model
    * ties need to be broken when layering the sprites.  This may result in different layering in different implementations.

    * sprites should default to different depths.  Perhaps each sprite, when created, should get a 1 larger Z value than the largest current Z (assuming + is front and - is back).

Controlling the layer for the variables *is* a problem.  It could be fixed in the "z" model by having the variables at a fixed depth.


Thinking about the Z model some more---it would be better to the background at +infinity rather than -infinity---that way Z becomes "depth".  The Z values would be useful for approx perspective transforms:
     set size to 100/(<Z> - <camera Z>) 

(Camera Z could be a variable or a constant, perhaps -10---no need for a new block.)

It might also be useful to have a block:  reset Z to layer number, which takes the current ordering of the layers (including the arbitrary breaking of ties) and assigns Z values based on the ordering.

I can see a lot of things that would be easy to do  in the Z model that are hard to do in the "deck of cards" model, and it certainly would be much easier to explain to novice programmers.