Appendices

On Structure of Appendices & Vignettes

Vignettes: Vignettes contain extended transcription of discourse and when possible participant gestures and inline commentary. Vignettes are contained in a special appendix section.

  • Recruitment & administrative
  • Methodology section
  • Interviews, smaller vignettes, & specialist findings
  • Learning design
  • Technical appendices - links to online material.

Appendix A: Ethics and recruitment

A2: Game Making Club follow up email

My name is Mick Chesterman. I am a tutor and PhD student in the Manchester Met Faculty of Education. I am looking for families to take part in a Game Making club to learn how to make video games together.

The weekly game making activities start on take place on _____ and the Manchester Met Brooks campus and will last until ________.

These activities are part of a study looking at collaboration, creativity and problem solving in a family learning environment. Taking part in the study will involve some of the sessions being recorded and some interviews with you about your experiences. More details will be provided as part of a fuller participant information sheet.

If you do not wish to be a part of this study that’s not a problem. You should still apply to take part as one version of the club will not be a part of the study. This version of the club will undertake equivalent activities.

To register your interest in taking part. Please email me on m.chesterman@mmu.ac.uk

Many Thanks

Mick Chesterman.

Appendix A3: Full Participant Information Sheets

Investigating the Potential of Family Game Making to Support Collaborative Production: Participatory research with Families

A3a. Information Sheet for Parents

You and your child/children are being invited to be involved in this research study. Before you decide whether you want your child to take part, it is important for you to understand why the research is being done and what your participation will involve. Please take time to read the following information carefully to help you decide whether you wish to take part. If anything is unclear or if you would like more information please contact Mick Chesterman (email: m.chesterman@mmu.ac.uk)

What is the purpose of the study?

The project hopes to understand the process of making digital games. Two or more family members will join a larger group to explore creativity and problem solving in this context. The aim is that this understanding will help inform good practice for wider game making activities as part of family learning projects and venue programmes.

What will participation involve?

We would like to observe you and your child/children’s participation in an approximately 8-week (2 hours per week) game making programme. The activities are designed to support participants to review and make your own digital games that can be played on web browsers. Some of the work will involve using paper, pens, textiles, and other materials to make picture prototypes and generate sounds to include in the games created.

These sessions will occur during Autumn 2019 / 2020 at Manchester Metropolitan University (Brooks Building) during school time, facilitated by the researcher. You will be expected to accompany your child/children and participate in the activities.

There are no known risks, inconveniences or direct benefits, although we expect participants may increase their understanding of game making concepts and practices.

All written, drawn and material artefacts produced will be treated as research data. The researcher will make descriptive notes during sessions. Some activities will also be audio and video recorded. These recordings may be used for reflective interviews. These interviews will also be audio recorded, with the content analysed to inform reports or academic publications.

Approximately three weeks after the sessions are complete, each family unit will be invited to a follow-up interview.

Identities will be kept confidential through coding and the use of pseudonyms. Any images used in reports will be altered using Photoshop to create anonymised line art sketches. Video used in research presentations will be edited to maximise anonymity. All data will be stored on a password-protected external drive in a locked office at MMU.

Please note:

  • Names will be removed from all data, and information will be anonymised.
  • If there is any risk of indirect identification, we will consult with you.
  • You and your child can withdraw at any time by emailing Mick Chesterman.
  • If you withdraw, your data will not be analysed, and you may still take part in other activities.

Who to contact

For questions about the study:

  • Mick Chesterman, ESRI, MMU, Room 1.43, Birley Building
  • Email: m.chesterman@mmu.ac.uk
  • Phone: +44 161 124 72060

To raise a concern:

  • Prof Ricardo Nemirovsky, Faculty Ethics Committee
  • Email: r.nemirovsky@mmu.ac.uk

A3b. Information Sheet for Young Participants

Dear Student,

We are asking you to take part in a research project called Investigating the Potential of Family Game Making to Support Collaborative Production. We’re interested in how young people and their family members can work together to solve problems and create new ideas when making simple video games.

If you agree to join in, you and other students will come to Manchester Metropolitan University with your parent or guardian. You will use fun equipment and technology to explore and make digital games.

These activities will happen over about 8 days. Your parent or guardian will be with you the whole time and take you to and from the university.

We will video and record what happens while you work together and on the computer. When we show or write about the project, we’ll change your name and turn any pictures of you into cartoon-style line drawings, so no one knows it’s you.

If you change your mind, you can stop taking part at any time. Just tell us or let your parent or guardian know.

Questions?

  • Call: +44 161 124 72060
  • Email: Mick Chesterman (m.chesterman@mmu.ac.uk)

A3c. Information Sheet for Practitioners

You are being invited to take part in a research study. Before you decide, it’s important you understand why the research is being done and what it will involve. If anything is unclear or you want more information, please contact Mick Chesterman (m.chesterman@mmu.ac.uk).

What is the purpose of the study?

he project explores how families make digital games together and how this process supports collaboration. The goal is to develop good practice for family learning and public programme delivery.

Why have you been chosen?

You have experience working with different age groups in digital game making. Your insights are valuable for the study.

This is a personal academic study. Whether or not you participate will have no bearing on your professional relationship with MMU.

What will participation involve?

You will take part in an interview about your experience, held at MMU or another convenient location. The interview will be audio recorded, and notes will be taken. These will be used to inform the researcher’s doctoral thesis and related academic work.

Participation is voluntary. You can withdraw at any time, and any data already collected will be destroyed and excluded from analysis.

Who to contact

For questions about the study:

  • Mick Chesterman, ESRI, MMU, Room 1.43, Birley Building
  • Email: m.chesterman@mmu.ac.uk
  • Phone: +44 161 124 72060

To raise a concern:

  • Prof Ricardo Nemirovsky, Faculty Ethics Committee
  • Email: r.nemirovsky@mmu.ac.uk

Appendix B: Methodology contributions

Appendix B.1: Video data analysis workflow and methodological adaptations

The table below outlines the main techniques and strategies used across the three stages of video data analysis in this study. It summarises how different tools, formats, and frameworks were employed in response to the evolving demands of the dataset, including screen capture and 360° footage. While the methods described here were specific to this project’s context, they offer a potential model for other researchers working in complex, real-world learning environments where formal software tools may fall short. The emphasis on pragmatism, triangulation, and iterative adaptation aligns with the ethos of DBR and sociocultural research.

Summary table of data analysis of video data

The table below provides an initial summary of approaches employed at different stages of the data analysis process in relation to video data used. The purpose of this summary is to provide a summary of the process o

Stage Technique Description
1 & 2 Making observations of activity based on 3 planes approach (& practicalities) Dipping into screen capture and 360 footage (VLC player) helped inform the smaller subsequent selection of data.

Observations stored in an Excel spreadsheet and separate Word documents on tensions and barriers in activity.
2 Transcription of activity and conversations Simultaneous viewing of screen capture and 360 footage.

Actions and extracts of conversations recorded into a Word document.

For the individual/pair, their activity was split into 5-minute sections and recorded in a Word document, time-coded via a grid table format.
2 Exploratory Thematic Clustering Eight screen capture/360 files from five group sessions analysed.

The process was complicated by the video file formats and their extended length.

Activity was coded based on an evolving schema including design cycle stages, participant interactions, and game elements participants were working on.
3 Revised Thematic Clustering Video capture and 360 data in NVivo.

Twelve screen capture/360 files from five group sessions analyzed.

A revised thematic analysis focused on different uses of game design patterns (GDPs) and dimensions of participant agency.
3 Choosing and transcribing vignettes Simultaneous viewing of screen capture and 360 footage in VLC player.

Practitioner interviews also reviewed in VLC player.

Four vignettes chosen and transcribed.

Full transcription for a limited time period including description and commentary on non-verbal aspects like movement and gesture.

Provides deeper insight into pair processes and individual experiences.

Additional summary of phases of this study’s methodology

D1 Before engaging with families in P1 I followed tutorials on Mozilla’s developer community website on writing games in javascript. I had used Mozilla’s Thimble code playground tool in earlier work teaching javascript, a snapshot of which is available as PGCE dissertation [@chesterman_webmaking_2015].

P1 was an extended, exploratory series of game making sessions over several months. This stage was aimed not at collecting user data rather than building my competency as a facilitator. The process began with no pre-existing supporting materials or clearly defined limitations. At the end of this stage participants showcased their games to students in the foyer of the MMU Brooks building.

D2: One-off workshops at Mozilla, Feral Vector and Manchester libraries events and to PGCE computer students helped focus and the creation of a game template and supporting resources.

P2, A game making course of 6 weeks. The template and resources created D2 were used as a starting point but still under rapid development based on informal participant feedback and my journal reflections.

Direct input was through requests and informal feedback and structured end-of-course interviews. Indirect input came from research data in the form on the games participants created, my research journal entries on my interactions with and observations of participants and recorded audio and video data of the participants and their computer screen capture.

P3 used the same toolset as P2 however in addition, drew on my previous work with the MMU Faculty of Education drama department [@caldwell_drama_2019] to create a simple drama process to give an external motivation and narrative to the creation of games using for a fictional audience of visiting aliens. The participant activity of these stages and tensions between system elements are discussed in detail in the remainder of this chapter and in following chapters.

The last iterations of the learning design adopted the MakeCode Arcade tool as a new game authoring tool [mc]. I adapted and advanced resources with an aim that they could be used within secondary classrooms to support computing curriculum. The facilitation techniques and approach were adapted from those of P2 to facilitate the use of the block coding language . Tool use at this stage is also explored in a chapter in a collection on K-12 computing education [@chesterman_game_2023].

B.x Methodology - Extract of 5 minute transcripts

Timespan Content
15:00.0 - 20:00.0 Fok -

Ed is looking for an animation frame already created

Mark still reading documentation on how to add animation to a character.

Mark: Quite complicated. But we can do it. But it would mean a lot of mucking around
Ed: Ah Er
Mark: Which is difficult to do while we’re here. But it’s doable.
Mark: It’s like a project in itself really.
Ed: Project in itself?
Mark: Yeah! (laughing). I just want to know like. We can get him in. So if I ask about the sizing.
Ed: Hmmn
Mark: I think you can edit the size here.
Ed: Why don’t you go here for a computer and you can do that?
Mark: Why. What. While you’re doing what?
Ed: Um making a sound track or something. I could do something like that.
Mark: Ok. Yeah. I’ll see if there’s any more computers in the cupboard.

Plan – Polish
Child Solo – creating assets –
20:00.0 - 25:00.0 Ed then creates a head – struggling
Seems a bit stuck – not able to recreate work

Making noises to indicate stuckness after 10 mins

Create – Polish
Child Solo – creating assets –
Pair – navigating to assets

Methodology - Appendix B.Rqs & coding schema

A short commentary on the evolution of research questions and the title of the thesis indicating shifts in focus.

The coding schema evolved in tandem with shifting understandings of the research focus.

Disguarded:

Retained for initial 5 min transcripts;

Design stages
Peer Interaction Varied uses of game design pattern

Methodology - Back up links to short URL resources

The short code generator tiny.cc has been used to create more readable links for footnotes and at times in appendices. The following list of short codes used allows readers to follow links if the tiny.cc service is deprecated.

Appendix C - Interview data & participant feedback or detailed observations

These interview extracts are presented sometimes with commentary and sometimes without as they are directly reference from commentary in chapters.

Participants Interview questions - semi structured

Background & Purpose of Interview

The interview will support my studies of family game making through an exploration of the aims, issues faced and types of learning you promote in your program/s.

There’s more info here - https://docs.google.com/document/d/1qSpeVjLi2CMs2HCWL_In1WAM-egPXpCLQl3F6wdxNJ8/edit

Introductory Questions

  • In a nutshell, can you tell me about what you have done on the game making activities?
  • What are some of the background factors that motivate you taking part in these activities?
  • Is there anything that jumped out as successful
  • Was anything unexpected?

Personal Dimensions

  • What knowledge or skills are you trying to build by taking part?
  • What about personal attributes / qualities
  • Can you tell me more about any specific activities that did built knowledge or attributes?
  • Tell me about any  times you felt you could bring your own identities or interests into your making processes?
  • Tell me more about how that happened and any impact it had on you.
  • Tell me any times you felt you could choose your next steps or your own path of progression in your activities
  • Tell me more about how that happened and any impact it had on you.

Material Dimensions

  • Tell me about the software or hardware tools or materials you used
  • How did they impact on how or how much you were able to collaborate?
  • Did they make some of your goals easier or harder?
  • What was your general thinking around these tools or materials, any other reactions?
  • What about the resources used, printed or online? Similar questions to the above.

Social Dimensions

  • What are your recollections of any  social dimensions of learning you recall from the game making programme? Either Unstructured interaction or more structured, directed interaction
  • Tell me about any specific activities or resources that you think may have supported this social approach to learning?
  • What challenges do you think existed in this area?
  • What are the pros and cons of working with families?
  • What are the pros and cons of working with other families?
  • Do you think the family nature of the programme impacted on how activities evolved?
  • What observations about intergenerational interaction did you made?
  • Are there particular any emerging patterns or roles of collaborative interaction that started to happen?
  • Is there any other impact that the family learning environment have on the overall programme?

Cultural Dimensions

  • Were you able to bring in interests of identities from family life to the programme
  • Could you draw on any other activities or groups you are a part of?
  • Did you make any links to any real life groups of people or communities outside the game making programme
  • Are there tensions or challenges or advantages about concerning linking with outside communities?
  • Are there other cultural factors which interacted with the game making programme?

Appendix C.2 - Email to participants in mid-P1 - Never mind the bees. I need your help too!

Mick ChestermanM.Chesterman@mmu.ac.uk

Hi there,

Never mind the bees. I need your help too!

I really appreciate all your energy going into the game making club over the last weeks. This is an experimental process and you guys are really going for it.

Also special thanks to J* for doing the Sonic Pi session on Tuesday that was great, and I learned some useful things for doing that one in the future.

It was a bit of a hard session for me on Wednesday as I was a bit low on confidence about how to pull all of your creativity into a finished game! It started to feel like a bit of a fantasy!

So I think I realised something. I said in the past that the idea of the club is for you to follow your interests and I’ll do the job of pulling together that creativity into a game.

But I realised that I can’t do it alone!

So I think part of the work we have to do is to visually map somehow what we have now at the start of every session. Via prints outs, or sheets where we map what we have and what we are missing.

I’m happy to give it a go at the start of next session to try to explore one way of doing it.

But ideas via email would be very useful too.

And let’s also have a break out group at the end to work out a bit more of a team approach as I need your help!

Thanks loads for reading this far… Mick

ps: I guess the challenge is to do this so that it’s a map, with different learning directions and possibilities, but that we are all still on the same map in our groups.

So supporting autonomous learning but also team work.

Appendix.C.3 - Case study with Anastasia’s family

One family in P1 chose not to continue with most other families after the Xmas break.

Members of this family had engaged in planning on paper and in particularly in creating pixel art, however tensions began to emerge when the introduced code framework framework did not support the desired features of one child. The feature they wanted to add to the game was bee design roaming a 3D landscape.

When the family withdrew, they shared in feedback (see below) that at one point the family 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 had been 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)

When the family withdrew, in my journal notes I reflected that the they shared of alienation from the group process occurred in a session where, due to a sense of urgency to complete games, I had omitted drama-based warm up activities. Instead as participant entered I began to support to help some participants debug some pressing code errors.

For some families and individual participants there were conflicts to do with a sense of anxiety and alienation from the group coding environment and associated peer working dynamics.

One family dropped out and in their exit interview they shared that at one point we looked around and just saw people doing hardcore coding and we no longer felt at home in the environment. In this emergent design, they had mostly completed asset design and narrative development and the only coding remained. I thus wanted to address the tension between completing the project and alienation from just coding.

The value of playfulness is illustrated with one exit interview with a parent where they shared their reasons for leaving the program. At one stage after a week where they had missed a session, their family looked around and saw other groups involved in ‘hardcore coding’ and no longer felt at home. They compared this previous sessions which had more fun and group oriented activity.

I was struck that his incident happened during a session where I had not played customary drama games to create an inclusive environment. The games had been omitted as I was responding to a sense of urgency coming from families to solve problems. The scarcity in facilitator time drove me to crack on supporting families to debug code errors.

Limits of peer support

In feedback the parent shared they didn’t want to bother other families with problems via the email list, and also noted the hesitancy caused by parental involvement compared to the kids ability to jump in and learn from each other less self-consciously.

Thus this surfaced a tension, the value of a peer learning balanced with the need for low pressure. In other words avoiding a negative sense of obligation.

Anastasia’s input into P1 evaluation interview

Anastasia shared reflections on the issues of family and home education dynamics, suggesting that parents may get in the way of young people’s ability to move into other’s spaces to learn things, and that parental helping roles may therefore be a hindrance.

The concept of learning from peers is different to family learning.

One perspective, maybe adults keep children back from progressing in their own way.
Could have worked well if just kids.
Adults have more social rules.
Kids don’t mind copying, invading space.
But adults do. Some lack spontaneous approach.

In home ed many either observe from the back or go to a separate room
How is it different at home?
If parents and kids work together, social rules are stuck to, in that the adults lead a learning process.

Appendix C.4 - Use of visual prototyping

In Chapter 6 the use of visual prototyping was explored in relation Vignette 6 with Dan and Toby.

In Vignette 2, the Susanna(p) notices the child’s difficulty in using cursor and delete/backspace keys to edit a matrix allowing level design. The parent provides a book with grid paper to allow the child to replicate the matrix. The parent is then able to transcribe the design to the code example while engaging the child by checking she has interpreted the design correctly.

The use of paper prototypes was one technique used by several parents to support their children to form and develop their design ideas. In our starting vignette the matrix helped the child design with little coding or literacy ability. The way the code is structured has been chosen to allow a graphical analogue between the lines of code in the form of a comma separated array and the appearance of the resulting game output on the screen. The parent uses the graphical representation of design in the code template as a jumping off point to make a connection to home practice of sketching things out in paper. The process of turn the sketched into reality on the screen and sharing with others appears to be transformative in terms of the engagement level of the child.

There are other examples of the use of paper prototyping of GDPs being used by parents to provide scaffolding for their children. When invited to share about their design process in a post session interview, Ed and Mark also discuss the use of paper to clarify initial GDP ideas in interview data. When asked if they were able to Mark prompts

Mick: Tell me a  bit  how you came up with those aims in your game, in terms of coming up with a plan.
Mark: What for the things that we need to do to it to finish it?
Mick: Yeah. Oh, just even from the beginning point. How did you plan together as well?
Mark: Well we started off on paper didn’t we. That's the first thing we did. I think it was a benefit actually. We, we did a lot of sketching didn’t we and a lot of brainstorming ideas and seeing and trying to test out whether it would work.

Later in the interaction, the parent outlines a different use of prototyping, that of sketching directly into software. For this pair, the child appears to prefer sketching directly into software. The father also appreciates potential problems of translating ideas from paper into a digital format.

Mark: I was very excited by seeing Ed playing with this because it's interesting that everything doesn't have to be a paper and pen.
It's nice to just for the kids to feel that they can sketch on Piskel straight off the bat without taking a tutorial or being told by an adult.  It's really intuitive and you just go straight into it.
Mick: That's an interesting thing because in some ways it started off with people working on paper because I thought that would be really accessible. Yeah. And maybe it was through observations of people just going “Do you know what I’m just happy sketching on Piskel”.
Mark: (Animatedly) The kids, all the kids I saw not just Ed.
Mick: Digital sketching.
Mark: Yeah.
Mick: It seemed to have value in that you were just doing it in the same format that you would use for the game.

Mark:   Yeah. I think it's really important. I think the pencil and pen thing just didn't work did it. We sketched... It's got its place. But it's, the kids weren't that interested in using the graph paper to block out Piskel. It didn't translate. It was just easier to block it out straight in software.

Appendix C.5 - Case study with Maggie’s family

There are some relevant reflections in interview data. THIS SECTION TO COME.

Interview.3.a

Choice of home interests bee keeping

Other extracts

  • Emotional when J. who was dyslexic was able to do the code pattern matching exercise.
  • Felt they neglected Tony

Interview data

Transcript of S and J The testing of the jigsaw activity

While the flexible / non-testing nature of the environment makes claims here difficult, a reflection by a parent interview data on a testing activity in P1 is relevant. S parent of J and T on completion of a jigsaw test, celebrated seeing that her family were able to recognise and order the code structures presented as validation of the experiential, non-instructional approach (see appendix.learningmap).

Appendix D - Learning design appendix

Appendix D.1 - On software tools

Appendix D.1.a - Summary of software tool use

  • Piskel - a graphical editor used to create pixel art sprite characters;
  • Audacity - a desktop based application to record and edit audio using audio effects and filters like delay and echo;
  • freesound.org - an open repository of audio files which could be downloaded, used directly or altered using Audacity;
  • Sonic Pi - an education music application allowing the creation of music using text coding;
  • Bfxr & jsfxr - web based tools to create sound effects aimed at game production;
  • Scratch - while scratch was not use for game production, I encouraged participants to use its intuitive graphical editor to create backgrounds for the game;

PREVIOUS Description of types of activities involved in game making and the tools used to do them

Phaser 2.6.2 javascript library Glitch code playground Incomplete game template Print out of cards with simple coding missions Online graphics editor Piskel. Audio editors, audacity, Updated incomplete game template Piskel online graphics editor Step by step tutorials on FLOSS manuals Drama scenario Interactive chat page in glitch

Appendix D.1.x - Links to online resources created as part of Phases 1-5

P1 Template P1 Template: https://codepen.io/mrmick/pen/jaXzxw?editors=0010

P2-3 Grid Game Template & Resources

Main resources

  • 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

_Additional _

CodePen () https://codepen.io/mrmick/pen/gbaOEgB?editors=0010 Github: https://github.com/jamm-labs/grid-game Replit: https://replit.com/@3m-gaming/Grid-Game-Template

Appendix D.2 - Supporting documentation

Appendix D.2.a Summary of online resources

A summary table including:

  • Manual,
  • GDP menu
  • Game to remix
  • Manual splash page

To do

  • List of the code examples - update GDP manual with this.

Appendix D.2.? - Sample chapter on Keys and Doors gameplay design chapter

This chapter, used as an example in Chapter 6 was being accessed online by Susanna in Vignette 2.

The full manual is available here. https://3m.flossmanuals.net/

Game Space: Keys and Doors

The game mechanic of collecting keys to be able to open doors to enter other spaces is well used in platform games to increase a sense of adventure. Let’s look at one way to do this. We draw on the code of a similar tutorial here by Belen Albeza.

Check the code: what we need to know and do

There is some background knowledge in this book that will be useful for us in getting this mechanic to work - adding More levels - Game Mechanic: Adding Levels Going over the code:

The code for a minimal example of the Keys and Doors game mechanic is shown here - https://glitch.com/edit/#!/key-and-doors-grid?path=js

Make sure you have or add these variables at the start of our code that are located outside of any one function as they are needed by more than one function.

var hasKey = false; var key; var door;

In the playState.preload function we will need to load some images for our keys and doors. Here are two lines which you can copy and use while testing. You can replace these images with your own.

game.load.image(“key”, “https://cdn.glitch.com/5d318c12-590d-47a1-b471-92a5dc0aae9d%2Fkey.png”); game.load.spritesheet(“door2, “https://cdn.glitch.com/5d318c12-590d-47a1-b471-92a5dc0aae9d%2Fdoor.png”, 42, 66);

Then we will create a key and door for our first level. Add the following code to our if statement in the playState.create function which controls which level is loaded.

if (!currentLevel || currentLevel === 1) { loadLevel(level1); // add extra code for just level one here key = game.add.sprite(100,25,”key”); door = game.add.sprite(20,260,”door”); door.animations.add(“open”, [1, 2], 8); // 8fps

Then when the play is happening. We want to set up overlap conditions in our playState.update function for player and keys and doors.

game.physics.arcade.overlap(player, key, hitKeys); game.physics.arcade.overlap(player, door, hitDoors);

We then create new functions mentioned in these overlap statements. Create these functions after your update function in your code.

In hitKeys we want to kill off the key and set our hasKey variable to true, ready to open the door.

var hitKeys = function (player, key) { key.kill(); hasKey = true; };

For the hitDoor function we need to check to see if the player has already picked up the key, as we don’t want anything to happen if that is not the case, or if they haven’t collected all the coins yet too.

var hitDoors = function (player, door) { if (hasKey === true && coins.total === 0){ door.animations.play(“open”); hasKey = false; player.kill(); game.time.events.add(1000, nextLevel, this); } };

If the player does have the key then we want to play the animation of the door opening, then reset the value of hasKey as we don’t want that to continue to the next level, make the player disappear, and then call the next level function after one second so that we get to see the door opening.

We also need to comment out the code which would allow the player to progress to the next level if they have just collected all the coins.

// MAKE SURE TO COMMENT OUT OR REMOVE THE FOLLOWING CODE
//if the player has collected all the coins move them on to the next level
// if (coins.total === 0) {
//     nextLevel();
// }

That’s it. We hope you enjoy adding this game space element to your game to allow the use of keys and doors to encourage exploration.

Appendix D.2? themeing - Themeing GDPs

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].

Printable framework to support game analysis via game elements

In early stages of my design participants completed a similar activity after playing retro arcade games. As a possible resource for other practitioners I include a link to a printable power point sheet with the above structure.

INCLUDE LINK 

Guidance for practitioners
As part of the introductory activity make sure students are familiar with the 5 parts of a game, or sometimes called the 5 principles of game design.  Be sure to ask students what they already know about these terms or see what educated guesses they may have before giving the answers away.

I related this simple categorisation the emerging list of requests for game features made by my participants. The final categorisation used in P4 is included as a Table 5.x below.

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 Sound Track (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 game design patterns used in P4.

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.

I noted that some patterns addressed game aesthetics (simplified to game polish) for example; the graphical representation of game characters; adding sounds; and adding background images. Others could be described as game mechanics including: jumping on enemies; finding a door or flag to progress to the next level; and collect all food before progressing to next level. Others concerned aspects of game space: the size and shape of game world; and adding new levels the game. In P5 I extended the scheme to included system and challenge patterns. These explore at how different elements in cxteract to create challenge in the game.

I then took the existing list of game elements that have been identified by students and categorised them based on a blend of two frameworks. I made some simplifications and adaption to increase accessibility for non-professional and young people. For example, the term of aesthetics is very wide and used by suited simplification game polish.

Game Design Themes{width=55%}

Appendix D.R.x - Sketching towards a map to help navigation.

In trying to organise and represent code examples to participants in a logical way, I experimented with different categories and themes to contains the emerging game elements. I also explored the concept of mapping the different challenges by difficulty on a map via structuring via concentric rings. An example of the kind of grouping sketch used is included below as Figure 4.x.

Scan of Journal Sketch of early attempt at dividing features by type and difficulty{width=85%}

Fig 4.x. Scan of Journal Sketch of early attempt at dividing features by type and difficulty - Dated 11.3.2019

The process of sketching, revising and re-sketching the elements led me to connect this process of categorisation with the work of game theorists.

MDA framework -

In addition, I recognised synergies with between open-world game design and my attempts to structure resources and help learners navigate the learning experience based on choosing challenges based on their interests and appropriate difficulty levels [@squire_open-ended_2008].

Appendix D.3 - Other intervention resources and processes

Appendix D.3.x - .map – Dialogue of use of physical maps at the start of session X

Add some kind of description and a photograph.

Transcript Description
Mick (f): I’m putting the ones that are hardest further away from our home island. So, because keys and doors is quite tricky, I’m going to put that one over there in the corner, if that’s one that you’re working on. Mick cuts out an image from [^4] representing a GDP of key and doors.
Tehillah (c): So I’ve gone really far away on the map. Tehillah quickly places her marker on that image and grins. Other parents and children to the right and left of her look at her marker.
Mick (f): Yeah. Mick smiles too whilst walking to get and glue another cut-out.
Tehillah (c): Heh! Tehillah walks back to her mother and stretches out her arms to her, who picks her up. Tehillah whispers in her mother’s ear.
Mick (f): There should be some blue tack if you are struggling to make your character stand up. Mick walks around the back of the group and sticks another GDP pattern on a different pre-drawn island. Roxanne (p) notices Agnes’s (c) falling character and passes the child blue tack to help.
Roxanne (p): Oh that’s something you were wanting to do. Roxanne points at a cut-out that Mick has just stuck down.
Richie (c): I like the idea of making the enemies move. –
Roxanne (p): Ok, there’s a worksheet here about that. So you don’t want to any any health meter? –
Richie (c): No. –
Roxanne (p): At least not right now. You want to do this, on a sheet, right here, here you go. Roxanne waves sheet and smiles at Mick and laughs.
Mick (f): Great that’s good. We’ve got some sheets that I would recommend. That are almost like gateways to other places. One is to make your character move when it moves around the screen. Mick moves hands when saying “make your character move,” indicating animation.
Mick (f): Another is to make your enemies move around the screen to make it a bit harder. I know you guys have done that. Mick moves a pointed hand to indicate an enemy moving on the screen and then points to Clive and Pearl to indicate “you guys.”

Appendix D.3.x - Maker types and social missions

Appendix referred to in Chapters 5 and 7.

The process of exploring identity in this way surfaced the cheekiness of some young people and the pleasure they took in demonstrating their playful mischievousness. I began to make journal notes on this subject and talk to other games study practitioners. I began to ask the question can the surfacing maker types (as per player types) encourage awareness and celebrate the emerging practices that the community was producing.

Appendix.bartle - Summary of interactive Bartle test

EDIT DOWN LOADS - MOVE SOME TO BLOG POST INTRO OF JOHN’S INPUT?

As part 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. I saw potential value here to address the danger internal bias about the kind of process that a computer programmer should adopt, echoing the call for pluralism in approaches [@papert_epistemological_1990].

I introduce a warm-up activity trialled in P2 where participants took part in an physical version of the Bartle Player Test, a framework used to categorise players of multiplayer games based on their preferred play style [@hamari_player_2014]. It identifies four main player types: Achievers (motivated by goals and rewards), Explorers (interested in discovery), Socialisers (driven by interaction with others), and Griefers (focused on disruption of other people’s game experience). The test helps game designers understand what motivates different players.

\ Illustration 10: Bartle Player Type Test{width=95%}

The process was adapted so players moved to a different quadrant of the room based on their response to the question. The process allowed young people to see how their response differed from that of their parents.

This process celebrated different game playing types and allowed a public sharing of previously hidden gaming preferences, although for some non-gaming parents and children I had to ask them to use their imagination.

Several parents noted that this process gave them great insight into how their child identified within the cultures of the games they played. The process of exploring identity in this way surfaced the and the pleasure some young people took in demonstrating their playful mischievousness. I began to make journal notes on this subject. I began to ask the question can the surfacing maker types (as per player types) encourage awareness and celebrate the emerging practices that the community was producing.

After the results were revealed, I then proposed as facilitator that my observations were that there different game maker types. I read out the different types and asked them to place themselves in a two-dimensional grid based on their self evaluation of what kind of game maker they were. Other family members were then invited to comment to see if they agreed with this interpretation. The process of exploring identity in this way surfaced the cheekiness of some young people and the pleasure they took in demonstrating their playful mischievousness. I began to make journal notes on this subject, reflection on the potential value of surfacing maker types (from player types) to encourage awareness and celebrate the emerging practices that the community was producing. In particular, linking griefing in digital play with similar disruptive practices in digital making, in this case the process of messing with game play conventions other people’s creations. As an example some players created impossible or overly easy game levels. They appeared aware of implications for game balance but is taking pleasure in this seeming destruction of the key challenge of the game as an act of disruptive play. They seem to take pleasure from ignoring concepts of what should be done to maintain game balance and from the sense of shock from their current audience her parent. Going against this convention is a type of playful destruction in this context. The process mirrors play theory concept of playing against the game or dark play [@sutton-smith_ambiguity_2001].

I translated player types to maker types based on notes in my observation journal and extracts from screen capture data. The following list of Game Maker types:

  • 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

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. Madiha 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?.

It is worth stating that, the reflections on game maker types or styles above are not imagined or proposed as an exclusive or unchangeable styles. This statement addresses concerns on learning styles advanced by Fleming. The main problem with Fleming’s learning styles (VARK) is that there is little scientific evidence of improved outcomes or even for set styles in learners. Instead the styles are advanced as a reflective tool and as a prompt for exploratory activities in the learning design as explored in the following section.

Adapting the learning design to encourage activities exploring different maker types

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. By the end of P2 most of the tools and main processes were in place. But I wanted to decrease reliance of my role as facilitator, to increase organic reflective processes and to celebrate emerging participant identities. To do this I began to integrate my observations of different game maker styles in to the learning design more explicitly.

I used the question “What kind of game maker are you?” as an indicator to participants that one aim of the project was to create a space where different approaches are possible and celebrated. To communicate this approach, as well as starting game activity, I incorporated the question into an animation of the resources home page (see illustration 4.x). In P3 the underlying ideas were incorporated into the process drama described in the next section.

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

Side missions

Full table of side missions

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.
Find out who plays the most computer games per week in your group. Change of the images in someone else’s project to a very similar but slightly different version and see if they notice.
Find out what other people are planning. Give some friendly feedback to one other person / group. Why don’t you try… Add a rude sound to someone else’s project.
Ask 2 different groups if they have thought about what sounds they are going to put in their game. Swap over some sounds in someone else’s project and see if they notice.
Find out from three groups if they are going to try any totally new ideas. Delete all of the code of someone else as they are editing it and see how they react. Then help them get it back using the Rewind function.

In the transcript above of vignette 4.1.b we see that in the end-of-session reporting back participants engage in a lively discussion about the secret missions they had been given. Encouraged by her mother Madiha, Nasrin shares that she has been highly engaged in a disruptive secret mission. Dan and Toby express playful frustration. Mark and Ed contribute by sharing their more subtle disruption and Richie is keen to have his rude noise mission noticed and commented on. Some public missions had a noticeable impact in this session particularly in stimulating a discussion among parents around which arcade games they played as youths.

Side missions or side quests are also used in open world games are used in part to appeal to different kinds of players and are often models on Bartle’s taxonomy of game player types [@bartle_hearts_nodate]. In this phase, parents Madiha and Mark both used the prompts of the social missions to take a break from their creative work using the software toolset to talk to other parents and children.

Mark: Right we’ve got a background in. Do you. Do you want to reply to the Weean.
Ed: Yes. (Ed starts to type very slowly)
Mark: (after some time) While you do that I’m going to go do my mission.
Ed: What's your mission?
Mark: To find out about other people's favourite games.
Ed: Alright.

DISCUSSION

the lively discussion about game playing in response to the mission to find out the favourite games of 3 other people - from parents is explored here

ADD IN DETAIL FROM P3 -

In later reflections parent Mark made the following comment in post-session interviews; “We used the instructions, we like to plod.”.

Playful Playtesting

Referenced in Chapter 7.

The maker types listed above were in particular played out in the playtesting process.

Some children added additional playful elements to playtesting. Because these interactions were mobile between workstations 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.

Appendix D.4 - Drama process

Introducing a drama process in P3

Context:
The participants have entered the room and chosen a laptop to work on. Some of the children are playing web-based games or reviewing the games they made previously. The session progresses with a warm-up game involving many false starts, rule changes, tactics, appeals to be serious, laughter, and repeated restarts. The transcript picks up at this point.

Transcript and inline notes

Mick:
Ok. So I’ve got a surprise. I don’t know if you know but as part of our Home Ed club we did a page of different games. It’s on glitch.com and it’s called Glitch Game Club… there’s one for Home Ed Winter 2019 and here are all the games that we made. We made a lot of games. 15 games.
This has not gone unnoticed because I got a message through this account. This is kind of a story now. We are entering a story. You have to use your imagination.
We got a message and it was an audio message. If you guys take your fingers off your keyboards and have a listen to this audio message which is quite unusual as I don’t think it was from anyone on … this … Earth.

Audio message (read aloud):

Greetings Earthlings, we have an important message for the Glitch Game Makers.
We are the Weean. You would call us an alien life force. We like to think of ourselves as friendly space cousins.
We can see your Internet from space. We are contacting you because we know you are making games on the Internet.
We are on our way to Planet Earth, and we have an important mission for you. We are an Intergalactic Rescue team. We know you have problems on your planet. We can help.
But we need to find out one thing first. Are you worth it?
After we are gone will you also be able to help yourselves? Or are you already doomed to make the same mistakes again?
You must pass this challenge. Make some games showing problems you have on Earth. In the games also include ideas for how to solve them.

Mission Instructions:

  • Make a game about a big or small problem for your planet to solve.
  • 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 as part of a team.
  • We will send you text messages with mini-missions. Tell us how you do.

Mick:
So yeah, that’s the story. (with heavy irony) I’m pretty sure it’s true.
(Mick and others laugh)

So all they’re asking us to do is come up with a game. We’ve got four sessions. It’s got to be about the problems of the world—big or small. Include your ideas on how to solve them.
And yeah, work alone but also as a team. We’ve got to give them a report by the end of each session. That’s our mission.

Exploring documentation and accessing technical help within the drama frame

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.

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.

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.

Session reflections involving drama narrative and secret missions (P3)

Context:
This extract comes from the following session in phase three. In three of the four sessions, the last 10 minutes involved giving a progress update to the aliens.

Compared to previous phases, these structured reflections prompted near-complete participation. The need to maintain the drama narrative seemed to boost motivation.

I asked participants to gather around a particular computer “monitored by the aliens” which helped them stop coding and physically cluster together. Even initially reluctant participants began contributing more than in earlier reflective formats.

Transcript and Activity Log

Mick:
Ok are you guys ready to share back? If you could come to this side of the room we’re going to get Mark and Edward to share back first. Everyone can use this computer the Weean are watching.

Mark:
All we’ve done today is just get a background in and then we were working on the one the Weean sent us—about dropping the coins in.
The idea is planting trees—dropping seeds. Some enemies tweening around take them away.
We want a timer—drop enough in a certain timeframe or you can’t go to the next level.
Level two is watering trees.
Level three is protecting them from being chopped down again.
We’ve got the concept and code, so we should make a jump forward now. Doesn’t look like we’ve done much—but we have. (laughs)

Mick:
That’s great. Anything you want help with before next time?

Mark:
Yeah, we’d like to ask the Weean some more questions. Is that OK?

Mick:
Yes for sure. You’ve been talking to them—this project called Talking to the Weean lets you do that. Go to “Edit Project,” click “WEEAN,” and use Markdown to ask questions.

Chat Extract from ‘Talking to the Weean’ project

Ed:
Weean what’s it like up there?

Weean:
It’s cold and very big but quite tranquil.

Ed:
What is your name?

Weean:
We are the Weean. We have no name. We are all the same.

Ed:
That must be hard at Xmas. (laughter)

Weean:
It is. It sure is.

Mark:
That’s tickled me, that.

Mick:
So you can have a conversation with them in markup. Nasrin, can you tell us what you’ve added to your game? Is it still called “No Toby Allowed”? (laughs)

Nasrin:
Not really done much today, I was busy doing stuff with Toby’s.

Dan:
We noticed.

Nasrin:
I’ve changed the platform a bit.

Madiha:
You had a secret mission though, didn’t you?

Nasrin:
Yeah, it was to change someone’s game—their character or something—and see if they noticed.
I think they did notice.

Dan:
We did.

Madiha:
You couldn’t not notice.

Mick:
You turned up the volume on the mischief. (laughter)

Madiha:
Sprite!

Mark:
We also had a secret mission.

Mick:
What was it?

Mark:
To change the sound on someone’s game.

Nasrin:
Oh, was it?

Mark:
Did you notice?

Nasrin:
No! (laughing)

Mark:
Play it now!

Richie:
You definitely noticed my bit. (points)

(Nasrin starts playing her game)

Nasrin:
I can’t hear anything different. (Everyone laughs)

Mark:
I thought you were going to go “Aagh!” but you didn’t say anything.

Mick:
Interesting—some people notice, some don’t.

Appendix.D.5 - On the discovery, mapping and participant experience of a map of learning dimensions.

This appendix outlines the evolution of a map of learning dimensions which is referenced in Chapter 6. A section section contains reflections on the aspect of the learning design which suit curricular approaches to computing and computational thinking.

Similarly, one of the outcomes of my research was to extract from hours of recorded material some of the concepts and practices that learners engaged with when making games. Table 4.x. shows my resulting map of learning dimensions. While some concepts are common to existing computational thinking frameworks others, including systems thinking concepts, are more unique to game making. The choice to include some elements over others is based on a synthesis of the experience of participants, existing frameworks in this domain (previously explored in the LR), and my own interpretation which privileged under explored elements like systems patterns. Due to the dominance personal input, this framework is offered as starting point which could benefit from the type of collaborative analysis undertaken in Bevan and Petrich’s process.

Computational Thinking Coding Concepts Systems Patterns Design and Technical Practices
Abstraction Sequences Systems Elements Goal Setting
Decomposition Variables Systems Dynamics Being Incremental and Iterative
Pattern Recognition Logic Reinforcing Feedback Loops Developing Vocabulary
Algorithmic Thinking Loops Balancing Feedback Loops Web Literacy (as a subset of digital literacy) [^moz]
  Arrays   Code patching
  Creating Functions   Version Control
  Change Listener   Debugging
  Input Event   Reusing and Remixing

Table - Learning Dimensions final version from D5 process.

Background on learning Dimensions Map - - COMPRESS?

Research on concept maps [@canas2003summary] as methods for teachers and researchers to identify key learning suited to particular computing projects has gained traction in the field of computing education [@keppens_concept_2008; @noauthor_quick_2020; @weinerth_concept_2014]. The value of facilitators presenting concepts and asking students to create maps of concepts for formative assessment. In addition, there is value in mapping which are likely to occur in project work especially when such concepts are embedded in activity in a way which resists superficial analysis. Research on hands-on tinkering in science museums by Bevan and Petrich [-@petrich_it_2013] together with educators examined video footage of families interacting with exhibits to make a structured list of the learning they observed. Their resulting map of learning dimensions included underlying science concepts but also contained more general skills and helping behaviours involved in exploratory learning processes.

The potential of learning maps

This process of mapping this framework is potentially of use for teachers and other researchers to help their observation of students in game making activities to align with design, coding and computational concepts. Offering student choice in project work can create stressful demands on a teacher trying to support a diverse design paths [@blumenfeld_motivating_1991; @cole_fifth_2006]. To address this issue practically, rather than students working on varied game types and features, I restricted the genre of game and offered a significant but limited menu of features, a process explored in the next section. The mapping of specific design features to the related concepts, as outlined above, has potential to aid teachers and students to track and correlate the underlying curricular concepts being explored in these divergent learning pathways.

The process of adapting this learning design to the needs of more formal settings can be aligned to existing research on this area. For example the concept of semantic waves is relevant here as a way of visioning the alternation between concrete design experience and communicating the underlying abstract concepts [@curzon_using_2020; @maton_making_2013].

However, despite this alignment and potential utility in a school setting, I was reluctant to introduce these resources in this informal context, reflecting the lack of external motivation for participants to align with curricular demands driven by exam requirements. Introducing additional mediational tools with the aim of the communicating and reinforcing abstract computing or systems concepts risked effectively establishing a new competing activity system. This perspective validates my reluctance to introduce additional distracting stimulus, instead prioritising time spent in on-going hands on experimentation, peer learning and playful activities. Additionally, while this approach aligns with situated understandings of knowledge which problematise the separation of the content to be learned from the embodied social activity itself [@rogoff_observing_1995; @leontev_problem_1974], this alignment did not halt my concern over remaining locked into concrete experience and not developing awareness of repeated abstract concepts which could be of future generalised utility [@maton_making_2013].

My ongoing discomfort surrounding the validity of the learning experience without direct alignment to abstract content, stem from wider concerns around avoiding danger of tacit learning by reinforcing learning and spur metacognition [@gherardi_toward_1998]. Even if generalisable concepts can be encountered in the context of an learner-driven activity, they may not be explored without guidance from others. Hoyles and Noss term this tension a ‘play paradox’ [@hoyles_pedagogy_1992, p.46]. This theme is explored in more detail in chapter six concentrating on social processes rather than external documentation.

CROSS REFERENCING

Evolution of the map

The inspiration is that of Bevan and Petrich’s [-@bevan_learning_2015; -@petrich_it_2013] work to bring a similar learning map to a seemingly chaotic tinkering and making process in museum contexts.

IS THIS IN LR?

Conflicts stemming from tensions between privileging participant choices or underlying computing and systems concepts

In P4 I wanted to create resources and processes which are of potential value to practitioners in the UK classroom. At this stage I noted a contradiction between aligning activities to curriculum or following learner choice and expression [@hoyles_pedagogy_1992].

To illustrate these concepts in more depth, I created concise descriptions of the concepts [^2], and cross referenced with examples of the concepts in practice in the application common game features[^3]. This process aimed to be an aid to my existing attempts to highlight relevant concepts in-situ.

In journal notes I note my attempts to find learning relating to abstract concepts happening in-situ. A common example of use of loops or arrays or functions. I would highlight their use by participants and link to their activity. This mirrors the concept of the value of abstract in context for wider application is underlined in the work Davydov of rising to the concrete [@valsiner_cultural-historical_2007].

Evidence of CT in the results

Even, taking Wing’s more abstract definition of CT, many examples arise in recorded interactions without being explicitly taught.

Abstraction: identified by Wing as the most vital CT concept, merits a deeper examination and is covered in a later section of this chapter. The work of Dan and Toby beyond the template?

Decomposition: example of parents helping children break a larger problems into more manageable steps e.g one parent suggests to his child “Save that for version 1.1”.

Generalisation / pattern recognition is present in the majority of participants as patterns are readily available to participants in starting code and the extra patches that are added. The process is repeated.

Sequencing / algorithms are frequently explored in the resolution of errors with participants. This exploration focuses on the potential of the 3M learning design rather than making claims on the suitability to develop CT via game making which is explored extensively in other research.

Conceptions of personal appropriation should not be limited to only the curricular concepts included in the learning map, the many of the behaviours explored above show both the appropriation and feeding back of varied understandings of game design patterns and related concepts and skills. The process of reusing and modify code to create a computer game can surface both abstract and concrete computing concepts present in the concrete application of code that have emerged organically at different stages of the creative process. While the design of this study does not suit full exploration of the personal plane of activity, the repeated, solo, incremental changes of the details of implementation of game design patterns indicate a personal appropriation of concepts like game feel and challenge and design processes. In one interaction with Sh, exploring how a bracket placed in the wrong place can effectively break the game yielded a productive discussion on the importance of correct code sequencing (PERHAPS INCLUDE AS APPENDIX?).

Beyond this broad mapping of systems and computing concepts to aid facilitators to highlight I also sketched out metacognitive activities to explore these concepts on completion of each GDP. As explored in the design chapter, later revisions of the design of supporting materials for each GDP included links to online descriptions of design, systems and computational concepts. Thus, beginning with experience and progressing to analysis in a sway that mirrors reflective professional practice. However analysis of my journal entries show an ongoing reluctance to shift learners away from the practical implementation of repeated game design patterns to focus on more abstract, de-contextualised conceptions of the knowledge.

My intuitive reluctance to impose shifts in the scope of activity systems, can be interpreted through the lens of TADS. For me to prompt a shift to a activities to reinforce recognitions and connection of learner generated code to computing and systems concepts, would impose a objective (first stimulus) and expose a new set of secondary stimuli for learners to draw on. THIS SECTION NEEDS DEVELOPMENT AND COMPLEXIFICATION IN RELATION TO EXISTING RESEARCH.

Tensions involving explicit teaching of curricular concepts or not

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.

Facilitators can use a prepared collection of GDPs to facilitate participants to surface chosen computational, design and systems concepts embedded in games. SEE BOOK CHAPTER FOR recommendations FOR TEACHERS - AND INCLUDE HERE. DROP?

I also noted my own caution about overloading learners with shifting and competing goals. My concern hinged on the potential disorientation of the learner that imposed shifts of focus may provoke. As learners shift between different stages of creation the object of their activity shifts from the larger goal of making an engaging game to a narrower goal of implementing a game design pattern to narrower still of completing one of several actions to complete the implementation of a GDP.

The map of learning dimensions created, reflects the tensions explored in this section on which element of personal knowledge to privilege.

While the contextual factors involved in this learning environment did not require alignment with a particular curriculum or external examination, computing, design and systems concepts have the potential to arise as part of the game making process.

In particular, the facilitator has the ability to surface and to explore more abstract concepts present in the concrete application of code that have emerged organically from the participants drives to implement particular patterns.

Toby to find patterns and to duplicate them in different situations.

With prompting from parent the child is able to recognise, duplicate and alter the update code for accepting left and right key input to change character x-axis velocity. After update and test iterations they change this to up and down key input to update y-axis velocity. The 3M approach lends itself well to exploring pattern recognition as patterns are readily available to participants in starting code and the extra patches that are added.

Also the knowledge of the GDP helps ability to recognise patterns in the code. Left / right -> Up / Down

I could trust my instincts as a facilitator to not detract attention from participants following an organic and flexible pattern of implementation, self-testing, improvement and playtesting. In the language of activity theory the change of objective denotes is a shift in scope of the activity system.

Appendix E - Technical appendices

THESE WILL BE INCLUDED AS LINKS TO ONLINE RESOURCES

Summary of structure follows.

Footnotes

https://medium.com/read-write-participate/a-note-about-thimble-b8ba0a51b8fd