Blogs

Theming Gdps

ChatGPT

feedback on this

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

That works well in context because it feels genuinely provisional and exploratory, which fits the reflective tone running through the GDP posts. The hand-drawn quality helps communicate that these ideas were emerging through practice rather than arriving as a finished framework.

A few thoughts though:

“early attempt at dividing features by type and difficulty” is clear, but slightly functional. You could lean a little more into the reflective/process aspect.

“dividing” sounds a bit mechanical. “organising”, “mapping”, or “grouping” might fit the narrative tone better.

“feature” is okay, but if the surrounding discussion is about GDPs specifically, naming them directly could strengthen continuity.

Possible alternatives:

Journal sketch showing an early attempt to map gameplay design patterns by type and difficulty {width=85%}

Early journal sketch exploring how gameplay design patterns might be grouped by type and perceived difficulty {width=85%}

Notebook sketch from the early stages of organising gameplay design patterns into different categories and levels of complexity {width=85%}

Journal sketch capturing an early attempt to make sense of emerging gameplay design patterns through categories and difficulty levels {width=85%}

The last one probably fits best if the surrounding writing is reflective and about emergence rather than presenting a polished taxonomy.

all the regular stuff you have here

zotero: scannable-cite: false # only relevant when your compiling to scannable-cite .odt client: zotero # defaults to zotero author-in-text: false # when true, enabled fake author-name-only cites by replacing it with the text of the last names of the authors csl-style: harvard-cite-them-right # pre-fill the style layout: post number-sections: true categories: blogs title: Exploring game elements with new coders draft: true

Early in my journey of helping young people to making their own digital games. I adapted a simplified framework of game elements developed for use in youth-oriented Game Jams to help novice game makers hack/analysis and then adapt key elements of non-digital games ¹.

This Game Jam guide had a lot of great games and content that helped teach game making concepts in an accessible way. It helps 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.

To do this it breaks down academic and professional interpretations of game elements, for example Schnell’s detailed analysis of tens of game elements presented as design lenses ², in a way suitable for a younger audience. The resulting framework has been passed between different organisations and programmes undertaking this kind of work.

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?

Creating a 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 here is a link to a printable power point sheet with the above structure.

Here is some guidance for use.

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.

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 interact 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 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 Soundtrack (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 - Categorisation of gameplay design patterns used in P4

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%}

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

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.

Dialogue of use of physical maps at the start of a game making session

Photo of Island {width=85%}

The following transcription details the use of a map created using the elements of the GDP framework on in the table above.

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

Footnotes

This is strong overall. It feels grounded in practice and has a clear through-line from practical workshop activity → emerging categorisation → later conceptual/theoretical framing. The reflective tone also works well for the blog format.

The strongest aspect is probably that it shows theory emerging from practice rather than theory being imposed in advance. That connects really well to the wider narrative running through your PhD reflections.

A few things I think could be tightened or clarified though. Main strengths

The practical examples make the ideas accessible.

The transition from youth game jam activities into your own GDP work is convincing.

The map/island activity is excellent material. It concretely demonstrates learner navigation, challenge, agency, and social interaction.

The sketch image and progression toward categorisation gives the post a nice “research in motion” feel.

The discussion of adapting professional frameworks for novices is one of the clearest links to your thesis contributions.

Main areas to improve

Opening sentence needs smoothing

This currently reads awkwardly:

Early in my journey of helping young people to making their own digital games.

You probably want something more like:

Early in my journey of helping young people make their own digital games, I adapted a simplified framework of game elements developed for use in youth-oriented Game Jams.

Or:

Early in my work supporting young people to make their own digital games, I adapted a simplified framework of game elements developed for use in youth-oriented Game Jams.

The second is probably cleaner. 2. “hack/analysis” feels unclear

This phrase:

help novice game makers hack/analysis and then adapt key elements

doesn’t quite scan.

Maybe:

help novice game makers analyse, hack, and adapt key elements of non-digital games

Or:

help novice game makers break down and remix key elements of non-digital games

The latter fits your broader remix/pedagogy language quite nicely. 3. There are quite a few grammar slips throughout

A few examples:

implicit knowledge of game design concepts in to explicit share vocabulary

Should be:

implicit knowledge of game design concepts into explicit shared vocabulary

Schnell's detailed analysis of tens of game elements

Should be:

Schell’s detailed analysis of dozens of game elements

(or “many game elements”)

way suitable for a younger audience

Should be:

in a way suitable for a younger audience

simplifyed to game polish

Should be:

simplified to game polish

used by suited simplification

This sentence breaks grammatically:

For example, the term aesthetics is very broad, so I used the simplified term game polish.

The theory paragraph gets overloaded

This paragraph:

This categorisation, while simplified, is consistent with professional and technical frameworks...

starts well but becomes dense.

You could split it:

This categorisation, while simplified, is consistent with professional and technical frameworks popular in game making communities including the MDA framework [@olsson2014conceptual], the Elemental Tetrad [@schell_art_2008], and DDE [@korn_design_2017].

My aim was not to reproduce these frameworks in full, but to adapt aspects of them into forms that were accessible to novice and younger game makers. This broader theme of adapting professional and technical structures into accessible mediational tools continued throughout Chapters 5 and 6 of the thesis.

That gives the argument more breathing room. 5. The map section is genuinely interesting, expand it slightly

This is one of the strongest sections conceptually:

synergies with between open-world game design and my attempts to structure resources

That idea could use another paragraph because it links directly to:

navigation

agency

self-directed progression

challenge selection

game-space metaphors for learning

Something like:

What interested me about this approach was that it started to resemble aspects of open-world game design itself. Rather than all participants following a single linear pathway, learners could navigate towards different challenges based on interest, confidence, and curiosity. Some participants deliberately selected difficult or distant challenges, while others focused on smaller or more immediate goals. The map therefore became both an organisational device and a social representation of learner agency within the space.

That would strengthen the significance of the vignette that follows. 6. Figure caption formatting

This line:

Figure Scan of Journal Sketch of early attempt at dividing features by type and difficulty - Dated 11.3.2019

feels clunky.

Maybe:

Figure 4.x: Journal sketch exploring early attempts to group gameplay design patterns by type and perceived difficulty (11.3.2019).

Minor but important: “game polish” probably needs framing earlier

Because “game polish” is slightly informal, it may help to introduce it intentionally:

I began using the term game polish as a more accessible alternative to the broader concept of aesthetics.

That makes it sound purposeful rather than simplified accidentally. Overall

This is one of the clearest blog posts yet in terms of showing:

how your pedagogy evolved

how GDP categorisation emerged

how practical workshop design connected to theory

how spatial metaphors and navigation became important

The transcript section especially helps ground the abstract discussion in observable interaction, which is one of the strongest features of your wider writing.

let’s end it liek this - adn put in related posts here.

This interaction shows some key elements of how a group understanding of the different patterns and features involved began, and was in a way seeded by my involvement as a practitioner. For example, the linking of recognisable patterns with new support documentation, the ability for participants to pick their own level of challenge and the grouping of areas of interests aligned with a categorisation of possible patterns. These aspect developed into themes and tactics explored in other blog posts. For example x, y etc.

Plain text:

This interaction shows some key elements of how a shared understanding of different gameplay patterns and features began to emerge, and how this process was, in part, seeded through my own role as a practitioner and facilitator. For example, the linking of recognisable gameplay patterns with support documentation, the ability for participants to select their own level of challenge, and the grouping of areas of interest through categories of possible patterns.

These ideas gradually developed into broader themes and design tactics explored elsewhere in the project and in related blog posts. For example, Reflection on Choice and Messy Learning explores the role of learner choice and non-linear participation, while Reflection on Jamming reflects on collaborative and improvisational aspects of the learning environment. Meeting yourself in the middle - structuring linear manuals for non-linear work connects these ideas to the challenge of creating support materials for open-ended learning processes, and On the way Gameplay Design Patterns became a vital part of my PhD thesis traces how these patterns gradually evolved into a central mediational structure within the research.

Markdown:

turn this in to html

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

Scan of Journal Sketch of early attempt at dividing features by type and difficulty

Photo of Island {width=85%}

Photo of Island

ok this is getting a bit confusing now - i’ve added a section on practice - but there’s now theory stuff there too - how to oganize

all the regular stuff you have here

zotero: scannable-cite: false # only relevant when your compiling to scannable-cite .odt client: zotero # defaults to zotero author-in-text: false # when true, enabled fake author-name-only cites by replacing it with the text of the last names of the authors csl-style: harvard-cite-them-right # pre-fill the style layout: post number-sections: true categories: blogs title: Exploring game elements with new coders draft: false weight: 120

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?

Using a printable framework to support game analysis via game elements

This staged approach was discussed in the design narrative section of my PhD writing.

Advancing a stage-based pedagogy structured around GDPs

In the learning design outlined in this chapter, GDPs drive stage-based instructional processes. Adapting terminology from Denner et al. (2019), the shift from P1 to P2 represents a move from a design-build-test to a stage-based approach. The term stage-based here describes a process that introduces code structures and challenges in an initially simplistic, prototypical format for learners to experience and explore, and which are subsequently replaced by more advanced models or complex instances of the task. In this design, this stage-based approach is enacted through participant interaction with increasingly sophisticated documentation and code structures.

The structure of documentation, created in response to participant requests to add new GDPs to their games, evolved from a piecemeal format in P1 to, by the end of P2, a menu of GDP code snippets accompanied by detailed instructional documentation. This progression is shown in Table 5.4.

Stage	Pedagogical focus	Design focus
Stage 1	Informally identifying GDPs	Identifying GDPs via an activity of playing games
Stage 2	Quick start cards	The quick start cards supported rapid changes to GDPs highlighted as affordances in the starting game code template
Stage 3	Adding simple GDPs	These additions required only small-scale changes to the template structure
Stage 4	Advanced GDPs	Larger changes, including new functions or fundamental changes to the code

Table 5.4 – A representation of the staged processes

So, how did we get here?

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 in Chapter 5 of my thesis. This categorisation, while simplified, is based on professional and technical frameworks popular in game making communities including: game design patterns, the MDA framework and DDE³. The theme of using technical frameworks in an accessible way to facilitate the creations of novice participants is outlined in the chapters five and six of my PhD thesis.

The process of theming them of I then took the existing list of game elements that have been identified by students and categorised them based on a blend of these 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 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 Soundtrack (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 - Categorisation of gameplay design patterns used in P4

Sketching towards a map to help navigation

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

Dialogue of use of physical maps at the start of a game making session

Photo of Island

The following transcription details the use of a map created using the elements of the GDP framework on in the table above.

Transcript	Description
Mick (facilitator): 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 representing a GDP of key and doors.
Tehillah (child): 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 (parent): 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.”

Footnotes

I think what’s happening is that the post has quietly become three different things at once:

A practical resource for educators

A reflective narrative about your design process

A conceptual/theoretical bridge into GDPs and pedagogy

None of those are wrong, but they currently weave in and out of each other a bit unpredictably. The result is that the reader loses track of whether they are:

learning a workshop activity,

reading a reflective account,

or reading conceptual analysis.

The good news is that the material itself is strong. It mainly needs clearer layering.

I do not think you need to split this into separate posts yet. I think you just need a stronger structural progression from:

practical
→ reflective
→ conceptual.

At the moment theory arrives too early and then keeps reappearing. The main issue

This section:

Advancing a stage-based pedagogy structured around GDPs

is the point where the post suddenly becomes thesis-like.

Up until then the tone is:

practical,

grounded,

workshop-based.

Then suddenly:

Denner et al.

stage-based pedagogy

design-build-test

pedagogical processes

documentation structures

That material is interesting, but it changes genre abruptly. My recommendation Structure the post into 3 clearly separated layers

Practical origin story

Keep:

Game Jam framework

5 elements

printable worksheet

classroom/game analysis activity

Tone:

accessible

practitioner-facing

concrete

This should feel:

“Here’s an activity I used and why it was useful.”

Emergence and adaptation

THEN move into:

participants requesting features

categorisation evolving

GDP themes

maps

sketches

challenge organisation

Tone:

reflective

exploratory

“I noticed…”

This is where the post becomes:

“The activity started evolving into something larger.”

Conceptual reflection

ONLY near the end bring in:

stage-based pedagogy

MDA

DDE

game theorists

open-world parallels

navigation/agency ideas

Tone:

interpretive

conceptual

retrospective

This becomes:

“Looking back, I can now see theoretical significance.”

Specifically: what I would move MOVE THIS SECTION DOWN NEAR THE END

Advancing a stage-based pedagogy structured around GDPs

This is the main structural disruption.

Right now it appears before:

the GDP categorisation,

the maps,

the participant interactions.

But conceptually it depends on those examples.

The reader needs to SEE the process first.

Then you can say:

“Looking back, this resembled a stage-based pedagogy.”

That would massively improve the flow. Suggested structure

Something more like:

Intro

Game Jam framework + adapting for novices

Using a printable framework

Practical activity 5 elements worksheet

From analysing games to requesting features

Participants begin asking for mechanics/features Emerging categorisation

Grouping gameplay design patterns

Your categories table Mechanics / polish / challenge etc.

Sketching towards a map

Notebook sketches difficulty rings navigation

Using maps in sessions

Transcript island activity

Reflecting on the pedagogy that emerged

NOW introduce:

stage-based pedagogy
GDP scaffolding
documentation evolution
MDA/DDE links
open-world navigation parallels

Closing reflection + related posts

That order would feel much more natural. Another important point

You are mixing:

“this is what I did then”
with

“this is how I later theorised it”

Those need clearer signalling.

Use phrases like:

At the time, I mainly saw this as…

Looking back, I can now see…

or:

Only later did I begin connecting this to…

Those little transitions help enormously. I would also soften the academic density

For example this:

This categorisation, while simplified, is based on professional and technical frameworks…

works better late in the post after readers already understand the practical examples.

Right now it arrives before readers fully understand the actual activity. What the post is REALLY about

I think the hidden core of this post is actually:

How informal game analysis activities evolved into navigational learning structures for participant-led coding.

That’s a very good blog post topic.

Once you realise that, the organisation becomes easier:

analysis activity

requests/features

categorisation

maps/navigation

learner agency

theoretical reflection

That’s the real arc.

but the stage based is part of 2 - not practical

Yes, I think you’re right actually. The issue is not that the stage-based section is “too theoretical”, it’s that it currently arrives before the reader fully understands:

what the GDPs are becoming,

why categorisation mattered,

and how the support structures evolved from the activity.

So the problem is more sequencing/context than category.

I’d now frame it more like this: Layer 1 — Practical entry point

Game Jam activity

5 elements

worksheet

analysing games

Layer 2 — Emerging pedagogical structure

This includes:

stage-based pedagogy

evolving documentation

participant requests

categorisation of GDPs

quick start cards

increasing complexity

maps/navigation

This is still design/process, not “pure theory”. Layer 3 — Retrospective conceptual reflection

Only here:

MDA/DDE

open-world parallels

game theorists

agency/navigation interpretation

So I think your instinct is correct: the stage-based material belongs in the middle.

What probably feels confusing is that the middle layer currently oscillates between:

concrete workshop history,

thesis explanation,

conceptual framing,

and practitioner guidance.

I think the actual fix is: Move the “So, how did we get here?” section UP

directly after the stage-based section.

Because they are really the SAME discussion.

At the moment you have:

Practical worksheet ↓ Stage-based pedagogy ↓ So how did we get here? ↓ GDP categorisation

But logically it should probably be:

Practical worksheet ↓ Participants start requesting features ↓ Stage-based support/documentation evolves ↓ GDP categorisation emerges ↓ Maps/navigation ↓ Theoretical reflection

So instead of isolating “stage-based pedagogy” as a formal academic block, integrate it into the story of emergence. In practice I’d restructure like this Section 1 Using a printable framework to support game analysis

Game Jam framework

worksheet

activity

Section 2 From game analysis to gameplay patterns

participant requests

identifying recurring features

quick start cards

evolving documentation

staged complexity

THIS is where your stage-based table belongs.

Because the table is really about:

how support structures evolved around participant-selected gameplay features.

That’s coherent. Section 3 Grouping gameplay design patterns

mechanics/polish/space/challenge

simplification for novices

GDP categories

Section 4 Sketching towards maps and navigation

sketches

concentric rings

challenge mapping

islands

Section 5 Reflecting on navigation and open-ended learning

NOW:

open-world parallels

navigation

learner agency

MDA/DDE/game theory

That keeps the conceptual escalation gradual.

At the moment the post jumps:

practice → pedagogy jargon → practice → theory → vignette

You want:

practice → evolving structure → categorisation → navigation → reflection

That’s the hidden narrative already inside the material.

is this in other posts?

A bit, yes, which is probably part of why it feels hard to organise. The themes are spreading across several posts already, but from different angles.

Here’s roughly how I think they currently overlap:

On the way Gameplay Design Patterns became a vital part of my PhD thesis

→ emergence of GDPs as a core mediational structure
→ practitioner/research journey
→ abstraction/concrete tensions

Meeting yourself in the middle

→ structuring support materials
→ manuals/documentation/navigation
→ linear structures for non-linear learning

Reflection on Choice and Messy Learning

→ learner choice
→ non-linear participation
→ self-direction and agency

Reflection on Jamming

→ collaborative environment
→ improvisation
→ social organisation of the learning space

This new post is different because it is much more:

grounded in an actual workshop activity,

focused on categorisation/navigation,

and about the transition from analysing games → organising learning pathways.

So I do not think it is redundant. But I do think you should avoid trying to fully explain every connected theory thread here.

At the moment this post risks becoming:

the GDP post,

the choice post,

the navigation/manuals post,

and the pedagogy post,
all at once.

Instead, I’d let this post specialise more clearly around:

how game element analysis activities evolved into navigational structures for learner-led coding.

That gives it a distinct role in the network.

Then the other posts can do the heavier lifting on:

abstraction/concrete debates,

remix pedagogy,

manuals,

jamming,

agency models.

So rather than removing overlap entirely, I’d use overlap intentionally:

this post introduces/grounds ideas,

linked posts deepen them from different perspectives.

That actually suits the “choose your own adventure” ecology you’re building across the blog series.

so - stage based - down play - just one part of it? - put the stages in reeeppp?

Yes, I think that would help a lot.

Right now the “stage-based pedagogy” section risks becoming disproportionately important relative to the rest of the post. It suddenly sounds like:

“this is the pedagogy.”

But the rest of the post actually shows something more fluid, negotiated, and emergent.

And that aligns much more closely with your wider REEPPP framing.

So I would:

downplay “stage-based pedagogy” as one useful structure,

rather than presenting it as the defining model.

Because what your examples actually show is:

remix,

elective pathways,

pattern patching,

variable progression,

navigation by interest,

evolving support structures,

social exploration.

That is much closer to REEPPP than to a strongly staged curriculum model. I think the cleaner framing is:

The staged support/documentation:

was one infrastructural tactic,

inside a broader REEPPP-style ecology.

That feels much more accurate to the actual material.

So instead of:

Advancing a stage-based pedagogy structured around GDPs

maybe something softer like:

Developing staged support around gameplay patterns

or:

Using gameplay patterns to support progressive challenge

or:

From quick-start cards to more advanced gameplay patterns

Those titles sound:

developmental,

practical,

emergent,
rather than declaring a formal pedagogical model.

Then REEPPP becomes the bigger umbrella

This is probably the cleaner conceptual hierarchy:

REEPPP └── gameplay design patterns └── staged support/documentation └── maps/navigation

Rather than:

stage pedagogy └── everything else

And I think your actual evidence supports the first model much better. The stages table itself

I would keep it, but:

shorten the surrounding explanation,

make it sound descriptive not declarative,

frame it as “one way the support structures evolved”.

Something like:

As participant requests became more varied, the supporting documentation gradually evolved from quick prompts and starter modifications into a broader collection of gameplay pattern guides. Looking back, this process loosely resembled a staged progression, where learners moved between increasingly complex forms of modification depending on their interests and confidence.

That tone fits the rest of the blog much better. Then save the heavier pedagogy framing for:

REEPPP post,

thesis chapters,

or dedicated pedagogy-focused writing.

Because this post’s strength is really:

tangible workshop practice,

emergent categorisation,

learner navigation,

and the visual/spatial organisation of challenge.

ok lets’ linke to reeppp now - finish this to do so

add link to chpater 5 too.

This staged approach was discussed in the design narrative section of my PhD writing.

Plain text:

As the project developed, this relatively simple activity gradually became connected to broader approaches for supporting participant choice, progression, and remixing through gameplay design patterns (GDPs). Rather than functioning as a rigid sequence of stages, the activities and supporting documentation evolved into a more flexible ecology of optional pathways and challenges. This later contributed to the development of the REEPPP pedagogical model discussed in the related post REEPPP , and in more detail within the design narrative section of Chapter 5 of the thesis.

Markdown:

As the project developed, this relatively simple activity gradually became connected to broader approaches for supporting participant choice, progression, and remixing through gameplay design patterns (GDPs). Rather than functioning as a rigid sequence of stages, the activities and supporting documentation evolved into a more flexible ecology of optional pathways and challenges. This later contributed to the development of the REEPPP pedagogical model discussed in the related post REEPPP, and in more detail within the design narrative section of Chapter 5 of the thesis.

make it practioner focused

Plain text:

What I found useful about this approach was that it created a bridge between playing games and making them. Over time, the activity also became a way of helping participants choose their own directions and levels of challenge. Some learners became interested in animation, others in enemies, level design, scoring systems, or storytelling. This gradually led to the creation of collections of gameplay pattern examples and support sheets which participants could navigate based on their interests.

These ideas later connected to the broader REEPPP approach discussed in the related post REEPPP , and are explored in more detail in the design narrative section of Chapter 5 of the thesis.

Markdown:

These ideas later connected to the broader REEPPP approach discussed in the related post REEPPP, and are explored in more detail in the design narrative section of Chapter 5 of the thesis.

reorder?

all the regular stuff you have here

zotero: scannable-cite: false # only relevant when your compiling to scannable-cite .odt client: zotero # defaults to zotero author-in-text: false # when true, enabled fake author-name-only cites by replacing it with the text of the last names of the authors csl-style: harvard-cite-them-right # pre-fill the style layout: post number-sections: true categories: blogs title: Exploring game elements with new coders draft: false weight: 120

Using a printable framework to support game analysis via game elements

Early in my journey of helping young people and their families to making their own digital games, I used a break-down of game elements to help them deepen their knowledge and language of video games. We began each session by playing classic arcade and console games that were on the laptops as they entered the rooms. Sometimes I even brought in arcade cabinet boxes with real buttons and joysticks.

This framework was developed for use in youth-oriented Game Jams to help novice game makers hack/analysis and then adapt key elements of non-digital games ¹. It helps 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. I have put this resource online for other practitioners: here is a link to a printable power point sheet with the above structure.

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?

This activity helped students become familiar with these elements sometimes called the five principles of game design. You can students what they already know about these terms or see what educated guesses they may have before giving the answers away.

These ideas later connected to the broader REEPPP approach discussed in the related post REEPPP, and are explored in more detail in the design narrative section of Chapter 5 of the thesis.

Dialogue of use of physical maps at the start of a game making session

Photo of Island

The following transcription details the use of a map created using the elements of the GDP framework on in the table above.

Transcript	Description
Mick (facilitator): 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 representing a GDP of key and doors.
Tehillah (child): 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 (parent): 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.”

So, how did we get here?

The following section is aimed more at game nerds, or academics rather than practitioners in general.

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 Soundtrack (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 - Categorisation of gameplay design patterns used in P4

Sketching towards a map to help navigation

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

Footnotes

Yes, this ordering is much better already. The post now has a much clearer “expanding outward” structure:

practical activity

participant interaction

reflective interpretation

theoretical deepening

That feels natural.

I only think a few smaller reorder tweaks would improve the flow further. Main recommendation Move “Sketching towards a map to help navigation”

UP before the dialogue section.

Because right now:

the dialogue suddenly introduces islands/maps,

before the reader fully understands where the maps came from.

The sketch section is effectively the conceptual bridge into the vignette.

So I’d do:

Using printable framework ↓ So, how did we get here? ↓ GDP categorisation table ↓ Sketching towards maps/navigation ↓ Dialogue of map use ↓ Closing reflection + related posts

That creates a much smoother escalation.

At the moment the post does:

worksheet ↓ dialogue with islands ↓ THEORY ↓ sketches explaining islands

which is slightly backwards. Why this matters

The map dialogue becomes MUCH stronger if the reader already understands:

categories,

challenge mapping,

concentric rings,

navigation ideas.

Then the dialogue feels like:

“Ah, now I can see this in practice.”

instead of:

“Wait, where did these islands come from?”

Another small structural improvement Rename:

So, how did we get here?

It sounds slightly defensive/apologetic.

And:

“The following section is aimed more at game nerds…”

slightly weakens confidence in the material.

You do not need to apologise for the theory turn.

Maybe something more like:

From game analysis to gameplay patterns

or:

Grouping gameplay patterns

or:

Developing gameplay pattern categories

These keep the flow continuous. Then the sketch section becomes

Sketching towards maps and navigation

which nicely follows the categorisation section. Then the dialogue section becomes the payoff

The dialogue section is now the strongest part of the whole post because it demonstrates:

navigation,

learner agency,

differentiated challenge,

social mediation,

documentation use,

facilitator positioning,
all concretely.

So you want the post building towards it.

Right now the dialogue appears too early for maximum effect. My suggested final structure

Using a printable framework to support game analysis
- game jams
- 5 elements
- worksheet
- practitioner framing
- REEPPP mention
Developing gameplay pattern categories
- participant requests
- GDP categorisation
- mechanics/polish/space/challenge
Sketching towards maps and navigation
- concentric rings
- challenge organisation
- open-world parallels
- sketch image
Dialogue of map use in practice
- island vignette
- transcript
Reflection and related posts
- learner choice
- support structures
- links outward

That feels coherent and progressive.

ok - mild proof reading - not tone

all the regular stuff you have here

zotero: scannable-cite: false # only relevant when your compiling to scannable-cite .odt client: zotero # defaults to zotero author-in-text: false # when true, enabled fake author-name-only cites by replacing it with the text of the last names of the authors csl-style: harvard-cite-them-right # pre-fill the style layout: post number-sections: true categories: blogs title: Exploring game elements with new coders draft: false weight: 120

Using a printable framework to support game analysis via game elements

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?

These ideas later connected to the broader REEPPP approach discussed in the related post REEPPP, and are explored in more detail in the design narrative section of Chapter 5 of the thesis.

Sketching towards a map to help navigation

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

Dialogue of use of physical maps at the start of a game making session

Photo of Island

The following transcription details the use of a map created using the elements of the GDP framework on in the table above.

Transcript	Description
Mick (facilitator): 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 representing a GDP of key and doors.
Tehillah (child): 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 (parent): 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.”

So, how did we get here?

The following section is aimed more at game nerds, or academics rather than practitioners in general.

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 Soundtrack (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 - Categorisation of gameplay design patterns used in P4

Footnotes

Plain text:

“helping young people and their families to making their own digital games”
→ “helping young people and their families make their own digital games”

“hack/analysis”
→ “analyse, hack, and adapt”

“implicit knowledge of game design concepts in to explicit share vocabulary”
→ “implicit knowledge of game design concepts into explicit shared vocabulary”

“Schnell's detailed analysis of tens of game elements”
→ “Schell’s detailed analysis of dozens of game elements”

“This activity helped students become familiar with these elements sometimes called the five principles of game design.”
→ add comma after “elements”

“You can students what they already know”
→ “You can ask students what they already know”

“themes to contains the emerging game elements”
→ “themes to contain the emerging game elements”

“mapping the different challenges by difficulty on a map via structuring via concentric rings”
→ slightly cleaner:
“mapping different challenges by difficulty using concentric rings”

Figure caption:

Figure 4.x: Journal sketch exploring early attempts to group gameplay patterns by type and perceived difficulty (11.3.2019).

“synergies with between”
→ remove “with”

“The following transcription details the use of a map created using the elements of the GDP framework on in the table above.”
→ “The following transcription details the use of a map created using elements of the GDP framework shown in the table below.”

“So you don’t want to any any health meter?”
→ probably:
“So you don’t want to add any health meter?”

“I related this simple categorisation the emerging list”
→ “I related this simple categorisation to the emerging list”

“The process of theming them of I then took”
→ currently broken sentence. Maybe:

I then took the existing list of game elements identified by students and categorised them using a blend of these frameworks.

“simplifications and adaption”
→ “simplifications and adaptations”

“the term of aesthetics is very wide and used by suited simplification”
→ currently grammatically broken. Maybe:

For example, the term aesthetics is very broad, so I used the simplified term game polish.

remove double full stop after _game polish_..

“collect all food before progressing to next level”
→ “collect all food before progressing to the next level”

“adding new levels the game”
→ “adding new levels to the game”

“included system and challenge patterns”
→ “include system and challenge patterns”

“These explore at how”
→ “These explore how”

Overall, this now reads much more coherently. The flow is considerably clearer than earlier versions and the practitioner/theory balance feels more controlled.

give me md - keep comments

all the regular stuff you have here

zotero: scannable-cite: false # only relevant when your compiling to scannable-cite .odt client: zotero # defaults to zotero author-in-text: false # when true, enabled fake author-name-only cites by replacing it with the text of the last names of the authors csl-style: harvard-cite-them-right # pre-fill the style layout: post number-sections: true categories: blogs title: Exploring game elements with new coders draft: false weight: 120

Using a printable framework to support game analysis via game elements

Early in my journey of helping young people and their families make their own digital games, I used a break-down of game elements to help them deepen their knowledge and language of video games. We began each session by playing classic arcade and console games that were on the laptops as they entered the rooms. Sometimes I even brought in arcade cabinet boxes with real buttons and joysticks.

This framework was developed for use in youth-oriented Game Jams to help novice game makers analyse, hack, and adapt key elements of non-digital games ¹. It helps participants develop their implicit knowledge of game design concepts into explicit shared vocabulary before engaging in digital making via collaborative analysis of common games. I have put this resource online for other practitioners: here is a link to a printable power point sheet with the above structure.

To do this it breaks down academic and professional interpretations of game elements, for example Schell’s detailed analysis of dozens of game elements presented as design lenses ², in a way suitable for a younger audience. The resulting framework has been passed between different organisations and programmes undertaking this kind of work.

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?

This activity helped students become familiar with these elements, sometimes called the five principles of game design. You can ask students what they already know about these terms or see what educated guesses they may have before giving the answers away.

These ideas later connected to the broader REEPPP approach discussed in the related post REEPPP, and are explored in more detail in the design narrative section of Chapter 5 of the thesis.

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 contain the emerging game elements. I also explored the concept of mapping different challenges by difficulty using 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

Figure 4.x: Journal sketch exploring early attempts to group gameplay patterns by type and perceived difficulty (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.

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

Dialogue of use of physical maps at the start of a game making session

Photo of Island

The following transcription details the use of a map created using elements of the GDP framework shown in the table below.

Transcript	Description
Mick (facilitator): 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 representing a GDP of key and doors.
Tehillah (child): 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 (parent): 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 add 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.”

So, how did we get here?

The following section is aimed more at game nerds, or academics rather than practitioners in general.

I related this simple categorisation to the emerging list of requests for game features made by my participants. The final categorisation used in P4 is included in Chapter 5 of my thesis. This categorisation, while simplified, is based on professional and technical frameworks popular in game making communities including: game design patterns, the MDA framework and DDE³. The theme of using technical frameworks in an accessible way to facilitate the creations of novice participants is outlined in the chapters five and six of my PhD thesis.

I then took the existing list of game elements identified by students and categorised them using a blend of these frameworks. I made some simplifications and adaptations to increase accessibility for non-professional and young people. For example, the term aesthetics is very broad, so I used the simplified term game polish.

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 collecting all food before progressing to the next level. Others concerned aspects of game space: the size and shape of the game world; and adding new levels to the game. In P5 I extended the scheme to include system and challenge patterns. These explore how different elements interact to create challenge in the game.

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 Soundtrack (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 - Categorisation of gameplay design patterns used in P4

Footnotes

give me another outro - or move some of the related posts to the end for the nerds that got there

Plain text:

I think moving the more theory-heavy related posts to the very end would work well. Right now the current ending slightly interrupts the momentum of the vignette reflection by immediately branching into multiple conceptual threads.

A softer ending could:

conclude the practical narrative first,

then offer optional “further reading” for people wanting the deeper theory/design side.

Something like this:

This interaction shows some key elements of how a shared understanding of gameplay patterns and features began to emerge through collaborative activity. The use of maps, categories, worksheets, and recognisable gameplay features helped participants navigate different challenges based on their own interests and confidence levels. Over time, these kinds of activities gradually evolved into a wider collection of gameplay pattern examples, support sheets, and navigational structures used throughout the project.

For practitioners, one of the most useful aspects of this approach was that it created multiple entry points into coding and game design. Participants did not all need to follow the same pathway, start from the same interests, or progress at the same speed.

If you are interested in the more theoretical or research side of these ideas, some related posts include:

The broader design narrative and development of these ideas is also discussed in Chapter 5 and Chapter 6 of the thesis.

That structure:

lets the practitioner-focused conclusion land properly,

then turns the rest into optional onward routes,
which fits your wider “non-linear reading” ecosystem nicely.

not bullet points - If you are interested in the more theoretical or research side of these ideas, some related posts include one on the way Gameplay Design Patterns became a vital part of my PhD thesis traces how these patterns gradually evolved into a central mediational structure within the research and a follow up post on how they can be framed in relation to abstract and concrete interpretations of computing concepts in education.

If you are interested in the more theoretical or research side of these ideas, the related post On the way Gameplay Design Patterns became a vital part of my PhD thesis traces how these patterns gradually evolved into a central mediational structure within the research, followed by a second post exploring how gameplay design patterns can be framed in relation to abstract and concrete interpretations of computing concepts in education. Related themes concerning learner choice, navigation, and open-ended learning environments are also explored in posts on REEPPP, Reflection on Choice and Messy Learning, and Reflection on Jamming.

broken in 2 for 2 audiences

all the regular stuff you have here

zotero: scannable-cite: false # only relevant when your compiling to scannable-cite .odt client: zotero # defaults to zotero author-in-text: false # when true, enabled fake author-name-only cites by replacing it with the text of the last names of the authors csl-style: harvard-cite-them-right # pre-fill the style layout: post number-sections: true categories: blogs title: Exploring game elements with new coders draft: false weight: 120

Using a printable framework to support game analysis via game elements

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?

These ideas later connected to the broader REEPPP approach discussed in the related post REEPPP, and are explored in more detail in the design narrative section of Chapter 5 of the thesis.

Sketching towards a map to help navigation

Scan of Journal Sketch of early attempt at dividing features by type and difficulty

Figure 4.x: Journal sketch exploring early attempts to group gameplay patterns by type and perceived difficulty (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.

Dialogue of use of physical maps at the start of a game making session

Photo of Island

The following transcription details the use of a map created using elements of the GDP framework shown in the table below.

Transcript	Description
Mick (facilitator): 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 representing a GDP of key and doors.
Tehillah (child): 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 (parent): 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 add 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.”

These ideas gradually developed into broader themes and design tactics explored elsewhere in the project and in related blog posts. For example, Reflection on Choice and Messy Learning explores the role of learner choice and non-linear participation, while Reflection on Jamming reflects on collaborative and improvisational aspects of the learning environment. There is another post on how gameplay design patterns were used by participants and meeting yourself in the middle - structuring linear manuals for non-linear work connects these ideas to the challenge of creating support materials for open-ended learning processes.

So, how did we get here?

The following section is aimed more at game nerds, or academics rather than practitioners in general.

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 collecting all food before progressing to the next level. Others concerned aspects of game space: the size and shape of the game world; and adding new levels to the game. In P5 I extended the scheme to include system and challenge patterns. These explore how different elements interact to create challenge in the game.

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 Soundtrack (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 - Categorisation of gameplay design patterns used in P4

If you are interested in the more theoretical or research side of these ideas, some related posts include one on the way Gameplay Design Patterns became a vital part of my PhD thesis traces how these patterns gradually evolved into a central mediational structure within the research and a follow up post on how they can be framed in relation to abstract and concrete interpretations of computing concepts in education.

Footnotes

Yes, this works much better now. The split is becoming clearer:

first half = practitioner-facing

second half = reflective/theoretical deepening

And importantly, you signal the transition explicitly.

I think the only thing still slightly muddy is that the first “related posts” paragraph comes a little too early now that you have a second audience section later.

You effectively have:

practitioner ending

theory section

theory ending

So I’d simplify the first related-post paragraph to keep it practitioner-focused, and let the second ending do the heavier theory linking.

Something like this would make the split cleaner:

For me, one of the most useful aspects of this approach was that it created multiple entry points into coding and game design. Participants did not all need to follow the same pathway, start from the same interests, or progress at the same speed. Related practitioner-focused reflections on learner choice and collaborative environments can be found in Reflection on Choice and Messy Learning and Reflection on Jamming.

Then your later theory-facing outro becomes the “further reading for nerds” section.

Also, this sentence at the end still needs a slight grammar fix:

Maybe:

That gives you a much cleaner:

practitioner close,

then optional theory extension.

md in full

If you are interested in the more theoretical or research side of these ideas, the related post On the way Gameplay Design Patterns became a vital part of my PhD thesis traces how these patterns gradually evolved into a central mediational structure within the research. A follow-up post explores how gameplay design patterns can be framed in relation to abstract and concrete interpretations of computing concepts in education. Related themes concerning the organisation of support materials and navigation through open-ended learning environments are also explored in Meeting yourself in the middle - structuring linear manuals for non-linear work.

full thing

all the regular stuff you have here

zotero: scannable-cite: false # only relevant when your compiling to scannable-cite .odt client: zotero # defaults to zotero author-in-text: false # when true, enabled fake author-name-only cites by replacing it with the text of the last names of the authors csl-style: harvard-cite-them-right # pre-fill the style layout: post number-sections: true categories: blogs title: Exploring game elements with new coders draft: false weight: 120

Using a printable framework to support game analysis via game elements

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?

These ideas later connected to the broader REEPPP approach discussed in the related post REEPPP, and are explored in more detail in the design narrative section of Chapter 5 of the thesis.

Sketching towards a map to help navigation

Scan of Journal Sketch of early attempt at dividing features by type and difficulty

Figure 4.x: Journal sketch exploring early attempts to group gameplay patterns by type and perceived difficulty (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.

Dialogue of use of physical maps at the start of a game making session

Photo of Island

The following transcription details the use of a map created using elements of the GDP framework shown in the table below.

Transcript	Description
Mick (facilitator): 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 representing a GDP of key and doors.
Tehillah (child): 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 (parent): 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 add 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.”

So, how did we get here?

The following section is aimed more at game nerds, or academics rather than practitioners in general.

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 collecting all food before progressing to the next level. Others concerned aspects of game space: the size and shape of the game world; and adding new levels to the game. In P5 I extended the scheme to include system and challenge patterns. These explore how different elements interact to create challenge in the game.

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 Soundtrack (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 - Categorisation of gameplay design patterns used in P4

If you are interested in the more theoretical or research side of these ideas, the related post On the way Gameplay Design Patterns became a vital part of my PhD thesis traces how these patterns gradually evolved into a central mediational structure within the research. A follow-up post explores how gameplay design patterns can be framed in relation to abstract and concrete interpretations of computing concepts in education. Related themes concerning the organisation of support materials and navigation through open-ended learning environments are also explored in Meeting yourself in the middle - structuring linear manuals for non-linear work.

Footnotes

The Game Jam Guide: How can designing games about real world issues teach students empathy, systems thinking, and design thinking? https://kilthub.cmu.edu/articles/book/The_Game_Jam_Guide/6686948?file=12212804 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
See here - https://schellgames.com/art-of-game-design ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
for an overview of the interaction between game design patterns and game mechanics see here - FULLTEXT01.pdf - and for related reading on a similar frameworks MDA and DDE see here - ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

Visual prototyping - some examples