Teams
3 to 4 students, 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. |
Inquiry Questions
| Type | Question | Where it is answered |
|---|---|---|
| Factual | What makes a choice in a game meaningful? | The two non-negotiables |
| Factual | What mechanic families exist, and which ones are used in the games your audience already plays? | Aiii, with the Game Mechanics Catalog |
| Conceptual | How does the set of choices a game offers communicate who it was designed for? | Bii and Biii |
| Conceptual | Why does a game need to be played by other people before its designer can know whether it works? | Ciii, Di and Dii |
| Debatable | Is a game that is fun for its designers but not for its audience a failure? | Ai at the start, Div at the end |
If something is 'negotiable' it means it can be discussed and potentially changed. non-negotiable means that something cannot be changed, no matter how good your argument. There are two 'non-negotiable' requirements in this unit. Your game must allow players to make meaningful choices, and it must be playable during lunch recess. Both are written into the specifications in Bi, then tested in Di and Dii. A game that misses either one cannot reach the top band, however well it is made.
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. Most of the design thinking in this unit is about making choices meaningful.
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 your game will 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 you can run on your 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.
The roll and move trap
Many first drafts 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.
Interactive
Does your choice survive?
Take one decision from your game and put it through the four criteria. Answer honestly. Not sure is allowed, and it tells you which of the four tests above to run next.
Game building teams are created, and each team will be assigned a real client group inside the school. (Your audience, which is a specific grade level) You'll justify why that group needs a new game and plan the research needed to design a good game. You'll "take apart" existing games using the shared mechanics vocabulary, and combine all this together into a brief.
You will choose an audience and find a client group, then conduct research to support the development of a new game.
Each team will is now assigned your client group (or target audience). You will identify, explain and justify the need for a tabletop game for that specific audience. The justification is the whole strand, so your writing has to argue specific points rather than describing general ideas.
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.
Writing about yourself
It is easy to write about the game you want to make, instead of the audience who needs it. Try writing your first draft without using the word "I".
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.
Your design brief summarises the analysis, so this is a synthesis document. This means it combines details from Ai, Aii, and Aiii, and also includes additional details. Measurable criteria belong in Bi, not here. Keeping these two apart is the single most common A to B confusion.
The brief is the page that carries Criterion A into Criterion B. A reader who has never seen the Need Statement, the Research Plan or the teardowns should finish the brief knowing who the game is for, what they need, what the research found and what the team intends to make. Bi then points every specification back at a line in this brief, so anything missing here has nowhere to come from later.
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. Name the strand and the specific source, such as "Aii, interview with the library supervisor", rather than "research".
| Section | An example row | Evidence |
|---|---|---|
| What the research showed | Grade 6 students at lunch stay at one table for about 20 minutes before they drift to the field. | Aii, structured observation of the Grade 6 lunch tables over three days |
Optional: Write the design intent as the back of the box
The back of each tabletop game includes a description about what you'll find inside. This writing also tries to convince anyone reading that it's worth their time (and money) to buy and play the game. Writing about your game concept in this way could help make your ideas more clear, and might even be fun.
Write it on the worksheet
The Aiv Design Brief is one A4 landscape side with every section of the brief beside an evidence box. Two suggested rows, the games the audience already plays and what the research left unanswered, are there for students who want them.
Work saves in the browser as you type. Hand in the PNG, or print the side and write on it.
You'll turn your design brief into testable specifications. A specification is testable if you can check it with a test. Then you'll create a range of game concepts using the mechanics catalog. Your team will converge on one direction, which means you agree on one idea to build. Then you will each draw the parts 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. A success criterion is the result that shows a specification has been met. Each specification says how it will be tested and why you chose it.
Discuss your specifications with your team, because you will all build one game. The six specifications you hand in are your own work. In Dii, you will test your game against each of them.
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 implication 2 |
| × | The game is fun | No number, so there is nothing to measure | Nothing can test this | — |
Specification categories
These are the categories in the tool's dropdown list. Meaningful choice and playtime are the two non-negotiables, so you must include both. Choose your other four from the remaining seven. Pick the ones that matter most for your game.
| Category | What it covers |
|---|---|
| Meaningful choice | Rule 1. Players make decisions that matter, and no option is right every time. Required. |
| Playtime | Rule 2. How long one game session takes, including setup and pack away. Required. |
| Audience fit | Whether it suits the group you were assigned: their age, their reading level, the time they actually have. |
| Rules clarity | How quickly someone can learn to play without your help. |
| Components and materials | What the game is made of, and whether your team can make it during the Build Classes. |
| Balance and fairness | Whether every player still has a reason to keep playing, including the one who is behind. |
| Aesthetics | How it looks and feels on the table, and whether that matches your audience rather than your own taste. |
| Accessibility | Whether people with different eyesight, language skills or hand control can play it. |
| Cost | What one copy costs to make, in materials and in class time. |
If it cannot be measured, it is not a specification
"The game is fun" fails, because it cannot be measured. "At least 7 of 10 testers choose to play a second round" passes. A measurable specification can feel less exciting, but it is the only kind you can test in Dii.
Write the how it will be tested column now, not later in Di. This stops you from writing specifications that can never be checked.
Build it with the tool
The Design Specifications Tool is one A4 landscape page with six specification cards. You choose the category, the test method and the source from a list, so everyone in the class uses the same words. Each card has space to explain your reason.
Your work saves in the browser as you type, so it is still there next class. Hand in the PNG, or print the page and write on it.
Develops a range of feasible design ideas, using an appropriate medium(s) and detailed annotation, which can be correctly interpreted by others.
Requirement
Include 9+ mechanics, with 3 unique to your work
Across your three concepts you must use at least nine mechanics, named from the Game Mechanics Catalog. That is about three per concept. This stops your three ideas from becoming the same idea drawn three times.
At least three of your nine mechanics must not appear anywhere in a teammate's concepts. Compare lists with your team before you start sketching.
Annotations have to be clear enough that another designer could build the game from the notes and drawings alone.
Include these on each A3 concept sheet
- A core loop diagram that shows what a player does on their turn, in order.
- A sketch of the board or components, drawn roughly to scale.
- The mechanics you used, named from the catalog.
- A meaningful choice, clearly marked on the drawing. If you cannot point to it, the concept is not finished.
- Annotations (notes on the drawing) that link to your Bi specifications by number.
- One risk. Write about one part of your game that is a risk, and could fail.
Drawing by hand works best here. Your mark depends on detailed annotation, and most people write more notes by hand than on a computer. You may work digitally if your annotations are just as detailed.
The Bii Concept Sheet is the A3 page you draw on. It is laid out like an engineering drawing. Its border has letters and numbers, so you can name a part of the page (for example, C3). It also has a large grid for the board and components, a strip for the core loop, a column for the five things every concept needs, and a title block in the corner. Print one for each concept, so three in total.
You can type into the boxes in the column if you start on a laptop, and your typing saves in the browser. Draw on the two large areas by hand.
Feasible means your team could actually make it
The descriptor asks for feasible ideas. Feasible means your team could really make it, with the materials in this room, during the Build Classes. Name the components and say what each one is made of. If a concept needs a part that nobody can make or buy, it is not feasible, even if it looks good on the page.
Part of the task
The interpretation test
The descriptor says your ideas must be "correctly interpreted by others". This means other people can understand them from your sheet. You will test this. Swap sheets with a classmate. They explain your concept back to you, using only the sheet, while you stay silent. Write down everything they got wrong.
Hand in that list with your concepts. It is evidence for the descriptor, and it is some of the most useful feedback you will get in this unit.
What you will do in each class
1Pick mechanics and sketch fast
Choose mechanics from the catalog and check your list against your team's. Then sketch three quick concepts without notes. Aim for many ideas, not neat ones.
2Develop and annotate all three
Add detailed notes to all three concepts. Circle the meaningful choice on every sheet.
3Finish the annotation and run the interpretation test
Finish your notes, then run the interpretation test. Hand in the list of what your reader got wrong with your concepts.
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 your team chooses one design
- You each present your strongest concept to your team.
- Your team agrees on one design to build.
- Then you each write the justification on your own, even if your concept was not chosen.
Part 1: weighted decision matrix
Score your three final concepts against every Bi specification. Give each specification a weight, a number that shows how important it is, and explain why. Without weights, every specification counts the same, and that is never true.
Part 2: critical justification, 1 to 2 pages
- Why the chosen design wins, referencing specifications by number.
- The case against it, meaning what it does worse than the concepts you rejected.
- What was carried over from the rejected concepts into the final design.
- What is still unresolved, and how the build will resolve it.
What you will do in each class
1Pitch and converge
You each present your strongest concept to your team in three minutes. Together, score the three finalists in the decision matrix, discuss the weights, and agree on one direction.
2Write it alone
Write the four sections of the critical justification on your own, even if your concept was not chosen. Spend the most time on the case against the chosen design.
Build it with the tool
The Biii Choose and Justify tool has two A4 landscape pages. The first is the weighted decision matrix. You score three concepts against your six specifications, give each specification a weight and a reason, and the tool adds up the totals. The second page holds the four sections of the critical justification.
If you used the Bi tool in the same browser, your specifications fill in automatically. Hand in both PNGs.
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. Your drawings must show measurements, materials and what is needed to make each component.
| Page | Content |
|---|---|
| Component manifest | Every component, quantity, size in mm, material, and who makes it |
| Board drawing | Drawn to scale, with dimensions and a title block |
| Card template | With dimensions, showing bleed, safe margin and text sizes |
| Token or piece drawings | Drawn from the front, side and top (orthographic), or as a flat pattern if folded. For 3D printed pieces, show the model |
| Iconography sheet | Every icon drawn at final size, with its meaning |
| Rulebook map | The sections and their order across the 4 pages, not the full text |
| Requirements | Materials, tools, quantities, cost, and time per component |
Your own part. You draw the components that you will make yourself in Criterion C. Biv and Ci must name the same owner for the same parts. This is how your own work is assessed in a team build.
Every page must give enough information for the rest of the team to continue if you are absent. If you own the card designs, you can still help with the board or the rules when someone is away.
What you will do in each class
1Scale, roles and setup
Watch a short demonstration of drawing to scale. Then split the components with your team, and set up your title block and page types in the production pack builder.
2Lay out your pages
Lay out the pages for the parts you own, at the right scale. Check every size against the component manifest.
3Print, finish and check
Print your pages and finish the drawings by hand. Then check, as a team, that every component in the manifest is drawn by someone, and that each page gives a teammate enough information to continue.
Lay out the pack with the tool
The Biv Production Pack makes A3 landscape pages at true size, so a card drawn at 1:1 prints at its real size. Add the pages your role needs and choose a page type to start from. Then drag in card templates, boards, tokens, icon cells, rulebook maps, tables and labels. Items can snap to a 5 mm grid, or you can place them freely.
You type the title block once, and it repeats on every page. Each page also has space for its materials and a note for a teammate in case you are absent. Print your pages and finish the drawings by hand. Use a backup file to move your pack between devices.
Drawing to scale. You used scale drawings, dimensions and title blocks in Grade 8. The first Biv class starts with a short reminder of how they work.
Criterion C has one planning class, one introduction and skill clinic class, and then nine Build Classes. You will work on Cii, Ciii and Civ at the same time during the Build Classes. This is why recording your evidence as you go matters more here than anywhere else in the unit.
How you are assessed on your own in a team build
Your team builds one game, but you are each assessed on your own work. Three things show your own work:
- Component ownership. You are named as the owner of certain components in Biv and Ci, and only you make them.
- The technical skill sheet. You name the three skills you will show and the evidence you will upload for each. For example, dated photos with your hand or initials visible on the part.
- Your own writing about team decisions. You write your Civ change log on your own, even when the team made the change together.
The Build Classes
0Introduction and skill clinics
Look through the production toolkit below, then visit the skill stations. Choose the three skills you will show and start your Cii technical skill sheet.
1Build Class 1: start what you own
Work from your Ci plan. Start on the components you own, take a first progress photo, and write your first Civ entry at the end of class.
2Build Classes 2 and 3: first versions
Make a first version of every component. Print cards and boards as drafts, and make tokens and pieces once. Keep and photograph your weak first attempts, because Cii needs them.
4Build Class 4: rulebook draft
Finish a draft of your four page rulebook, so another team can read it in the next class.
5Build Class 5: rulebook cold read
Rulebooks are swapped. You read another team's rules for the first time, fill in the Rulebook Cold Read form, and share it with that team.
6Build Classes 6 and 7: second attempts
Fix the problems the cold read found, and remake what went wrong the first time. Write every change in your Civ log, with what caused it and the options you considered.
8Build Class 8: full play-through
Play your game from start to finish, using only what is in the box. Record it on the Ciii submission form.
9Build Class 9: finish and hand in
Make final fixes. Then hand in the Ciii submission form, your Cii technical skill sheet with its evidence, and your Civ change log as PNGs.
Every Build Class ends with a five minute log stop, when you write your Civ change log entry.
These are tools you can choose from when you plan your build in Ci. The difficulty is for a Grade 9 student using the tool for the first time. Your teacher will tell you which equipment is available in your classroom.
| Tool | Good for | Difficulty | Cost | Runs on |
|---|---|---|---|---|
| Game Bench | Card layouts, print sheets, dice odds, playtest timing | Easy | Free | Browser |
| Canva for Education | Card and board layout, rulebook pages | Easy | Free for verified K-12 teachers and the students they invite | Browser |
| Google Slides | Cards and rulebook pages at a set page size | Easy | Free | Browser |
| Affinity, by Canva | Print ready layout, vector icons, photo editing | Medium | Free with a Canva account; the AI features need Canva Pro | Mac, Windows |
| Inkscape | Vector icons and boards | Medium | Free | Mac, Windows, Linux |
| Krita | Drawing and painting card art | Medium | Free | Mac, Windows, Linux |
| Procreate | Drawing card art with a stylus | Medium | $12.99, one purchase | iPad only |
| nanDECK | Making a whole deck from a spreadsheet | Hard | Free | Windows |
| Tinkercad | Simple 3D tokens, stands and trays | Easy | Free | Browser |
| Autodesk Fusion | Precise 3D parts, inserts and boxes | Hard | Free education licence for eligible students, renewed each year | Mac, Windows, browser |
| Blender | Sculpted miniatures | Hard | Free | Mac, Windows, Linux |
| The printer's slicer | Preparing a 3D model to print | Medium | Free | The software for your school's printers |
| Tabletop Simulator | Testing a digital copy before printing | Medium | $19.99 on Steam, often $9.99 on sale | Mac, Windows |
| Craft knife, steel rule, cutting mat | Cutting card and board cleanly | Medium | School supplied | In class |
| Bone folder or blunt scorer | Folds and boxes that close square | Easy | School supplied | In class |
| Corner rounder | Card corners that match | Easy | School supplied | In class |
| Greyboard, foam board, card stock | Boards, tiles and boxes | Easy | School supplied | In class |
Prices were checked in October 2026, in US dollars. Check the price before you buy anything.
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. Make a plan for building the game, with the time and resources for every step. Everyone in your team should be able to follow it without asking questions.
- Personal task plan. Make a plan for the tasks you are responsible for. It must be detailed enough that your teammates can help if you are absent.
Part of the task
The peer follow test
The descriptor says your plan must be "sufficient for peers to follow". This means another team could use it. You will test this. Swap plans with another team. They read yours for five minutes, then explain what they would do in Build Class 1 and Build Class 4. Anything they cannot answer is a gap in your plan.
Write down the gaps and improve your plan. Hand in both versions, before and after. Together they show your planning much better than one neat chart.
A plan a peer cannot follow, and one they can
Both plans are for the same team, making a card game with a board. Many teams hand in a plan like the first one before the peer follow test.
Weak: "Make the game"
- Make the cards
- Make the board
- Write the rules
- Test it and fix it
When the other team was asked what they would do in Build Class 1, they could not say who starts, what they use, or what must be finished first. No task has an owner, a time, a resource or a fallback (a backup option).
| # | Task | Owner | Needs # | When | Resources | If not available |
|---|---|---|---|---|---|---|
| 1 | Final card list, 40 cards, in a spreadsheet | Mia | Build Class 1 | Laptop, the Bi specs | Paper list | |
| 2 | Card template at 63 x 88 mm with bleed | Jun | Build Class 1 | Game Bench card layouts | Biv card page, traced | |
| 3 | Draft print of all 40 cards | Jun | 1, 2 | Build Class 2 | Colour printer, 4 sheets card stock | Black and white print |
| 4 | Board, 300 x 300 mm, drawn at 1:2 then full size | Sam | Build Classes 1 to 3 | Greyboard, steel rule, knife | Card stock taped in four panels | |
| 5 | Four page rulebook draft | Ava | 1 | Build Classes 2 to 4 | Laptop, OnePageRules as a model | Handwritten draft |
| 6 | 16 player tokens, 25 mm | Sam | 4 | Build Class 3 | 3D printer, Tinkercad file | Punched card circles |
| 7 | Fix rules from the cold read | Ava | 5 | Build Classes 6 and 7 | Cold read forms | |
| 8 | Box that holds everything | Mia | 3, 4, 6 | Build Classes 6 to 8 | Greyboard, Game Bench box sizes | Card stock tuck box |
The second plan passes the peer follow test. Every task has an owner, what it needs first, a Build Class, what it uses, and what to do if that is not available.
Plan it with the tool
The Ci Build Plan has two A4 landscape pages. The first is the team plan, with an owner, a dependency (a task that must be finished first), a Build Class, resources and a fallback for every task. The second is your own plan, class by class.
One student types the team plan and shares it as a file. The rest of the team loads the file and adjusts their own copy. Download the PNGs before the peer follow test and again after you improve your plan, so you can hand in both versions.
Demonstrates excellent technical skills when making the solution.
You must show technical skill while you make your game. You choose which skills to show, and you provide evidence of your work.
Four skill tracks
Systems and rules design
- Writing rules that survive a cold read
- Balancing the game with numbers, not with feelings
- Designing icons that replace words
- Teaching the game in under five minutes
Graphic design
- Card layout with correct bleed and safe margin
- Text sized for your audience and for reading across a table
- Colour and contrast, including colour blind safe choices
- Artwork that is ready to print
Digital fabrication
- 3D modelling tokens, miniatures, trays or inserts
- Printing well: orientation, supports, tolerance and fit
- Laser etched surfaces and markings
- Designing a part that can be made twenty times
Hand fabrication and finishing
- Precision cutting, scoring and folding
- Mounting, hinging and board construction
- Surface finish, edges and corners
- Making a jig (a guide) so twenty parts come out the same
Requirement
Three skills at depth, across at least two tracks
Three skills done well are better than ten done quickly. You must use at least two tracks, so that your build is more than ten classes at a 3D printer.
For each of your three skills, your evidence shows:
- A dated photo of work in progress, with your hand or initials visible on the part
- A photo of the outcome
- What went wrong, what you changed, and what your second attempt did better
The worksheets
The Cii Technical Skill sheet lists the skills in each track as tick boxes. You choose your three skills, explain why, and name the evidence you will upload for each. It warns you if all three skills come from one track.
The Rulebook Cold Read form is for when you read another team's rules. Fill it in, then share it with that team. Both teams keep the PNG.
Follows the plan to create the solution, which functions as intended and is presented appropriately.
You and your team will follow your plans and finish a game that works. People who did not help make it must be able to play it.
Strongly suggested
The cold read test
Give your box and rulebook, and nothing else, to a team who has never seen your game. They set up and play without any help. You watch in silence and record every question they ask and every rule they get wrong.
It is not required, but it is the best evidence that your game works as intended. It is also practice for Di. Staying silent is the hard part. If you explain anything, your results are no longer useful.
The four page rulebook. Look at OnePageRules for good examples. They fit complete games into a few pages, and fitting so much into a small space is the skill. Clear structure, icons and a worked example work better than long paragraphs.
Hand it in with the submission form
The Ciii Game Submission form is filled in once by your team. It lists every component, who made it and how it was uploaded. It also records one full play-through using only what is in the box.
Fully justifies changes made to the chosen design and plan when making the solution.
| Date | What changed | What triggered it | Options considered | Why this option | Effect on specification or plan |
|---|---|---|---|---|---|
| One row per change. Expect fifteen to thirty rows across the Build Classes. | |||||
A log written the night before is easy to spot
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.
A worked example: Tome of Secrets
Here are six entries from the change history of Tome of Secrets, Mr. K's dungeon crawling card game. They are written the way your log should be. Where several small updates were one decision, they are combined into one entry. The dates and triggers are real. The options considered were written for this example.
| Date | What changed | What triggered it | Options considered | Why this option | Effect on specification or plan |
|---|---|---|---|---|---|
| 23 Sep | The retrieve prompt picks a card from the discard pile, laid out over the board | A fight froze. Reshelve asked for a card to retrieve, but only the hand could be clicked, so nothing could be chosen and the turn could not end | Remove Reshelve; let it retrieve from the hand instead; show the pile and pick from it | Keeps the card working as written, and leaves the other prompts alone | Rules clarity: a card now does what its text says |
| 28 Sep | The shop re-checks a relic at the moment of purchase and shows OWNED instead of a price | A student bought the same relic twice. The second purchase took the gold and gave nothing | Hide owned relics when the shop opens; refund afterwards; check again at the till | Fixes the problem whatever caused it, and the player can see why they cannot buy it | Fairness: no player loses gold for nothing |
| 29 Sep | Relics and vials from a fight are taken automatically. A card reward is still a choice, with Skip | New players walked past the relic and the vial on the reward screen and lost both | A flashing hint; a tutorial step; take them automatically | They were winnings, not decisions, so making the player click them added nothing. The real choices stayed choices | Meaningful choice: a click that was never a decision is gone |
| 29 Sep | Enemy block lasts until the start of the enemy's next turn, the same rule as the hero. The enemy turn plays at 1.5x length | Playtest: an enemy's block vanished before the hero could hit it, so defending meant nothing, and new players could not see what had hit them | Raise enemy health; give enemies more block; change when block expires | One rule for both sides is easier to learn, and it makes defending a real decision | Balance: harder, on purpose. A setting lets experienced players speed the enemy turn back up |
| 29 Sep | The in-game guide was built small: the system and three chapters, with the rest written later | The full guide would have taken the time planned for the next chapters of the game | Delay the guide; build all of it now; build the system and the first three chapters | Anyone can add a chapter later as plain text, without code | Plan: the remaining chapters moved later |
| 30 Sep | A phone layout: larger numbers, a map that drags, and cards you hold to read | On a phone, a number was 5 pixels tall and a card in the hand 70 pixels wide | A separate phone version; shrink everything to fit; enlarge only what carries information | Desktop stays exactly as it was, and only the parts players need to read grow | Accessibility: playable on the devices students actually have |
Each entry has a trigger and the options considered. You will use the last column again in Dii.
Keep it with the tool
The Civ Change Log opens at Ci and runs to the end of Build Class 9. Each entry is stamped with the time you wrote it, next to the Build Class and date you choose. This shows that you wrote it during class.
It warns you if a Build Class has no entry. At the end, download the PNGs (four entries on each page) and upload them to ManageBac.
You will design testing methods that collect real data about your game. Then you will use them with your audience, evaluate your game, suggest improvements and explain its impact.
You will test with your own client group. Each team takes its game to its own client group, the audience from Ai. A larger showcase may happen afterwards, but it is not assessed.
Designs detailed and relevant testing methods, which generate data, to measure the success of the solution.
These testing methods come from user centred research in the IB Diploma Design course: user observation, interviews, focus groups, questionnaires, user trials, personas and scenarios. Learning them now will help you if you take Design in the Diploma Programme.
The core requirement
Naming a method is not designing one
The descriptor asks you to design methods that generate data. Writing "I will use a questionnaire" does neither. You must hand in the instruments, the actual tools you will use to collect data:
- The questionnaire, with the real questions in order
- The observation sheet, showing what you will count, and how
- The interview script, with your questions and follow-up questions
- The user trial protocol (the steps of your test), showing what is timed or counted, and by whom
| Which specification | 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 |
Match the method to the specification
Many students use a questionnaire for everything. Playtime needs a stopwatch, not an opinion. Rules clarity needs you to watch for mistakes in play, not to ask whether the rules were clear, because everyone says yes. Meaningful choice needs the explain back test, because players cannot easily judge whether their own decision mattered.
One specification, four test plans
You will look at these in the first Di class. All four plans test the same specification: rules learnable in one recess, measured as a new group starting to play within 8 minutes.
| Level | The test plan | What is missing |
|---|---|---|
| 1-2 | We will ask people if the rules were easy. | No method beyond a question, no participants, no data and no threshold. It cannot tell whether the specification was met. |
| 3-4 | Questionnaire after playing. Question: were the rules clear? Answer 1 to 5. Success if most people say 4 or 5. | A method and a threshold, but a questionnaire cannot measure time, and players who were confused often still answer kindly. |
| 5-6 | Timed user trial. A group of 4 who have never seen the game get the box. Start the stopwatch when they open the rulebook and stop it at the first turn. Success: under 8 minutes. | The right method and a real threshold, but one group, and no record of why it was slow. |
| 7-8 | Timed user trial with three groups of 3 or 4 from the client audience, none of whom have seen the game. Stopwatch from opening the rulebook to the first turn, plus an observation sheet tallying every question asked and every rule misread. Success: all three groups under 8 minutes, with no more than two questions each. Quantitative data for the time, qualitative for the reasons. |
What you will do in each class
1Good and bad test plans
Look at the four plans above and match methods to specifications as a class. Then decide which method each of your six specifications needs, and why.
2Build the plan and the instruments
Build your test plan in the Di tool. Then write your instruments: the real questions, the observation sheet and the trial protocol.
Build the plan with the tool
The Di Test Methods tool shows your six specifications, plus two spare boxes. Drag a method onto a specification as many times as you need. Then fill in who takes part, the type of data, the instrument and the success threshold for each.
It warns you if a specification has no method, or a method has no threshold (the result that counts as success). The Dii tool reads your plan, so its test column fills in automatically.
Observation sheet
The Gameplay Observation sheet is made to print. Use one sheet for each group you watch. It records timings, a tally of what players do, explain back answers and quotes. You will use it again in the Dii sessions.
Formative · 20 min: five bad questions, fixed
Each bad question is shown beside a better one. First, work out what is wrong before you look at the middle column. Then write five questions for your own game, swap with a partner, and fix each other's questions.
| Bad question | What is wrong | A better question |
|---|---|---|
| Don't you think the game was fun? | Leading. It tells the player the answer you want. | What part of the game would you change first, and why? |
| Were the rules clear and the game the right length? | Double barrelled: it asks two questions but gets one answer. | Ask them apart: Which rule did you have to ask about? How long did the game feel: too short, about right, or too long? |
| Did you like it? | Vague: a yes answer does not tell you what to change. | Would you choose to play this again at lunch next week? Yes, maybe or no. |
| Would you buy this game? | Impossible to answer honestly. Your audience is not buying games. | If this game were in the library, would you borrow it? Why or why not? |
| Rate the game from 1 to 10. | No clear scale: a 7 means something different to everyone. | How easy was it to learn? 1, I could not learn it, to 5, I learned it in one turn. |
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.
1First session with the audience
Your team takes the game to your client group. You each use your own Di instruments and collect your own data. Do not help the players understand the rules, because that is what you are testing.
2Second session with the audience
Use the same instruments again with your audience, so your results do not depend on one session. Write down anything that was different the second time.
3The evaluation
Evaluate every specification from Bi, one row each, in order. Do not skip the ones your game did not meet.
| Specification | Test used | Data collected | Met / partly / not met | Evidence | What this means |
|---|---|---|---|---|---|
| One row per specification, all six of them. | |||||
What "critically" looks like
The limits of your own evidence
End with a section about why your data might be wrong. For example, you may have had only a few testers, only one session, or testers who knew you and wanted to be kind. Also look at the difference between what people said and what they did.
If you say a specification was met with only three testers, and admit that this is not much evidence, you show better judgement than someone who claims to be certain.
Evaluate with the tool
The Dii Evaluation sheet has one row per specification and a closing box for the limits of the evidence. If you used the Bi and Di tools in the same browser, your specifications and test methods fill in automatically. You can still edit every field.
Formative · 15 min: met, partly met, or not met
Many students say a specification was met when the evidence is not strong enough. Read each case and decide: met, partly met or not met. Explain your choice out loud, then open the case to check.
1Setup to pack away under 25 minutes. Three groups took 22, 24 and 31 minutes.
Partly met. Two of three groups were under the limit. The slow group learned the rules with no help, which is how the game will really be played. So that result matters more than the average.
2Testers can explain why they chose, in 4 of 5 sampled turns. Across two sessions, 18 of 20 sampled turns were explained.
Met. 90 percent is above the 80 percent threshold, and the result was the same across two sessions.
3At least 7 of 10 testers choose to play a second round. On the questionnaire, 9 of 10 said they would play again. When a second round was offered, 3 of 10 stayed.
Not met. The specification is about what testers choose, and what they did matters more than what they said. Mention the questionnaire in your limits section, not in your verdict.
4No card text below 9 pt. Measured: every card is 10 pt except the four reference cards, which are 8 pt.
Not met. It is tempting to say partly met, but the specification says no card. Four cards fail. The fix is small, but it belongs in Diii, not in your verdict.
5A new group starts playing within 8 minutes, tested with three groups. One group was tested, and it started in 6 minutes.
Partly met. The one result passed, but the test plan needed three groups. Say that the threshold was met once, and explain why the other two tests did not happen.
6Materials cost under $15 a copy. The bill of materials comes to $12.40.
Met. The measured cost is under the limit. Some specifications are simple to judge.
Explains how the solution could be improved.
You will explain how your game could be improved, using the evidence from your Dii evaluation.
| 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 must come from a specific Dii finding. An improvement with no evidence is only an opinion, and opinions do not count as evidence for this strand.
- Include one improvement for something that passed. Meeting a specification does not mean it is as good as it could be. Noticing this is part of a 7-8 answer.
Write it on the worksheet
The Diii Improvements sheet has five ranked rows. Each row is linked to a specification and its Dii result. If you used the Bi tool in the same browser, your specification names fill in automatically. You can also print it and write on paper.
Explains the impact of the product on the client/target audience.
Impact is not "satisfaction"
"They enjoyed it" is a Dii result about a specification. Impact asks a different question: what did your game change for the people it was made for, and for the people around them?
Div is the final assessment of the unit. You will write it by hand in one class, after your audience has played your game. You will evaluate how your game was received and what it changed. Use your earlier work: the need statement from Ai, the data from Dii and the improvements from Diii.
Six things to cover
- Who was affected, including people beyond the players themselves.
- What you planned compared with what happened, quoting your Ai need statement.
- Evidence from playing with your audience: quotes, observation tallies, and what people did, not only what they said.
- Effects you did not plan, good and bad. Did quieter students join in more? Did the reading level, the language or the hand skills needed leave anyone out?
- Wider impact on at least two of these: the school, families, materials and waste, cost, or how well it suits players from different languages and cultures.
- Was the original need met? Answer clearly: yes, partly or no, with reasons.
Thirty three assessed classes, one launch, and two held in reserve. The nine Build Classes are 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, 6 testable lines |
| 9 to 11 | Bii | 3 annotated concepts, brainstorming, interpretation test list |
| 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 | Introduction and skill clinics | Rotating stations, no submission |
| 19 to 27 | Build Classes 1 to 9 | Cii skill evidence, Ciii the game, Civ change log. Rulebook cold read in Build Class 5 |
| 28 to 29 | Di | Test Plan with instruments built |
| 30 to 31 | Dii, sessions | Two sessions with the audience, data collected |
| 32 | Dii, evaluation | Point by point against every spec |
| 33 | Buffer | Catch up before Diii |
| 34 | Diii | Ranked improvements |
| 35 | Div | Impact evaluation, handwritten in class |
| 36 | Reserve | Slack, or the broader showcase |
-
Glossary
MYP Design Glossary
Every coloured word on this page has an entry: the command terms in the descriptors, design terms and the game design words. Hover a coloured word to read it here, with a Chinese translation beside the English when you switch it on.
-
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.