Length
36 classes, 33 of them assessed
Teams
3 to 4, formed before Ai
Assessed
Individually, on a group build
Client
A real group in school, assigned to fit the team
Submission
16 pieces, plus a running portfolio
Outcome
A playable game and a 4 page rulebook
Key Concept, Related Concepts & Global Context
| Key Concept | Related Concepts | Global Context |
|---|---|---|
| Communication | Innovation, Collaboration. | Personal and Cultural Expression. |
Two requirements sit above everything else in this unit. Both are written into the specification in Bi, then tested in Di and Dii. A game that misses either one cannot reach the top band, however well it is made. Teach them in the launch class and return to them constantly.
Rule 1
Meaningful choices
The player must make decisions that matter. A game where players roll, move and do as they are told is not a design, it is a procedure.
This is the harder of the two rules and the one students underestimate. It is assessable, testable, and it is where most of the design thinking in this unit lives.
Rule 2
Fits a recess
A session runs 20 to 30 minutes, because the target slot is post-lunch recess. A game may span many sessions, but no single sitting may exceed 30 minutes.
Learning the rules must also fit inside one recess. That is the real constraint behind the 4 page maximum rulebook.
Core concept
What makes a choice meaningful
Sid Meier's description of a game as a series of interesting decisions is the standard students should be held to. A choice is meaningful only when all four of these are true at once.
- The options are actually different. Picking red or blue is not a choice unless red and blue do different things.
- No option is always best. If one move is correct every time, players stop thinking after the first game. This is called a dominant strategy and it is the most common way a student game fails this rule.
- The player can reason about it. They need enough information to have an opinion, and not so much that the answer is obvious. A pure guess is not a decision.
- The consequence is visible. The player must be able to connect what happened back to what they chose. If they cannot, the choice may as well not be there.
Four tests students can run on their own game
The coin flip test
Would a player choosing at random do about as well as one thinking hard? If yes, the choice is decoration.
The dominant strategy check
Watch five players in the same situation. If all five pick the same option, it is not a choice, it is a rule with extra steps.
The explain back test
Ask a player why they chose that. "It was the only sensible option" and "I don't know" are both failures.
The regret test
After the game, ask whether there was a moment they wish they had played differently. No regret usually means no real decision.
Watch for
The roll and move trap
Most first drafts from students are roll and move: throw a die, move that far, do what the square says. There is no decision anywhere in that loop. Catch it early, in Bii, not in Dii when the game is already built. Two fixes work most of the time. Give the player two things to spend instead of one, or let them choose which piece moves instead of whether it moves.
Planned
Interactive: meaningful choice checker
A short interactive where students describe one decision from their game, answer the four criteria, and see whether the choice survives. Feeds directly into the Bii annotation requirement.
Teams are formed, and each is assigned a real client group inside the school. Students justify why that group needs a game and plan their research. They then take apart existing games using the shared mechanics vocabulary, and pull it all together into a brief.
Client assignment. Teams are assigned their client group by the teacher, based on what the team says it wants to make. A team that wants to build something they would enjoy themselves gets an older cohort. A team drawn to what they loved a few years ago gets Grade 6. This keeps motivation high while still making the audience someone other than themselves.
You will choose an audience and find a client group, then conduct research to support the development of a new game.
Each team receives its client group. Students identify, explain and justify the need for a tabletop game for that specific audience. The justification is the whole strand, so the writing has to argue rather than describe.
What goes on the page
- Who the audience is, in specifics. Not "Grade 6 students" but what they do at 11:45 on a Tuesday.
- The situation as it stands, with at least one piece of evidence gathered rather than assumed.
- Why a tabletop game rather than a club, an app, a sport or nothing at all.
- What happens if nothing is made. If the honest answer is "nothing much", the need has not been found yet.
Common failure
Writing about themselves
Students write about the game they want to make instead of the audience who needs it. Ban the word "I" from the first draft and the problem mostly disappears.
Constructs a detailed research plan, which identifies and prioritizes the primary and secondary research needed to develop a solution to the problem independently.
You will plan your research methods and topics before designing anything, then provide explanations for your choices. (Then do the research).
Task device
The research budget
Each student gets 12 research tokens. Every activity has a price, and they cannot afford everything.
| Activity | Cost | Gives you |
|---|---|---|
| Read a secondary source | 1 | Background, fast, shallow |
| Analyse an existing game | 2 | Mechanics you can borrow |
| Questionnaire | 2 | Numbers from many people |
| Structured observation | 3 | What people do, not what they say |
| Interview | 3 | Depth from one person |
| Focus group | 4 | Disagreement between people |
With only a limited budget for research, you'll have to prioritise! Talk to your group and work together to ensure you all produce enough research to adequately prepare for your game.
| Question I need answered | Method | Primary / secondary | Cost | Priority | What decision this unlocks | When |
|---|---|---|---|---|---|---|
| One row per activity. Eight to twelve rows is typical. | ||||||
Two short paragraphs sit under the table:
- Why these, in this order. Which activity had to happen first, and what it unblocks.
- What I gave up. The activity they could not afford, and the risk that creates.
Analyses a range of existing products that inspire a solution to the problem in detail.
You will analyse three existing games against the same set of questions. The games you choose must appeal to your assigned target audience and be able to assist in the development of your new game. The Game Mechanics Catalog is a great place to find games to explore and shared vocabulary.
Required range, one of each
- A game played in class
- A game using a mechanic family the student has not used before
- Free choice, and it may be a video game if the mechanic transfers to a table
An important team rule
No more than one of a your three games may be a game that a teammate is also analysing. A team of four will cover at least nine different games, and twelve if nobody overlaps.
The synthesis page
A comparison matrix across the three games against the same criteria, ending in numbered design implications, each written as "Because..., my game should...". These get quoted directly in Aiv and Bi, so they need to be sharp.
Class shape
1Teardown together, then the first one alone
Model a full teardown on the board, then students complete page 1 on a game played in class.
2Two more teardowns
The new-family game and the free choice. Students who cannot get a physical copy use the catalog, publisher rules and video.
3Synthesis and design implications
Build the comparison matrix, then write the implications. This is the class that decides the quality of the strand.
Develops a detailed design brief, which summarizes the analysis of relevant research.
Note the verb. The brief summarises the analysis, so this is a synthesis document. Measurable criteria belong in Bi, not here. Keeping these two apart is the single most common A to B confusion.
One page, with an evidence column
| Section | Content | Evidence |
|---|---|---|
| Audience | Who they are and what matters about them | Ai, Aii |
| The need | Restated in one sentence | Ai |
| What the research showed | Three to five findings | Aii, Aiii |
| Design implications | Carried across from the Aiii synthesis | Aiii |
| Constraints | 20 to 30 minute session, 4 page rulebook, materials, table size | Given |
| Design intent | One paragraph on what will be made and for whom | Synthesis |
The evidence column is required. Every claim must point at a source, so a brief that has drifted away from the research becomes visible immediately.
Optional flourish
Write the design intent as the back of the box
Same content, box copy format. On theme, and the word limit forces students to decide what the game actually is. Keep the evidence table as the graded part.
Students turn the brief into testable specifications, then generate a real range of concepts using the mechanics catalog. Teams converge on one direction, and each student draws what is needed to build it.
Develops detailed design specifications, which explain the success criteria for the design of a solution based on the analysis of the research.
You will write specifications with measurable success criteria for your game. Each one states how it will be tested and why it has been chosen.
Every specification has four parts
| # | Specification | Measurable success criterion | How it will be tested | Source |
|---|---|---|---|---|
| 1 | Plays inside one recess | Setup to pack away under 25 minutes | Timed user trial, 3 groups | Given |
| 2 | Players make real decisions | Testers can explain why they chose, in 4 of 5 sampled turns | Explain back test during observation | Rule 1 |
| 3 | Rules learnable in one recess | Cold read group starts playing within 8 minutes | Cold read observation | Aiii impl. 2 |
Required categories, at least one each
Audience fit · meaningful choice · playtime · rules clarity · components and materials · balance and fairness · aesthetics · accessibility · cost.
Two hard rules
If it cannot be measured, it is not a specification
"The game is fun" fails. "At least 7 of 10 testers choose to play a second round" passes. Students will resist this because the measurable version feels less ambitious. It is not; it is the only version that Dii can do anything with.
The how it will be tested column is written now, not later in Di. Writing it now is what stops students from setting specifications that can never be checked.
Planned
Interactive: specification builder
A guided form producing the four column table, with a warning when a success criterion contains no number and a nudge toward a matching test method. Exports to the portfolio.
Develops a range of feasible design ideas, using an appropriate medium(s) and detailed annotation, which can be correctly interpreted by others.
Task device
The mechanic draw
Each student draws two family cards from the Game Mechanics Catalog and must build a concept using at least one mechanic from each.
Students develop a range of different game ideas and annotate them. The annotations have to be clear enough that another designer could build the game from the notes and drawings alone.
Each concept sheet, on A3
- A core loop diagram. What a player does on their turn, in order.
- Board or component sketch, roughly to scale.
- Mechanics used, named from the catalog.
- The meaningful choice, circled and labelled. If it cannot be pointed at, the concept is not finished.
- Annotation linking to a Bi specification by number.
- One risk. The part most likely to fail.
Hand drawing is the better medium here. MYP rewards annotation density, and students annotate far more freely by hand than in software. Digital is allowed if the annotation is as rich.
Two paper prototypes, actually played
Feasibility is written into the descriptor. An idea nobody has tried is not demonstrably feasible. Five minutes of play with scrap card is enough, and it kills bad ideas before they get expensive.
Assessment device
The interpretation test
"Can be correctly interpreted by others" is hard to evidence, so make it a test rather than a claim. Swap sheets with a classmate. They explain your concept back to you from the sheet alone while you stay completely silent. You write down everything they got wrong.
That list is submitted with the concepts. It is direct evidence for the descriptor, and it is the most useful feedback a student will get all unit.
Class shape
1Mechanic draw and rapid concepts
Three draws, three fast concepts, no annotation yet. Quantity over polish.
2Develop and annotate the best six
Annotation is the work of this class. Circle the meaningful choice on every sheet.
3Paper prototypes and the interpretation test
Two prototypes played for five minutes each, then the silent swap and explain.
Presents the chosen design and justifies fully and critically its selection with detailed reference to the design specification.
You will choose one design and justify that decision against the others. You'll also make the strongest case you can against your own choice.
How the team converges
- Each student pitches their strongest concept to their team.
- The team converges on one direction to build.
- Then each student individually writes the justification, including the students whose concept was not chosen.
Part 1: weighted decision matrix
Three finalist concepts scored against every Bi specification. Weights assigned by the student and justified, because an unweighted matrix implies every specification matters equally, which is never true.
Part 2: critical justification, 1 to 2 pages
- Why the chosen design wins, referencing specifications by number.
- The case against it. What it does worse than the concepts they rejected.
- What was carried over from the rejected concepts into the final design.
- What is still unresolved, and how the build will resolve it.
Develops accurate and detailed planning drawings/diagrams and outlines requirements for the creation of the chosen solution.
You will draw the chosen game accurately enough for it to be made. The drawings carry measurements, materials and the requirements for producing each component.
| Page | Content |
|---|---|
| Component manifest | Every component, quantity, size in mm, material, and who makes it |
| Board drawing | To scale, dimensioned, with a title block |
| Card template | Dimensioned, showing bleed, safe margin and type sizes |
| Token or piece drawings | Orthographic, or a flat pattern if folded. 3D printed pieces show the model |
| Iconography sheet | Every icon drawn at final size, with its meaning |
| Rulebook map | Section structure and page order across the 4 pages, not the prose |
| Requirements | Materials, tools, quantities, cost, and time per component |
Individual portion. Each student draws the components they will personally make in C. Biv and Ci name the same owner for the same parts, which is what makes the group build individually assessable.
Plan around the kit
The large laser cutter is not reliable
Any component whose only route to existing is the large laser cutter needs a stated fallback in the requirements page. This is not a nuisance. It is the kind of production constraint the strand asks students to think about, and it gives Ci's fallback column something real to hold.
Print shop orders need lead time and cost money, so anything going to the shop has to be finalised earlier than everything else. That decision belongs on this page.
Reteach expected. Scale, dimensioning and title blocks were met in G8, but budget one class to bring them back before the pack begins.
One planning class, then a ten class build block. Cii, Ciii and Civ all run inside that block at the same time. That is why the evidence routines matter more here than anywhere else in the unit.
The grouping problem
How a group build stays individually assessed
This is the part of the unit most likely to go wrong. Three devices carry individual evidence through a shared build:
- Component ownership. Every student is named owner of specific components in Biv and Ci, and only that student makes them.
- The making log. Dated photographs with the student's own hand or initials visible on the part, plus a note on what went wrong.
- Individual writing on team decisions. Civ is written alone even when the change was collective.
Constructs a detailed and logical plan, which describes the efficient use of time and resources, sufficient for peers to be able to follow to create the solution.
Two linked plans
- Team plan: build a plan for making the game, with time and resources established every step. All members of the group should be able to follow it without asking questions.
- Personal task plan: Create your own plan for the specific tasks you will be responsible for. It must be detailed enough that other group members can help if you are absent.
Assessment device
The peer follow test
"Sufficient for peers to follow" is testable, so test it. Swap plans with another team. They read yours for five minutes, then narrate what they would do in build class 1 and build class 4. Anything they cannot answer is a gap.
Students record the gaps and revise. Both versions are submitted, before and after, which evidences the strand far better than a single clean chart.
Planned
Interactive: build planner
Drag tasks across ten build classes, assign owners, set dependencies, and have the critical path highlight itself. Flags any student with no owned components.
Demonstrates excellent technical skills when making the solution.
You must demonstrate technical skill while making your game. You choose which skills to highlight, and provide evidence of the work for consideration.
Four skill tracks
Systems and rules design
- Writing rules that survive a cold read
- Balancing with numbers, not with feeling
- Designing an icon language that removes text
- Teaching the game in under five minutes
No equipment
Graphic design
- Card layout with correct bleed and safe margin
- Typography sized for the audience and the table distance
- Colour and contrast, including colour blind safe choices
- Export ready artwork for the print shop
Colour printers · print shop
Digital fabrication
- 3D modelling tokens, miniatures, trays or inserts
- Printing well: orientation, supports, tolerance, fit
- Laser etched surfaces and markings
- Designing a part that can be reproduced twenty times
3D printers · small laser etcher
Hand fabrication and finishing
- Precision cutting, scoring and folding
- Mounting, hinging and board construction
- Surface finish, edges and corners
- Making a jig so twenty parts come out identical
Art and craft supplies
Requirement
Three skills at depth, across at least two tracks
Three skills done properly beats ten touched lightly. The two track minimum stops a student from spending ten classes at a 3D printer and calling it a build.
For each of the three, the making log carries:
- A dated photo of work in progress, with the student's hand or initials visible on the part
- A photo of the outcome
- What went wrong, what they changed, and what the second attempt did better
Follows the plan to create the solution, which functions as intended and is presented appropriately.
You and your group follow the plans and finish a game that works. It has to be playable by people who had no part in making it.
Assessment device
The cold read test
A team who has never seen the game receives the box and the rulebook and nothing else. They set up and play with no help of any kind. The designers watch in silence and record every question asked and every rule misread.
This is evidence for Ciii, it is the rehearsal for Di, and the silence is the hard part. A designer who explains has destroyed the data.
The four page rulebook. OnePageRules is the reference to hand students. Complete wargames in a few pages, and the compression is the skill. Structure, iconography and a worked example beat prose every time.
Fully justifies changes made to the chosen design and plan when making the solution.
| Date | What changed | What triggered it | Options considered | Why this one | Effect on spec or plan |
|---|---|---|---|---|---|
| One row per change. Expect fifteen to thirty rows across the build. | |||||
The thing that decides this strand
Logs written the night before are obvious
You and your team must record all the changes you make to the design while building it. You must explain why each change was needed and the result of the change.
Planned
Interactive: change log with a real timestamp
Entries stamped when written rather than when claimed, so the log stop routine is self evidencing. Warns when a build class has no entry against it.
Students design testing methods that produce real data about their game. They will use the methods established to gather data.
Client sessions are per team, not a mass event. Each team takes its game to its own client group. Div is assessed on that session, where the audience is the one named back in Ai. A broader showcase can follow, but it is not assessed.
Designs detailed and relevant testing methods, which generate data, to measure the success of the solution.
Methods are drawn from the DP A2.1 user centred research toolkit: user observation, interviews, focus groups, questionnaires, user trials, personae and scenarios. Meeting them here sets up the DP course for anyone continuing.
The core requirement
Naming a method is not designing one
The descriptor says designs, and it says generates data. A student who writes "I will use a questionnaire" has done neither. The instruments themselves are submitted:
- The questionnaire, with its actual questions in their actual order
- The observation sheet, with what is being tallied and how
- The interview script, with prompts and follow ups
- The user trial protocol, with what is timed or counted, by whom
| Which spec | Method | Participants | Data type | Instrument | Success threshold |
|---|---|---|---|---|---|
| 2, meaningful choice | Observation + explain back | 5 client testers | Qualitative + tally | Choice observation sheet | Reasoned answer in 4 of 5 sampled turns |
| 1, playtime | Timed user trial | 3 groups | Quantitative | Stopwatch + trial sheet | Under 25 min, all 3 groups |
A correction to make early
Match the method to the specification
Students default to a questionnaire for everything. Playtime needs a stopwatch, not an opinion. Rules clarity needs observation of actual misplays, not a question asking whether the rules were clear, because everyone says yes. Meaningful choice needs the explain back test, because a player cannot self report whether their decision mattered.
Critically evaluates the success of the solution against the design specification based on authentic product testing.
You will test the finished game and evaluate it against your own specifications. Every success criterion is judged on the evidence your testing produced.
1The client session
The team takes the game to its own client group. Every student runs their own instrument from Di and collects their own data. Nobody helps the players understand the rules; that is the whole test.
2The evaluation
Every specification from Bi, one row each, in order. No skipping the ones that failed.
| Spec | Test used | Data collected | Met / partly / not met | Evidence | What this means |
|---|---|---|---|---|---|
| One row per specification, all 8 to 12 of them. | |||||
Where "critically" lives
The limits of your own evidence
A closing section on why the data might be wrong. Sample size, a single session, and testers who knew the designers and wanted to be kind. Also the gap between what people said and what they did.
A student who says a specification was met by three testers, and admits that is thin, shows more judgement than one who claims certainty. Reward that plainly, or students learn to hide it.
Explains how the solution could be improved.
| Improvement | Which spec it addresses | Dii evidence that prompted it | Why this would work | Cost and feasibility | Rank |
|---|---|---|---|---|---|
| Five to eight improvements, ranked. | |||||
Two rules
- Every improvement traces to a specific Dii finding. An improvement with no evidence behind it is a preference, and preferences do not evidence this strand.
- Include one improvement for something that passed. Meeting a specification is not the same as being as good as it could be, and noticing that gap is a top band move.
Explains the impact of the product on the client/target audience.
A core confusion
Impact is not satisfaction
"They enjoyed it" is a Dii finding about a specification. Impact asks a different question: what did this product do to the people it was made for, and to anyone else near them.
Six required sections
- Who was affected, including people beyond the players themselves.
- Intended against actual impact, quoting the Ai need statement directly.
- Evidence from the client session: quotes, observation tallies, what people did rather than what they said.
- Unintended effects, positive and negative. Did quieter students join in more? Did the reading level, the language or the hand dexterity required exclude anyone?
- Wider impact, at least two of: the school, families, materials and waste, cost, cultural and linguistic fit for a multilingual audience.
- Was the original need met? Yes, partly or no, answered plainly, with reasons.
Thirty three assessed classes, one launch, and two held in reserve. The build block is the only stretch where three strands run at once.
| Classes | Strand | Individual deliverable |
|---|---|---|
| 1 | Launch | Teams formed, clients assigned, the two rules taught |
| 2 | Ai | Need Statement, 1 page |
| 3 | Aii | Research Plan, prioritised by budget |
| 4 to 6 | Aiii | 3 teardown cards plus a synthesis page |
| 7 | Aiv | Design Brief with evidence column |
| 8 | Bi | Specification, 8 to 12 testable lines |
| 9 to 11 | Bii | 6 to 8 annotated concepts, 2 played prototypes |
| 12 to 13 | Biii | Decision matrix and critical justification |
| 14 to 16 | Biv | Production Pack, 4 to 8 pages |
| 17 | Ci | Team plan and personal plan, both versions |
| 18 | Skill clinics | Rotating stations, no submission |
| 19 to 27 | Build block | Cii making log, Ciii the game, Civ change log |
| 28 to 29 | Di | Test Plan with instruments built |
| 30 | Dii, session | Client session, data collected |
| 31 | Dii, evaluation | Point by point against every spec |
| 32 | Diii | Ranked improvements |
| 33 to 34 | Div | Impact report, poster and pitch |
| 35 to 36 | Reserve | Slack, or the broader showcase |
Routines
Four things to run every time
- Log stop. Last five minutes of every build class, Civ entry written in place before packing up.
- Catalog callout. Whenever a mechanic comes up, name its family out loud. Builds shared vocabulary at no time cost.
- Spec check. Open the Bi page at the start of every B and C class. Specifications that are never reread do not get met.
- Swap and read. Anything claiming to be readable by others gets read by others before it is submitted. Applies to Bii, Ci and Ciii.
Planned
Interactive: student progress tracker
Sixteen strands, submission state per student, and a view showing which team members own which components during the build block.
-
Tool
Game Mechanics Catalog
Seventy mechanics across ten families, each with rules, the games that use it, and a diagram. The shared vocabulary for Aiii and the concept generator for Bii.
-
Rules
OnePageRules
Complete wargames written in a handful of pages. The model to hand students for the four page rulebook limit, and a lesson in compression by itself.
-
Course
DP A2.1 User Centred Research
Observation, interviews, focus groups, questionnaires, user trials, personae and scenarios. The method source for Di.
-
Tool
User Persona Builder
Guided persona construction, printable to A4. Useful in Aii for teams whose research budget stretches to a persona.
-
Games
You Should Play These Games
A curated list with the educational reasoning attached. A starting point for the Aiii teardown selection.
-
Reference
BoardGameGeek
Component lists, playtime data, player counts and rules downloads for almost any published game. The practical source for Aiii research.