Check your starting point
- I can sequence actions and explain a choice.
- I can draw a simple storyboard.
- I can distinguish a story outcome from evidence about real people.
If one item feels unfamiliar, revisit these foundation missions:
FROM AN AVATAR TO AN INTERACTIVE WORLD
Creative computing & stories
Make the EaseBrain crew’s decisions playable through events, variables, branching and user testing.
Make a first version.
START: club budget = 100; waterFixed = false CHOICE: repair water (60) OR reading corner (40) IF chosen cost > budget: explain and offer another choice ELSE subtract cost and show the consequence IF repair chosen: waterFixed = true ENDING: show remaining budget and an unresolved need RESTART: reset every variable to its initial value
Copy this into your chosen tool or trace it on paper. Do not enter passwords, private learner data or API keys.
Storyboard a consequential choice
A story becomes interactive when the player’s action changes what follows. Decorative buttons with the same outcome do not create a meaningful decision.
Build & try
Draw three scenes: the crew discovers a need, chooses under a 100-token constraint, and sees an outcome. Give each choice a benefit, a cost and an unresolved issue.
Show that it works
You can trace at least two different paths with different consequences.
Map events to actions
Events start behaviour: a click, key press or a new scene. A sprite represents an actor or object. Keep story text available so understanding does not depend on sound.
Build & try
Build the scenes in Scratch or as a simple browser story. Use drawn placeholders or the academy crew as visual inspiration. Add labelled buttons or clearly explained keys.
Show that it works
A new player can begin without your voice instructions, and the story is understandable without audio.
Use variables and conditions
A variable can track budget or state. A condition prevents an impossible choice. Validation matters in stories too: a budget should not silently become negative.
Build & try
Implement the starter logic. Test repair then reading, reading then repair, and repeated repair. Prevent buying the same completed repair again, or deliberately explain a maintenance cost.
Show that it works
Every available action has a coherent consequence; impossible or repeated choices are handled explicitly.
Reset the whole state
A restart bug happens when the scene resets but old variable values remain. A state table lists what must return to its initial value.
Build & try
List scene, budget, completed actions and score if used. Play two full runs, restarting between them. Check that the second run begins identically to the first.
Show that it works
Budget and completed actions reset, with no hidden advantage from a prior run.
Playtest for understanding
Usability evidence comes from observed behaviour. A player enjoying the visuals does not tell you whether choices, controls or consequences are clear.
Build & try
Ask a supervised reviewer to explain a choice and reach an ending without hints. Record one confusing moment. Improve text, control labels or pacing and repeat the task. Avoid flashing effects and colour-only instructions.
Show that it works
Your revision addresses an observed issue and you credit any reused art or code.
Create an independent story
Transfer changes the problem while keeping the underlying method: events, state, conditions and tests. Narrative outcomes are simulated, not predictions of actual communities.
Build & try
Make a new crew story about a missed deadline, a research claim or a resource trade-off. Include two endings, a restart, a test log and credits. Export the project or record evidence for your portfolio.
Show that it works
Another player can operate it, explain a trade-off and reproduce your restart test without a paid animation service.
Make the idea your own.
Choose a twist. Use paper, a sketch or a conversation.
Optional practice. Copy useful observations into your workbook; choosing a twist does not record completion.
Compare ideas with someone you know. Sharing is optional.