Billy's Sprig Developer Tour
DC companion deck
Start here

Let Billy drive.

“I realised I’ve watched this grow all term without ever getting the proper developer tour. Show me what you’ve made.”

This deck is a steering wheel for you, not a worksheet for Billy. Let him play, explain, demonstrate and wander. Use a prompt only when there is somewhere interesting to go.

Useful rule

Ask how something works before mentioning anything you noticed in the code.

1 · Origin story

What did you start with?

“What was already there when you began, and what parts did you add yourself?”

If he gives a broad answer, get him to point at things on screen or in the code.

Listen for
  • What came from a tutorial, example or existing Sprig game.
  • What he designed, adapted or rewrote.
  • Where he got stuck and how he found help.
  • Whether he can distinguish “I copied this” from “I understood and changed this”.
2 · Game tour

Play it from the start.

“Talk me through what the player is learning as the levels go on.”

The six maps appear to introduce and then combine mechanics: basic movement, spikes, lock blocks, bullets and finally the Qwerty element.

Interesting follow-up

“Did you plan that order, or did the levels just grow that way?”

3 · Gravity

How is the player falling?

“Show me the bit that makes gravity work. What is happening over time?”
Listen for
  • movePlayers()
  • changing the player's y position
  • the repeating timer
  • why the player cannot simply fall through solid floor tiles
If you want to stretch him

“If you wanted jumping to feel smoother instead of moving one tile up, what would have to change?”

4 · Locks

How do the lock blocks work?

“What changes when I press S? Are the blocks moving, disappearing, or is something else changing?”
Listen for

The important idea is state: isOn changes, and the game rebuilds which sprite types count as solid.

Small investigation

Finish a level while the locks are clear, then try the lock control in the next level. Ask whether the code's idea of isOn always matches what the game is actually doing.

5 · Bullets

These are interesting.

“Show me how a bullet knows which way it is travelling, and how it knows when to turn around.”
Listen for
  • each bullet getting its own dx
  • checking the next position before moving
  • reversing direction at the map edge
  • reversing when the next tile contains floor or a lock block
“What are the bullets supposed to do when they hit the player?”

The code moves them, but does not appear to make them damage or kill the player. That may be unfinished, deliberate, or simply not noticed yet.

6 · Secret ending

Qwerty Winner 👀

“How do I discover Qwerty Winner? Show me how that ending works in the code.”
Then ask

“Why does (goal).length work there?”

Don't explain it first. goal is the string "g", so its length happens to be 1. The condition can therefore work for a single Qwerty tile without actually counting Qwerty tiles.

Lovely accidental-success debugging question: the game can work while the reasoning underneath it is shaky.

7 · If he wants to improve it

Pick one. Don't turn it into homework.

Once Billy has given you the tour:

“If you had another session, what would you improve first?”

Make bullets dangerous

Add player/bullet collision and decide what a hit actually does.

Make hazards more reliable

Spike checking currently happens on the gravity timer, so a quick move may potentially escape between checks.

Make locks fully consistent

Keep isOn and the actual solids list synchronized when levels change.

Let bullets respect the switch

Bullets currently treat lock tiles as barriers even when the player can pass through them.

Fix the Qwerty count properly

Count Qwerty tiles instead of relying on the length of "g".

Add a proper restart

After Game Over, gameRunning is false, so the current J reset handler cannot run.

Tidy old experiments

mapWidth and showQwertyText are declared but not used.

Polish the code

Use the bullet constant consistently instead of sometimes using "b" directly.

8 · Finish here

One question.

“What’s the bit in here you’re proudest of?”

Then let him answer properly. No need to translate it into a learning outcome while he is sitting there.

For you afterwards

Notice whether he chooses a technical problem, a design decision, an aesthetic detail, a joke/easter egg, or the fact that he worked something out independently. That tells you what this project meant to him.

1 / 9
Keyboard: ← → to move through cards. Notes save in this browser.