How Gameplay Design Patterns (GDPs) became a vital part of my PhD thesis

This post comes out of a PhD project where I worked with families making their own video games together, in a setting that was closer to a collaborative workshop than a traditional classroom.

This post tells the story of how gameplay design patterns (GDPs) became the kernel around which my PhD thesis took shape. I did not start the project with this idea. They emerged from the messiness of trying to meet the needs of my learners, as a growing set of features people could add to their games, for example enemies, scoring, timers, and movement.

My research process was very exploratory and responsive to the needs and ideas of participants. I threw myself into it with a brave group of home educating families. The initial phase of research was like a collaborative game making lab where we were trying out tools, taking some on and discarding others. After this initial phase, the process settled into a starting set of resources, an incomplete game, and participants could choose to add their own features to it. Over time, the code solutions and the supporting documentation built up into a library that others could draw on.

The learning process worked well. It felt good. Students and parents were learning coding together. They were interacting extensively and having fun. In practice, it felt less like delivering a curriculum and more like a jam session. There was a loose structure and a shared starting point, but what actually happened emerged through people trying things out, responding to each other, and building on ideas in the moment. The gameplay features that became GDPs were like riffs, picked up, modified, and passed around.

At this stage, I found myself returning to a question I had come across in this area: “It looks like fun, but are they learning?” It’s a reasonable question, and one that comes up often in discussions of informal and exploratory learning. Work by Bevan and Petrich¹, which is where the phrase comes from, offers frameworks for identifying dimensions of learning such as engagement, intentionality, innovation and solidarity. That kind of approach makes it possible to point to evidence and say, yes, something valuable is happening here.

But for me, this question also carried a different weight. It felt like a kind of internalised checkpoint, a voice asking me to justify the work in terms that would be recognisable to formal education. A kind of “cop in the head” that pushed me to translate what was happening into established categories. As a result, when I began to map some of the dimensions present in the data from the recorded sessions, the resulting learning dimensions here, the framework I produced, while including some of the design and social processes at play, was skewed toward more abstract knowledge or concepts that would make up a curriculum. This process was a marker of an underlying tension. The more I tried to frame the activity through a formal learning perspective, the more I felt it drifting away from the motivations that had shaped the learning experience in the first place.

Tension

On one hand, mapping the concepts highlighted in discussions of computational thinking [^wing] gave me a way to account for what was happening, reassuring me that the educational experience fit within established frameworks of valuable concepts, so-called powerful, abstractable knowledge that could be transferred to other domains. This kind of framing has been used to advocate for including computer coding in school curricula and wider programmes. However, the assumption that such knowledge transfers easily has been questioned, and in practice felt less certain within these sessions.

At the same time, this focus did not really fit my own setting or the underlying ethos of this research. Instead, I was much more drawn to the work of Papert and Turkle, who promoted the value of hands-on, tinkering approaches ². It was immediately accessible and fun in spirit. It stood in contrast to some of the theory-first approaches to learning coding that I had seen discourage students in school contexts.

The tension here stemmed from my sensitivity to the learner’s experience in this setting. If you push too far towards abstract concepts, it becomes hard for learners to relate them to what they are actually making. But if you stay entirely at the level of concrete activity, it becomes difficult to connect that work to wider ideas that may help learners develop as coders and creators more generally.

Looking back, while the process of mapping learning dimensions in this way created some interesting outputs, I was missing a more obvious way to orient conceptual learning, one that was already present in the activity itself, but not yet recognised as such.

Resolution

I realised that rather than selecting and shoehorning in external frameworks of abstraction, forms of abstraction were already present within the learning design, and learners were already using them extensively. Rather than a fixed choice between abstract and concrete, what became more important was that learners had the possibility to move between the two.

As I retraced my steps by re-examining the research landscape on game making, I came back to work on computational design patterns from Repenning and his team in the Scalable Game Design programme³. The patterns in this context were more concrete than computational thinking concepts, yet still abstract enough to be useful in other contexts. In that work, teachers report that these patterns were more accessible than more abstract computational thinking models, partly because they were grounded in recognisable behaviours and often aligned with natural science contexts rather than drawn directly from video game experience.

At this point, I made a connection between the menu of design features I had co-created with participants and the concept of design patterns. While the design features I had developed with participants were focused more on tangible gameplay experiences rather than abstract concepts, they were similar to the kind of design patterns that I had encountered in my Masters computing studies. They were practical, replicable in different games, bundled with a suggested code solution, and importantly, socially oriented, to be used as part of an evolving community of practice.

Something clicked. This was an important breakthrough: the use of game design patterns as both a conceptual framework and a pedagogical tool. Shortly afterwards, I found the work of Steffan Björk and colleagues ⁴, which also used a collection of gameplay design patterns to guide the modification of games. It was reassuring to find an academic precedent. Importantly, my own research was able to add to this work through its focus on text-based coding, and by providing evidence of how GDPs were being used by participants in varied ways.

Their framing as a collection of design patterns was also important in shaping how I started to present these resources, as a design repository that learners could draw on. As shown in the figure above, I had already designed and implemented the programme’s resources as a collection page structured like a menu of gameplay design patterns that students could choose from to add to their starting game template.

Once that clicked into place, it became increasingly useful as a point of connection between academic theory, practitioner planning and learner experience. I started to connect this intuitive design feature of the emerging learning design with relevant research from both computing education and broader socio-cultural traditions.

But I still needed a way to get past my mental wrestling with how my learning design interacted with concepts related to teaching computational thinking and systems thinking. What I had at this point was a strong intuition that gameplay design patterns mattered, but not yet a clear way of describing what they were doing. The next step, then, was to try to understand this more directly, to explore how gameplay design patterns might act as a bridge between abstract ideas and concrete making.

Related posts

If you want to find out more, there are a couple of directions you could take. In the next post, I pick up on this directly, exploring how gameplay design patterns act as a bridge between abstract concepts and concrete making. If you are more interested in how participants actually used these patterns in practice, you can also jump to this post on their diverse uses.

For a broader sense of where this approach comes from, you might also find it useful to read Choice and Mess, which explores the learner-led origins of this work, and Learning Dimensions, which reflects on an earlier attempt to make sense of what was happening in the sessions described here.

Footnotes