Potential Book Chapter on specifics of the Learning Design from Computer Science perspective

Tensions due to lack of access and familiarity to game programming tools

MOVE THIS WHOLE SECTION BEFORE DESIGN ADAPTATION / CODE PLAYGROUND

Conflicts arose due to a contradictions between the desire of participants to use the tools to create games and their lack of experience of them. FINESSE THIS WITH MORE DETAIL - accumulation

The process of helping participants build familiarity and competency in tool use was further complicated by my own motivations for working with as authentic as practical game authoring tools.

Thus crux of the conflict is that coding games to create a webpage using a text environment is a complex process. While some of the group had some experience, many did not. In early stages, this gulf created a tension between the need to use the tools and text coding processes which often resulted in frustration and paralysis in the activity of game coding. While, tensions stemming from gaps in knowledge and practice are commonly addressed in formal learning environments through forms of instruction, the informal nature of this learning setting allowed for more flexible approaches.

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

The motivation was to align to authentic web technology due to my previous experience. The reason for working with code this authentic bears exploration. Characteristics of broader dimensions of authenticity of tools and processes in learning environments are explored in the literature review. A brief summary being: similarity to workplace settings; facilitating activity which serves a need of participants; an ability to showcased resulting work to an audience [@shaffer_thick_1999; @warr_bridging_2020]. While my choice of open source digital tools allowed for a high level of aligning with professional practices, it was also potentially complex in terms of use of tools. In part my motivation for choice of code language (Javascript, Phaser) was driven by desire to align with common workplace practices and to be potentially extensible for future student-led web projects.

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

Design adaptations to facilitate novice use of a code playground

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

Addressing code syntax errors

COMPRESS AND LINK TO ABOVE PARAGRAPH

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

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

While block coding offers significant advantages (GL)in preventing syntax errors, in a comparison to text coding approaches, Bau and colleagues summarise the inherent disadvantages [@bau_learnable_2017]. These include: block coding can take of a lot of the users screen; making small changes to code can be tricker in blocks than text; block coding can complicate remote collaboration and version control; searching for code structures is simpler using text code. While these disadvantages are more applicable to more advanced users, they remain relevant to my general goal of working with an environment aligned to professional practices.

Distributed vs. self-contained approaches to asset creation

SHIFT FROM P1-> P2 IMPORTANT, TENSION OF A NEAT APPROACH WITH LESS FRICTION > AUTHENTIC SKILLS

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

In P1 I observed participant showing a high motivation to incorporate assets created in a diverse set of graphical and audio tools, often struggling to overcome the technical challenges in the process. Responding to the enthusiasm of participants in asset creation, I had introduced the following tools to participants including:

• 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;

Not all participants would use all of these tools; rather suggested their use responsively based on their immediate need. However, similar patterns of use emerged. Participants would identify the need for an asset in their game. They would then use the separate software to create that asset, and the be supported to save assets to their computer’s hard drive in a compatible format. They would then need to upload assets to the code playground environment, discover the text link of the asset, and then insert that link into the main javascript game file at the relevant line of code.

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

Despite these benefits, I was concerned that in P1 the diversity of asset related approaches had caused a complexity and distraction from the leading activity of game making. To address this, in P2 I reduced the number of tools suggested when creating assets. The distributed nature of the toolset used helped build authentic digital literacy skills. Analysis of the video data of participants using the more fragmented tool set used, which involve one online tool for coding and others for asset authoring, reveals a large number of broader digital literacy skills. For example, the processes of replacing a block image with a bespoke pixel sprite which comprised: file downloading; file migration using the browser and file manager; browser tab navigation; graphics tool use in Piskel; copying and paste text code; and selecting more than one lines of text code with mouse or keyboard shortcuts. Undertaking the full process involved learning a complex chain of these individual actions. Some participants became remarkably adapt at this, thus transforming this chain of actions into a fluid operation.

Remixing and showcasing projects

REDUCE THE IMPORTANCE OF THIS PARAGRAPH - NO REALLY STRONG DATA SO SUMMARISE TENSIONS

Another common feature of novice coding tools is the use of a gallery of creations, in a way which aligns with the potential for community-based learning strongly advocated by Gee and Ito [@gee_what_2003; @ito_hanging_2010]. The ability to easily remix community projects, supports the process of becoming familiar with, and using other projects or approaches as a base, thus supporting the use and modify stage of the UMC pedagogy (see glossary). Remixing also informs professional practice [@kotsopoulos_pedagogical_2017-1] in the form of distributed revision control tools such. A practice known as code forking.

As explored in the LT, Code playgrounds address issues of complexity of web coding environment and practices of forking by providing access to a self-contained server structure from within a browser. However for novice users the web location still also offers friction in terms of digital literacy issues of logging in, remembering passwords, linking to email accounts for password reminders. To circumvent these issues in P2 and P3 all participants and facilitators used a shared account for code playground the graphics editor.

In this program, while participants where not encouraged to browse the creations of a wider web-based community, they were encouraged to view and interact with fellow participants projects.

Practically, in novice coding communities, this is encouraged by the use of community galleries and buttons encouraging. In Scratch this is seen in buttons named see inside and remix when viewing projects. Similarly both the Thimble (used in P1) and Glitch (used in P2 and P3) prominently featured remix buttons and view source buttons in the community interface. The shared community element on the other hand was quite different for glitch due to its very mixed user base and range of different web based projects. In this learning design I took a decision to not promote with existing online communities but to focus instead on internal sharing of projects between the group.

The process of adding a remix button, removes the needs for participants to copy underlying code by hand and set up the parameters of a new project. This process is especially relevant in reducing barriers to initial participation given the use here of authentic professional text-based coding language and potential alienation from unfamiliar syntax and file structures.

This theme of shielding from complexity is contained in all design choices detailed above and in turn aligns with a constructionist design principle to ‘choose black boxes carefully’ [@resnick_reflections_2005, p. 119]. A black box here refers to the process of hiding away aspects or functionality of the code or processes. The decisions made in the design each tool shape the skills and concepts the end user is guided towards. While the principle here is applied to software tool use, it also applies to the use of a starter game template, as explored in the next section.

Design choices of the starter game template

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

The initial use of a working structural template was an intuitive response based on my own experience of teaching technology. The choice to pre-select a particular genre was initially a pragmatic response to tensions experienced in P1. When offering feedback to address her family’s feeling of isolation from the coding process, the parent of the family described in part two of this section had more hands on play and use of the tools of production before being called on to make creative decision, likening this to an arts studio approach. I realised that to allow for this playful experimentation, a purely structural template was insufficient and that a working game template was preferred. To create the template I drew on the structure of online tutorials ¹ to support create a two-dimensional platformer game ². The following section describes designs decisions relevant to the evolution of this starting template by drawing on concepts explored in the literature review, namely: UMC approaches; constructionist design heuristics; and the domain of human-computer interaction (HCI) research. In particular, I explore the concept of affordances understood from a socio-cultural perspective as ’technology affordances as possibilities for human actions mediated by cultural means’ [@kaptelinin_affordances_2012, p.927].

Structural design of the game template

A web code project using the chosen game framework phaser consists of several interlinked files of Javascript, HTML and CSS and image files. Creating the project from first principles is relatively complex both semantically and practically. In the domain of web technology, starter templates consist of pre-built collections of HTML, JavaScript, CSS and other configuration files which allow users to avoid initial configuration and thus accelerate adding 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 ¹.

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

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 (See Figure 4.x below)

Variable editing for player movement

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

{width=95%} 4.x glitch coding environment with code structure of left menu, a central code window with code, comments and game preview on the right.

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

Level design and prototyping

ILLUSTRATE BLOCK HERE WHICH BECOMES A TENSION - IN P1 OF PARTICIPANTS WANTING TO DO THINGS THEY COULDN’T -

The use of a graphical grid structure to edit level design helped balance concerns of accessibility with the use of authentic code language. Platform games often conform to certain patterns in terms of the elements involved in a level and their affordances. Common elements include the player that you control to movement of, platforms to be jumped on, enemies to be avoided and rewards to be collected. In the templated used in P1 the process of adding game elements was involved relatively complex process which involved changing parameters of functions to alter to adjust their location. An example of the code needed to add two platforms is included one of my tutorial chapters ³. In the preload function the following code would be added.

game.load.image("grass:4x1", "images/grass_4x1.png");

Then in the create function the following code would be added.

var platform1 = platforms.create(150, 220, 'grass:4x1');
platform1.body.immovable = true;

var platform2 = platforms.create(250, 150, 'grass:4x1');
platform2.body.immovable = true;

Using this technique to add level design elements had several disadvantages which introduced tensions into the game making activity. These including: complexity of adding function parameters for screen coordinates and difficultly of troubleshooting location; the need to add code to various places in the code; each platform needs to be added separately; and the difficultly of creating and swapping out different size graphical files when altering the length of a platform. A similar process was also needed for each reward and hazard. While in early stages I took measures to mitigate some of these complexities, the process remained too complex for the immediacy of game modification that I envisaged as desirable. For the template use in P2, I revised the starting template to created game elements was based on a visual design in a grid format(see figure 4.x below). Changes to the text based grid in the code area on the left would be immediately seen in the right hand project preview area.

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

I adopted a different solutions which abstracted away complexity to prioritise ease of use to help sustain participant engagement. Technically, this approach involves the construction of a data array for each level of 17 blocks which can be one of the following: x (platform); h (hazard); o (coin); or could be left blank (see Figure 4.x above). The end result was that while participants altered a text-based array, the grid structure had a strong visual correlation with the resulting game layout. This design choice allowed alignment with design principles for tools for novice coders, in particular the importance of visual approach to facilitate the programming multi-media projects for novices [@guzdial_programming_2004; @resnick_scratch:_2009]. This adaptation had a positive impact on engagement with level design in initial stages. Many participants spending significant time and effort undertaking many iterations of changes to the level design. As explored in the vignette above, Toby designed many levels making the game very challenging but still technically possible. Participants varied in their approach to level design, some drew on their experiences to mirrors platform game conventions, while others enjoyed working against these conventions, a theme which is explored in more detail in chapter five.

Background colour and a pixel art

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

Participants were keen to replace the default coloured block sprites of game elements with their own art of characters and backgrounds. From P2 onwards the one suggested tool to do this was the online Piskel tool ⁴. A pixel art approach to graphics allowed a balance between the potential for positive engagement with game making and the potential drain of time to this one activity, thus helping resolve one of the tensions emerging in P1. Piskel had proved to be intuitive for many younger participants with three main areas: a set of editing tools; a canvas for creation; and a set of tools to export, save and import work (see Figure 4.x).

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

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

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

Observations on the game template and core tools

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

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

Gilbert is the worsted name.