The conceptual framing of Gameplay Design Patterns

In the previous post, How Gameplay Design Patterns (GDPs) became a vital part of my PhD thesis, I described how gameplay design patterns emerged within the project and how they began to connect different aspects of the learning process. Here, I want to focus more directly on what they were actually doing, and how they helped me rethink the relationship between abstract concepts and concrete making.

Even with that shift, I still needed a way to get past my mental wrestling with how my learning design related to ideas about computational thinking and systems thinking. The solution did not come from a single source. While I agreed with Papert and Turkle that more abstract approaches had often dominated computing education to the detriment of students who favoured concrete approaches, it did not seem appropriate to reject abstraction altogether.

As I began to trace these patterns in the data, it became clear that gameplay design patterns were doing more than supporting individual understanding. They were shaping how participants worked with ideas, code, and each other across the activity. In a follow-up post, I look more closely at these different roles, and how gameplay design patterns function as a responsive and evolving resource within project-based learning.

While orienting the research towards mapping how participants used GDPs helped resolve some of the tensions outlined in the previous post, it also reframed the exploration of abstract concepts as a potentially optional pathway for learners. However, I still wanted to locate this work within existing research on abstraction in computing education.

To do this, I explored the work of Björk and others ¹, who positioned gameplay design patterns as sitting between abstract and concrete dimensions of knowledge. One way of interpreting this is as a learner moving between abstract ideas and concrete coding activity. While this has parallels with semantic waves theory and work on levels of abstraction (LOA)², it did not fully capture the experience of my learners, which was far more fluid and, at times, chaotic.

Instead, I began to think of gameplay design patterns as a kind of gateway concept. They can open up access to more abstract ideas, but they also support engagement with the concrete structures needed to implement them in code.

This positioning of GDPs as a gateway led me to reflect further on how abstraction operates in practice. You may be familiar with levels of abstraction and semantic waves through resources such as the National Centre for Computing Education materials for teachers.

To explore this in context, I mapped levels of abstraction using video data from Vignette 1 (see Chapters 5 and 6 of the thesis). This mapping tracks shifts between gameplay goals (expressed through GDPs), code implementation, and observed results as a child participant worked on their game.

Movement between abstraction and concreteness occurs as the participant shifts between goal formation and implementation. They begin by imagining and selecting a gameplay feature, then navigate to the relevant documentation. From there, they implement the pattern by adapting example code, and test it through previewing and playtesting.

This process is iterative. For example, several adjustments may be needed to position a moving enemy correctly. In doing so, the activity moves back and forth between checking the game output and modifying the code. Increasing fluency appears closely tied to this repeated movement between perspectives.

Gameplay design patterns provide a shared language and structure that help guide and articulate this process. There is a strong link between the idea of a pattern and how it is experienced through gameplay feedback. In this sense, GDPs can support participants in navigating the different levels of abstraction involved in game making.

Moving forward

This reflection traces a shift in how I came to understand abstraction in this work. Gameplay design patterns became important not simply as a resource, but as a way of engaging with abstraction that remained grounded in making.

One of the biggest challenges in sessions was always the same: giving people enough freedom to make something that felt like theirs, while still supporting them to work with code and structure in a meaningful way. Too much openness and things drifted. Too much structure and it became procedural.

Gameplay design patterns offered a way of working in the middle. Each pattern was concrete enough to work with, something you could build or try out, but also carried an abstract idea about how a game behaves. This allowed learners to engage at different levels at the same time, sometimes just using a pattern, sometimes beginning to understand what it was doing more generally.

This work has also led to a set of practical resources for facilitators, including a map of learning dimensions (see /blogs/learning-dimensions) and a developing facilitator toolkit, both grounded in the activities and interactions observed in the workshops.

There is also a broader question about transfer. Could a similar approach work in different settings, in teaching, workshops, or even campaign work? That raises the question of whether this is really about game design, or about a more general way of supporting creative production.

One outcome of this process has been a shift in my own stance towards computational thinking. I started out quite resistant to abstract-first approaches in computing education. Working with patterns shifted that position. Rather than choosing between abstract and concrete, patterns seemed to support movement between the two.

Rather than rejecting abstract concepts, I now see them as part of a broader ecology of learning. They are valid, but not the be all and end all of game coding in this context.

Related writings

To read a more academic account of the relationship between GDPs and debates around abstraction, see the first part of Chapter 7 in my PhD.

If you are interested in how the study of GDP use expands from personal to social and cultural dimensions, read on here.

If you are interested in the learner-driven origins of this work, see Choice and Mess.

Footnotes