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
  • Recommendations for practitioners (summary if needed?)

Appendix A: Ethics and recruitment

This information is to be circulated to Home Education Forums and Email groups.

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

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?

Interview data summaries

Use of helping roles in Interview data.

Mentioned in Chapter 7

Interview.1 - Madiha, Nasrin and Xavier

Interview.1.a

Interview.1.b

The involvement of Madiha in Nasrin’s gaming

Interview.1.b

The choices to explore issues of social media

Interview.2 - Mark and Ed

Interview.2.a

  • The use of paper prototyping and then progression to digital sketching. The quick use of digital tools

Interview.2.b

Choice to explore trains as a subject

Mark and Ed designed a game around the character of a train driver that needed to collect coal. In subsequent post course interview Mark describes the impact of the child feeling like they could bring their own identity and interest into the project.

Mick: (17-46) Can you tell me anytime that you felt like you bring your own identities or interests into what you were doing. Ma - Oh, definitely. Yeah. Mick: Let’s ask Ed that as well. Mark: Yeah. Mick: Can you do feel like in making the games, you’re able to bring your own interests or things that you related to into it? Ed: Yeah. The Fireman. Mark: Yeah, well, tell us about that game. Tell about your interests and stuff? Ed: A little fireman, he’s going around collecting coal for this train. They lost it. But then there’s sheeps on the line.map …. Mark: What is your aspiration for your life? Ed: I wanna be a fireman (on a steam train). … Ed: I really like trains, since like I was very, very young.

Mick: Do you think I mean, was that was that like something that helps you a little bit keep your interests go in for the game? Mark: I think it excited you to have to build a fireman sprite? Is that right? Ed: Yeah. Mark: and to have it train themed, didn’t that like, keep your interest in the designing part of it up? Is that true? Ed: Yeah. Mark: Because the whole theme of it. Just I know just your eyes lit up when you realised you could expand your interests into gaming.

Interview.2.

Plodding

Interview.3 - Maggie and Toby

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.

Interview.4 - Dan

Interview.4.a

Dan’s involvement in Coder Dojo.

App.7.fdb - Feedback Extracts

App.fdb.a - Susanna and Tehillah note on starting games

Added to vignette 2 also

Tehillah got on better during the coding once the student who was hovering initially left us alone. Because every time Tehillah hesitated, she jumped in to do it for her. Whereas I know her better so can judge how to facilitate more minimally, and I resist the urge to fix things immediately when she struggles. Plus she can’t read yet, so she was recognising the relevant bits of code by matching the individual letters, which takes longer.

End of course evaluation at show case for P 1. Find extracts from here https://docs.google.com/document/d/1VL8FPnrBUbcpwL1nmGLCsF1t2JjkitQV_3N8DYeFcoM/edit

App.fdb.a - P1 end evaluation

Athena (P1.debrief) also 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.

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.

c - Additional Smaller Vignettes

Appendix.C .dliteracy - Developing Digital Literacy skills & Play paradox

The process of creating a pixel art characters and hazard involved using an online grid design tool called Piskel, creating an design of an appropriate size, saving, exporting as an image, downloading to the hard drive of the laptop in use and finally uploading and incorporating the image into the code project and linking using code syntax.

Perhaps play paradox here? Not a tension but something to design for? And thus backgrounding the aspects of computational thinking in favour of a more accessible experience using authentic technology. A reflection as a facilitator.

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.

Digital / Web Literacy

Belshaw?

To integrate new gameplay design patterns or adapt existing ones in their games, participants needed to develop unfamiliar technical processes associated with computer coding, as well as foundational digital skills related to using a desktop personal computer. See Appendix: Digital Literacy for further details. One example of a skill developed by many participants was proficiency in keyboard and mouse use. Combined with the ability to navigate internet browser tabs, this facilitated movement between computer code, game prototypes, and supporting web-based documentation.

The process of collating these skill aligned to curricular concepts above or those explored in computing research as desirable in a manageable list involved excluding a large number of relevant skills that were being developed as part of the game making activities. In particular key digital literacy and basic skills associated with using a desktop personal computer which were developed are listed below.

  • Keyboard use: in particular use of shortcuts including Cntl + C, Cntl + V and the use of Shift and arrow keys to highlight text
  • Mouse use: building proficiency with accurate mouse use and the process of clicking and dragging
  • File management: downloading and locating digital files on a desktop environment
  • Exporting graphical assets: locating the proceedure for exporting files from applications for use on other applications in the correct (interchangeable) format.
  • Using web browser tabs: creating new tabs and navigating between different browser tabs as part of a iterative design process.
  • Use of graphical editing tool sets: for example drawing pencils, fill buckets, eraser tools.

Appendix.C .? - patching & and debugging

Transcript of interaction explaining code patching

The following is a transcript…

So if you click on that (referring to tutorial link) if you want to add a moving enemy.

I’ve tried to put a bit like that (referring to illustration below on code patching). What that means is, you’re looking for that bit of code at the top. And you’re going to copy it and paste it into that bit at the bottom. Where it says Playstate.preload. That’s the part of the code that you need to put it into. Just to make it a bit clearer.

Figure 5.1. Code Patching{ width=80% }

Madiha: So you’re not cutting the bit at the top out, in red. You’re using that bit instead of the yellow bit.

Mick: Well actually, you’re putting it inside of it. So here you would copy it and in your code example. You then look for that bit where it says preload. You then put it inside of it at the bottom of that.

Madiha: So just insert it somewhere.

Mick. Yeah insert it. So here we’ve got different parts of our game. We’ve got preload. We’ve got create. And we get used, we start to get used to finding them. In this one it’s preload that’s the one that its saying we should put it inside of. And then this next bit. It’s saying, ah, you should put that into your create function.

So we’re moving in the right direction. But any other things where you think. Ah that could be easier. Let me know and I’ll try to make these resources much easier.

Mick: It’s almost like this is our control panel. What do you want to do next and we jump off from there. And I’ve put it down on a bit of paper. It’s just gcc-examples.glitch.com

Appendix.debugging GDPs used to nurture tactical responses to coding errors

COPIED FROM GDP CHAPTER

Additionally the key affordances of the learning design including the starting template code snippets and the resulting code patching process appear to encourage the creation of glitch errors (Appendix Debugging).

Solving / Debuggging code problems that responses are helped by the high level of context present in the use of GDP as a structural design framework.

In critique of online tutorials researchers note few provide common errors [@kim_pedagogical_2017]. While it seems reasonable not to include all possible errors, the challenge of supporting participants to build skills and effective repertoires involving debugging is widely recognised [SUPPORT]. My observations suggest that the close coupling of code implementation and target behaviour aids participants in debugging and also be profitably can be drawn on by facilitators.

In analysis of journal notes and recorded screens I began to identify different kinds of coding problems that blocked participants from progressing and build proficiency and flexibility in addressing them. Reflections on participant experiences of kinds of errors are explored in Appendix.tech.2. In the appendix I reflect on syntax errors which stopped the game from working entirely, bugs where code changes had no effect on the game and glitches which don’t crash the game instead creating an unintended effect. Glitches merit a summary here as a particularly interesting site of guided participation. In my reflective notes I propose that glitches are more motivating to correct than other errors.

Aspects of the design, use of a starting template and supporting resources based on code snippets and thus code patching process increased appear to encourage glitch bugs. See Vignette 1 for an example of a glitch bug which provoked further investigation and hand on tinkering. A diversity of helping strategies evolved, my own and those of others, in response to errors. For my part, these altered when I judged when participants to be receptive to different forms of input. Glitch errors were often embraced as curiosities and as a learning opportunity to understand the related code and associated abstract concepts using a concrete example afforded by the mechanics of the game design pattern. Mirroring the proposition of half baked games theory that a incomplete / templated game are motivates initial participation, my observation support a position that glitch bugs, which move game into a broken state also provide motivation. Additionally, as the bug relates to a targeted GDP which is closely coupled with a suggested code solution and tutorial, this process incorporates the benefits of a just-in-time approach to supporting documentation

This area opens some interesting lines of questioning which are beyond the full remit of this research but are included in Appendix.tech.2 as promising areas for future work. When addressing issues of motivation and efficacy a different research methodology would be needed.

This section highlights different possible errors and notes that responses are helped by the high level of context present in the use of GDP as a structural design framework.

On Patching

More on patching and interaction with debugging.

and interaction with UMC process.

On different kinds of errors

In analysis of journal notes and recorded screens I began to identify different kinds of coding problems that blocked participants from progressing.

In critique of online tutorials researchers note few provide common errors[@kim_pedagogical_2017]. This lack of problem solving techniques communicated in online tutorials may addressed through use of GDPs.

Professionals build up this sense through experience. While some practices are taught many others become ad-hoc rules of thumb that are difficult to communicate in abstract ways.

More research would be welcome on how to help learners pick up these understandings. Further analysis of the different kinds of errors that are likely to arrive and testing different strategies for dealing with them that take into account the zone or proximal development of the participants may provide not only useful input for the participants, but also opportunities to check understandings of processes and game patterns and computational patterns in use.

For example, on into the detail and types or errors. These include:

  • Syntax and Program Errors are errors in your code which stop the game from functioning at all, often resulting in a blank screen.
  • No Behaviour Bugs are errors which in your code which don’t stop the game from functioning but your intended effect is not present when it should be.
  • Glitches don’t stop your game from running but as you play you see that there is an unintended effect. The game does something different from what we want it to do.

NOTE - Perhaps explore glitch examples.

This area show potential but is under explored. However, just surfacing the issue feels valid in terms of useful stream of facilitator practice to explore.

Concluding remarks on debugging and revision

Many participants spent significant periods of time improving, testing and fixing coding errors in their games. Analysis of the coding of video data showed that revision and debugging was often a solo effort. In a way that mirrors the spread of other creative technical processes, certain revision and debugging practices that were transmitted through interaction with the facilitator that were adopted and used by the community. Some practices were straight-forward, for example the swift navigation between the source code window and a preview window of the live game. Others were more specialist like the use of the developer console of the internet browser to debug JavaScript errors or the process of hovering over red dots in the code playground to explore error messages.

The experience of debugging appears to be a particular practice evoking certain feelings. Feelings of frustration alternate with elation at solving a tricky bug.

As I built proficiency as a facilitator I began to identify different kinds of errors. The use of code patching often provoked glitch bugs which where actually behaviour did not match intended behaviour. In analysis of interactions with participants when trying to solve coding blockages, I note different strategies in responding to such errors. For some participants I quickly solve them with short explanation to allow them to continue. For other participants who I judge to be receptive I may celebrate the glitch and explore with them the opportunities they provided to understand the related code in a way that allowed the exploration of more abstract concepts using a concrete example afforded by the mechanics of the game design pattern.

The following example provides an illustration of this kind of interaction and examines the surfacing of computational thinking concepts in particular. FIND EXAMPLE IF POSSIBLE.

This area opens some interesting lines of questioning which are beyond the full remit of this research

  • Question - do more useful / less de-motivating errors result from remixing and game patching?
  • Question - what impact does the process of being driven by GDPs have on how users deal with errors?
    • For example does the closely paired code structure and game output help with motivation?
    • How do you develop a more granular sense of the kinds of blocks, errors and how to overcome them.

Appendix.C .bee - Contextual Vignette on the conflict experienced by one family & the 3D Bee

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 appendix 4.x) 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 probems 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.

Appendix. prototyping Use of visual prototyping

MOVE FOLLOWING TO AN APPENDIX ON PAPER PROTOTYPING ?

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

By way of contrast, 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 D - Learning design appendix

Mapping?

Mentioned in Ch.5 table of manifestations of system tensions, barriers and congruences.

Appendix D.1 - On software tools

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

The current toolset

P2-3 Grid Game Template

CodePen () https://codepen.io/mrmick/pen/gbaOEgB?editors=0010 Github: https://github.com/glitch-game-club/simple-game-to-edit Replit: https://replit.com/@3m-gaming/Grid-Game-Template

Resources

Manual: http://3m.flossmanuals.net Manual Splash page: https://glitch-game-club.github.io/ggcp/manual Menu of GDPs: https://glitch-game-club.github.io/ggcp/ggc-examples/

Historical toolset

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

P2 original editor - Glitch.com - add screenshot.

Getting started

In D1 the decision to work with retro games stemmed from a Home Education consultation event which is described in Chapter 1. This possibility to work with games spurred a return to my own love of arcade games. I became an enthusiastic pirate, scouring the web for emulated versions of the arcade games I played in the late 1970’s and early 1980’s. I was intrigued and impressed by the community of enthusiasts sharing these archives of games, translated into ROMs, and shared online, and creating software to emulate the old arcade machines and home video game consoles.

Exploratory Phase 1

When reviewing my notes on this section I am surprised how the learners managed to keep engaged as I only introduced the actually tools to undertake text coding in week 5 due to my own hesitancy in supporting coding.

The journey certainly took us around the houses with diverse use of tools and processes. I even asked participants to create a mock up of their characters and backgrounds within Scratch as its interface was familiar to some, and more user friendly to others.

I don’t know why it took me so long to adapt a template from the community and use it as a base given that I had taken this approach in my previous study detailing accelerated coding using a starter template of an HTML and css based meme [@chesterman_webmaking_2015].

In week 5 I introduced a minimal template to remix from based on a phaser tutorial. I used this one from Phaser - and adapted it and presented in the Thimble code playground. As of October 2025 it is still available to view https://codepen.io/mrmick/pen/jaXzxw?editors=0010.

Summary of motivations and sources of P2 template

Chapter 5 gives a summary of the motivations of the structure of the P2 starting template. A fuller picture is included here. THIS IS INCOMPLETE RIGHT NOW. COMPLETE IT - AND DECIDE HOW MUCH DETAIL TO GO IN CHAPTER 5 - HOW MUCH HERE.

Appendix D.1.? structural aspects ()

Appendix D.1.? .toolist - Tools used in different phases of activity

  • 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 intuative graphical editor to create backgrounds for the game;

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

Table - or short entries with screenshots.

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

Mapping skills used. See this attempt at a map of skills used in P1 - very extensive but not the focus of this study.

https://docs.google.com/spreadsheets/d/1Zu7bTMmQRj_Kgt6k6cI9nECdBtwgfnUAVd3OGruqoko/edit?gid=1216831858#gid=1216831858

Appendix D.1.? - On Codeplaygrounds from P1-P3

Is the introduction needed?

My dissertation work on Codeplaygrounds at post graduate level used Thimble [@chesterman_webmaking_2015] 1. The pedagogy was guided by Mozilla’s work on Webmaking [@mozilla_foundation_webmaker_2014] 2.

D.1.? - Overview of Code Playground on features

(referenced in Chapter 5 C1)

Relevant for this study

  • Side by side preview
  • Image uploading
  • Code linting
  • Rewind facility

Less relevant

  • Community feedback, support

Reduced functionality of Code Playgrounds in 2025

The deprecation of Glitch and migration has involved the loss of some functionality. The main one being the live aspect of both the Thimble and Glitch tools. The process of working on a project and having an ongoing live weblink which could be shared with fellow participants, friends and family is significant as a contribution to an online community of enthusiasts publishing games. There are several alternatives available now that this functionality has been lost from the toolset but none as immediate and simple.

A similar process happened in 2025 to the glitch platform. Glitch migration was needed after glitch.com announced it would stop hosting in July 2025.

I undertook a process of downloading files and reuploading them to an online repository. They are now online here: https://github.com/glitch-game-club/ggcp.

This begs a question, where best for facilitators to host code playground projects from 2025 onwards.

  • Replit: Live hosting not supported
  • Codepen: Image uploads not supported.
  • Raspberry Pi Code Editor: Image uploading not supported

Appendix D.1.? - Design decisions in the technical decisions of the template design in P2

Creating a web game project from first principles is relatively complex both semantically and practically. There are technical advantages of using a structural template rather than creating from first principles. The process of supporting novice coders via boiler plate templates allows those writing supporting documentation to pull together a pre-built working demonstration is particularly useful in the domain of web technology, which normally consist of collections of HTML, JavaScript, CSS and other configuration files. This process allows users to avoid initial configuration and thus accelerate the process of adding new features to projects. For example the Next.js web framework comes with a large range of starter templates based on common requirements of web sites [@nelson_best_2023].

Phaser starting templates available from the website share this aim of providing scaffolding by providing a downloadable zip of files which when extracted are already interlinked correctly [^5]. 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 .

Evolution of the structure of the starting template

The process

The code is available at the following link - https://glitch.com/edit/#!/grid-game-template?path=game.js%3A242%3A25

Original source of grid template https://web.archive.org/web/20170606010908/http://www.lessmilk.com/tutorial/2d-platformer-phaser

Phaser tutorial https://phaser.io/tutorials/making-your-first-phaser-2-game/ https://web.archive.org/web/20170601000000*/https://phaser.io/tutorials/making-your-first-phaser-game

Code variables and structure

In P1, after delays caused by lack of coding knowledge, I had guided participants to begin their games by using a very partial template based on an online tutorial. As the process continued, it became apparent that the starting template greatly shaped the following design possibilities.

To address this, in the development period between P1 and P2, I redesigned the starting code template of a game with a greater attention to pedagogical concerns in the following ways: I made changes to the code to reduce obscure syntax where possible increasing code readability and simplifying the structure of inter-related functions to facilitate the process of adding new code structures and code snippets.

The choice to pre-select a particular genre, specifically a platformer game (see glossary), was a pragmatic response to reducing the tension caused by diverse help requests, which narrowed the range of game features that would be requested. A summary of how these concerns were implemented in the design process follows (see Appendix 5.tech. for a fuller description).

Graphical asset scaffolding

Turning to the use of graphical assets, the starting template was altered to facilitate and encourage the process of adding designs created by participants. Initial graphical assets consisted of colour blocks, a design choice inviting learners to develop game characters from a clean slate (see Figure 5.px). To help resolve the overly complicated use of multiple asset creation tools, I prioritised the use of the pixel art tool Piskel, as I evaluated it to be intuitive for many younger participants. In P2, participants were guided to make a game on a broadly environmental theme, participants often redesigned sprites to games involving animals. Figure 5.fish shows a whale as a player character and plastic bottles as a hazard and fish as an item to collect.

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

The process of game art and audio creation opportunities seeding narrative and artistic creativity is explored in more detail - IN AN APPENDIX?

Figure 5.fish - a sample set of assets created in Piskel in the context of a working platform game created by child in P2{width=95%}

While I made several technical adjustments to facilitate the swapping of participant graphical designs (outlined in Appendix 5.tech), the process still required a series of potentially tricky operations. While some novice code authoring tools offer self-contained solutions for audio and graphical asset creation by providing in-built authoring tools and libraries of assets, the code playground Glitch provided neither, thus requiring the use of Piskel as an external asset creation tool, complicating the process. However, this forced choice to use a distributed toolset, rather than a self-contained approach to asset management, led to benefits in developing key digital literacy skills needed for web creation. Some participants became remarkably adept at the complex process of migrating assets from Piskel into their games, transforming the chain of actions involved into fluid operations. This section has focused on the rationale behind the introduction and initial expansion of the design’s primary tools, rather than evidencing their subsequent impact on participants, which is explored in Chapter 6.

Audio assset design

To add here

Sonic Pi Online sound editor.

Level design

Addressing level design, in P1 the process was relatively complex involving changing parameters of functions to change asset location, and spiralling code complexity (see Appendix 5.chapter). Instead, to align with research on the value of a visual approach to coding multi-media projects for novices [@guzdial_programming_2004; @resnick_scratch_2009], in the P2 starting template the use of a graphical grid structure to edit level design shown in Fig 5.grid. A minimal choice of level design elements were represented specifically; platforms to be jumped on; hazards to be avoided; and rewards to be collected.

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

Technically, each level is a JavaScript object consisting of a data array of 12 entries containing 17 characters which representing a matrix layout of the game. Each grid entry can be either black or one of the following: x (platform); h (hazard); o (coin). The structure of text-based array has a strong visual correlation with the resulting game layout and changes to the text based grid in the code area on the left would be immediately seen in the right hand project preview area. This solution abstracts away complexity and repetitive nature of asset placement mirroring a technique called tilemaps [@erhard-olsson_procedural_2018] used in GUI oriented game making tools (see glossary and Appendix.tech).

Using Phaser 2 not 3 & Game States

The process of using JavaScript was challenging. At one stage I contacted a developer of JS who had written a tutorial for Mozilla. Her response was why use JS over scratch, and why not use Phaser 3.

These are fair questions the first of which I address in the introduction of the thesis. The technical question of why to not use Phaser 3, a more recent version, raises a point of interest surrounding the complexity of the code syntax used and the initial appearance of the code project to novices.

Object structure and use of this keyword A key decision to keep using Phaser 2 in the development period between P1 and P2 was to avoid the use of the object structure needed to initialise a game state.

The move from Phaser 2 to 3 structure was in part to integrate with other modern JavaScript frameworks but a side effect is to introduce an object structure requiring greater complexity of syntax and the use of this as an object orientated concept.

While a useful programming concept, the this keyword which can refer to a contextual parent object regardless of the context of which function it is called withing, is potentially confusing to explain to novice coders. Instead I judged that referring explicitly to the GameState object was preferable.

To do this, I used global variables in the code in a way which in another context would be problematic, say if interacting with other code libraries.

An alternative would be to use template based on Phaser 3 but use this construct to avoid the use of this via assigning it the name of the state.

https://codepen.io/samme/pen/JjYreex function init() { // You do need to read this, once: state = this;

Structure of Game States

One change that was needed between P1 and P2 was the addition of an initial game state into the starting code.

We can compare the code structure of the Phaser 2 tutorial with the starting template of the P2 starting game.

Phaser.com Phaser 2 tutorial

var game = new Phaser.Game(800, 600, Phaser.AUTO, '', { preload: preload, create: create, update: update });

function preload() {
}

P2 starting game extract

// Initialize the game at a certain size
var game = new Phaser.Game(550, 400, Phaser.AUTO, "game-div", "", false, false);

// The following javascript object called playState contains all the active code for this simple game.
// You can add other states like, win, lose, start etc
var playState = {};

playState.preload = function () {}

The motivation to add game states was driven by the requests of participants to As this was allow the addition of a game over screen, or a starting splash screen to introduce the topic and instructions to play the game.

The decision to introduce this in the starting template was motivated by an experience in P1 of one group who and J - to change the code structure to do this was jarring and reduced the familiarity that they had built up with the existing code structure. This was borne out in a comment in the end of project interview. “Once we had got over x”

Game states and functions to create the game loop (see glossary) are included natively in the phaser framework [@faas_introduction_2017]. Game states allow designers to deconstruct games and game code into collections of sub-units (states) [@kostolny_digital_2017]. For example a simple arcade games may only had an insert coin state, a play state and a game over state. A game coding framework like phaser shields its users from code complexity by providing a game state manager and associated functions out-of-the-box, meaning that lots of underlying code is already written and hidden from view. To increase simplicity for my participants the starting template I created had only one game state called PlayState. It followed the following structure: a beginning section out side of a function declaring variables; a preload function which loads assets into the game; a create function which sets up the initial game; an update function which listens to and responds to user input. The following illustration from the step-based instructions illustrates the structure for participants, including the possibility to create new game states e.g. a game over state.

{width=55%}

4.x - Game states and function structure explained in the Glitch Game Makers manual created for for P2 and P3

Template structure and asset placement - Add in Chapter tutorial example extract here too

In P1 the suggested process of adding game elements was relatively complex 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 [^7].

Complexities included: each element needs to be added separately with code elements required in three different areas of the code template, adding x,y coordinates to place each game elements was; difficulties concerning adding graphical elements of different sizes. These complexities created frustrations in the game making activity P1, in particular as project became bigger cod became unwieldy and confusing to alter, causing a negative impact on the testing and revision process in particular.

Grid structure for graphical assets I had previously set the dimensions of the matrix above based on this size to create a resulting game size of 550, 400, in line with a retro game style.

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

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

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.

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.

Coding Concepts Systems Patterns Design Practices
Sequences Systems Elements Goal Setting
Variables Systems Dynamics Being Incremental and Iterative
Logic Reinforcing Feedback Loops Developing Vocabulary
Loops Balancing Feedback Loops Web Navigation
Arrays   Problem Solving
Creating Functions   Version Control
Change Listener   Debugging
Input Event   Reusing and Remixing

Table 1.1. Learning Dimensions of the 3M Game Making Model

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.

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

Reflection on personal appropriation of concepts

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

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 .recommendations - for practitioners - KEEP OR DROP?

Additional commentary from chapter 6.

Practitioners can use GDPs to foster of culture, home interests and evolving participation in an idioculture

The link to home interests and funds of knowledge is demonstrated in varied ways which enrich the development of a community idioculture which is inclusive and productive in terms of the practicalities of learning how to make games.

The work of Rogoff and Wegner and Lave has guided the surfacing activity in the such as legitimate peripheral participation, community norming and taking on roles of specialism.

At times, activity crosses between cultural and pair guided processes - DEVELOP HOW

  • the role of playtesting as a medium for cultural exchange and a ground in which culture grows in of note
  • individual requests and implementations can spread via playtesting
  • the immediacy of designing for other is used by parents or children to norm behaviour in inter-personal interactions.

Recalling that cite one of the challenges of learning coding

GDPs again - Move some of this to Chapter 2 if helpful?

Both the GDPs and the sub-actions of the wider activity design become short-cuts which stand in for previously tricky to complete set of actions.

Rather than promising the transfer abstract concepts to other domains, we see learners build competency in participation in replicable processes. These processes which aid future iterations of the GDP implementation design cycle. The process of operationalisation of these sets of actions contributes to the creation of an informal, complex networked resource of operations which complement the more visible curated catalogue of GDPs.

Game design patterns or their fragments are used as a form of design short cuts. Examples from the above include, get an enemy in , animate player or get it in the game (when referring to transferring an graphical asset from authoring tool to the coding environment). The advantages of such shortcuts are, as discussed, to help with the prioritisation and ideation processes, to facilitate peer propagation of ideas, and potentially to inform debugging and improvements to increase game playability.

There are challenges of the use of these short cuts and at a more general the design choice to lead with a menu of intermediate-level constructs in the form of a menu of GDPs. There may be confusion over use of terms to new comers and these GPD related terms may hide more complex patterns within the name. For example, the shortcuts in Mark and Ed’s interaction hides a large amount of problems solving which seems “overwhelming”. GDPs can limit the ideation process through an accelerated approach. Also as the menus themselves are not all used by students, and while GDPs do propagate from student to student, which risk further constraints on the process of asking questions about user experience and exploring ideas before committing to implementation.

The concept of a restricted activity helps us understand the value a GDP collection for participants & Design Pattern collections can help structure a learning design into an inclusive pedagogy

The process of creating a learning design where students were able to choose from a curated set of game design patterns, evolved from open approach in P1 and can be seen as a form of restricting possible activity. The positive impact of restricted choice of activities are outlined in varied educational concepts including Bruner’s reducing degrees of freedom [@wood_role_1976]. In the 3M design the process of offering a choice of games patterns emerged to counter a previous open design process of which many learners found too challenging. The patterns emerged chiefly in response to requests from learners and partly from facilitator decision making which broadly matched the criteria of the other study. However, in Eriksson’s study the authors selected from an extensive, pre-existing pattern collections [@bjork_patterns_2005].

Design patterns have been explored as a form of scaffolding [@ertmer_scaffolding_2019] for project based learning experiences. Research on design online experiences shows value in interrelated scenarios, features and underlying patterns and principles [@mor_assessing_2014; @kali_collaborative_2006].

In its engagement with participant choice over which patterns to implement, and varied approaches to making facilitated by varied uses of GDPs, this chapter has begun a process of exploration of the nature and evolution of agency in the practices of the participants, which is continued in the next chapter.

Unplaced - but needed.

Technical / Additional Blog Posts.

Publish the following as blog posts

  • Break down of the starter code design structure decisions and adaptations as a contribution to applied half-baked / UMC research.

Footnotes

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

  1. Thimble was an online code editor for teaching HTML, CSS, and JavaScript, released in 2012 and updated in 2015. It was shut down in 2019. Mozilla allowed Thimble projects to be migrated to Glitch.com which they suggested as a replacement. ↩

  2. https://wiki.mozilla.org/Webmaker/Whitepaper ↩