Findings: Design Narrative

Findings: Design Narrative

Chapter introduction

This chapter presents a design narrative that traces the evolution of the learning environment developed in this research across different phases of implementation. The narrative approach adopted here is informed by design-based research (DBR) traditions and the analytical tools of third-generation activity theory (3GAT), as outlined in Chapter 3. This chapter demonstrates how changes in tools, documentation, and pedagogical strategies were shaped by participant need, focusing in particular on phases one to three of the research process.

Design narratives are a useful DBR technique for describing situated, context-sensitive changes to an intervention over time [@hoadley_creating_2002-1; @bell_theoretical_2004]. Here, the narrative is grounded in the concrete details of the research setting and practices, and attends closely to how formative redesigns emerged in response to barriers encountered by participants. While Hoadley [-@hoadley_creating_2002] covers motivations of design narratives, there are no set forms. My design narrative is an additive blend of contextual information, facilitator reflections, justifications of design changes, and interwoven vignettes drawn from close observations of video data. By narrating the emergence and evolution of the learning design, this chapter contributes to the overall methodological project of the thesis: to develop a participatory, tool-mediated environment informed by a synthesis of CHAT and DBR processes. The narrative also begins the task of articulating the emerging design heuristics.

The chapter begins with a situated vignette that introduces the activity and its participants. This is followed by three major sections, each focused on a cluster of contradictions identified during the analysis. These cover tensions related to technical tools and accessibility, issues of navigation and documentation, and cultural or identity-based challenges in the coding process. Each section presents a sequence of problem identification, design response, and analysis of outcome or change, drawing on session notes, participant feedback, artefact analysis, and observations from the researcher’s journal.

Vignette locating the game making activity

To open this chapter, I present a summary of Vignette 1. The purpose is to ground the reader in the evolving design through a demonstration of indicative activity from the perspective of a young participant in the process. This scene offers a humanising and situated entry point to a detailed exploration of the wider project. The fuller vignette, showing how learner motivation, intergenerational collaboration, and playful tool use unfolded in context, is included in the special appendix chapter containing vignettes of activity¹. As the phases of design and tools used are referred to frequently in this chapter, Table 5.x is included as a summary ².

Phase	Brief description
P1	Exploratory process: with varied non-code tools use, and code playground use as a main coding environment, minimal supporting resources.
P2	Glitch.com (code playground), Phaser.js (JavaScript game framework), Piskel (online pixel art editor)
P3	This phase used a similar approach to P2, the core toolset was unchanged, additional social missions and a drama narrative was added to the wider process.
P4 & P5	These phases marked a transition to a block coding approach using MakeCode Arcade tool. Supported resources were developed and integrated with computing curricular concepts.

Table. 5.x Reminder of delivery phases and development periods

The vignette takes place at the start of the session in the latter stages of Phase 2 (P2), shortly after I had made a brief opening announcement, reminding participants that it was the last coding session before the showcase event ³. The tools used in this vignette are explored in a following section.

Toby, a child participant, had been working independently for around five minutes of the session. On Toby’s right, Mick is helping Veronica’s request, demonstrating how to access two different forms of help in the form of code examples and step-by-step tutorials. On his left, grandparents Pearl and Clive are working on their own game (within earshot).

Figure.5.x - Location of Toby {width=90%}

Toby tests his game by playing through the many different levels of his game, showing fluidity and skill. At times during playtesting, Toby undertakes a process of changing the game code to alter his level layout. Toby finishes playtesting and navigates to a web page containing a menu of gameplay design patterns to add to his game. He clicks on the entry for adding a moving enemy. He undertakes a careful process of exploring, copying, and pasting code from an exemplar document into the correct locations. The resulting change to his game is shown in Figure 5.x. The process required Toby to use and navigate multiple tools [^2], which he undertook in a self-directed way, occasionally rapidly and fluently, and at times in a more hesitant manner. The immediate audience of his peers appears to influence his design decisions. During the session, Toby invites other group members to play his game, initiating and responding to conversations about the difficulty of his game design. He makes a comment to a peer while self-playtesting his game: *"I’m just going to have one go of beating this (his own game). It’s 21 levels in it. So Yeeeah."* A student helper also notes his distinct level design: *"Is yours the one where level one is harder than level three? ... I like that."*

Vignette 1 has elements of activity which occur at intersecting activity systems outlined in Chapter 4. Toby’s activity is focused sometimes as part of a wider, community scope, and at times on an individual level to make practical changes to his game. Figure 5.x illustrates one aspect of the objective of the wider system, working towards a game showcasing activity in the foyer of the University building where games are shared with the students in the building. This photo shows a homemade cabinet surrounding a laptop computer.

Figure.5.carrot - Game showcasing event {width=90%}

Narrative exploration of key areas of contradictions emerging in the game-making learning design

In line with the theoretical framing established in Chapter 3, contradictions are understood as historically and structurally embedded misalignments between elements of an activity system, often made visible during periods of change or innovation [@engestrom_activity_1999]. Following Kuutti [-@kuutti_activity_1995] and Engeström [-@engestrom_discursive_2011], tensions, barriers, and disruptions in practice are treated as surface-level manifestations of deeper contradictions within and between activity systems. These manifestations may take the form of technical difficulties, motivational conflicts, or mismatches between participant expectations and other systemic elements shaping the activity. The following sections of this chapter examine three key areas of contradiction.

The first area of contradiction addressed includes tensions arising from the introduction and evolution of technical tools in the learning design, particularly the shift in software practices between P1 and P2. The second focuses on a contradiction related to navigation and supporting documentation during P2. The third explores cultural and identity-based tensions in coding participation, an area highlighted in earlier chapters as a persistent barrier to inclusion.

Contradiction area 1: involving organisational issues and the use of game programming and asset authoring tools

In this section, I analyse journal notes, participant feedback, and the changes in tools and resources between P1, which was highly experimental, and P2, which ended with a more complete implementation of the introduced resources. This section (and the subsequent two) begins with a composite description of activity, summarises key tensions and resulting conflicts, and outlines the responses they provoked.

Email communication inviting participation and describing the proposed workshop activities set an expectation of parents being involved in “families to take part in a Game Making club to learn how to make video games together” and this was reiterated in the first session ⁴. In the early stages of P1, working groups formed organically, broadly along family lines, with three mixed-age groups of roughly five participants. These groups began to define their game ideas during these relatively unstructured early planning sessions. My initial focus was to create a welcoming, low-pressure environment for exploring the process of making games in a way that allowed participants to follow their own interests ⁵. To achieve this, I used several activities unrelated to computer coding to scaffold the game design process. Each family had access to a laptop with vintage games installed, and early sessions included time for playing and discussing retro arcade games, particularly focusing on describing their component parts ⁶. Other activities included brainstorming game story scenarios, creating pixel-art characters on paper, and making craft collages for game backgrounds ⁷.

I postponed introducing code editing tools until around week five, prompted by concerns about overwhelming participants and my own ability to support unstructured coding from first principles ⁸. I had previously chosen a game design framework, Phaser.js ⁹, and at this stage introduced a simplified game template featuring just a character, ground, a hazard to avoid, and a star to collect, illustrating common tropes of a simple retro platform game ¹⁰.

{width=95%}

Figure 5.x - Simple breakdown of code playground areas.

The code playground tool proved initially productive in scaffolding the early coding experience of participants working on HTML5 games ¹¹. Both code playground tools used in P1–3 shared a similar layout, which is common to code playgrounds in general. The three areas shown in Figure 5.x represent a visual and technical structuring of a web project: with the ability to create and upload files as assets in area (a), to view and edit the code in area (b), and to preview the resulting game in area (c) ¹². The decision to use a code playground was guided by the need to support participants, given my motivation to encourage authentic engagement with real code rather than a block coding approach [@chesterman_webmaking_2015]. While the affordances of the code playground ameliorated some of the barriers associated with text-based coding [^10], predictable challenges in this area remained for participants.

In P1, once participants began engaging with code, several tensions quickly surfaced. Differing levels of ability and interest in implementing code led groups to specialise. Some participants with greater confidence or prior experience took on coding tasks, while others focused on graphical game assets (both digital and physical), narrative planning, or sound elements ¹³. Even so, at this point my ability to support coding activities became a limiting factor. Whole-group demonstrations were largely ineffective: attention drifted, and groups progressed at different speeds, requiring different support at different times. Without in-tool help or the kinds of support provided by block coding environments, participants had few scaffolds to rely on. Given the complexity of the starter code, learners frequently required one-to-one support to make even minor additions to their games. They relied heavily on me as their primary source of help, further increasing the facilitation workload. As a result, support bottlenecks emerged and some participants stalled early in their projects. My journal notes describe these sessions as increasingly difficult to manage.

In line with CHAT analytical processes, I now synthesise emerging tensions as a contradiction. The use of a professional text-code language and framework was a contributing factor. While simplified, the structure of the starting template was still relatively complex for novices and offered no easy way into experimentation as advocated by a tinkering or bricolage approach ¹⁴. Many learners had ambitious ideas for their projects that were either beyond the scope of the framework or not realistic given their novice level ¹⁵. Regarding peer learning, while some learners became aware of each other’s programming work, it was difficult to adapt bespoke additions from one project to another.

These tensions reveal an underlying contradiction in the activity system between the object of creating expressive, technically functioning games and the mediating means available to support that objective, as shown in Figure 5.x. In summary, the use of an authentic text-based code environment aggravated a misalignment between participants’ ambitions, their actual skill levels, and the support structures in place within the software toolset. At the same time, the mediational role of a single facilitator proved insufficient to sustain steady progress within project work and to support diverse learner needs, resulting in friction and delay. This contradiction pointed to the need for redesigned tool affordances and wider scaffolding that could better support the object of creative game development.

Turning to the response to this conflict, one initial response was a non-technical one. After one session in P1, I emailed participants, expressing that I felt daunted by the task of helping integrate the disparate creative elements being produced into cohesive game projects—a process which I felt responsible to facilitate. In response, I emailed parents for support in organising and bringing more order to group and planning processes ¹⁶. The group planning process improved, and the self-organisational abilities of parents and tenacity of young people freed up more of my time to support technical issues in the remaining sessions.

The contradiction outlined above also shaped a series of design adaptations to tools used between P1 and P2. Recognising the need for scaffolding without over-prescription, I developed a starter game template with greater scaffolding, including repositioning key variables at the start of the game code and embedding comments to highlight lines intended for modification. The process of developing the affordances of the starter game involved close attention to learners’ first encounters with the game and its underlying code. This game template was introduced by facilitators who prompted learners to play a broken game in a web page. 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) ¹⁷.

Figure 5.x Simple game template - with limitation of initial jump height shown {width=95%}

The following section provides a description and analysis of the toolset that emerged from the tensions and contradictions of Phase 1 and was then implemented in Phase 2. While P1 had been exploratory and had used a large set of tools, in P2 I reduced the number of suggested tools significantly ¹⁸. I offer the following overview to give the reader a clearer, situated understanding of the activities being carried out ¹⁹.

Code playground: The code playground supported: a place to view and play the starting template, and a remix button which, when clicked, created a new version of the project that could be adapted.

Simplified file structure: The overall file structure was simplified so that participants only needed to alter the game.js file. An older version of Phaser.js was used, allowing simplified syntax for object and function construction ²⁰.

Variables at the start of the document: Small changes to variables at the start of the JavaScript game file created rapid feedback and noticeable effects in the game. The starter templates included editable values and visible parameters for player movement, enemy speed, and image and sound assets.

Block graphics and use of Piskel: Generic coloured blocks in the template encouraged participants to add their own graphics using the Piskel tool ²¹. The template was adapted to allow importation of 32×32 pixel blocks, matching Piskel’s default project size. Using this tool external to the code playground supported key digital literacy skills, as participants had to migrate assets from Piskel into their games by downloading them and reuploading them.

Figure 5.px - Interface of Piskelapp tool {width=95%}

Graphical structuring of the level design using text code: To align with research on the value of visual approaches to multimedia coding projects for novices [@guzdial_programming_2004; @resnick_scratch_2009], changes to level design were scaffolded to mimic tile map logic using text-based arrays and regular block graphics. The P2 starting template featured a graphical grid structure for editing level layout, as shown in Figure 5.grid.

Figure 5.grid - Grid based editing of level design with a simple key for hazards, coins, and platforms. {width=95%}

At this stage, I also invite the reader to play the starting game template and view the underlying code ²². A more detailed account of design issues related to the structure of the template is included in Appendix D.1, allowing replication by other practitioners.

This section now summarises and analyses some of the ways in which the design helped address the tensions described above. In line with the exploratory rather than quantitative nature of the thesis, the aim is not to prove the efficacy of the intervention, but to explain its role in the iterative process. However, broad summaries of impact are included to help contextualise the later sections.

The starting template reduced the difficulty and time required to initiate a game project. This contributed to a significant shift in working practices from P2 onwards, characterised by smaller working groups, normally pairs or individuals. In addition, the process of starting with a working game and altering existing affordances within the template allowed participants to begin sharing their emerging games with others immediately, which contributed to the concurrent increase in time spent on peer playtesting during this phase. Selecting a reduced toolset in P2 helped prevent participants from being overloaded by the diversity of tools in play and also led to greater alignment of experience across the group. This appears to have been a contributing factor to increased peer exchange of skills and knowledge.

The technical adaptation of the text-based level editing grid had a specific impact on both the coding experience and the wider environment. The ability for individuals and pairs to make quick changes to the game templates through the affordances described in the previous section appeared to build their ownership over these fledgling games. Vignette 1 shows Toby designing many levels of varying difficulty, making the experience of playing his game distinct from others. This individuality is noted and encouraged by a student helper (see Vignette 1 extract in the previous section).

I now discuss this design in relation to existing research on the use of supporting code templates in programming education. The template design is an example of a “half-baked” microworld (in the form of a game) [@kynigos_children_2018; @kynigos_half-baked_2007], and aligns broadly with the UMC framework [@lee_computational_2011]. The work of Kynigos et al. [-@kynigos_children_2018] on the concept of half-baked microworlds and games shares a similar focus on the motivational aspect of incomplete game affordances to drive initial engagement. This motivation spurs and shapes activity in the early making stages of this learning design, aligning with the use and modify stages of the UMC approach [@lee_computational_2011] (see Ch.4). The use of a template that introduced hands-on engagement with coding tools early in the process helped avoid the mismatch between participants’ planning and the technical limits of their novice abilities. Small code changes that produced large visible differences in game behaviour, appearance, or difficulty align with a long-standing principle in HCI research that feedback is motivating for users [@bernhaupt_introduction_2015; @malone_heuristics_1982].

Turning to the aspect of authenticity in the learning design, it is valuable to re-examine the factors driving my choice of JavaScript and Phaser, a professional, open-source game-making framework. Specifically, this choice relates to the potentially empowering impact of exposing participants to authentic technologies and concepts in hands-on, exploratory processes. Ratto [-@ratto_critical_2011] discusses this through critical making, a process that playfully brings forward Latour’s [-@weibel_making_2005; -@latour_cautious_2008] ideas of shifting from matters of fact to matters of concern by revealing taken-for-granted artefacts as deliberately designed objects. This was evident in conversations between participants where they expressed a sense of inspiration or engagement with previously unknown technologies. For instance, exchanges demonstrated a growing appreciation for the complexity behind professional games, based on their perception of the effort required for their own simple game projects:

Pearl: It just shows you what goes into these games.
Student Helper 3: Think about how much effort goes into.
Pearl: You just take things for granted don’t you?

While my design aim was in part to reduce coding syntax errors ²³, part of the goal was also to lessen the anxiety and frustration often experienced by novice coders [@denny_all_2012]. I did not wish to remove the possibility of learners making mistakes entirely. Even these small changes involved potential syntax errors, but because these simple expressions were surrounded by other lines modelling the correct syntax, participants were often able to correct mistakes without facilitator support ²⁴. Thus, this careful structuring of the template appeared to mitigate the challenges of syntax errors.

This section outlines a contradiction associated with the need for and introduction of supporting documentation to scaffold the game-making process. In P1, participants followed divergent creative pathways using a diverse set of tools (see description in the following section), but this came at the cost of a sense of overall coherence and shared understanding of the process. In P1, group organisation coalesced around the creation of wish lists of game features, which acted as mediating tools to coordinate between different team members and to request facilitator support for implementing them via code structures. Between P1 and P2, I reflected on how this process could be developed into a structured approach to documentation that could support this style of project organisation.

In P2, a reduction in the average size of working groups and a subsequent increase in the number of game coding projects led to increased demand on my time as a technical troubleshooter. At this stage, while the in-tool scaffolding provided by the code template accelerated production for learners significantly [@laurillard2020significance], participants still required direct support from me when adding new code structures, causing delays and participant frustration due to the limited time I could offer each group. Early in P2, resources to support implementation were driven by specific participant requests. However, unlike in P1 ²⁵, due to greater similarity in the underlying code structures, the supporting resources created for one project now became suitable for reuse in others. As such, as P2 progressed, a library of short stand-alone instructional documents began to accumulate.

A recurring tension noted in my journal during this period concerned the clash between divergent participant learning paths and the need for technical support. This was compounded by resistance to whole-class teaching input²⁶, which consistently yielded low engagement. I surmised that participants saw these attempts at class teaching as not immediately relevant, misaligned with their preferred hands-on working styles, and disruptive to the flow of their making. Repenning et al. [-@repenning_scalable_2015], as discussed in Chapter 2, frame this resistance as a barrier arising from a principles-first approach. The authors describe the risk of such an approach plainly as participant boredom. The challenge became how to support progress given my limited facilitator time, without losing the important pedagogical feature of participant choice over their pathway. I also struggled to reconcile an additional tension between this responsive approach to providing documentation and requests from some parents for resources involving background concepts and explanations of coding constructs.

Together, these challenges surfaced a contradiction between an important component of the object of the activity (learner-led game creation) and the evolving rules and mediating artefacts intended to support that process. The activity system lacked a shared, structured way for participants to orient themselves in the process, or to develop and reuse successful code patterns without the input of facilitator mediation. Thus, the flexibility of the environment became problematic. This contradiction appeared to be a double bind [@engestrom_expansive_2001]; how could I provide greater support via documentation detailing implementation and underlying principles without compromising the responsiveness to the learner pathways that was foundational to the ethos of my approach? This contradiction drove extensive revision in the learning design concerning methods of technical support.

Recalling my organisational crisis in P1 outlined in the section above, in response to my email asking for help, parents made suggestions including: the use of a visible and shared list of game features that were being worked on, and documentation to support the implementation of code that explained underlying principles and foundational code structures. The suggestion of the list of game features, used as both a shared organisational tool and as the basis for providing supporting documentation, became relevant in addressing the contradiction outlined above. Thus, early in P2, I used this dual function as a guiding principle to structure and present supporting resources in the form of themed features ²⁷, which users could choose from, allowing them to take on features in the order that they chose. From this point onwards, resources which addressed some of the contradictions outlined above evolved rapidly, resulting in the creation of three main sources of documentation: quick start cards, written instructions, and code snippets. I now describe the process of creating these varied supporting documentation resources and the purposes they served.

Quick start cards were initially developed to support one-off sessions and to allow rapid experimentation with the starter game of P2 ²⁸. They were designed to let participants choose challenges based on area of interest and difficulty. Quick start cards (see Figure 5.cards below) were A5-sized printouts highlighting the key affordances of the template, involving: game mechanics such as movement, jumping, level design, and the final challenge of swapping out the look of one or more characters by designing pixel art and replacing the line of code that adds the asset to the game. These printed resources highlighted key lines of code and demonstrated how they could be altered to impact game behaviour ²⁹.

Figure 5.cards - Example of a Quick start card {width=95%}

The cards supported participants’ initial interaction with the code in a way that further developed the use and modify stages of the UMC framework [@franklin_analysis_2020]. They allowed participants to get started with the template game with less in-person support from facilitators, due to the strongly scaffolded interaction with the code and the relatively minimal changes needed. Thus, this process scaffolded simple coding tasks while also facilitating choice over learner pathways.

To further reduce dependence on my time as a facilitator, I wrote supporting documentation in a step-by-step format for each code example. In the early stages of P2, learners accessed these documents through a shared Google Doc with links and brief descriptions. I continued developing new projects and producing printable instructions to support these code snippets, ensuring that each snippet linked to a descriptive chapter and vice versa.

While the use of code examples or snippets ³⁰ is a common professional practice in problem-solving [@yang_stack_2017], their use by novice learners presents challenges related to relevance, consistency, and accessibility [@treude_understanding_2017]. Indeed, difficulties experienced by participants in P1 in understanding and applying abstracted code snippets from the Phaser documentation website prompted me to create more tailored resources for P2. These bespoke, stand-alone code projects demonstrated annotated code features within a playable game project based on the starter game template, allowing participants to copy and paste the relevant code sections into their own projects. Projects illustrated requested game features such as gameplay design patterns, including: jumping on an enemy to zap it and making a moving enemy. To help learners situate the code within the correct structure, all projects used the core game template and included only the new code required for each feature.

This section now addresses the introduction of code snippets and self-contained instruction based on game design patterns, and their integration within a manual with a more linear structure. While quick start cards scaffolded existing affordances within the game code, an innovative structure of documentation was needed to support the addition of new features.

To meet participants’ requests for foundational coding knowledge, I created step-by-step chapter resources guiding users to code a core game template structure from first principles ³¹. While this linear format did not fully align with my choice-driven approach, I envisioned it as supplementary reinforcement for learning outside of sessions, which indeed some participants did take up ³².

Figure 5.patterns: a screenshot of the hub of GDPs pointing to code snippets and instructional chapters {width=95%}

I experimented with ways to present these feature choices in an accessible, visually engaging format (see Figure 5.patterns). Concerned that multiple documentation formats could lead to confusion, I created a centralised hub, structured around these graphical representations of the game features, to host both snippets and tutorial chapters, with the aim of making navigation more intuitive and orienting documentation around participants’ gameplay experience ³³.

Game Mechanics	Game Polish	Game Space	Challenge Systems
Add Static Hazard	Add Graphical Effects	Change Design of Levels	Gain Points when Collecting Food
Add an Animated Enemy	Add Sound Effects	Add More Levels	Add a Timer
Jump on Enemy to Zap them	Add a Soundtrack (Music)	Change Shape of Levels	Collect all Food before Progressing
Double Jump	Add a Game Story with Messages	Change the Background Image	Power-up – Higher Jump
Moving / Patrolling Enemies	Add a Game Story with Messages	Change the Background Image	Power-up – Player Speed
Moving / Following Enemies	Animate your Player’s Movements	Key and Door	Random Doubling Enemies
	Make Player Immune

Table 5.x Categorisation of gameplay design patterns used in P4

I now turn to a short analysis of the trajectory of the supporting resources in relation to other research. It is covered only briefly, as it is developed more extensively in Chapter 6. The structuring of the collection of code examples, as outlined, was developed in response to requests for new features from participants, aligning with a shared motivation to encourage diverse learner pathways. This style of intervention aligns with the concept of just-in-time learning approaches within project-based learning [@riel1998education], where access to supporting documentation is provided based on learner need.

Chapter 2 reviewed research on using collections of gameplay design patterns to support learning in game design [@holopainen2007teaching; @holopainen2011foundations; @eriksson_using_2019; @bjork_patterns_2005], including the potential of thematic organisation of these patterns to develop a shared understanding of game-making concepts within a coding community.

For the documentation hub described above, I grouped gameplay design patterns into categories based on academic and professional interpretations of game elements [@salen_game_2006; @schell_art_2008; @tekinbas_rules_2003; @olsson2014conceptual], as well as participants’ evolving requests for game features. Specifically, these patterns were themed in a way that aligned with the MDA (mechanics, dynamics, and aesthetics) game element framework explored in Chapter 2 ³⁴. The final categorisation used in P4 is shown in Table 5.x. It was in this stage of theming the game features that I started to explore in detail existing research on game design patterns in educational contexts.

Video data collected documents the creation of games with diverse and complex styles and themes ³⁵. These issues are discussed in more detail in relation to the development of participant agency in Chapter 7. Discussion of how the development of these supporting resources interacted with the core template contributes to research on microworld environments and the UMC framework, and is continued in the final discussion section of this chapter.

Contradiction area 3: tensions and barriers in cultural aspects of the game-making activity

This section addresses an area of contradiction related to cultural aspects of the game-making activity, which, while discussed last in this chapter, is foundational to the thesis. At times during the interventions, in line with existing research ³⁶, some participants experienced alienation from the process of coding. Early in Phase 1, I incorporated several non-coding techniques to foster positive affect and create an inclusive learning environment. These included: playing and analysing retro arcade and console games, drama games as session warm-ups, a process drama ³⁷, sketching pixel art on paper, digital pixel art creation, loosely structured ideation sessions to decide on themes, and sessions on music-making and audio effects creation using accessible tools. While this wide diversity of activities was later streamlined in subsequent phases ³⁸, the initial impact of these more accessible creative approaches on the general culture of the group appeared positive, in line with existing research ³⁹. It was the transition away from a period characterised by widespread use of these non-programming techniques toward one more dominated by text-based coding and the use of related tools that brought about a sense of exclusion for some participants.

This alienation is now illustrated using a case study of one family consisting of Anastasia, the mother, and her two daughters, one at the lower end of our 8–12 age range and one at the upper end. While this family actively participated in non-coding activities, tensions emerged when the coding framework was introduced and its limitations became clearer. The structure of a two-dimensional game did not support a key gameplay idea that the younger child had imagined during the ideation stage: specifically, exploring a three-dimensional landscape from the point of view of a bee avatar ⁴⁰. This realisation was very upsetting to the child and required extensive negotiation, led by Anastasia and with support from me, to explain the limitations of our beginners’ coding course. This episode echoed the previous tensions described in C1 related to tool use but was amplified by the strong emotions of the child.

Two sessions later, the whole family experienced a sense of alienation. As the phase progressed, an organic division of labour had occurred, with some members continuing to focus on graphical and audio asset creation while others worked on incorporating these assets and ideas into the code framework. As participants moved beyond early-stage ideation and asset creation, the flexible, diverse, and decentralised working practices gave way to a narrower set of expected competencies. There was progressively less for the non-coders to do. During participant feedback, Anastasia shared that, in one session, they had arrived a little late and, after observing other participants deeply immersed in problem-solving with text-based coding tools, felt surrounded by a process of hardcore coding (participant’s phrase) that they felt disconnected from.

This experience was not isolated to this family. In interview data, parent Maggie noted, “I was worried we (her and her son Jay) neglected Toby,” referring to this stage where smaller subgroups were focused on implementing the code for various elements created earlier by the wider group. In my journal, I noted that group work at this stage felt disjointed, with non-coders left with little to do, and a feeling that the previously playful culture was transforming into something more serious. I reflected on the fragility of learners’ positive affect and the risk of alienation during the transition from the planning and sketching phase to the coding phase.

Turning now to the surfaced tensions, barriers and resulting contradictions: these reflections show two strands of tension between activity system elements. One tension is between the object of working together and the emerging norms requiring close engagement with the technical aspects of coding, and a shift in the division of labour prioritising these aspects. Another tension concerned the division of labour itself. To participate fully in later design stages, participants would need to engage with text-based code regardless of their previous (and perhaps preferred) working practices. In addition, given that coding activities were ongoing, attempts to incorporate these team members at this stage would be disruptive to those existing divisions of labour.

Fig 5.x – A contradiction between subject experience and the evolving cultural layer of the game-making activity {width=95%}

These tensions, combined with previously explored cultural barriers to coding, expose a contradiction between the object of the activity (inclusive game-making allowing diverse creative contributions) and the cultural layer of activity [@engestrom_activity_1999]. The accumulated contradiction is illustrated in Figure 5.x.

The contradiction and resulting feelings of alienation occurred despite a learning environment that included diverse and inclusive elements informed by previous research. This suggests that treating such activities as an “add-on” creates difficulties. The process of introducing accessible non-coding activities helped with acculturation to the game-making process in general, but as text-based coding became necessary later, this only delayed alienation for some participants. Indeed, the process potentially heightened frustration if participants had invested in a process they were later excluded from. In P1 feedback, the parent Anastasia suggested more hands-on exploration with the tools of production before being required to make creative decisions ⁴¹. As such, addressing this contradiction required rethinking not only the technical scaffolds, as outlined above, to enable early interaction with tools, but also the need to accommodate ongoing contributions in visual design, sound production, and narrative development in a more balanced fashion.

Addressing the design response: as previously outlined (see C1 and C2), changes in tools and documentation had a positive impact. The use of a template and quick start cards facilitated shareable games from early stages and created varied points of entry into the activity. Participants were increasingly able to work either individually or in small groups, often alongside family members. This helped reduce role-based exclusions, such as in the case above, where non-coding contributions became marginalised. In particular, structuring resources around an episodic process of applying one GDP after another shifted the design pattern away from a linear design–build–test progression and allowed for greater balance between coding and non-coding activities.

Two key design interventions were introduced in P2 and P3 to respond to the tensions outlined above: the use of social coding practices within playtesting, and the introduction of side missions. These strategies served to realign cultural dimensions of the activity system and supported more inclusive and flexible forms of participation.

Turning first to social coding within playtesting: a longer period with a functioning game and the ability to make small iterative changes allowed each tweak to be self-tested and shared with others. As participants spent more time playtesting both their own and others’ games, playtesting evolved beyond instrumental testing into a significant social and cultural practice. By the midpoint of P2, it had become a key site of peer exchange, prompting spontaneous sharing of advice, assets, and debugging strategies.

Video data captured instances of participants expressing frustration when errors rendered their games unplayable (see Vignette 2). While such frustration was natural, I also felt a strong sense of urgency. I prioritised supporting participants with broken games to make them playable again so they could benefit from playtesting. I observed that different people gained different things from this process: some used it to generate ideas, others to socialise. Journal notes, later confirmed by video and interview data, described a variety of playtesting behaviours, including: forming social connections (often parents), chaotic clusters of excited young people, and sneaky design choices that bent game conventions ⁴². These examples demonstrate productive chaos, and participants clearly experiencing flow in their playful playtesting.

The characteristic of flow in a social and cultural setting felt especially evocative to me as a facilitator. This recalls Basawapatna’s work on proximal flow [-@basawapatna_zones_2013] ⁴³, although the structure here differs from SDG considerably. Whereas SDG followed a linear structure, my approach, based on learner choice, allowed greater opportunity for peer interaction. The evolving role of playtesting is developed further in Chapter 6 in relation to GDPs, fluency, and agency. In P3, I began gently but deliberately intervening to support the emergence of these collaborative social coding practices.

The focus now moves to the use of side missions to encourage varied creative practices. The side missions, framed within a drama scenario, aimed to encourage varied playtesting practices. In P3, I introduced a narrative framework to scaffold participant engagement in the form of a fictional scenario: an alien civilisation had contacted the group after seeing the games published in P2. They demanded that participants upload more games so the aliens could assess the worth of the human race ⁴⁴. Within this scenario, participants were assigned printed side missions that were not directly related to game creation ⁴⁵, some public and some kept secret, that encouraged forms of interaction and exploration with playtesting similar to those described above. Examples of these missions are included in Table 5.sidemissions.

Your Alien Mission (social)	Your Secret Alien Mission
Find out the names of 3 games that are being made	Change the variables at the start of someone else’s game to make it play in a funny way
Make a list of characters in two other games	Replace the images in someone else’s project with something unexpected
Find out the favourite computer games of 4 people	Change the level design of someone else’s game to make it impossible using minimal edits

Table 5.sidemissions – an extract of side missions given as part of the drama scenario

These side missions supported playful social dynamics and aimed to shift the focus away from individual technical mastery toward creativity within a shared community.

This section concludes by analysing this area of contradiction. While it focuses on a specific set of missions and the drama-based approach used to frame them ⁴⁶, these interventions can be interpreted as design artefacts that mediated both cultural and affective engagement, making space for diverse learners to see themselves as legitimate participants in the game-making space. In line with theory on formative interventions, these missions acted as secondary stimuli, opening up new pathways for agency development [@hopwood_agency_2022]. They positioned observation, playfulness, and curiosity as valid forms of participation, helping to legitimise roles beyond that of a hardcore coder.

As discussed in Chapter 2, much of the literature on computing game design and programming (CGD&P) emphasises learners’ personal appropriation of programming concepts, often framed through individual progression or mastery. The learning design presented here offers a different approach, foregrounding the cultural and affective dimensions of participation. By integrating narrative framing, varied social missions to enhance playful playtesting, and role-based reflection activities, the design created space for learners to engage on their own terms. This broader framing of legitimate participation responds to critiques of overly individualistic orientations in CGD&P and aligns with sociocultural perspectives on learning as relational and situated. Chapter 7 builds on this by analysing how these design features supported the development of learner agency through cultural repertoires, shared roles, and evolving patterns of participation.

Alongside the elements detailed above, several additional features of the learning design contributed to its cultural and affective dimensions, although they are not explored in depth here. A map of learning dimensions, based on the work of Brennan and Resnick ⁴⁷, was developed and refined in Phases 4 and 5 to align more explicitly with MakeCode and national computing curricula ⁴⁸. Reflection activities were conducted in role, drawing on Heathcote’s Mantle of the Expert approach [@heathcote_drama_1994], which encouraged learners to take perspective and consider purpose within the design process. A large-scale visual map was also introduced to aid navigation, allowing learners to trace and narrate their movement between GDPs over time ⁴⁹. These features extended the project’s commitment to inclusive and flexible participation, offering learners additional ways to make sense of their progress and engage with computing concepts in relation to identity, story, and community. While not fully explored in this chapter, they remain important for understanding the broader scope and coherence of the design, and merit attention for a more complete picture of how participation was supported, particularly in relation to issues of inclusive participation and emotional responsiveness. While they are not examined in detail in the chapters that follow, the cultural and relational themes they reflect are taken up more fully in Chapter 7, which explores how participants responded to the broader social and cultural affordances of the design and how these contributed to the development of agency within collective activity.

Chapter Discussion

This discussion explores features of the design narrative and elements of the design process that contribute to the research landscape. Specifically, a stage-based approach adapted from design-build-test pedagogy is offered as a practical contribution. The learning design is contrasted with UMC and constructionist design principles, highlighting the increased complexity that arises when using authentic tools and processes. Subsequently, a harbour metaphor is proposed to clarify these conceptual contributions. Finally, a summative table synthesises aspects of systemic contradictions.

A stage-based approach structured around a germ cell concept of GDPs

In the learning design outlined in this chapter, GDPs drive stage-based instructional processes. Using terminology from Denner et al. [-@denner_does_2019], the shift from P1 to P2 represents a move from a design-build-test to a stage-based approach. By the term stage-based, I mean a process that introduces code structures and challenges in an initially simplistic, prototypical format for learners to experience and explore, and which are subsequently replaced by more advanced models or complex instances of the task. This term arose from an initial misunderstanding I had in my reading of the review by Denner et al. [@denner_does_2019]. I was not familiar with the US term step-wise instruction (referring to step-by-step instructions), and misinterpreted it as a stage-based approach involving the progressive increase in complexity of challenge. In this design, this staged approach is enacted through participant interaction with increasingly sophisticated documentation and code structures.

The structure of documentation, created in response to participant requests to add new GDPs to their games, evolved from a piecemeal format in P1 to, by the end of P2, a menu of GDP code snippets accompanied by detailed instructional documentation.

Stage	Pedagogical focus	Design focus
Stage 1	Informally identifying GDPs	Identifying GDPs via an activity playing games [see Appendix D.1.?]
Stage 2	Quick start cards	The quick start cards supported rapid changes to GDPs highlighted as affordances in the starting game code template
Stage 3	Adding simple GDPs	These additions required only minimal changes to the template structure
Stage 4	Advanced GDPs	Larger changes including new functions or fundamental changes to the code

Table 5.x – A representation of the staged processes

This stepped approach, which increases the complexity of the object of activity, is explicitly addressed only in limited CGD&P research. The work of Repenning on SGD operationalises this progression through guiding learners to undertake projects of increasing complexity, each implementing more advanced patterns. However, it differs in that no common template is provided, so learners must start from a blank slate each time [@repenning_scalable_2015]. This is notable, as I found in P1 that changes to the underlying code structure were stressful and unwelcome once participants had developed familiarity with it ⁵⁰.

The four-stage approach outlined above shares characteristics with, and offers benefits aligned to, the Use Modify Create (UMC) pedagogy [@lytle_use_2019-1] ⁵¹. Stage 1 uses playful game analysis as a precursor to game making [@cornish_game_2018]. Stage 2 and the design of the P2 starting game template helped participants rapidly build familiarity with code structures and tools (Use stage of UMC). Stage 3 aligns with Modify, where minimal changes have a large visual or behavioural impact, matching UMC’s guidance to “create choices that show visible and immediate changes” [@lytle_use_2019-1, p. 6]. The careful scaffolding of early coding experiences described earlier forced early and repeated transitions from use to modify, helping to overcome possible negative affect related to text-based coding. Stage 4 represents the most advanced level of this stage-based model. This includes implementing a more complex GDP from the menu (requiring new functions or significant changes to code). The decision to choose from a restricted set of options, rather than create from scratch, aligns with some adaptations of UMC. A further extension still would be the choice to imagine, design and implement a GDP not included in the menu provided, this is a process that Dan and Toby take on in P3 by adapting the code template to create a Pac-Man like maze game ⁵².

In this chapter the use of a design narrative processes informed by DBR practice [@hoadley_creating_2002] has been employed to share not only the detail of the resulting learning design but also the emerging tensions that drove them and replicable approach. With that aim in mind the following list shares links to currently online and reusable resources ⁵³.

P2-3 Starting Game Template: https://codepen.io/mrmick/pen/gbaOEgB?editors=0010
Menu of GDPs: https://jamm-labs.github.io/ggcp/ggc-examples/
Manual: http://3m.flossmanuals.net
Manual Splash page: https://jamm-labs.github.io/ggcp/manual

Given the close alignment in the structural model with UMC, the contribution to the research landscape in relation to this aspect of my thesis is in the guiding use of GDPs as a structural support to guide the development between stages. This aspect of the research is developed in Chapter 6.

Analysis and discussion in relation to existing research – half-baked and constructionist heuristics

There is strong alignment between the underlying principles of the learning design described above and research on constructionist design heuristics ⁵⁴. This part of the discussion briefly outlines these similarities using specific examples, and then explores a fundamental difference in approach related to the role of authenticity in the learning design. Of particular relevance is the constructionist principle to choose black boxes carefully [@resnick_reflections_2005]. Resnick et al. [-@resnick_reflections_2005] describe black boxes as abstractions that simplify or hide complex elements of the production process, creating a scaffolded learning experience while maintaining a boundary between the learner and the challenges of interactive professional coding communities ⁵⁵. Based on Laurillard’s [-@laurillard2020significance] interpretation of constructionist microworlds as being driven by affordances that support user experimentation and concept formation without relying on direct instruction, this learning design aligns with those core characteristics ⁵⁶.

However, the structure of the learning design should be interpreted as an adapted microworld, marked by greater authenticity and connection to professional coding environments and documentation. When compared to a classic microworld like LOGO’s Mathworld and its use of drawing turtles, my design is characterised by relatively porous boundaries between the structured learning environment and external, more authentic coding ecosystems.

One risk of using professional tools with novice learners is that they may experience a form of culture shock, encountering unfamiliar or alienating aspects of coding environments designed for experienced users. The learning design outlined in this chapter helps mitigate that initial shock through the scaffolded elements explored in Contradiction Area 1 (C1). Following Resnick, I still “choose black boxes carefully”, but my strategy differs: rather than shielding learners from authentic creative tools and communities, I provide guided and supported access to them. This represents a shift in emphasis from restriction to supported exposure.

In summary, the relationship between authentic tools and scaffolded processes is best understood here as a dialectical tension that should be accounted for, not avoided. The next section develops this point further using a metaphorical framing.

Synthesis of tensions and resolutions

To enable a summative view of the contradictions involved in the resulting learning design, Table 5.2 shows a summary of some of the barriers, congruencies, and tensions, alongside the design resolutions that emerged from the process.

Tension, Barrier or Congruence emerging in Game Making	How design addresses this issue [and location of supporting analysis]
Category One – Tool use for coding and asset creation processes
Congruence: Learners interested in video games are motivated to create their own game.	The use of a common game format helped address barriers to text coding, providing clear motivation in terms of a recognisable end goal.
Tension: Guidance is needed in order to make changes, but there is potential for learner disengagement if game coding is taught from first principles, especially for younger participants.	Learners start with a half-working minimal game template that requires only minimal code changes to produce noticeable in-game feedback.
Congruence: Learners interested in art want to create digital artwork to replace placeholder graphics.	An intuitive pixel art editor supports rapid character design, with clear code template signposting to help learners incorporate their artwork.
Category Two – Documentation and Navigation
Barrier: Learners take on game genres or features too complex for their current coding ability.	Game type is limited to a single genre; missions are capped in complexity. GDPs are scaffolded to start with low-threshold/high-impact patterns.
Tension: Learners become frustrated when they cannot choose their next feature; facilitator capacity is strained by diverse pathways.	A menu of GDPs enables learners to select additions in a flexible order. This supports autonomy and motivation while keeping complexity manageable.
Tension: Facilitators need to justify learning but may struggle to see it in situ if unfamiliar with game making. Formal skills frameworks can restrict flexibility.	A map of learning dimensions flexibly linked to GDPs and missions helps both learners and facilitators trace progress and identify learning.
Tension: Reflection and documentation are valuable but interrupt creative flow.	Learner progress is traced on an attractive physical map displayed in the learning space, integrating reflection into the making process.
Category Three – Social and cultural barriers
Congruence: Designing a game for a real audience is experienced as motivating.	Playtesting within sessions offers short-term motivation; end-of-project showcase events help learners prioritise and reflect on progress.
Barrier: Learners may feel alienated from coding culture or the tools themselves.	Relatable code structures and role-based fictional scenarios help reduce anxiety and encourage engagement through role-play.
Barrier: Participants may avoid written documentation or lack proactive planning skills.	Side missions and extended playtesting time support peer-to-peer sharing, allowing knowledge of GDPs and implementation techniques to circulate informally.

Table 5.2 – Table of emerging tensions and design responses

3M game making (Meta) model of pedagogical elements of the learning design

In summer 2020, I began early dissemination of results in a peer-reviewed book [@keane_teaching_2023]. The resulting chapter presented the essence of the learning resources and design to fellow practitioners, participants, and researchers [@chesterman_game_2023]. To do this, I framed key elements of the process used within the research phases as a pedagogic model I called 3M (Missions, Maps and Methods). This model is shared now as a facilitator-focused summary of key features and the motivations behind them.

Figure 5.x Synthesising diagram of 3M Game Making Model { width=80% }

Missions	Maps	Methods
Simple code changes yield quick feedback	A map of learning dimensions flexibly linked to main missions/patterns can be used by both learners and facilitators	Playtesting in each session aids short-term motivation. Showcase events help longer-term motivation and aid project prioritisation
Free choice of Patterns increases learner engagement and ownership	Tracing the learner pathway on an attractive physical map in the learning space can help integrate navigation and reflection into the creative process	Drama and fictional scenarios can help explore issues and reduce learner anxiety through coding in a role
Restrict game type and number of Patterns to reduce facilitator stress		Adding electronics to control the game via arcade buttons and cabinets increases engagement and perceptions of project authenticity
Limit complexity of patterns. Some are simple but cause a large change in the game
Side missions which explore and celebrate different approaches to making ( based on from Bartle’s player types [@schneider_analysis_2016])

Table 5.x – Key features of the 3M Game Making Model

Harbour metaphor

Building on earlier reflections on facilitation, a final analogy is offered here to illustrate how the design space balanced constraint and choice, structure and freedom: that of a harbour. Harbours are transitional spaces between land and sea, built to facilitate the movement of people and goods between these domains ⁵⁷. In this metaphor, the Microworld functions as a vehicle for exploration, forming the base of the learning experience. It is designed to support input from technical communities through the lens of the facilitator’s design experiences. This chapter has highlighted how input from professional communities was integrated into the Microworld vehicle of the starting template game. In addition, affordances within the template design and accompanying resources enabled participants to bring in interests from home into the new learning space.

Figure 5.x - Harbour metaphor {width=95%}

Figure 5.x shows a simplified representation of a harbour (centre), with land on the left and sea on the right. Harbours are protective spaces, artificial or naturally occurring, used as safe locations for docking ships. If artificial, protection is provided by walls that extend into the sea to create shelter ⁵⁸. In this metaphor, the harbour walls represent restrictive design decisions: the use of a fixed game genre and simplified code structures. While this design employs an authentic, professional text-coding language with its inherent challenges, many design choices were made to protect new users from the complexity of the underlying web technologies. The safe space of the harbour encourages free exploration within its walls, including collaboration with peers, use of bespoke documentation, and facilitator support.

Harbour walls block disruptive forces like large waves but leave gaps to allow ships to move into open waters ⁵⁹. The motivational potential of using authentic tools exists in tension with the complexity they bring [@nachtigall_authenticity_2024]. The learning design outlined here helps ease the transition from the protected harbour to the open seas of independent practice. The choppy waters beyond represent the challenges of interpreting and navigating professional-level documentation and community support ⁶⁰. This metaphor offers an accessible representation of the design responses to contradictions concerning authenticity. It also begins to show how carefully structured constraints can foster the creative potential for agency development [@rosso_creativity_2014], a theme explored in more detail in Chapter 7.

Chapter conclusion

This chapter has explored the complexity of the interacting tools and documentation as they evolved across different phases of the formative intervention process. It has described three contradictions that occurred during an iterative, phase-based approach informed by techniques of DBR and CHAT. The contradictions explored initially focused on technical and then more social dimensions of the learning design.

Regarding methodology, the emergent and mutual nature of this design process aligns with both DBR principles and CHAT concepts of transformation in tool use arising from both explicit and implicit feedback. The descriptions in this chapter also show that the process was demanding for participants. I was fortunate that the tenacious character of the participants in P1 helped mitigate the challenges posed by beginning with such an incomplete pedagogy. The design narrative above has acknowledged my active input into the direction of the process, in line with an active approach to steering the design towards collaborative learning opportunities [@stetsenko2020radical]. My reflective analysis within journal entries shows that, while this general direction was present from early stages, the on-going process also served to clarify my own guiding motivations behind each design shift ⁶¹.

My observations, supported in the following chapter, indicate that the use of a template and a collection of GDPs accelerated the uptake of certain coding fluency practices, which in turn increased the use of collaborative coding processes.

This chapter has explored the iterative development of the learning design, focusing on resolving barriers to coding and aligning with existing research principles, particularly the use-modify-create (UMC) process and constructionism. It emphasized the potential and challenges of leveraging professional tools within scaffolded environments, underscoring the pivotal role of learner-led design decisions in motivating coding practices and fostering social collaboration. Two key lines of inquiry that illuminate the cultural and social dimensions of game-making are explored in the chapters that follow. Chapter 7 examines the impact of emerging community processes on participants’ agency, while Chapter 6 employs video data to describe and analyse the diverse applications of GDPs.

Gilbert is the worsted name.

Footnotes

[^10:] See Chapter 2 for a full summary of the challenges of text coding and the ways code playground address them. Appendix D.1 gives more detail of my evaluation of the advantages of code playgrounds.

For a recap of benefits see Chapter 2.

All Vignettes are located in a special appendix called Appendix V. See Vignette 1 for a full version of Toby’s activity. ↩
Chapter 4 describes the phases in more depth. A summary of the tools used in described in more detail in Appendix 5.1.x. ↩
I make the following opening announcement “We’ve got this one final making session next and then, if you can make it, the Monday after we can play our games and we can share them with students. We can make the students frustrated when they can’t beat our games. It’s usually quite fun. So, if we can do that - same time next week let me know. So, we’ll keep trying to help you and yes good luck everyone!”. See Appendix.V for full context. I CAN’T FIND THIS ↩
The invite email is included within Appendix A. ↩
At this early stage, I termed this process following affinity paths, imagining some would be drawn to artwork, some to music creation and others to code problems solving. ↩
The process of playing games and analysing their component parts, guided by the Moveable Game Jam process is outlined in a way replicable by practitioners in Appendix Appendix D.2? themeing ↩
These low-tech activities involving diverse non-coding processes helped surface ideas, supported collaborative group dynamics, and eased participants into the creative space without the pressure of unfamiliar digital tools. They are described in more detail in section C3 later in this chapter. ↩
Reflections on this delay are included in Appendix D.1.a and reflect a convergence of my own tacit expectations to begin from first principles and my relative inexperience working in this area. ↩
Choice of phaser.js as a JavaScript framework is outlined in Chapter 1, and explored in more detail in Appendix D.1.? ↩
As of October 2025 it is still available to view and play - https://codepen.io/mrmick/pen/jaXzxw?editors=0010. ↩
The term HTML5 games is included here as it was relevant at the time. HTML5 became a buzzword for modern webpages which included dynamic content due to the presence of JavaScript and css technology. Code playgrounds, as described in Chapter 2, are online environments used to test, share or invite help from online users on complete or partial code projects or problems, primarily for web-based projects (for more detail see Appendix 5.tech) ↩
A fuller breakdown of the features of code playgrounds is included in Appendix D.1.? ↩
While I wanted participants to be able to follow their interests, this total dis-enagement with coding was not optimal as we will see in section C3. ↩
See Chapter 2 for outlines of tinkering or bricolage approaches [@bevan_learning_2015; @papert_epistemological_1990]. ↩
See appendix bee for an example. ↩
This email included in Appendix.email illustrates a pivotal moment in my understanding of the limits of my role as facilitator of an open process and the need to impose limitation. This aspect is explored later in section C3. ↩
Participants would try to jump up to the platforms in the game but find that they could not jump high enough ot progress. Figure 5.x 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 shows indicating how high the player character can jump. ↩
Tools used in P1 included several audio and music making tools, Scratch as a graphical editor, and varied non software tools. See Appendix D.1.? ↩
The structural decisions to support the use of a code playground are expanded with greater technical detail in Appendix D.1.? ↩
While a technical consideration beyond the scope of a non-technical reader this issue is significant for the participants experience. See Appendix D.1 game state for a technical exploration. ↩
Piskel is a pixel art graphical editor which participant both young and old appeared to find enjoyable and intuitive. See interview ? with Mark and Ed. ↩
An online version which is easy access both game and code is viewable here as of 29.10.25 https://codepen.io/mrmick/pen/gbaOEgB?editors=0010. For a more long-term link see https://github.com/glitch-game-club/simple-game-to-edit ↩
Syntax errors in computer coding equate to grammatical errors in other languages. They occur when code violates the rules of the programming language, such as missing punctuation, incorrect structure, or misspelled commands, preventing the program from running. ↩
The errors made therefore were the right kind of errors. An exploration of the diffent kinds of resulting errors adn the process of debugging in relation to the use of GDPs is explored in more detail in Chapter 6. ↩
In P1 there was a greater diversity in the underlying structure of the code projects as the starting template used at that stage was less developed. ↩
This form of teaching input took the form of facilitator-led instruction using a projection screen, powerpoint and demonstrations of coding issues and solutions that I judged were or would be relevant to most participants. ↩
While the term GDP has already been used in this thesis, as this stage for me there were still just game elements of features. WHERE TO DEVELOP THIS SHIFT? ↩
The time limitations one-off events at Mozilla conference (for technology educators), Feral Vector (for grass-roots game developers), and Manchester Libraries (local families) and for trainee computing teachers helped me distil the essence of the affordances into an accelerated process of getting started with the design process. ↩
A version of the quick start cards is available as part of Appendix.tech. ↩
Code snippets and their co-location within code playground tools are explained in Chapter 2. In short they are code examples extracted from context in a way designed to facilitate reuse and often shared online as a community resource. ↩
See opening chapters of https://3m.flossmanuals.net/ ↩
Mark and Ed described themselves as plodding throught that step by step documentations in Vignette ?. Writing these chapters prompted reflection balance structured guidance with choice-driven learning, which I describe within the manual as meeting yourself in the middle, reflecting that the starting chapters on foundational concepts were not designed to be read first. ↩
At this stage I suggest the reader take one minute to browse that experience at - https://jamm-labs.github.io/ggcp/ggc-examples/ ↩
The evolution and of this theming is outlined in more detail in Appendix 5.theming ↩
Evidence of this diversity is present in Chapter 6 and in the Vignette data in Appendix.V. ↩
The introduction gave an outline of cultural barriers to CGD&P. ↩
A process drama is a drama activity which engages participants in a scenario in which they engage with a wider activity in role. The process drama of Phase one is explored in Appendix X. ↩
The immediate tension that the diverse tool set brought was in how much time playing with such a diverse set of non-coding practices took. In addition the greater diversity reduced the possibility or at least the fluency of peer learning that happened in later phases. ↩
TRY TO SUMMARISE IMPACT HERE FOR C1&2? - Research particular on varied approaches to address alienation to coding games has been explored in Chapters 1 and 2. In particular see the work of by Kafai, Burke and Peppler [@kafai_constructionist_2015; @peppler_gaming_2009-1]. ↩
More detail of the engagement and disengagement of Anastasia’s family is described in the case study Appendix 5.bee, ↩
Fuller feedback is described in the Appendix 5.bee ↩
see playful.playtesting ↩
In SGD the concept of proximal flow links flow theory and social engagement within the learning [@basawapatna_zones_2013]. ↩
The drama scenario was based on the techniques of undertaking a process within drama which I had explored in previous work with Manchester Met Drama education department [@caldwell_drama_2019]. See Appendix D.? for more information. And literature on Mantle of the Expert (website) ↩
Side missions or side quests are a concept from video games involving exploration. They complement main missions and offer greater choice over player experience. ↩
The drama narrative builds on existing work of Rebecca Patterson, Alison and myself [caldwell_drama_2019] involving a process of coding in role, which extends better know idea of writing within a dramatic role. ↩
The term map of learning dimensions . The map includes: computational thinking, systems thinking, computing concepts and practices. In Chapter 6, I present a framework of concepts. ↩
While the learning resources of P2 and P3, which is analysed in depth are explored in more detail, those developed in D3 for P4 and P5 are relevant as a more suited to classrooms and therefore greater interplay with the learning map of curricular concepts. ↩
Using several large sheets of flip chart paper, I created a large scale map charting the different GDPs within an island landscape. Participants created avatars to represent themselves and positioned them on the pattern they were currently working towards. While I reflected in notes that the process was potentially useful for reflection, and peer positioning, the process lacked repeated engagement. ↩
The process of having to change the underlying structure of the template in P1 was something that one group found particularly jarring. An experience outlined in interview data (Maggie 1) and in Appendix.tech ↩
These include, greater syntax support, etc. FINISH ↩
Pac-Man is a maze game where the decision to break out of the paragdim of the platformer game showed significant participant agency and is detailed in Vignette 6. ↩
A fuller design summary which includes the P1 template and previous iterations is included as Appendix. D.1.a and is available online here. These resources are freely downloadable, and adaptable in line with the ethos of open educational resources. ↩
These design heuristics present in decisions made in creating microworld environments, the development of Scratch software, and constructionist gaming research include: principles of low floors, wide walls, high ceilings, open windows and choosing black boxes carefully (see Chapter 2 for a summary). ↩
Black box decisions steer learners toward exploring preferred concepts. Papert’s [-@papert_mindstorms_1980] work on Turtle control in LOGO exemplifies this approach, using abstraction to focus on powerful mathematical ideas. ↩
In my design, the Phaser game-making code library framework serves this purpose by managing underlying structures for gravity and physics calculations necessary for object collisions. In addition, my starting game template further simplified these processes by allowing participants to modify gravity settings through a single variable, thus combining professional coding language use with an accessible learning experience. ↩
Harbours provide opportunities for loading, refuelling, or maintaining sea vessels. In addition, harbour transport infrastructures may be present to provide connections to inland rail or road links. Various structures exist, such as gang planks, gantries, and cranes to assist the importing of goods, vehicles, and people onto the ships. ↩
The term harbour is also used metaphorically to indicate a space of safety, nurturing, or a gathering space for a community. ↩
In early stages, the process of clicking remix to expose the underlying code and try to fix and improve an incomplete game exposes a new frontier language of text code which for many will involves entering unfamiliar waters. ↩
An example of this being Toby and Dan (in Vignette 6) who, in their choice to change the game genre from platformer to maze game, leave the safety of a set of design patterns and paired support documentation. A process explored in more detail in Chapter 6. ↩
These reflections on my own deeper motivations are explored in the discussion section of Chapter 6 in relations to the complex and expanded object of activity of this research. ARE THEY? ↩

5. Findings - Design Narrative