From Concept to Ship — A Nine-Week Design Arc
Builder Hub asks students to make something that didn't exist before and answer for it — to a real person, to a real standard, to a real-world test. The deliverable is a game level. The formation outcome is a builder who knows the difference between a design and a decision.
Grit — the capacity to persist through difficulty, treat failure as data rather than verdict, and ship something rather than endlessly refine it in theory. Grounded in a Christian account of why making things for others matters.
Each student submits a written player profile before logging off.
Warm-up live play. Teacher shares screen and plays a short browser-based game level while thinking aloud. Students add observations to a shared doc: what works, what frustrates, what keeps you going.
Structured play. Students each play two assigned levels and complete an observation sheet: What is the player supposed to do? Where did you get stuck? What made you want to keep playing?
Peer interview. Paired activity. Each student interviews their partner using five provided questions about what they want from a game level. Roles swap at 20 minutes.
Player profile draft. Students write a short paragraph: who is their player, and what does that person need from a game? Teacher reads two or three aloud and asks: is this specific enough to build for?
Close. Students submit their player profile before logging off.
Model observation language. Narrate what you notice as a player, not as a designer. Show students how to separate "I didn't like this" from "this mechanic created this problem for the player."
Monitor observation quality. Flag sheets that are too vague ("it was fun") or too personal ("I hate platformers"). Redirect toward player-centered language.
Enforce the interview protocol. Keep students on the five questions. If a pair finishes early, ask the interviewer: what surprised you?
Push toward specificity. "Someone who likes games" is not a player. "A 7th grader who gives up when they die more than three times" is.
Gate the submission. Do not let students leave without submitting. A missing profile means no concept to lock next session.
Each student submits a concept lock statement — genre, mechanic, player type, and win condition.
Problem statement share-out. Each student reads their player profile from week 1 aloud in 30 seconds. No feedback yet.
Three-concept sketch. Students sketch three genuinely different level concepts. Each needs a rough layout, the core obstacle, and the win condition.
Gallery walk. Students post all three concepts in a shared visual space. Each student leaves one sticky note on a peer's board: which one best serves the player you described?
Decision and lock. Students read their feedback, make a final choice, and write a concept lock statement: genre, mechanic, player, and win condition.
Close. Concept lock statements submitted.
Listen for vagueness. Note any player profiles still too broad. Flag those students for a quick check-in during the sketch phase.
Hold the three-concept rule. Students will want to do one concept in detail. Enforce the constraint: three different concepts, each one real.
Redirect gallery feedback. Interrupt feedback about personal preference. The only question on the board is: which one serves your player?
Hold the commitment. Students will resist locking. Be direct: the project requires a decision today. You can revise the execution later.
Collect and confirm. Read each concept lock statement before the session ends. If a statement is missing the mechanic or win condition, send it back.
Each student submits a complete level design document.
Design document intro. Teacher shares a real indie game level design document and walks through what it contains: layout map, obstacle list, learnable mechanic, win condition.
Draft the design document. Students build their own using a provided template. The mechanic description must answer: what does the player have to figure out to finish this level?
Peer design review. One student walks through their document while the partner plays the role of the player, asking "what do I do here?" at any point of confusion. If the builder has to explain something verbally, it goes back into the document.
Revise and resubmit. Students revise based on the review.
Close. Final design documents submitted.
Teach the document as a constraint. Frame it not as paperwork but as a commitment device: this tells you what you are building before you build it.
Enforce the mechanic requirement. Students will describe what the level looks like but not what the player has to learn. Push: can someone who has never seen your level read this and understand what skill they need?
Run the design review strictly. The review partner must stay in player role. Every verbal explanation from the builder is a documentation gap.
Check revision depth. A student who makes zero revisions either had a perfect document or wasn't listening. Ask: what did your partner ask that you had to answer out loud?
Collect and file. This document is the reference point for the whole quarter. You will return to it in week 8.
Each student submits a shareable link to a playable prototype.
Tool orientation. Teacher demonstrates the minimum viable build in Scratch or GDevelop: a character that moves, an obstacle that stops it, a finish line that ends the level.
Build sprint. Rule posted: no music, no final sprites, no title screen. The only question: can a player start this level, attempt it, and reach a win or fail state?
Live playtest. Teacher selects three students to share screens. Each plays a peer's prototype live while the class watches. Builder is silent. Teacher asks: where did the player get confused? Where did they stop trying?
Repair sprint. Students fix the single most important problem the live test revealed. One fix only.
Submit link. Students submit a shareable link to their prototype before logging off.
Set the minimum bar explicitly. Say out loud: the prototype is done when a player can start it, attempt it, and either finish or fail. Not art, not music. A working level loop.
Interrupt polish. Rotate screens constantly. Every time a student works on art or sound instead of the level loop, redirect them.
Pick representative prototypes for the live test, not the strongest. The class learns more from watching a broken prototype than a polished one.
Enforce the one-fix rule. Students who finish early should playtest their own level ten more times and write down what else breaks — not fix it yet.
Chase missing links before the session ends.
Each student submits a written diagnosis of their prototype based on playtest observations.
Assigned playtest. Each student plays their two assigned games and fills out a playtest sheet: where did you get stuck, where did you stop trying, what worked, what confused you.
Public debrief. Each playtester shares observations for their assigned game while the builder listens. Builders do not speak. If a builder starts to explain, the teacher stops them.
Builder response. After all playtesters have spoken, builders may ask clarifying questions only — not defend, not justify.
Written diagnosis. Students write a diagnosis, not a fix list. What did the playtest reveal about the gap between what I designed and what the player experienced?
Close. Diagnoses submitted. Teacher previews week 6: every student will present their diagnosis publicly next session.
Chase missing playtest sheets. Contact any student who hasn't submitted before the session begins.
Enforce builder silence. Say it once at the start and enforce it every time. If a builder speaks during their playtester's report, that data is invalid.
Keep builder responses narrow. Push back on any response that begins with "yeah but" or "the reason I did that was." Those are justifications, not questions.
Distinguish diagnosis from fix list. A fix list says: I need to change the jump height. A diagnosis says: the player had no signal that the mechanic required timing. Push toward the second.
Set expectations for week 6. Be direct: next session every student presents their diagnosis out loud.
Each student submits a revised problem statement.
Public debrief. Four minutes each. Students present from their week 5 diagnosis: what broke, what the data showed, and what assumption they held going into week 4 that the test proved false. No solutions yet.
Q&A. After each presentation, teacher asks one follow-up and opens it to peers for one more. Questions target the assumption, not the fix: what made you think that would work?
Revised problem statement. Students return to their week 2 concept lock statement. Is the player still the same? Is the mechanic still right? Students rewrite to reflect what they actually know now.
Close. Revised problem statements submitted.
Hold the room. Students will rush toward solutions. Stop them every time: we are not fixing yet. We are naming. The question is "what was wrong, and why did you not see it in week 2?"
Watch for surface-level failure naming. "My jump physics were off" is a technical note. Push for the assumption underneath.
Ask the assumption question. Your follow-up should always target: what did you assume that wasn't true?
Push the revised problem statement. A student whose revised statement is identical to week 2 hasn't absorbed the data. Ask: what changed?
Note which students significantly revised their statement. This informs your check-in at the start of week 7.
Each student submits an iteration log and an updated prototype link.
Revision plan check-in. Each student states their three changes out loud in one sentence each.
Build sprint. 75 minutes of focused revision. The design document from week 3 stays open — changes need to be consistent with or consciously departing from original design intent.
Second playtest. Same pairs as week 5. Same rules: builder watches, doesn't explain. The only question: is it better? Where is it still broken?
Iteration log. Students write a one-paragraph log: what changed, what it cost them to make the change they resisted, and whether the second playtest confirms the revision worked.
Close. Iteration logs submitted. Teacher previews week 8: polish is now permitted.
Find the resistant change. Ask every student: which of your three changes did you not want to make? A student who cannot name one did not engage honestly with their data.
Prioritize students with major revisions. Students whose week 6 statement changed significantly may need to rethink more than mechanics. Check in with them first.
Keep the playtest clean. Same rules as week 5. Builder silence, observer documents.
Read the iteration logs. A log that says "I changed the jump height and it works better" is a changelog, not an iteration log. Push for reasoning: why did the data say this had to change?
Open the polish gate. Tell students explicitly: week 8 is the only session where polish is permitted. Not before.
Each student submits a final game link and a written presentation outline.
Final build. Music, sprites, title screen — everything forbidden in week 4 is now allowed. At the 60-minute mark, the build tool closes and the game is submitted.
Presentation prep. Students structure a three-minute presentation around four questions: What problem were you solving and for whom? What did you build? What broke, and what changed? What would version two look like?
Close. Games and presentation outlines submitted.
Close the gate at 60 minutes. Announce the deadline at the start and again at 45 minutes. At 60 minutes, the game is submitted in whatever state it is in. Do not extend.
Push the presentation away from demo mode. The audience will play the game themselves. The presentation is about decisions, not features.
Surface the arc. Ask each student: what is the one moment from this quarter you want the audience to understand? That moment is the center of the presentation.
Confirm every student has both a submitted game and a presentation outline.
Each student submits a final written reflection — 150–200 words answering: what kind of builder am I now that I was not in week 1?
Presentations. Students present in sequence. Three minutes each, no extensions. One question from the teacher and one from a peer after each. The game is not demonstrated live — pulled up for reference only.
Written reflection. Independent and silent. 150–200 words: what kind of builder am I now that I was not in week 1?
Close.
Ask the arc question. After each presentation: what was the moment this quarter that cost you the most, and what did you do? Redirect students from features to decisions.
Time-keep strictly. Three minutes is three minutes. Cut at the mark and ask your question.
Protect the reflection. No talking, no sharing screens. Students need to think alone.
Follow up on incomplete reflections asynchronously. A reflection that summarizes the project has not answered the question.