There is no scene in a 2D game. There is no model of what is in front of what. There is a list of drawing instructions, run in a fixed order, sixty times a second, and the order is the only thing that decides what is in front.
That is a much simpler mental model than people expect, and once you have it, a whole category of visual bug becomes obvious rather than mysterious.
Back to front, like a stage
Everything is drawn in the order a set is built: the backdrop first, then the scenery, then the props, then the actors, then anything held in front of the whole thing.
In our platformer that order is fixed and it is short.
The background image, filling the frame. Then the platforms, each a rectangle with a bright line along its top edge. Then the collectibles, each with a small vertical offset so they bob. Then the goal. Then a soft shadow ellipse. Then the character. Then, outside the game's drawing surface entirely, the score and the touch controls.
Anything drawn later covers anything drawn earlier. That is the whole rule, and it is why a character standing in front of a platform is simply a character drawn after the platform.
The whole screen, every frame
The screen is cleared and completely repainted every frame.
That sounds wasteful and it is the right answer nearly every time. Working out which regions actually changed, and repainting only those, is a real technique, and it is usually more expensive than the thing it saves, because the calculation is complicated and clearing a surface is very fast.
It is also much safer. A partial update that misses a region leaves the previous frame's pixels behind, and a moving character leaves a smear across the screen. Clearing everything makes that impossible by construction. Nobody has ever debugged a trail bug in a game that clears every frame.
Shadows, and why they go where they go
The shadow under the player is drawn immediately before the player, and this ordering does two jobs.
The obvious one: the character partly covers its own shadow, so the shadow reads as being on the ground beneath rather than as a shape pasted next to it.
The less obvious one, and the reason it is worth having at all: a soft dark ellipse under the character is a guaranteed patch of contrast, travelling with the character, over whatever background happens to be there. A character can be drawn over a bright wall or a dark one and there is always something separating it from what is behind.
That is a legibility trick rather than a lighting one, and it belongs to the same family of decisions as reserving colours, which is covered in how a game gets its colour palette.
Where layers come from
A game with parallax has more layers, and they are still just more instructions in the same list.
The distant painting is drawn first with a small horizontal offset. The foreground of pavement and railings is drawn after the character, with a larger offset, so the character walks behind it. The difference in offsets is the entire depth effect, and the difference in draw position is the entire question of what is in front.
That is all a layer is: a group of things drawn at the same point in the sequence with a shared offset. The full treatment is in parallax, and how a painting becomes a place.
Two cheap wins hiding in the order
Two implementation details from our own builds that are worth knowing, because both are one line.
Tell the browser the surface is opaque. A drawing surface is transparent by default, which means the browser has to blend everything drawn onto it against whatever is behind. A game that fills its whole area never needs that, and declaring the surface opaque lets the browser skip the blending entirely. Our platformer does this. It is free performance.
Turn off smoothing for pixel art. When an image is drawn at a different size from its natural one, the browser interpolates between pixels to smooth it. That is correct for a photograph and completely wrong for pixel art, where it turns crisp squares into mush. One flag, and it is the difference between deliberate pixel art and a blurry mistake. The trade between those styles is in pixel art or painted.
The interface is not in the list
One structural point. The score, the buttons and the touch controls in our builds are not drawn by the game at all. They are ordinary page elements sitting over the drawing surface.
That is deliberate. Text drawn onto a canvas is a picture of text: it does not select, does not scale with the reader's settings, and is invisible to a screen reader. Text in the page is text. Buttons in the page are buttons, with focus outlines and keyboard support that come for free.
The cost is that the interface has to be kept in step with the game's state, which is one more reason the state variable described in the one variable that runs the whole game earns its place.
What this means for a commission
Almost every "in front of the wrong thing" bug is an ordering bug. Which makes it a five-minute fix rather than a mystery.
Layers are a cost. Each one is more artwork that has to work in front of everything behind it, which is why the number of layers is a scope question.
And drawing is rarely the expensive part. In our builds it is a couple of dozen instructions a frame. What costs is the artwork it draws, which is where the megabytes go.
