Exploration of the Formative Learning Design Process

Exploration of the Formative Learning Design Process

Research Questions - April 2024

~1. What pedagogical tools and processes are available to support novices to overcome barriers to participation in game coding processes?~

What ~barriers~ area of contradictions arose in participation in this research’s game coding processes and what pedagogical tools and processes are available to address these contradictions?
How can game design patterns support the development of coding practices with novices?
How can learners build agency in an evolving community of game makers?

A note on style

This chapter contains a large number of headings in draft form. These will be replaced with introductory sentences when structure is stable.

Chapter Introduction

This chapter contains a high level of detail on the technical elements of the learning design to situate the findings of the next chapter and to allow the design to be by other practitioners and researchers in this area. The format of this chapter can be conceived as a design narrative [@hoadley_creating_2002]. To do to this I include narrative descriptions of shifts between phases of design as it mutually evolved over time. The concept of design narrative emerged from DBR as a way to communicate the important detail of context [@hoadley_creating_2002; @brase_knowledge_2024; @bell_theoretical_2004;]. While DBR has its own language of argumentation [@brase_knowledge_2024] in this chapter creates a design narrative using the rich set of descriptive and analytical tools provided by third generation activity theory (3GAT). Specifically this chapter identifies, key activity units/systems, names system elements, addresses the evolution of the key pedagogical features of the tools of learning design used in my research process using analysis of elements of nested activity systems and emerging tensions in learning design.

Firstly, I describe activity systems at different scopes, focusing on the objective of participants and drawing on a vignette illustrating indicative participant activity.

Following this, I explore emerging tensions in design in a way which communicates relevant context through the analysis of three areas of emerging contradictions in activity. Instead of a more technical definition [@engestrom_discursive_2011], here, in line with Kutti [-@kuutti_activity_1995], the term area of contradictions is used as a wrapper for more specific tensions, barriers, breakdowns, conflicts that indicate an “unfit with (system) elements . NOTE THIS NEEDS TO BE JUSTIFIED

Three main areas of contradictions are explored in this chapter are as follows.

Contradictions arising in use of coding tool use and game asset creation - often experienced as more individual level

Contradictions associated with project navigation and the use of supporting documentation: interpreted here through the lens of guided participation

Responding to contradictions in cultural aspects of the game making activity: In this section, I examine the impact of a process drama with an aim to establish and nurture community practice, exploring the value of introducing almost-real processes, near authentic tools and the possibility of learners developing learning identities within a drama frame. This chapter ends with a synthesis to initial barriers to engaging in game making practices and initial interventions to address them.

MOVE TO DISCUSSION IF THERE IS A SUITABLE SPACE The drama process is an example of an introduced cultural tool. The process acts as wrapper to several supporting techniques. the side missions to and to sanction different approaches, the imagined audience encourages reflection and semi-authentic approaches. It is the most advanced tools of a range that was put into place to create a space suitable for creativity, collaboration and self expression.

Analysis of dimensions of game making activity using 3GAT framework

In line with the process outlined in chapter 3, the following sections outline different scopes of activity, at times using detail from vignettes described in the appendix to describe the activity of participants and to introduce tensions between system elements which are explored in this chapter.

Environmental factors and objectives

In socio-cultural approaches is it important to situate the context of the learning environment within wider systems of activity. In line with Engestrom’s concept of shared object explored in the previous chapter [@engestrom_expansive_2001], I have selected several relevant systems and represented them in an illustration 4.x below.

This diagram is necessary simplification of contextual factors and objectives of interacting, focusing on research goals on the part of the researcher, learning computing skills and concepts as a home education project and finally a broad aim of fun on the part of the children participants. In the previous chapter we explored the technique of describing a shared object. The utility of this approach is to acknowledge and represent the diverse cultural contextual factors that are played out in a new space between diverse actors with different agendas.

Illustration 4.x - Broad Environmental Activity Systems {width=95%}

In this research I take the approach of treating this shared object as an activity system in its own right. Lecusay takes a similar approach [@lecusay_telementoring_2015] and describes the shared object as an ideocultural hybrid which develops into its own activity system. The concept of ideoculture is used in this study to deepen the description of the community dimension of 3GAT.

Following Barab’s description of nested activity systems [-@barab_using_2002], this shared system, whose objective is to make a games for an audience to play, can be seen not only as nested within the wider systems but also as a container for other activity systems nested with that. While this overall approach is considered valid [FIND OTHER SUPPORT], the danger of fragmenting activity to much is to make matters confusing. The job of the researcher is to prioritise systems to describe and analyse based on the area of study and the concerns of the participants. This prioritisation in AT is sometimes conceptualised as the process of finding a key units of analysis. In the process of research I have found two units of activity particularly illuminating, one being the shared activity system described above of making a game in a community process. The other, narrower in scope can be described as implementing individual game features. Beyond these key systems, I draw on the concepts of actions and operations within systems to describe tensions and contradictions which emerge in the research process [-@leontiev_activity_2009].

Broader activity system - a novice game making community making games as a learning experience

Illustration 4.x - Larger game making activity system {width=95%}

There are diverse end audiences for the games. The final target audience are students and staff in the Manchester Met Brooks building where the created games are shared in arcade cabinets at the end of the programme. An additional audience are friends and family who can be send the games to play online. The more immediate audience for the evolving games are peer game makers during the making sessions.

Carrot eater game with an self made arcade unit made from cardboard boxes {width=90%}

While the broad aim of making a game to share is agreed through participation, there are also diverse motivations stemming from environmental factors in the interrelated actors in this activity which feed into the contradictions which emerge at this level of activity.

Illustrative vignette on participants activity indicating general activity of participants

The purpose of this vignette is to illustrate some of the key features of the overall game making activity in relation to activity systems and relevant system elements. (included as an appendix of this chapter as Appendix 4.a - Link to online version here)

The participant, a child Toby, has been working independently on the design of a platform game for several minutes of the session. As a facilitator, I draw the participants attention to the showcasing of their games to an external audience to focus their attention on completion of their games. Toby pays close attention to the challenge and variety of the game playing experience for his imagined audience of players. During the course of the session Toby invites many other group members to play his game. He initiates and responds to conversations around the difficultly of the game he has designed. The more immediate audience of his peers is clearly important to him in guiding his actions.

He uses a variety of tools in the process of coding and testing his game including: a web based coding tool (code playground), a game template which he has used as the base of his game project and, a menu of documentation linking to code examples and tutorials test

While this vignette shows that the participant has developed fluid use of both software tools and documentation and support sources, these are areas where significant contradictions emerged which shaped the path of the support given. Contradictions concerned with use of core tools and additional documentation and support are explored in two later sections of this chapter.

The later section of the vignette shows evidence of elements of an emerging ideoculture of this group. A student helper shares a question - “Is yours the one where level one is harder than level three?”. This is indicative of some of the emerging playful approaches that younger participants in particular are taking to the overall process. This represents an example of the influence of the wider systems of play of on the shared ideoculture of the game making commmunity. The complexities of processes to create adn to help resolve contradictions as this cultural domain of collective making are explored later in this chapter.

Constructing a game feature by feature

Within the activity system of making a game, in analysis of video data and evolution of course resources from P2 onwards, I identified activity happening at an individual or pair work which emerged with distinctive characteristics.

Activity was driven by learners setting goals, requesting help and then implement code structures based around altering or adding new features to the game using tools available in the learning environment. Participants also worked on audio and graphical assets to achieve this objective.

While is it possible, aligning with Levontev, to identify the implementation of features as actions within the wider activity, there is value in treating of implementing each GDP as a sub-project or activity systems in its own right ( NOTE - or at least as as a key unit of analysis). Barab and colleagues justify smaller units in their study observing emerging practices in a technology rich learning environment [@barab_using_2002]. QUOTE?

Mid-level activity system of game making {width=95%}

Later in this chapter we examine in more detail the emergence of game design patterns as shared concepts and the implications for activity in more depth. At this stage is it sufficient to stage that game design patterns emerged as a shared object as descbed by Engestrom in x.

INSERT ENG’S DIAGRAM HERE FOR NOW - AND CALL BACK TO PREVIOUS CHAPTER.

DEVELOP THIS IDEA HERE OR MOVE IT TO DISCUSSION WITH SOME KIND OF SIGNPOSTING HERE.

Illustration 4.x - Shared object of implementing GDP {width=95%}

This diagram above helps illustrates that the object of activity here is not only the code and game assets which participants are working on. In addition the emerging concept and group understanding of the game design pattern becomes a share understanding on a community level as playtesing, pair work and peer help happens.

Objectives at this level also vary between participants with some more straight-forward and others more tricky based on their making style. For example, beyond a purely utilitarian objective, a further objective in implementing a GDP, e.g. a new graphical element may be to increase a sense of personal identificaiton with the game as an vehicle for personal expression. MOVE OR EXPLAIN

ALTER THE DIAGRAMS ABOVE TO REFLECT THIS.

An illustrative example of the use of the diverse tool set merits a summary before further discussion in this chapter. By this stage of the process, Toby is able to browse a collection of game design patterns and use diverse of tools, resources and processes. Participants developed preferred approaches and tool choices especially in accessing help when adding a new feature to their game. In the vignette 4.a I outline the two main sources of help at the level of adding a new feature to the game: “Here’s the tutorial and there’s the examples of code”. In the course of the vignette above, Toby chose to access only a code example of the desired game behaviour. He did not, as some in the group were doing in this session, use the tutorial which provided more descriptive, step-by-step guidance. Other participants relied only on direct verbal help from myself or other participants (like Toby) to help them progress.

A later section of this chapter details the different supporting documentation guiding participation in game making practices. Chapter five then explores activity occurring at this scope in more detail with a greater focus on emerging concepts as tools.

Smaller objectives and actions - Implementing discrete code and design structures

Within the objective of adding or altering game features (also referred to as game design patterns here), implementing more complicated patterns involved several stages and varied tools. Using the terminology of Leontiev [-@leontiev_activity_2009], participants undertakes certain chains of processes in a fluid way that shows that actions had become operations (as explored in chapter three). In vignette 4.x, an example of such an operation is Toby’s quick navigation between different areas of the game code, the game preview window and other sources of documentation. In contrast, some tasks are new to Toby and are performed more hesitantly. In the vignette’s description, it can be observed that at times Toby is careful and hesitant, checking and rechecking the process of copying and pasting new code into his game from the code example of a design pattern he has chosen.

Identifying shifts in participant activity in terms of scope facilitates analysis of the complex and interwoven cultural, social and personal actions in a communities activity [@rogoff_observing_1995]. Above, Toby shifts between the wider activity of making a game and sharing it with peers and narrower actions implementing concrete code structures. This aspect is developed in chapter five.

In addition to these shifts in scope, analysis of community processes also involves transformation over time. The next section offers a description of the evolution of tool use in different phases of the study with an aim to situate analysis of emerging tensions in the use of tools, resources and processes in the following section.

Applying activity theory to surface contradictions and design tensions experienced by participants and facilitator/s

The followings sections use a process of analysis of contradictions between system elements of the activity systems outlined above. The processes is a formative intervention (explored in chapter three) in that the surfacing of tensions due to changes in the learning design over time are examined. As noted in the introduction, this chapter explores the following areas of contradictions: contradictions in the technical tool use of design, contradictions shaping the development of supporting documentation, contradictions to do with issues of identity and the cultural dimension of participation.

<!– Including Coding Concepts in the LearninThe later section of the vignette shows evidence of elements of an emerging ideoculture of this group. A student helper shares a question - “Is yours the one where level one is harder than level three?”. This is indicative of some of the emerging playful approaches that younger participants in particular are taking to the overall process. This represents an example of the influence of the wider systems of play of on the shared ideoculture of the game making commmunity. The complexities of processes to create adn to help resolve contradictions as this cultural domain of collective making are explored later in this chapter. g Map and including Code Cards with links to online Concepts

Recap here the choice of coding concepts rather that CT in more abstract terms.

Make Code cards which contained links to game design patterns and the different component concepts
(see Eriksson and Bjork)
Draw on material and critique in chapter on semantic profiles / waves. –>

Summative narrative description of evolution by phaser

I feel here a tension in communicating clearly and retaining some of the surprise of a narrative. I feel like this table tells the story too soon.

A similar table in the previous chapter table of phases this one is about tool and documentation use in particular. For completeness and data replicability, and as a practice of openly sharing educational resources. A fuller table in the appendix links to different online versions of documentation and tools uses. All are free and as based on web standards are unlikely to decay, a process that unfortunately occurs too often, making replicating or even investigating out of curiosity the tools used in may studies impossible.

Description	Starting Resources
P1: Oct 2017 - Dec 2018; Experimental Course	Participants started with no set plan or toolset and were asked to plan and make a game in two larger groups of 5-6 participants of mixed ages. After several weeks, a minimal incomplete starting game code template was introduced in response to student need. Then One-off workshops at Mozilla and Feral Vector conferences and to PGCE computer students and the creation of a “half baked” game template	Phaser 2.6.2 javascript library; Thimble code playground; online graphics editor Piskel; audio creation tools
P2: Jan - Feb 2019; Glitch Game Club	First iteration of game making course of 5-6 weeks. The template and resources created in the previous stage were used as a starting point but continued to evolve.	Phaser; Glitch, Piskel; updated game template; quick start cards; step-by-step tutorials; code examples
P3: May 2019; Glitch Game Club 2	Second iteration of game making course with additional drama and reflective elements	As per P3; drama scenario; interactive chat page in glitch
P4: Jan 2020 - September 2020; Make Code Arcade	Two iterations of game making course of 5-6 weeks using MakeCode Arcade tool.	Make Code Arcade (MCA) tool; MCA Template starting game; MCA quick start cards; MCA game pattern menu; MCA game pattern tutorials; Learning Dimensions Map

Contradictions involving the use of game programming and asset authoring tools

Addressing contradictions arising in use of coding tool use and game asset creation - often experienced as more individual level

Activity theory has a broad definition of the concept of tool which in this context would include the use of language, concepts, supporting resources and production processes. While forms of documentation and supporting resources are explored in the following section, this section focuses on software tools and code framework used to create games in this program.

Situating tool use by phase

Insert table of tool use or link to this as an appendix.

Narrative description of the area of contradiction

Contradictions arose between the need of participants to use key tools to create games and their lack of experience of them. Thus crux of the conflict is that coding games to create a webpage using a text environment is a complex process. In early stages, this gulf created a tension between the need to use the tools and text coding processes which often resulted in frustration and paralysis in the activity of game coding. While this is to be expected given the novice status of the participants, contextual factors complicate this contradiction further. For example, the process of helping participants build familiarity and competency in tool use was further complicated by my own motivations for working with as authentic as practical game authoring tools (explored in the introduction).

While, gaps in knowledge and practice are commonly addressed in formal learning environments through forms of instruction, the informal nature of this learning setting encouraged me to prioritise approaches which avoided written or to whole class instruction. My motivations here were also supported by experiences in P1 documented in my journal. I found attempts to convene attention on a presentation screen for instruction based teaching to class uncomfortable, stemming from my judgement that these interventions to be unwelcome interruptions for the participants making activities.

The resulted in a design challenge involved designing a bespoke game authoring environment by adapting existing tools and embedding where possible affordances within that toolset to facilitate participants to address gaps in their knowledge without needing explicit instruction. The following sections explore the evolution of the tool selection and the tool use of participants in response to this conflict in the game making activity system.

Using a starter game template

FOCUS ON THE TENSION FIRST AND SHIFT FROM P1 -> P2

By P2, learners first experience of the experience of the tools was in the process of playing an incomplete game in a webpage and controlling the character using the computers arrow/ cursor keys which for many was a familiar process. Due to an intentional fault, players needed to click a remix button, and alter the underlying code to progress in the game. The following section outlines responsive design process surrounding two main elements: the starting game code template and the code authoring toolset.

The initial use of a working structural template was an intuitive response based on my own experience of teaching technology. The choice to pre-select a particular genre was initially a pragmatic response to tensions experienced in P1. When offering feedback to address her family’s feeling of isolation from the coding process, the parent of the family described in part two of this section had more hands on play and use of the tools of production before being called on to make creative decision, likening this to an arts studio approach.

I realised that to allow for this playful experimentation, a purely structural template was insufficient and that a working game template was preferred. To create the template I drew on the structure of online starter templates from several sources to create a minimal template for a two-dimensional platformer game.

Structural design of the game template

A web code project using the chosen game framework phaser consists of several interlinked files of Javascript, HTML and CSS and image files. (see glossary & appendix 4.x)

simple game template {width=95%}

4.x glitch coding environment with code structure of left menu, a central code window with code, comments and game preview on the right.

Javascript file which participants alter to make changes to their game
Html page within which the game is embeded (not usually altered by participants)
Css style sheet (not usually altered by participants)
Code editing area
Game preview area

While access to HTML and CSS files of the base project was available in the left menu as show in by default participants would see only the JavaScript file names game.js .

Variable editing for player movement

To accelerate and support the experimentation of users, I identified changes to the code that were easily recognisable game experience features and where small changes could provoke a high impact on the game experiences. These include changing gravity, altering the player jump height and walking speed.

The starting template began with the game in a broken state thus inviting players to modify the game to fix it. The player’s maximum jump trajectory was not sufficient to progress via a jump to the first platform. To progress, participants needed to change alter at least one of the key variables were highlighted at the very start of the game code (see Figure above). In their research Kynigos and colleagues [-@kynigos_children_2018] explore this concept as a half-baked games where incompleteness or bugs in behaviour are a provocation to participants to correct or to further modify them. This process also aligns with the motivations and techniques of the UMC framework explored in the literature review , in particular the guideline to “create choices that show visible and immediate changes” [@lytle_use_2019-1, p. 6]. In this design, the first participant choice and the need to transition from the use to modify stages is forced at an early stage by the half-baked design. While this design decision compromises the user choice initially, it allows a carefully scaffolding of early coding experiences and promotes a shared experience for all participants in a way which facilitates and encourages peer learning. After this shared first change, participants next choices varied greatly. While some participants engaged with extensive experimentation to find a player movement feel that seemed just right, others, mostly adults or younger participants, were much less concerned with this aspect of game play, despite sometime frustrating resulting player movement. Data explored in the next chapter supports foundational claims of contructionist computing and UMC advocates that greater user choice over the design process contributes to participant motivational and a feeling ownership of their projects [@lytle_use_2019; @peppler_computer_2009]

The process here began with me imagining what would be a good feature that players would notice and be spurred to change. Here, the deliberately unsuitable game variable is a key affordance of this half-baked game template. Descriptions of other key affodances follow (NOT GRAPHICS NOW? ADD A MENTION?).

Simple block graphics

The use of blocks of text invited Their size of 32 x 32 was also design to reduce friction in teh creative process as this was the default size of Piskel.

One of the complications encountered in P1 was the differing sizes of sprites created using different graphical tools. I helped resolve this for participants by matching the size of the block in the grid level design structure described above to the default size of sprites created in Piskel (32 x 32 pixels). This is one example of many small technical alignments which addressed and helped resolve practical obstacles that participants experienced.

NOTE - Make link with later section

Level design and prototyping

The use of a graphical grid structure to edit level design helped balance concerns of accessibility with the use of authentic code language.

Platform games often conform to certain patterns in terms of the elements involved in a level and their affordances. Common elements include the player that you control to movement of, platforms to be jumped on, enemies to be avoided and rewards to be collected. In the templated used in P1 the process of adding game elements was involved relatively complex process which involved changing parameters of functions to alter to adjust their location. An example of the code needed is included one of my tutorial chapters / appendix 4.x ¹.

Complexities included: adding function parameters for screen coordinates which made it tricky for participants to intuitively place game elements where they wanted them; each element needs to be added separately; difficulties concerning adding graphical elements of different sizes; in addition for each element added different code elements needed to be added to three different functions in the code.

These complexities created barriers and frustrations into the game making activity at a stage which in P1 accumulated into a risk of participants giving up at worst or significantly reduced a participants experience of computational fluidity (as explored in the literature review) at best.

The complexities outlined above are addressed in GUI oriented tools like Unity through the use of a concept called tilemaps [@erhard-olsson_procedural_2018]. This design choice allowed alignment with design principles for tools for novice coders, in particular the importance of visual approach to facilitate the programming multi-media projects for novices [@guzdial_programming_2004; @resnick_scratch:_2009]. While such an approach was possible graphical based tools like Scratch, this was in conflict with my motivation to use authentic, text-based tools.

In P2, I revised the starting template to created game elements was based on a visual design in a grid format (see figure 4.x below) which replicated some of the use of use of tilemap technique within the text code format. Changes to the text based grid in the code area on the left would be immediately seen in the right hand project preview area.

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

This solution abstracted away complexity of asset placement to prioritise ease of use to help sustain participant engagement. Technically, this approach involves the construction of a data array for each level of 17 blocks which can be one of the following: x (platform); h (hazard); o (coin); or could be left blank (see Figure 4.x above). The end result was that while participants altered a text-based array, the grid structure had a strong visual correlation with the resulting game layout. This adaptation had a positive impact on engagement with level design in initial stages. Many participants spending significant time and effort undertaking many iterations of changes to the level design. In the vignette in appendix 4.x referenced above, Toby designed many levels making the game very challenging but still technically possible. Participants varied in their approach to level design, some drew on their experiences to mirrors platform game conventions, while others enjoyed working against these conventions, a theme which is explored in more detail in chapter five. DEVELOP THIS SOMEHOW.

Thus, here a technical approach helped resolve tension described above. Black boxing the process of adding assets via x,y coordinates and reducing repetitive process.

Design adaptations to facilitate novice use of a code playground

Code playgrounds, as described in chapter two, are an online environment used to test, share or invite help from online users. My choice to use a text code environment risked maximising barriers to participation by not profiting from design decisions in specialist coding software to help novice coders (previously explored in LR). These elements include steps to reducing syntax errors, shielding complexity, facilitating community commenting, sharing, remixing and other forms of collaboration. Learning computer coding presents challenges in part due to unfamiliarity with and potential complexity of code authoring tools and environments [@guzdial_programming_2004]. To shed light on this conflict and to situate later findings, this section surfaces observations from my journal notes and video data on how participants responded the tools introduced and my design adaptations.

DROPPED THE REMIXING / SHOWCASE - COMMENT / SUMMARISE?

THE IDEA BEING HOW CAN THE IDEAS OF CONSTRUCTIONIST TOOL KITS INTO THIS TOOL SET - PERHAPS PICK UP IN OBSERVATIONS SECTION. CHECK THE MOVED SECTION IN CHAPTER 6 NOW.

Remixing and community inspiration

The literature review outlined that one of the key principles of constructionist approach is promoting community inspiration and interaction. In the Scratch community this is achieved through and extensive online community which encourages remixing, collaboration and peer review via comments [ @monroy-hernandez_cooperation_nodate; @cress_supporting_2016].

The shared community element on the other hand was quite different for glitch.com web playground tool due to its very mixed user base and range of different web based projects. In this learning design I took a decision to not promote this online community as a source of inspiration and code bases. Instead one code base was promoted. Sharing of ideas and inspiration did happen both on the playtesting of each others games and via incidental exposure to the online work of others. This happened as they shared log account details and thus when logging in to access their own work they would also see and have access to the code and graphical creations of others. I took advantage of this shared access in shared socThus affordance ial and playful missions which are described later in this chapter.

Addressing code syntax errors

COMPRESS AND LINK TO ABOVE PARAGRAPH

Many software projects aimed at for novices use visual coding (block coding) approaches to reduce complexities of code use [@bau_learnable_2017; @resnick_scratch:_2009]. This process reduced possibilities for syntax errors (see glossary) and often provides a limited set of blocks to reduce complexity. While this approach not explored here for reasons previously outlined, there are some features of the glitch code playground which help. For example, the environment can detect the file type as javascript from the file extension and then uses a static analysis tool (linter) scan the code for signs of inconsistencies of code and syntax errors and highlight them [@tomasdottir_why_2017].

In glitch such code syntax errors are highlighted via a red dot provided a quick visual indication of where the error occurred. In addition if the user hovered over the dot would give an error message. In analysis of pair interactions, I frequently [how much from video data] observed the non-coding peer notice and point out the red dot, thus preventing further errors.

ADD IN HOW FREQUENTLY THE PARTICIPANTS DID USE THIS.

DESCRIPTION OF MY INTERVENTION. At times when addressing code snags experienced by participants I would scan the code looking for the red dots and drawing attention to them.

If this was not helpful I would also use the console of the in-built developer tools of the browser [@collins_crossfire_2011-1].

Distributed vs. self-contained approaches to asset creation

A key element of game creation is the creation and management of graphical and audio assets. Many coding tools for novices provide a library of prebuilt assets and tools within the environment to alter or creation graphical and audio multimedia assets to facilitate and accelerate the creation of games and coding projects. While there are practical limits to the audio and graphical authoring capabilities of tools like Scratch [@payne2019music], such self-contained approached reduce possibility for compounding errors and complexity caused by the compatibility of file formats and migration and management of external asset files.

There has been extensive research supporting the motivational value of the ability for young people to bring their interests into multi-media creations via choice of assets and narratives [@kajamaa_digital_2018; @resnick2014give; @peppler_supergoo_2007]. In line with these findings, I observed a palpable a sense of achievement when participants succeeded in seeing and hearing their creations in their game after making the final changes in code. For some, the sense of a achievement appeared magnified by difficulty caused by the unfamiliar environment and processes. EVIDENCE?

THE BENEFITS OF ASSET CREATION AS A WAY TO INCORPORATE FUNDS OF KNOWLEDGE - WHERE IS THIS EXPLORED.

In P1 I observed participant showing a high motivation to incorporate assets. Responding to the enthusiasm of participants in asset creation, I had introduced six additional software tools to participants including tools for pixel art, sound editing, sound creation. A table of the different tools is included as appendix 4.x

A summative timeline is included as a diagram.

Similar patterns of use emerged. Participants would identify the need for an asset in their game. They would then use the separate software to create that asset, and the be supported to save assets to their computer’s hard drive in a compatible format. They would then need to upload assets to the code playground environment, discover the text link of the asset, and then insert that link into the main JavaScript game file at the relevant line of code. Undertaking the full process involved learning a complex chain of these individual actions. Some participants became remarkably adapt at this, thus transforming this chain of actions into a fluid operation. Thus, the distributed nature of the toolset used helped build authentic digital literacy skills.

Despite this benefits, I was concerned that in P1 the diversity of asset creation tools approaches was over complicated and risked distracting time and attention from other code-based actions involved in the activity of game making. Thus, in P2 I reduced the number of suggested assets creating tools.

This tension can be described as a play paradox. WHERE IS THIS FIRST INTRODUCED I was looking to avoid too much time spent in asset creation at the expense of other processes which would develop coding concepts and practices. It also increased the possibility of peer learning as less tools were being used.

ALSO NEEDED TO CHANGE DUE TO THE CHANGE IN GROUP WORK DESCRIBED LATER.

Use of Piskel

START WITH SHIFT FROM P1 DIVERSITY TO P2 FOCUSED & OVERCOMING PRACTICAL BARRIERS.

A pixel art approach to graphics allowed a balance between the potential for positive engagement with game making and the potential drain of time to this one activity, thus helping resolve one of the tensions emerging in P1. Piskel had proved to be intuitive for many younger participants with three main areas: a set of editing tools; a canvas for creation; and a set of tools to export, save and import work (see Figure 4.x).

{width=95%} Figure 4.x - Interface of Piskelapp tool

Participants spent a widely different length of time creating these graphics for a variety of reasons. Some took a long time to master the process of using the editing tool while others created images rapidly but would keep redesigning and recreating their game elements. The process of game art creation opportunities seeding narrative and artistic creativity is explored in more detail in chapter five.

–>

Observations on the game template and core tools

The previous sections have outlined changes to the core tool use including the use of a starter game template which I enacted to address the struggles participants had in becoming accustomed to game making. Despite the relative simplicity of the highlighted affordances outlined above, complex and divergent patterns of design behaviour began to emerge. Small code changes resulted in potentially large changes in game behaviour, appearance and difficulty aligns with a long standing concept of HCI research that feedback is motivating for system users [@bernhaupt_introduction_2015; @malone_heuristics_1982]. In addition, the use of revised in starter template in P2 allowed participants to maintain their games in a mainly working, shareable state allowing regular feedback from peers. The use of a starting template was inline with core motivations of UMC technique, namely, to build familiarity with the code structure, and confidence in use of tools in an accelerated way. As explored above, the shift in template design from P1 to P2 involved a much more careful and structured experience for participants in use and modify stages.

Despite these modifications, participants still needed help to access and use the relevant affordances in code template. In early trials with a limited number of families in late P1, I would point out the relevant part of the code and ask open questions e.g. ‘I wonder what would happen if you changed that gravity variable?’ However, for larger groups this was not optimal, risking leaving some unsupported. My response was to turn to supporting documentation. In addition, participants soon began to ask how to make modifications to the game which needed additional code structures, a development signifying a pivot to the create phase on the UMC model. The next section explores similar tensions related to the role of supporting resources and documentation.

- Contradictions associated with project navigation and the use of supporting documentation - interpreted here through the lens of guided participation

PERHAPS INCLUDE TIMELINE OF DOCUMENTATION IN HERE - THERE IS AN EXTENDED TABLE IN APPENDIX 4.X

Narrative pm the evolution of resources during P2

This section details a conflict where participants, frequently wanted to add new features or changes to their game but were not clear how to implement them. In P1 this caused delays and participant frustration, as although I could work with people directly to help them I had limited time with each participant or pair. The inability for participants progress due to lack of game and coding practices was compounded in early stages by little or no supporting documentation or supporting resources. This section outlines the evolutions and design choices informing the different forms of supporting documentation used to address this conflict.

The process of creating documentation which created enough support for users to be able complete coding tasks but also facilitated participants to choose their on path presented significant challenges.

MENTION HERE THE DISTINCTION BETWEEN PRIMARY AND SECONDARY USE OF TOOLS DUAL STIMULATION? SOME DISCUSSION MOVED TO CHAPTER 6 ALREADY - MOVE IT BACK HERE?

Quick Start Cards

To address the limit of one-to-one facilitator support to seed the starting processes outlined in the section above, I used printable resources which highlighted the key lines of code and how they can be altered to impact on game behaviour(see figure 4.x below). These quick start cards provoked a strongly scaffolded initial interaction with the code in a way strongly aligned with the use and modify stages of the UMC framework [@franklin_analysis_2020].

{width=95%} 4.x - Example of a Quick start card

The quick start cares were created at the end of P1 by trainee computing teachers in my faculty who volunteered to support a holiday outreach event for young people. I developed them by theming them into starting level, next level and boss level. Participants were encouraged to pick a card based on their interest and difficulty level.

Code snippet examples

The use of code snippets, while a promising authentic practice, presented initial challenges. To support a hands-on approach and responding the design choices of participants, I began by creating discreet code examples illustrating the requested elements. The use of code examples or snippets in code playgrounds is a common professional problem solving practice [@yang_stack_2017]. These code examples allow users to see the behaviour in context with the code and output side by side. While code examples existed on the Phaser website and support forums, in line with other support sites like stack exchange, their utility has limitations including lack of relevant, consistency, being removed from the domain context, and not being structured in a self explanatory way [@treude_understanding_2017]. Thus, while I initially encouraged participants to search within these examples, and authentic documentation and help forums, the resulting confusion and difficulties experienced by participants, prompted me to create other more bespoke documentation.

Creating a bespoke set of code snippets helped address the challenges described above. In P1 I responded by creating one off documents with the relevant code which were both printed, emailed and shared via google drive. In line with the practice of accessing help via code snippets, the code examples could be to be copied and pasted into the game. This process lacked coherent process for participants to navigation to the resource they need. The process also lacked a consistency in signposting how the code listed fit within the existing structure. To help students see the code in the correct structure, I began to create code snippets within code playgrounds and distinct project. These projects shared the structure of starter game template and added only the code needed for the additional requested functionality. My rationale was that each pattern added builds familiarity with the code structure, a theory supported by observations of Toby’s proficiency in the vignette above.

Structuring instructional tutorial chapters

For each code example I created descriptive step-by-step documentation which in P2 were developed into chapters of an online book ². Each code snippet linked to a descriptive chapter. These chapters attempted to balance an informal, hands-on approach over pre-teaching concepts, with the request from some from parents in the feedback to P1 (see appendix 4.x) to provide background concepts and explanations of coding constructs. To address this tension, in addition to self-contained chapter focused on instrumental code changes needed to implement game features, I created opening chapters of the online manual which were more traditional in format and explained underlying concepts that the starting template had initially abstracted away from the participants.

Introducing documentation created additional tensions in the learning activity, specifically, I observed users failing or struggling to find the right resources online. This prompted me to design and introduce a themed hub for both snippets and tutorial chapters. My aim was to mitigate potential learner alienation from unfamiliar technical documentation through accessible design and to relating documentation to participants existing gameplay experience rather than underlying coding constructs. While time consuming, the process of aligning documentation, code snippets with more general concepts of game analysis, served to simplify the navigation of documentation. The guiding principle is that key affordances of the supporting secondary stimuli are designed to closely align with the objectives of leading activity at the predominant scope of activity.

Pattern Collection {width=95%}

INTRO SENTENCE

The process of theming the patterns has the potential to develop the community knowledge of game making concepts [@holopainen2007teaching]. In grouping the game design patterns into categories for the documentation hub page, I drew on academic and professional interpretations of game elements [@salen_game_2006; @schell_art_2008; @tekinbas_rules_2003]. Schnell’s detailed analysis of tens of game elements presented as design lenses was too complex for this audience. Instead, I adapted a simplified introductory framework developed for use in youth-oriented Game Jams to help novice game makers hack/analysis and then adapt key elements of non-digital games [@cornish_game_2018].

SPACE: Where the game takes place.
GOAL: What is the objective of the game? What are you trying to do?
COMPONENTS: What are all the objects or actors in the game?
MECHANICS: What actions take place in the game. What are the verbs involved?
RULES: What can or can’t you do in the game? What defines boundaries? Does play happen in real time or do you take turns?

The framework youth game jams and in the Q2L school to help participants develop their implicit knowledge of game design concepts in to explicit share vocabulary before engaging in digital making via collaborative analysis of common games [@cornish_game_2018; @institute_of_play_gamestar_nodate]. Similarly, in early stages of my design participants completed a similar activity after playing retro arcade games [included in appendix].

I related this simple categorisation the emerging list of requests for game features made by my participants.

Game Mechanics	Game Polish	Game Space	Challenge Systems
Jumping on Enemies	polish.	New levels	New levels

This categorisation, while simplified, is consistent with professional and technical frameworks popular in game making communities including: the MDA framework [@olsson2014conceptual] (which focuses on analysis of games based on the user experience), Elemental Tetrad [@schell_art_2008], and DDE [@korn_design_2017]. The theme of using technical frameworks in an accessible way to facilitate the creations of novice participants is continued in the chapters five and six.

Responding to tensions and barriers in cultural aspects of the game making activity

Narrative summary of conflict:

Design narrative on conflict due to identity clashes and dysfunctional group work

MAKE MORE OF THE P1 -> P2 SHIFT AT START

Shift from p1 - p2 -

This experience aligns with research in this area explored in the literature review which explore pedagogies to address barriers concerning identity and technology-driven practices [@kafai_constructionist_2015-1]. These contradictions involved accumulating tensions which resulted in families feeling anxiety and alienation from the group coding environment and associated peer working dynamics. My journal notes see an evolution of attempts to try to build into the program, activities which help build the participants sense of their own identities of game makers or more generally digital designers. These are detailed later.

I illustrate this conflict using the experience of one family who withdrew from P1 three weeks before the end of the programme. While members of this family were able to engage in planing via sketching on paper and in creating pixel art, in later stages they were reliant on others to implement code changes. The freedom of choice and imagination allowed by designing on paper and via pixel art created compounding tensions. One crisis point involved a frustration of a child who was not able to implement a feature they wanted to add to the game next. A 3d bee design roaming a 3D landscape. I encouraged personal expression for the purposes of engagement and motivation. However, here it can lead to conflict and frustration as the desired changes of the child were not realistic to the technical scope of the project. The previous section explored the use of two dimensional (2D) platformer game as a technical template in P2. I also addressed participant expectations of an acceptable project scope for our timeframe as a non technical process.

When the family withdrew, they shared in feedback (see appendix 4.x) the moment that decided their withdrawal. that at one point they “looked around and just saw people doing hardcore coding and no longer felt that they belonged”. In the end stages of the game production process, due to the dynamic of the larger group, they were reliant on others to implement code changes for their imagined game, unable to contribute fully at this point and found themselves isolated. Thus a contributing factor to this families alienation were tensions engendered by the large group size and compounded by frustrations stemming from unfamiliarity with tools and processes. In participant feedback, the parent of this family described in the previous section indicated that it took too long before in the planning stage and called for more hands on play and use of the tools of production before being called on to make creative decisions. The parent likened this to an arts studio approach. This feedback contributed to choices outlined in other sections of this chapter. (WHICH ONES)

Some barriers stemming from alienation from participant group working processes were resolved partly by freeing up some patterns of collaboration and interaction and removing others.

The process of parents getting in the way of children’s not minding jumping in and invading social space struck me. Together with the frustrations of complexities of larger group work the restrictions created a tension between the suggested community norm of how division of labour was organised.

Thus in P2, rather than the larger groups of P1, smaller groups, allowing some children to work by themselves and others with parents. Avoiding large group fragmentation and encouraging freedom of participation vs benefiting from parental involvement.

P2 introduced some of the changes

Keeping games working to allow for less frustation - this promoted more playtestin time. explored next.

DROP - COMPRESS - CONCLUSION? The incident lead me to greater reflection on ongoing measures needed to prevent participant drop out for due to cultural tensions and negative affect to the working community. These include:

An awareness of the danger that those more confident in coding create more involved code problems that need more facilitator time, potentially making others feel less valued.
A concern for the fragility of learners positive affect towards the group game making process and thus the need for initial playful starting and closing activities to be continued beyond initial sessions.
The value of a stronger buy-in by participants, ideally a greater commitment to the collective making process balanced with the need for low pressure (avoiding a negative sense of obligation).

REMOVED

COMPLETELY REMOVED SECTION ON PHYSICAL MAPS

Playtesting as a cultural process

As explored in the literature review, playtesing is a process common to game making which corresponds to the evaluation phase of design thinking cycles. BE SURE TO CHECK THAT IT IS!

By the time video data recording started in phase three there were already complex patterns of playtesting underway. In this section, I review data to describe some of the emerging playtesting behaviours of participants.

In journal notes, I observed that the shift of process from a more open creation in p1 one to the use of a half-baked templated greatly increased the amount of time participants spent playtesting their own and other games. This is implicit in the process of starting from a broadly functional game.

NOTE - can support or discussion based on the research on UMC [-@lytle_use_2019-1] or that of half baked games [@grizioti_game_2018-1] be of use here. As a facilitator I would note my own concern if errors compounded to make the participants game unplayable for any extended time.

Participants, particularly older ones, used playtesting as a way of showing support for fellow game makers. Example behaviours included: praising graphical content; making links with home interests of participants through questioning; and building rapport.

Molly in particular used playtesting to show her appreciation of the graphical work of others especially in the creation of cute animal characters. In response to one game which featured an image of a dog, other participants asked: Do you like dogs? Do you have a dog at home?.

Playtesting and embodied participation in the games of others

Some children added additional playful elements to playtesting. Because these interactions were mobile between works is it hard to extract audio and transcribe their speech. However, it is possible to communicate the characteristics of this play via a description of a typical encounter and the gestures of participants.

WATCH MORE CLOSELY AND TRANSCRIBE GESTURES

Play is initiated by calling across the room as an invitation to play, or as a provocation. When playtesting is underway it is normally undertaken with two or three participants standing around the computer rather than being seated. The core of those involved take turns to play the game, exclaiming frustration or triumph at completing levels or failing. Failure may be extremely performative with a rapid pulling way from the screen and keyboard. This may be followed with a battle to wrestle control of the keyboard to play the game next. This may involving playful pushing, and wrestling of hands and arms and vocalisations. While this play is happening it may attract other participants who remain on outskirts of the activity looking on able to watch what is happening on the screen and respond non-verbally with smiles or laughs.

These changes to the form and function of playtesting by young participants is another example of expression of agency by participants that widens the scope of possibility of actions.

The process of play testing as a cultural process is explored in more depth in chapter six.

Local playtesting rather than participation with a wider online community

There is convincing research on on how online community can engender feelings of agency and motivation . FIND THIS - ROQUE AND ITO AND GEE. Thus, a possible question to level at the evolution of this design is why not engage with online communities as a form of authentic audience and as source of feedback as explored in the Scratch and New Grounds community websites.

A primary concern here were the time consideration of the process of being involved in an online community may remove time spent doing real life playtesting. Also there is a danger that, the diversity of creations available on a online community could remove the more communal experience of the designed limitations.

More pragmatically, in this situation the use of a more professional framework, and a lack of dedicated site run for children reduced the scope for this kind of interaction.

Shift to P3 Drama process and what kind of Maker are you

By the end of p2 most of the tools and main processes were in place.

But I still felt tensions around introducing reflective processes and wanted to de-centre myself where possible from a teacher position.

Before talking about drama process which addressed this in varies ways.

A smaller intervention was a game and at kind of player are you.

A game introduced in P2 where participants took part in an interactive the Bartle test. The Bartle test draws on work which …

The full process and rationale and initial reactions are detailed in appendix 4.x . In summary,

After the process I then proposed that there different game maker types and asked participants to evaluate and discuss with peers what kind of game maker they were. From the following list.

Social makers: form relationships with other game makers and players by finding out more about their work and telling stories in their game -
Planners: like to study to get a full knowledge of the tools and what is possible before they build up their game step-by-step
Magpie makers: like trying out lots of different things and happy to borrow code, images and sound from anywhere for quick results
Glitchers: mess around with the code trying to see if they can break it interesting ways and cause a bit of havoc for other users

This simple question “What kind of game maker are you?” - is a good indicator to others that you are trying to create a space where different approaches are possible and celebrated.

I incorporated it into an animation of the resources home page.

Illustration 4.x - What kind of game maker are you {width=95%}

On a drama processes

The introduction of a drama process was introduced in response to a the barriers to participation caused by not identifying with the culture of coding or gaming.

My journal notes detail an evolution of attempts to try to build into the program, activities which help build the participants sense of their own identities of game makers or more generally digital designers. In and early tentative attempt to define in broad strokes the types of game maker behaviour and underlying goals, taking inspiration from Bartle’s game player types [@hamari_player_2014], idenifying social makers, planners, magpies and glitchers. See appendix 4.x . I saw potential value here to address internal bias about the kind of process that a computer programmer should adopt, echoing the call for pluralism in approaches [@papert_epistemological_1990]. In P2 I introduced a starter game which celebrated different game playing and making types which is also described in appendix 4.x. In P3 the underlying ideas were incorporated into the process drama described in the next section.

Description drama process using extracts from vignettes and concepts of MoE

The drama process involved a fictional frame of aliens coming to judge the earth. An extract of how I introduce the drama frame, the main and side missions is included as appendix 4.x. Below is a short extract of the overall mission.

We have some guidelines:

  • Make a game about a big or small problem for your planet to solve. If you can let us play it each week as you go along.
  • Give us an update each week by recording a group update.
  • Show you can work on your own but also work as part of a team.
  • We will also send you text messages with some mini-missions sometimes. Be sure to tell us how you do.

Please now get started and come up with a new game about solving a problem on Earth.

Extract from Appendix 4.x: Vignette of introduction of the drama process

The process of introducing a scenario for participant to respond to is common in project based learning in this vignette. Here it is extended using a dramatic element in line with Heathcote on Mantle of the Expert (MoE) and other process drama techniques (explored in Lit Review). The following section outlines key characteristics MoE [@aitken_dorothy_2013] in context.

Contracting into drama

As a facilitator, I indicate that we are entering a dramatic process and attempt to draw everyone into a commitment to the process. The collusion is noted by both parents and children in recorded exchanges. For example, after engaging with a code example provided by myself in the role of the aliens, one pair make the following comment.

Parent: Look, this is what Mick’s showed, what Mick’s has done.

Child: The Weean have done!

Parent: The Weean, sorry yes.

Facilitator activities in role

My role is a link between the participant and the fictional commissioners of the games. The transcript in appendix 4.1.a details an example of extended facilitator input as instruction. As a practitioner in this setting, I had tried to limit teacher instruction and to outline boundaries to prevent learner disengagement. However some input was needed to help address the previously explored tension choice with over-ambition, and signpost participants to needed documentation. The drama narrative helped resolve some of this personal tension by allowing me using the dramatic commission as a foil to help avoid the encounter feeling personally controlling [heathcote_drama_1985]. CLARIFY - EXTERNALISING LIMITS TO ACTIVITY

Learner activities in role

Beyond the wider fictional frame of the making activity, learners were also sometimes asked to undertake some activities in role, in particular reflection in role. This and other example are explored via vignette 4.1.b.

Vignette 4.1.b illustrates this process. In the extract participants are invited to take turns showing their game, recapping their progress and outlining next steps to the alien observers. I play the role as a liaison facilitating the process for the fictional, remote audience. I also draw attention to the secret missions that had been distributed to participants, which along with social missions are explored in the following section.

Use of side missions to encourage varied creative practices

One of the activities that participants carried out within the frame of the drama process was the undertaking of side-missions. These missions encouraged community-focused patterns of behaviour which I had observed in previous iterations of game making and via the game on playing and making types described above. These were activities not directly related to game making process. They were designed to encourage the exploration of the games of others, to encourage a playful approach. I had identified these behaviours as potentially helpful in maintaining the positive affect and identification with the on-going group process of game making. An extract of the table of both social and secret missions follows (a full table is available as Appendix 4.x). These mission were printed out on cards and one of each type was given to the participants in the first half of the first two sessions.

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 being made.	Change of the images in someone else’s project to a totally different image and see if they notice.
Find out the favourite computer games of 4 people.	Change the level design of the first level of someone else’s project to make it impossible but try to change as little as possible to do that.

These activities were undertaken by most of the participants. In analysis of one key sessions involving missions from which the transcript was taken. Out of 10 participants, 8 visibly engaged with the secret missions during the session.

The process was not without friction. While the some of the secret missions encouraged forms of disruptive play, griefing of playing against the game [@bakioglu_spectacular_2008; @bartle_hearts_nodate]. While this increases engagement for some learners, the process also suffered the danger that participants transgress levels of cheekiness and play which explores boundaries, to more disruptive ones. In this context this involved frustration and wasted time for other users. After initially engaging with the process of secret games, Toby and Dave, who were later working on a tricky coding process, expressed frustration at interference.

Thus, while promising, limits to this process should be evaluated to avoid overly disruptive behaviour which create barriers to progress. For example, time limits could be in place.

This chapter makes limited claims in terms of the effectiveness of this process due to limits in terms of data gathering. However, it can make a claim that this activity has significant potential. HOW EXACTLY?

In summary, this activity helped addresses one of the key barriers to taking part in a coding community that of alienation from the culture of coding. The use of missions introduced by facilitator are taken up voluntarily by participants and aimed to address conflicts caused by identity clashes by recognising and encouraging diverse making approaches and styles of community participation.

The positive reaction of young people to the drama process was also picked up in interview data.

Mark: Tell us about the Weean?
Ed: er.
Mark: What did you like about the Weean?
Ed: Just very silly and I don't know. They answered your questions.
Mark: Was it, because there was a sense of play, a bit of fun and a bit of anarchy.
Ed: Yeah.
Mark: What else can you tell us about the Weean?
Ed: er.
Mark: There was the little sabotage things you had to do as well.
Ed: Yeah
Mark: So you liked those games where you had to kind of hack somebody else?
Ed: Yeah
...
Mark: The Weean thing was, I think, a massive hit for everybody because it just brought sense of play and fun. And it took attention away from it being overtly technical. Brought a personal element in and obviously that anarchy. Kids love the absurd.

Observations on written interactions with the alien in the drama

As previously explored, an emerging area of tensions that I noted in journal notes and in feedback from participants was the area of supporting documentation and resources. In addition to the careful technical and pedagogical creation and organisation of resources undertaken in P2, I sought a way for participants to be aware of and access relevant documentation without interrupting their creative flow or the fun of the experiences.

In P1 I created a mailing list for participants to ask technical and code questions of the wider group. My aim was to create a peer community helping each other rather than a helping relationship only between myself and individuals. However, this email list was hardly used for this purpose. Two parents shared that they were reluctant to bother other participants with their own issues. To address this in P3, as part of the drama process, I encouraged participants to write to the aliens to ask help. This is described and illustrated in appendix 4.x.

As well as exploring documentation and accessing technical help within the drama frame, student also engaged in playful dialogue with the aliens unrelated to game making. The process of asking the aliens for technical help within a code project sparked a playful process of informal chatting with the aliens. This chat began to fulfil a function of building insider rapport, creating a fun atmosphere, celebrating the completion of games in the absence of a public showcase, and signposting the achievements of other participants.

The process started with supportive and celebratory messages posted from the alien. The impact was significant with the young people with 5 out of 7 engaging by writing messages and all mentioning the interactions verbally during the session. <!– To do this in a way that encouraged other participants to join in, I created a project in the shared coding project area with a webpage that could be edited and viewed by participants. When in the vignette 4.1.b Mark asks “We’d like to ask the Weean some more questions (to overcome coding blockages), is that the best way to do it?”, he is referring to this project webpage. The process of writing down a text request encourages the adoption of professional practice of asking a written question to overcome a coding problem and thus builds experience of using technical terms. Undertaking it in-role potentially addresses the barrier of asking for help by de-personalising the process.

Dan and Toby also received written help from the aliens to implement a pattern of creating random movement in their pac-man clone game. For this pair, the process of following a code suggestion from the aliens gives the parent opportunity to deconstruct the code in detail to explore coding concepts. In later discussion, Dan uses the fiction of the alien when asking a clarifying question.

"Mick, do you think the aliens would mind if we get rid of the switch statement and replace it with some if-thens? They're just showing off these aliens aren't they?"

Here the text dialogue with the aliens is used as a mediating artefact first by the facilitator to share help in-role, and then by a parent to suggest a modification to the code syntax to create more readable code structure for novices.

While this aspect of the drama process was introduced by the facilitator, in alignment with the understanding of Sannino’s concepts of transformative agency through double stimulation (TADS) participants transform the function of the alien conversation to their own purposes. This theme is developed in the next section. –> <!– Playful dialogue with the aliens unrelated to game making

The process of asking the aliens for technical help within a code project sparked a playful process of informal chatting with the aliens.

This chat began to fulfil a function of building insider rapport, creating a fun atmosphere, celebrating the completion of games in the absence of a public showcase, and signposting the achievements of other participants. For some pairs, while the child interacted in the live chat, parents performed final tweaks to code projects and challenges. Two parents in particular worked hard debugging more complex elements of the game with facilitators and peers. Other parents engaged with the chat and encouraged their children to get feedback from the aliens about their game in particular.

Concluding remarks on process drama

While inspired by the work on Heathcote on Mantle of the Expert, not all element of the process align directly. For example, the drama does not try to position the participants as expert game makers in a professional context.

This section has explored the use of the possibilities of a drama process to support both the leaner expression of agency and as a pedagogical process for facilitators to militate probable conflicts and obstacles for learners in the creative process. The mission-based interventions began as naturally occurring expression of learner agency which became incorporated into the drama process.

The impact of time pressure to finish games also compounded tensions involving shifting away from game making to reflective activities. Even with the use of reflection in role, reflection activity was not prioritised in final sessions as time drew short.

This aligns with existing research addressing the barriers to effective reflection and meta-cognition on PBL processes. NOTE - EXPLORE THIS IN LR AND DISCUSSION IF KEEPING THIS.

Chapter Discussion

NOTE - MOVED A SECTION ON THE EMERGENT DESIGN TO METHODOLOGY

In summary, this chapter has explored the complexity of the interacting tools and documentation in relation to their authenticity and impact on participant experiences. While the use of authentic tools and processes, while challenging for novices, can be facilitated by careful alignment of key design principles. However, some barriers involving social and cultural factors suited interventions of other pedagogies. In later chapters I explore the interaction between authenticity and agency in more depth using the emerging pedagogies as an analytical lens.

Summary of barriers and tensions explored in this chapter

The following summary table lists barriers and tensions drawn from the literature review that were significant when reviewing my journal observations, feedback from participants and video data. The purpose of this summary is to help recap and ground the reader before exploring the experiences of participants in more detail in chapters five and six. It focuses on use of tools but also signposts some social and cultural elements.

Barrier / Tension	Description	Related Intervention
Alienation from culture of computer coding	As outlined in literature review.	Use of games, play testing and other social approaches. Explored in chapter six
Unfamiliarity with group project management	Tensions arising through group miscommunication in P1	Avoiding large groups from P2 onwards, and starting with a half-baked game template which individuals or pair used as a base.
Unfamiliarity with language and syntax	Example: Javascript use of punctuation especially in arrays and in the structuring of functions.	Use of UMC pedagogy and quick start examples to build familiarity
Unfamiliarity with coding concepts	Example: the use of if statements and global variables	A starting template with much of the needed code in place, facilitator explanation when concepts are met in-situ, supporting documentation to reinforce previous experimentation
Lack of direct knowledge of game making conventions and experience of game analysis	e.g. common game programming patterns	Games and activities to access and surface tacit knowledge, use of a structured GDP collection to reinforce concepts
Tension between pre-choosing game genre and allowing for flexible choice of participants	Example of the family wanting to make a 3D exploration game, but my in ability to support that	Introduction of the templated 2D platformer in a half-baked stage to create an engaging first impression, and ability to quickly personalise the game to increase participants’ feelings of ownership over it
Tension between teaching the programming of game states and the complexity it introduced	e.g. play state, settings page, welcome screen, game over screen	Introducing one state in the game code thus allowing extension, but not drawing attention to it
Tension between engagement value of providing a wide range distributed we production tools and complexity and disunity it induced	e.g. move from diverse tools used in P1 to one raphical editor and one audio tool in P2	Restriction prioritised to encourage group work, as engagement was already high
Tension between the use of professional coding tools which increase authenticity at the prices of greater learning curve in adoption	While suitable open source tools exist, they need careful curation by facilitators to reduce cognitive load	Design of template to surface key affordances to mitigate barriers to use and start usage patterns.
Tension between producing extensive and varied documentation to support the different design choices of users and the increased complexity of navigation of the learning experience this brings	The process of finding and following documentation was patchy	Resources were provided in a menu form linking to both code snippets and instructions

Different areas of contradictions between different elements in activity systems emerged in journal notes and retropective analysis of evolution of the design. Some blockages were non-technical including hunger or grumpyness between participants, others were due to lack of access to the right tools or understanding of processes, others were particular types of coding error. I propose that more granular understanding of different kinds of design blocks can help facilitators and ultimately learners in building agency in their response to them.

Additional tensions to integrate

There’s a tension of not wanting to jump in to teach CT concepts, or to force reflection on progress. Understandable not to want to interupt flow. It is not needed in terms of testing or curriculum here. This is an adaption where I project into the experience of participants and pick up on reluctance to step away from the ongoing coding and creative or playful tasks at hand. I adapted to end of session reflection on most sessions. I also did not draw attention to extra resources outlining formal frameworks. Although step by step instructions which did outline them in situ were available. Here I worked to remove barriers to accessing CT as a framework via resource creation which aligned to experience. But their agency is expressed through disinterest and reluctance in participation. This transform conceptions of the activity as I give up CT as a framework which guides the objective. Instead using GDPS as one more aligned with their interests and need to develop fluency in non-conceptual coding practices.

Also, the drama frame was able to address of of the tensions which emerge - but these are mention only in summary here as they are explored in more depth in discussion in chater six.

Exploring dimensions of these barriers through the lens of agency and authenticity

Briefly outline, the relationship of agency and (authenticity in relation to AT and other relevant literature pbl)?

Focus on agency. And springboarding to the next two chapters.

Some barriers outlined were addressed in a way which created adaptions to the design which facilitated participation by making the process more supported. These include ; unfamiliarity with coding concepts,

The adaptations of to these tools can be conceived of as increasing instrumental agency by removing the need to understand concepts or use tools which were beyond the skill level of the participants.

Other tensions were resolved with more fundamental shifts to the overall structure of the activity which can be said to align more closely with the concept of transformative (authorial agency) agency. IS THIS TRUE - NOT MUCH IS IN THE TABLE ABOVE - WHAT ARE EXAMPLES? EXAMPLES ALIGN BETTER WITH EMERGENT USE OF GDP CODED IN NEXT CHAPTER - SO PERHAPS CONTRAST THIS AND USE AS THE TRANSITION.

Link to next chapter

This chapter has dealt with the evolution of design in initial phases and responses to learner experience to resolve tensions. A key focus of this chapter has been barriers to computer coding and use of particular software. I have explored alignment with the results of extensive research from the constructionist school. While much the focus of much constructionist research is on the design of toolsets to facilitate to personal knowledge building and expression via open project work, more recent work from researchers in this school has started to embrace the value of situated, community driven production as a lens [@kafai_theory_2020]. One of my central proposals regarding the methodology of this thesis is that while under-explored in this area, there is great potential in collaborative design based approaches to uncover situated and emergent practices in a way that can help seed community activity by other facilitators.

The following chapters have a focus on this gap. The next chapter explores a potentially fruitful aspect to help guidance for educational practitioners. The use of a design pattern approach. In this study the patterns take the form of working with common game elements game design patterns. In the language of the theoretical framework, I explore the process of working with GPDs as a germ cell of the overall game making activity. Chapter six explores the delivery and start to explore the impact of the process drama used and emerging community processes on cultural dimensions of the game making activity.

Gilbert is the worsted name.

https://en.flossmanuals.net/phaser-game-making-in-glitch/_full/#create-a-game-space ↩
https://en.flossmanuals.net/phaser-game-making-in-glitch/_full/ ↩