Diverse mediational uses of Gameplay Design Patterns

Opening

This is a follow-up to my earlier post on how gameplay design patterns emerged in the project. There, I explored how GDPs helped me think about the relationship between abstract concepts and concrete making. Here, I want to shift focus slightly and look at how GDPs worked in practice, as resources that learners and facilitators could actually use.

One important part of this was presentation. I had already designed the project resources as a collection page, structured like a menu of gameplay features that learners could choose from and add to their starting game template.

Once the value of GDPs clicked for me, I realised I was dealing with a familiar design problem: how do you capture solutions that come up again and again, without turning them into rigid rules?

That is what design patterns try to do. They come originally from architecture, and have since been used in software and education as ways of sharing adaptable solutions to recurring problems. In this post, I want to focus on how GDPs became more than a set of ideas. They became a shared resource for planning, making, navigating, and collaborating.

From individual learning to shared practice

The collective aspect of design patterns became increasingly important as the project developed. What initially appeared as a way of supporting individual learning began to take on a broader role within the activity.

I started to connect this emerging design feature with socio-cultural perspectives on learning. In particular, Rogoff’s¹ framing of activity across three interconnected planes, personal, interpersonal, and cultural, offered a useful way of making sense of what I was seeing. This also resonates with work in game making research, such as Kafai and Burke², who emphasise learning as participation across similar dimensions.

With this in mind, I revisited my data, looking more closely at how gameplay design patterns were being used across these different aspects of activity. What became clear was that GDPs were not just supporting individual understanding. They were helping to organise the activity itself, shaping how participants planned, collaborated, and developed their ideas over time.

As I traced these uses, a wide range of examples emerged. These were not only analytically useful, but also pointed towards practical approaches that facilitators could draw on. The table below summarises some of these different uses.

Category	Use of GDPs	Description
Personal appropriation	Appropriation of personal knowledge	GDPs supported participants in exploring their own ideas, surfacing computational, design, and systems concepts embedded in games.
	Fluid design operations	The structure and modularity of GDPs facilitated iterative processes such as rapid prototyping, code patching, and debugging.
Guided participation / interpersonal focus	Framework for supporting resources and navigation	A restricted set of GDPs was used to organise tutorials, documentation, and menus, supporting flexible learner pathways.
	Scaffolding ideation and prioritisation	GDP concepts were used as shorthand in idea generation, planning, and decision-making during project work.
	Supporting division of labour	GDPs acted as a shared language that allowed participants to split tasks, coordinate roles, and build specialisms.
Cultural activity focus	Designing for others	The impact of GDP implementation helped participants imagine and respond to player experiences and feedback.
	Facilitating the use of home repertoires and interests	GDPs provided a way to incorporate personal, cultural, and home-based practices into game narratives and assets.
	Propagation through playtesting	Novel or effective GDP implementations spread between participants through peer interaction.
	Components of emerging repertoires in an evolving idioculture	Repeated use and adaptation of GDPs contributed to a shared culture of design practice.

Implications and analysis

One of the things I realised quite early on was that I wasn’t the first person to use gameplay design patterns in learning. There is existing work in this area, some of which is explored in this sister blog post. Pattern collections have been used to analyse games and, in some cases, to support learners in design tasks. So I was not introducing something entirely new.

Where it started to feel different was in the variety of ways the collection of GDPs was being used, and in how it was co-created with learners. The collection of patterns was not fixed upfront. It grew in response to what learners were trying to do. When someone wanted to add a feature, that became a prompt to develop or introduce a pattern. In this way, the resource was being shaped in real time, particularly in the early stages.

The idea of a menu of resources links closely to just-in-time learning. By having a shared collection available, learners could access resources when they needed them, and facilitators or peers could signpost them at relevant moments.

This became particularly important in a setting where participants were working on quite different projects at the same time. One of the main challenges was how to support that diversity without fragmenting the experience or forcing everyone down the same path.

The pattern collection began to hold that together. It provided enough structure to support progression, while remaining flexible enough to adapt to what participants were actually trying to make.

Additionally, by mapping how GDPs were used by participants and facilitators across the workshops, it became clear that engaging with more abstract concepts was not excluded, but rather became one possible pathway among others. While GDPs could act as a gateway into abstract ideas, this metaphor also helped extend the analysis beyond abstraction. It allowed me to account for how GDPs functioned across interpersonal exchanges and in the incorporation of participants’ home practices and repertoires.

Conclusion

I didn’t start my PhD thinking about game design patterns, but I’m very glad I found them.

Across this post, the earlier post on their emergence, and the follow-up on their conceptual framing, I’ve tried to show how gameplay design patterns developed in practice, how they can be understood conceptually, and how they ended up shaping activity across the sessions.

Rather than being fixed in advance, the collection of patterns evolved in response to what learners were trying to do, supporting planning, collaboration, and the development of ideas over time. What feels most distinctive in this work is not the use of gameplay design patterns themselves, but how they were used. As a responsive and shared resource, they helped hold together diverse projects, offering enough structure to support progression while remaining flexible enough to adapt to learners’ interests and approaches.

For facilitators, this suggests a way of organising project-based learning that does not require choosing between openness and structure, but instead works with both. This connects back to earlier reflections on choice and messy learning and the role of jamming as a learning model, where structure and improvisation coexist.

I return to these ideas in a follow-up post, where I connect them to a broader pedagogical framework, REEEPPP, and explore how this approach might be applied more deliberately in other settings. If you’re working on something similar, or trying to support open-ended, creative projects, I’d be really interested to hear how this resonates with your own practice. There’s also more about the wider work and ways to get involved on the Jamm Labs about page.

Footnotes