02 - Technical analysis of the game template design of the study

Introduction

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

This appendix outlines the evolution of the structure of the starting template and a detailed examination of the tensions involved. It provides additional information to Chapter 5 of the thesis.

The code used for the P2 and P3 sessions is available at the following link - https://jamm-labs.github.io/ggcp/grid-game-template/

I started by working through the Phaser 2 tutorial which is available at the following link,

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

This was used as the basis of the process in P1

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

EXPORT THIS>

The process of adding assets involved adding three new lines of code for each asset added in three different areas of the code project. This resulted in code that became very difficult to read and maintain.

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

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.

{width=95%}

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

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

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.