Learning evidence
A playable prototype, design intention, user test, error log and second version
LEARNING PATHWAY
Creative Coding and Game Design
Combines patterns, animation, physics, events, state machines, level design, sound, user testing and accessibility in a creative-coding cycle.
CENTRAL QUESTION
How do you turn code, visuals, sound, interaction and game rules into an original and accessible experience?
Completion evidence for this pathway is a playable prototype, design intention, user test, error log and second version. Page count or time spent alone does not demonstrate competence.
The intended capstone is a small one-mechanic game or interactive artwork with an alternative control and readable feedback. It should connect the lessons in one artefact and retain failed tests as evidence.
Capstone
A small one-mechanic game or interactive artwork with an alternative control and readable feedback
Return trigger
When a new player test, control method, level, visual or sound asset, or accessibility comment arrives.
LESSON MAP
14 items from concept to evidence
Accessible Game Design
Lesson · Accessible game design provides perceivable information, flexible controls, readable feedback and adjustable challenge without removing meaningful play. Th
Open page →Controlled Surprise with Randomness
Lesson · Randomness becomes a design material when its range, distribution, seed and constraints are chosen intentionally. This lesson includes a worked example, pr
Open page →Creating Patterns and Visuals with Code
Lesson · Patterns created with code emerge from repeated rules, coordinate transformations, colour relationships and controlled variation. This lesson includes a wo
Open page →Difficulty Balance and Player Feedback
Lesson · Difficulty balance aligns challenge, player skill, feedback, recovery and pacing through observation rather than guesswork. This lesson includes a worked e
Open page →Game Goals and the Core Gameplay Loop
Lesson · A core gameplay loop describes the repeated sequence of player action, system response, feedback and new decision. This lesson includes a worked example, p
Open page →Game States and State Machines
Lesson · A state machine makes game behaviour explicit by defining valid states, events, transitions and actions. This lesson includes a worked example, practice ta
Open page →Interaction with Keyboard, Mouse and Sensors
Lesson · Interactive systems map keyboard, pointer or sensor input to state changes, feedback and accessible alternatives. This lesson includes a worked example, pr
Open page →Level Design and Playtesting
Lesson · Level design arranges space, goals, obstacles, teaching moments and checkpoints to guide attention and decision-making. This lesson includes a worked examp
Open page →Project: A Mini Game That Teaches Robotics Concepts
Project · This project builds a mini game that teaches a robotics concept through decisions, feedback and repeated application rather than a text-heavy quiz. This le
Open page →Project: An Interactive Story About Online Safety
Project · This project creates an interactive story about online safety in which choices reveal evidence, consequences and recovery steps. This lesson includes a wor
Open page →Project: Digital Art Driven by Sensor Data
Project · This project turns live sensor values into changing visual or sound parameters while keeping calibration, privacy and artistic intention visible. This less
Open page →Scoring, Progression and Rewards
Lesson · Scoring and progression should communicate learning or mastery without rewarding repetitive, unfair or harmful behaviour. This lesson includes a worked exa
Open page →Sound, Rhythm and Animation
Lesson · Sound, rhythm and animation can share a timing system that connects beats, frames, easing and expressive change. This lesson includes a worked example, pra
Open page →Creative Coding and Game Design Quiz
Quiz · A 12-question interactive assessment for Creative Coding and Game Design, with explanations and a newly shuffled option order on every start. This lesson i
Open page →FOUR-WEEK PLAN
Place lessons in a production cycle
No week closes with reading alone. Use one session for concept and example, a second for practice, and a short third session for testing and explanation. Do not accelerate when a prerequisite is missing.
| Week | Focus | Evidence to produce |
|---|---|---|
| 1 | Accessible Game Design, Game Goals and the Core Gameplay Loop, Project: A Mini Game That Teaches Robotics Concepts, Sound, Rhythm and Animation | A playable prototype, design intention, user test, error log and second version |
| 2 | Controlled Surprise with Randomness, Game States and State Machines, Project: An Interactive Story About Online Safety | A small one-mechanic game or interactive artwork with an alternative control and readable feedback |
| 3 | Creating Patterns and Visuals with Code, Interaction with Keyboard, Mouse and Sensors, Project: Digital Art Driven by Sensor Data | Error log and second version |
| 4 | Difficulty Balance and Player Feedback, Level Design and Playtesting, Scoring, Progression and Rewards | Quiz result, misconception and next application |
COMMON TRAPS
They look fast but weaken learning
- Mistaking visual effects for game mechanics
- Using assets without a licence
- Treating speed and colour changes as an accessibility test
- Confusing player error with design error
DEEPENING
Deepening evidence in Creative Coding and Game Design
The pathway's distinctive question is: How do you turn code, visuals, sound, interaction and game rules into an original and accessible experience? A first response may be a definition, but completion requires a playable prototype, design intention, user test, error log and second version. If input, method, limits and review date are unclear, the result is not traceable even when it looks strong.
Start with two different activities among Game States and State Machines, Accessible Game Design, Interaction with Keyboard, Mouse and Sensors, Creating Patterns and Visuals with Code. In one, explain the concept in your own words; in the other, perform an application, measurement or user test. The two activities should not close with the same type of evidence. This distinction shows that Creative Coding and Game Design has been tested through different forms of production.
Later connect Controlled Surprise with Randomness, Sound, Rhythm and Animation, Level Design and Playtesting, Difficulty Balance and Player Feedback to the capstone: A small one-mechanic game or interactive artwork with an alternative control and readable feedback Keep failed tests as well as successful ones. For every error, record conditions, expected result, actual result, possible cause and the single change made.
Check these traps separately: Mistaking visual effects for game mechanics; Using assets without a licence; Treating speed and colour changes as an accessibility test; Confusing player error with design error. Reading a trap is insufficient; find an example from your own work and state which evidence made the problem visible.
Return rule: When a new player test, control method, level, visual or sound asset, or accessibility comment arrives. Do not delete the previous record; add a date, changed tool or source, new evidence and the next mini trial. Progress is therefore tracked through the quality of explanation, application and correction—not the number of pages completed.
MICRO QUIZ
Test the reasoning behind the module
1. How do you turn code, visuals, sound, interaction and game rules into an original and accessible experience?
The answer must produce evidence, not only a definition: A playable prototype, design intention, user test, error log and second version.
2. What should happen to the first failed test?
Keep it with conditions, expected result, actual result and the correction.
3. Does reading a source prove that practice occurred?
No. Sources define method and limits; practice evidence must be produced separately.
4. When should the module be reopened?
When a new player test, control method, level, visual or sound asset, or accessibility comment arrives.
5. What does the capstone connect?
A small one-mechanic game or interactive artwork with an alternative control and readable feedback
OFFICIAL / PRIMARY SOURCES
Verify technical detail in current sources
Scratch Educators
Primary or institutional source for method and technical limits.
Open source →p5.js Tutorials
Primary or institutional source for method and technical limits.
Open source →WCAG 2.2
Primary or institutional source for method and technical limits.
Open source →