BlockCode Journey
Exploring programming concepts through a tangible, physical learning game
MSc Coursework
01 — Project Overview
BlockCode Journey started with a simple question: what happens when programming logic is taken away from the screen and turned into something people can physically build and test?
I explored this through a tabletop game where players arrange physical blocks to create a path for a ball. Instead of writing instructions on a screen, players construct a sequence, release the ball, and see whether their decisions lead it to the destination.
The project became an exploration of how ideas such as sequence, constraints, iteration, and cause-and-effect could be represented through physical interaction.
My Role
I developed the concept independently, from exploring references and mapping programming ideas into physical interactions to designing the game levels, modelling and 3D-printing the components, building the prototype, and testing how the interaction worked in practice.
Project Information | |
|---|---|
Course | Mastering Tinkering |
Institution | University of Twente |
Programme | MSc Interaction Technology |
Tools | Figma, Fusion 360, 3D printing |
02 — From Code to Physical Actions
I started by thinking about what happens when programming instructions are turned into physical actions: something happens first, another action follows, and the result depends on how those actions are arranged.
I became interested in what would remain if those instructions were no longer written as code.
Looking at Scratch and Blockly helped me think about programming as smaller pieces that can be arranged into a sequence. RoboRally introduced another useful idea: instructions can be planned first and their consequences become visible afterwards.
I took these ideas as a starting point for exploring physical sequencing, rather than recreating either system.
The challenge became finding an interaction where players could construct a sequence and then see the consequence of what they had built.
03 — The Design Question
How might programming logic be represented through physical actions rather than written code?
I did not want the interaction to become a physical version of a programming interface, where blocks simply replaced commands on a screen.
I wanted the physical behaviour itself to carry part of the logic.
This led me to experiment with a board, modular pieces, and a moving ball. The player would not tell the ball where to go directly. Instead, they would arrange the environment around it and observe what happened.
That distinction became important to the concept: the arrangement is the instruction, and the movement of the ball is its consequence.
04 — Translating Logic into a Physical Puzzle
The first concept used a Lego-like board where players could place different pieces to construct a route between a starting point and a destination.
I chose a ball because its movement makes the result visible. Once released, the player cannot simply correct the sequence midway. If the arrangement does not work, they can see where it fails, change the configuration, and try again.
This created a simple cycle:
Build → Run → Observe → Adjust
At this stage, I was not trying to reproduce an entire programming language. I was exploring which ideas could actually be represented through the behaviour of the physical system.
What translated most clearly
Sequence
The order and position of the pieces affect what happens next.
Cause and effect
Changing one part of the route can change the outcome of the whole sequence.
Constraints
Obstacles and limited pieces restrict which solutions are possible.
Iteration
An unsuccessful route can be inspected, changed, and tested again.
I initially connected the concept to other programming ideas such as input/output and conditional logic. Looking back, however, these were not represented as clearly in the prototype.
I would therefore treat them as directions for further development rather than outcomes demonstrated by this version.
05 — Designing the First Levels
Before producing the physical pieces, I mapped the game in Figma.
I designed two initial levels with different purposes.
The first kept the board relatively open. This allowed me to work through the basic interaction: where the ball begins, how pieces connect, and how a player could construct a complete route before introducing additional constraints.
The second introduced obstacles and fewer obvious routes. Here, the arrangement of the pieces became more important because the player needed to work within the available space rather than simply connect the start and finish.
Creating the levels helped me see that difficulty could come from the relationship between the board, available pieces, and constraints, rather than from adding more instructions.
06 — Moving from Screen to Physical Prototype
Once I had mapped the interaction on screen, I began translating it into physical components.
I modelled the pieces and produced them through 3D printing so I could test their dimensions, placement, and behaviour on the board.
This stage exposed things that were difficult to judge in Figma.
A route that looked clear in a 2D layout still had to work with gravity, the dimensions of the pieces, the movement of the ball, and the way components connected to the board.
The physical prototype therefore became more than a representation of the design. It became a way of finding problems in the design.
07 — Testing the Interaction
Testing focused primarily on whether the physical system behaved as intended.
I observed how the ball moved through different arrangements, whether the pieces guided it consistently, and whether the levels could actually be completed with the available components.
When something failed, I could trace the problem through the route: a piece might need a different angle, a connection might interrupt the movement, or a level might need another configuration.
This gradually changed how I thought about failure in the game. Because the outcome was visible, an unsuccessful attempt could become part of the interaction itself: observe what happened, change something, and run it again.
What this testing did not establish was whether playing BlockCode helped someone understand programming concepts. The prototype allowed me to explore the physical interaction, but evaluating learning would require a different study with learners.
08 — What the Project Made Me Question
BlockCode began with the idea of making programming concepts physical. By the end, I became more interested in a slightly different question.
The prototype asks players to plan, observe consequences, identify where something went wrong, and try another configuration. These behaviours resemble parts of programming and debugging.
But resemblance is not the same as learning.
Someone might become very good at solving BlockCode while thinking entirely about slopes, paths, and the movement of a ball rather than programming.
That distinction is something this project did not answer.
What I would explore next
I would test the game with people who are beginning to learn programming and look beyond whether they can complete the levels.
I would want to understand how they explain what they are doing.
Do they recognise sequence and cause-and-effect in the interaction? Can they connect what happens on the board to similar ideas in programming? And does that connection remain when they later encounter those concepts on a screen?
I would also revisit conditional logic. Rather than labelling an existing physical behaviour as a “condition,” I would explore how a component could genuinely behave differently depending on an input or state.
That would make the relationship between the physical interaction and programming logic more explicit.
09 — Reflection
Before this project, most of my design experience had been with digital interfaces. BlockCode forced me to think differently because I could no longer control every outcome through a screen.
The dimensions of a piece, the angle of a surface, gravity, friction, and the movement of the ball all became part of the interaction.
It changed how I thought about prototyping. Making was not simply a way to realise a design I had already decided on; it became part of how I thought through the interaction.
The project also made me more careful about the assumptions I build into a concept. Designing an interaction that resembles a learning process does not necessarily mean that learning is taking place.
That is something I would rather investigate than assume.
