Reflection on the REEPPP model

In my PhD game making practice a key part of the learning design that emerged was a starting template of a half-baked game which was so incomplete as to be unplayable. The starter game template highlighted code features that could easily be changed to produce a large impact on the game. To do this I paid close attention to learners’ first encounters with the game and its underlying code.

This game template was introduced to learners with a prompt to play a broken game. They were asked to identify in what way the game was broken and then invited to look at the code to try to fix the game (e.g. to make changes to progress). Participants would try to jump up to the platforms in the game but find that they could not jump high enough to progress. Figure 5.3 below shows a white square as a player, red squares are hazards to be avoided, and yellow squares are rewards which must be collected to progress to the next level. A white line is shown indicating how high the player character can jump.

I didn’t come to this from a formal background in computing. My first experiences of coding were much more informal. I learnt HTML by viewing the source of web pages and copying bits that I liked. It felt a bit like piracy at the time, lifting fragments and trying to make them work elsewhere, but it was also one of the most engaging ways I’ve ever learnt. You could see something interesting, take it apart, and try it out straight away.

That early experience resurfaced within this project. I made the connection that it is one of the reasons I’ve always been drawn to remixing as a pedagogy, and to ideas from the free culture movement. The ability to take something that already exists, modify it, and make it your own is a powerful way into technical and creative work. The idea of “patching” code that I integrated into the learning approach of this project comes directly from that lineage. It ended up becoming an integral part of the final learning model of the PhD.

Summary of the structural components of the REEPPP approach

There were a lot of moving parts in both the technical and social aspects of the learning design that emerged through this project. Towards the end of the PhD process, I started using the acronym REEPPP to communicate some of these ideas in a more straightforward way: remix-enabled, elective, progressive, pattern-oriented, and patching.

It’s not intended as a fixed teaching method or strict sequence of steps. Instead, it is a way of describing some of the features that seemed to work well together in practice. These included giving learners a working project they could immediately modify, allowing choice over different pathways and features, supporting gradual progression through patterns and examples, and encouraging experimentation through remixing and patching code.

In this setting, the REEPPP approach brought together several elements that had gradually emerged during the project: a code playground, a game library, a half-baked starter template, remixing practices, and a growing collection of gameplay design patterns. I think these ideas could potentially be adapted by teachers, facilitators, and community educators working in a range of creative digital projects beyond game making alone. The table below summarises the main elements of the REEPPP approach using examples from the project to help illustrate how they worked in practice.

REEPPP Term	What this means in practice
Remix Enabled	Learners begin with a partly completed project rather than a blank screen. This gives them something concrete to explore and modify straight away. Small changes produce visible results quickly, helping learners experiment and get rapid feedback through testing and play.
Elective	Learners are able to make choices about what they create and how they approach the activity. They can choose different gameplay features, themes, roles, or pathways through the project.
Progressive	Activities are structured so learners can gradually build confidence and complexity over time. This might begin with simple modifications, move towards combining existing patterns, and later involve creating features more independently.
Pattern	The learning process is organised around recognisable gameplay features or “patterns”, such as scoring systems, enemies, timers, or collectables. These patterns act as shared reference points that learners can explore, discuss, and adapt.
Patching	Learners develop projects by modifying and extending existing code. This mirrors real-world creative and technical practice while also creating opportunities for debugging, experimentation, and collaborative problem solving.

Table - REEPPP as a technical structure that synthesises key elements of the learning design

Let’s focus on the last part of the model: EPPP (elective, progressive, pattern-patching).

Elective here refers to choice of pathway. One of the tensions I kept running into was how to support open-ended experimentation without leaving participants completely lost. I wanted learners to be able to remix, tinker, and follow their own interests, but I also recognised the need for some kind of structure that would help people make practical progress on their projects. The menu of gameplay patterns helped them follow those interests. Participants could choose different pathways and features based on their own interests, while still working through recognisable and increasingly challenging patterns. This connects to wider discussions in computing and inquiry-based learning research concerning scaffolding and the balance between experimentation and structured understanding.¹² These themes are explored further in related posts on Choice and Messy Learning, Jamming, and Gameplay Design Patterns.

Turning to the importance of progression, the process often began with quick-start cards, very small changes to the code that had a large impact, before gradually moving towards more complex modifications and combinations of patterns. In hindsight, this gradual progression shares similarities with staged approaches discussed in wider game-making and computing education research.³ In my work I identified four broad stages of progression, shown in the table below.

Stage	Pedagogical focus	Design focus
Stage 1	Informally identifying GDPs	Identifying gameplay patterns through playing and discussing games
Stage 2	Quick-start activities	Supporting rapid, high-impact changes to the starter game template
Stage 3	Adding simple GDPs	Introducing gameplay patterns requiring only small-scale code changes
Stage 4	Combining and extending GDPs	Supporting larger modifications, new functions, and more complex combinations of patterns

Returning finally to pattern patching, while the role of gameplay design patterns is explored in more detail elsewhere (see On the way Gameplay Design Patterns became a vital part of my PhD thesis), patching itself also became an important social process within the emerging game making community. I wanted to support learners in that messy process of snatching bits of code from other sources, whacking them into your own project, and just seeing what happens.

The documentation evolved as I tried to support that aim. Early support materials were piecemeal and reactive, but gradually developed into a more structured collection of gameplay pattern tutorials and code snippets. I began to express the idea and process of patching in written resources (see the Figure below).

However, in truth, the process of finding the right new batches of code, copying them, and pasting them into the right place was something that students would usually get direct personal help with, either from myself or from their peers. No matter how much I tried to structure the documentation, mistakes still happened regularly, and these mistakes were often the right kind of failure, the kind that makes you stop, think, experiment, and gradually deepen your understanding.

Mistakes also became a source of mini-drama and connection. Kids would cry out to their friends and family when something they had added to their code caused unexpected chaos in their game. Those moments often helped gameplay ideas, coding tricks, and debugging practices spread through the wider group as learners shared discoveries and solutions with each other.

When looking back at how different patterns spread through the game making community, it was often through peers helping each other rather than through formal instruction alone. Participants would share snippets of code, point each other towards useful gameplay patterns, help debug problems, or simply notice interesting features appearing in somebody else’s game and ask how they had been made. Over time, different learners and family members also began to develop informal specialisms within the group. Some became more confident with animation and graphics, others with enemy behaviour, level design, or debugging.

Importantly, this meant that knowledge did not just sit with the facilitator or inside the written resources. The learning environment gradually became more distributed and collaborative. People learnt through conversation, observation, imitation, experimentation, and shared problem solving, often moving between these approaches fluidly during a single session.

This also connects to principles of Universal Design for Learning (UDL), particularly the importance of providing multiple means of engagement, representation, and participation. Learners were not restricted to a single route through the activity. Some preferred reading tutorials, others learnt by watching, asking questions, experimenting directly in code, sketching ideas visually, or collaborating with family members and peers. The variety of pathways through the activity helped different participants find ways of engaging that suited their interests, confidence levels, and preferred ways of learning.

This raises interesting questions about how important the foundational resources themselves were compared to the folk knowledge and social practices that gradually emerged within the group. At the same time, perhaps separating those things misses the point. The worksheets, tutorials, gameplay patterns, patching practices, conversations, and moments of experimentation all became intertwined parts of the learning environment.

Looking back, I think one of the most important aspects of the approach was that learners had multiple ways to progress. They could follow written tutorials, ask for help, observe others, remix code snippets, experiment independently, or move fluidly between all of these approaches. These themes are explored further in related posts on Reflection on Jamming, Reflection on Choice and Messy Learning, and Inclusive Design and Neurodiversity.

Moving Forward

This also connects back to earlier work I’ve been involved in around media making more broadly. In areas like journalism or digital storytelling, there are often recognisable features that structure production, for example the elements of a news report, common ways of framing a story, or recurring formats used in editing and publishing.

There are parallels here with the idea of patterns. However, I’m not yet convinced that they operate in quite the same way as gameplay design patterns. Gameplay patterns tend to describe interactions and systems that directly shape player experience, whereas other creative domains may involve looser conventions, genres, or production habits.

That raises an interesting question for future work. To what extent can this kind of pattern-oriented approach transfer beyond game making into other forms of creative production? For example, do the recurring features of a news report constitute a kind of design pattern, or are they better understood simply as defining characteristics of a genre or medium? Where does the idea of a “pattern” start to break down?

Some of the wider theoretical background to these tensions between remixing, scaffolding, abstraction, participation, and agency is discussed in Chapter 2, while the practical evolution of these approaches during the project is explored in more detail in Chapter 5.

Footnotes