Learning Dimensions

This post is part of a series reflecting on my PhD, which explored how collaborative game making can support learning and agency in non-formal settings. The full thesis traces the development of a learning environment built around participants creating their own games, and how this design evolved in response to tensions that emerged in practice. If you want the full academic account, you can read the first part of Chapter 6 of the thesis.

In this post, I focus on one particular moment in that process: an attempt to map what learners were actually learning, and a growing realisation that this way of seeing, while useful, didn’t quite fit the activity it was trying to describe.

This post picks up on an earlier attempt I made to answer a question that kept coming up in the project: if this feels like good learning, how can I make sense of what is actually being learned? It outlines the evolution of a map of learning dimensions which is referenced in Chapter 6, but here I want to reflect more openly on how it emerged, and the tensions it exposed.

As I reviewed the recorded sessions, I began to list the different kinds of learning I could see in the game making process. Some of these fitted familiar computational thinking categories, such as abstraction, decomposition and pattern recognition. Others were more specific to game making, including systems patterns, design practices and technical habits such as debugging, remixing and code patching. The table below is my attempt to bring those strands together.

The systems patterns were important because games are not just sequences of code. They are interactive systems where rules, feedback, difficulty, and player action affect each other. This map is not meant to be final or universal. It reflects what I noticed in this particular project, and it would be strengthened by being tested and adapted with other teachers, facilitators, and learners.

Computational thinking	Coding concepts	Systems patterns	Design and technical practices
Abstraction	Sequences	Systems elements	Goal setting
Decomposition	Variables	Systems dynamics	Being incremental and iterative
Pattern recognition	Logic	Reinforcing feedback loops	Developing vocabulary
Algorithmic thinking	Loops	Balancing feedback loops	Web literacy (as a subset of digital literacy)1
	Arrays		Code patching
	Creating functions		Version control
	Change listener		Debugging
	Input event		Reusing and remixing

However, creating the map raised another question: should these concepts be introduced directly to learners, or should they remain in the background as something facilitators use to interpret the activity?

Tension: teaching concepts vs keeping flow

In another post, I noted that I leaned towards abstract concepts in this mapping. In my journal, I kept returning to a tension around whether to introduce computational thinking concepts explicitly, or to leave them embedded within the activity. Stepping in to explain concepts risked interrupting the flow of making, while leaving them implicit made them harder to recognise.

In practice, I tended to prioritise the activity itself, noticing that learners were often reluctant to step away from coding, testing, and play. This raised a broader concern about adding competing goals, particularly when participants were already shifting between designing, implementing, and refining their games.

The map of learning dimensions reflects this tension. In my setting, I rarely made direct use of it with participants, as there was no requirement for them to do anything beyond engage in the creative process. Here, though, I want to explore how it might be used to surface and connect these concepts without disrupting that activity.

The map makes visible a range of concepts that can emerge through the activity, without requiring them to be foregrounded. In this sense, it can also support the facilitator in noticing and drawing attention to these concepts as they arise. The challenge then becomes how to notice and build on them without disrupting the flow, something I return to later in the series.

Why learning maps can help

If you’ve ever tried to make sense of what students are learning in an open-ended project, these tensions will probably feel familiar. Balancing freedom and structure, deciding when to step in, and working out how to connect hands-on activity to underlying concepts are everyday concerns for teachers and facilitators. What’s interesting is that these are not just practical problems, they are also well recognised in research. Across computing education and learning sciences, there is a long-standing effort to develop ways of making learning visible without closing down the exploratory nature of making.

The idea of mapping learning is not new. Concept maps have been widely used in computing education as a way of identifying and organising key ideas within project work². I was particularly inspired by the work of Bevan and Petrich, who analysed video of families engaging in hands-on activities and developed a map of learning dimensions that included both conceptual understanding and more general practices involved in making³.

In this project, the map served a similar purpose. It provided a way of identifying and naming the kinds of learning that were taking place within what could otherwise appear as a messy and open-ended activity.

This becomes especially useful in settings where learners are following different pathways. Choice-based project work can make it difficult for teachers to track what is being learned, as students may be working on different features or problems at any one time⁴. A map like this offers one way of connecting those diverse activities back to underlying concepts.

At the same time, there is a tension in how such a map is used. In more formal settings, it could support planning and reflection, helping to link concrete activity with more abstract ideas. However, introducing it too directly into the activity risks shifting the focus away from making itself.

This tension reflects a broader issue sometimes described as a “play paradox”⁵, where the conditions that support open-ended exploration can make conceptual learning harder to identify. In this sense, the map is perhaps most useful not as a tool for directing activity, but as a way of recognising and connecting learning that is already taking place.

What this looks like in practice

The value of the map becomes clearer when you look at moments of activity rather than the full list of concepts.

For example, pattern recognition often emerged without being explicitly taught. In one instance, a participant adapted movement code that controlled left and right input to instead work for up and down movement. Through testing and iteration, they recognised a pattern in how input affected behaviour and applied it in a new context.

Other concepts appeared in similar ways. Parents would help break down problems into manageable steps, for example suggesting “save that for version 1.1”, which reflects decomposition. Debugging often led to discussions about sequencing, particularly when small errors broke the game.

What matters here is not whether these concepts were formally taught, but that they arose through the process of making. The map helps to notice these moments and, where appropriate, draw attention to them. At the same time, these examples reinforce the earlier tension. Stepping in too early to name or explain concepts risks interrupting the activity that produced them in the first place.

In practice, this kind of map could be used lightly after a session, as a planning or reflection tool. A facilitator might look back at what learners chose to do, identify which concepts appeared, and use that to decide whether to introduce a short prompt, question, or resource next time. The point is not to turn the activity into a checklist, but to help connect learner-led making with concepts that might otherwise remain hidden.

Where this led

Looking back, the map of learning dimensions helped me to see what was happening, but it didn’t help me work with it. It sat slightly outside the activity, translating it into concepts that made sense in formal terms, but didn’t really shape the way learners engaged with the process itself.

What I began to realise was that I didn’t just need a way of describing the potential learning that could be squeezed out of the activity, I needed something that could sit within the activity itself, something that learners were already using as part of making their games, and that could carry both the concrete experience of building something and the more abstract ideas that might travel beyond it. That realisation is what led me back to something that had been there all along, the growing collection of gameplay features that participants were choosing, adapting, and sharing.

If you want to read about that next have a look at either: How gameplay design patterns became a vital part of the project - or this post on Diverse uses of gameplay design patterns

Footnotes