Option 6: NES (Nintendo Entertainment System). The bot gets colour, but under hard limits: 3 colours per sprite and a maximum of 8 sprites per scanline.

**3 colours per sprite, plus transparent.**
The bot uses white, grey and black. Every shade on the sphere comes from dithering between those two fills.

**Palette swaps are free power-ups.**
Fire, Ice and Shadow reuse the same pixels with a different 3-colour palette. Many classic games made "new" characters and power-up states this way.

**The overlay sprite adds a 4th colour.**
A second sprite layer paints orange bounce light from the bricks onto the bot's underside. The extra colour costs 3 more sprites on those scanlines.

**The 8-per-scanline limit is simulated honestly.**
The hardware draws only the first 8 sprites it finds on each horizontal line. The scanline meter on the right edge turns red wherever the limit breaks.

**Set mini-bots to 2.**
The bottom row holds 3 bot + 3 overlay + 2 minis = 8. No flicker.

**Set mini-bots to 3.**
That makes 9 on one line, so something must vanish.

**Untick "Priority cycling."**
The same sprites disappear every frame, and some bots lose their bottom halves.

**Tick it again.**
Now the losses rotate each frame, so everything flickers but nothing disappears for good. Games chose flicker because a flickering enemy is still visible.

**Jump.**
In mid-air, the bot leaves the crowded scanline and the flicker stops.

**Untick "Overlay sprite."**
You get 3 free sprites back and lose the orange underside. Colour vs. flicker was a real trade-off.

**NES pixels aren't square.**
They're 8:7, slightly wider than tall. Untick the aspect box: the bot turns into an upright egg. Artists drew slightly "squashed" art to look round on a real TV.

**Background colour is rationed per 16×16 block.**
Tick "Attribute grid." Each 2×2 tile block shares one palette, which is why NES scenes look blocky in colour but sharp in detail.

**The hills and clouds scroll slower**
by changing the scroll position partway down the screen. That split only works because the clouds, hills and ground sit on separate horizontal bands.

**Memory limit:**
64 sprites total, tracked in the OAM (object attribute memory) counter top right. Your bot alone uses 9–12.

**Why 3 colours + overlay = 4**
```
base sprite (palette A) overlay sprite (palette B) screen . W W W . . . . . . . W W W . W W G W W + . . . . . = W W G W W K G G G K . O O O . K O O O K (W white, G grey, K black) (O orange, rest transparent)
```

**What the hardware does on each scanline**
```
for each line y: found = sprites in OAM order that touch y draw first 8 of found ← the rest are simply not drawn cycling ON: OAM start index rotates each frame → drops rotate → flicker cycling OFF: same sprites always last → they vanish
```

**Budget on the bot's bottom row**
```
bot tiles ███ 3 overlay ███ 3 mini-bots ██ 2 → 8 ✓ ███ 3 → 9 ✗ (flicker)
```

**Critical thinking:**
flicker was a bug the players learned to accept, and now retro games add it on purpose. Is authentic flicker good design or nostalgia? Who does it serve today?

**Lateral thinking:**
"8 per scanline" is a per-lane capacity limit, like checkout lanes, motorway lanes or a Slack channel's attention. Where in your work do you "cycle priority" (rotating who gets dropped) versus letting the same people always lose?

**First principles:**
why would hardware limit sprites per line instead of per screen? Hint: think about what the chip must do in the ~63 microseconds it takes to draw one line.

- How did games like Mega Man hide flicker better?
- What changes with 16-bit consoles (SNES, Mega Drive)?