Cognitive Walkthrough for Learning Through Game Mechanics at ECGBL13
Upcoming SlideShare
Loading in...5
×
 

Cognitive Walkthrough for Learning Through Game Mechanics at ECGBL13

on

  • 667 views

This presentation supports my paper at ECGBL13. ...

This presentation supports my paper at ECGBL13.

The central idea to the presentation is that making serious games that are reliably able to achieve their goal is really hard.

Good theory tends to be at a very high level, whereas game design happens on a day to day basis at a much lower level.

We need procedures and processes that can help designers bridge the gap between theory and practice.

Cognitive Walkthrough is a well established UI process that helps UI designers to correct their mistaken assumptions and biases by scaffolding their thinking - but there is nothing magical about UI design.

All interaction design requires the designer to think "like" another type of user.

So I'm arguing that we should adapt Cognitive Walkthrough to support our game designers, particularly serious game designers.

I also present one adaptation of Cognitive Walkthrough and use it to evaluate why very similar sections of one educational game differed greatly in their success.

Statistics

Views

Total Views
667
Views on SlideShare
667
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • With close reference to the player description created earlier, the evaluator should ask questions like: • Will the player understand the visual metaphors? • Will the player read and understand required text? • Will the player’s attention be drawn to the correct elements? • Will the player understand that the meaning of game interactions has a subject domain application?
  • For the successful Soap Section, the game actions were converted into the following inferences: 1. The player must realise that the environment in which they play represents a human hand. 2. The player must understand that she isn’t “firing bullets” but rather throwing soap. 3. The player must realise that the game’s placement of bad bugs on skin represents the reality that we have harmful bugs on our skin. 4. The player must realise that the bad bugs are being washed away by the soap. 5. The player must realise that the bad bugs are bugs, and not aliens or other enemies. 6. The player must realise that this doesn’t just happen in the game; it represents reality in that soap is used in real life to remove microbes from the hand. 7. The player must understand holistically that washing her hands will remove harmful bugs.
  • 1. Player must realise that the environment they are playing in represents "inside a human body". 2. Player must realise that the bad bugs are microbes (viruses) and not aliens etc. 3. Player must realise that the game's placement of the virus inside the body represents the real-world concept of a human being infected with a virus. 4. P layer must realise it's a white blood cell! 6. Player must realise that "white blood cells" are the body's natural defences. 8. Player must realise that most “coughs and colds” are viruses. 5. Player must realise that the bad bugs when hit by the WBC are being killed. 7. Player must realise that this doesn't just happen in the game; it represents reality in the sense that white blood cells kill infections. 9. Player must understand holistically that this means that their body can kill most infections like colds and flu’s by itself.
  • • the player was considered unlikely to recognise the artwork as representing the desired domain concept from sight alone because the concept is new to the player (e.g. white blood cells); • the introductory text was unlikely to be understood (25 sentences over 5 screens, each shown for 5 seconds); • the language used in the game is not consistent with the test question asked (e.g. the game referred viruses, yet the quiz refers to “coughs and colds”); • there were too many new concepts being introduced to reasonably expect the player to understand the semantic mappings.

Cognitive Walkthrough for Learning Through Game Mechanics at ECGBL13 Cognitive Walkthrough for Learning Through Game Mechanics at ECGBL13 Presentation Transcript

  • Cognitive Walkthrough for Learning Through Game Mechanics David Farrell & David Moffat Glasgow Caledonian University
  • Key Messages • We should be adapting tools, such as Cognitive Walkthrough to support serious game designers. • It’s hard to make good GBL
  • Information and animations for junior and senior pupils across Europe.
  • Lesson packs for teachers in junior and senior schools.
  • a game to teach junior pupils
  • a game to teach senior pupils
  • K. Squire & Civ III D. W. Shaffer & Soda War on Terror Sweatshop
  • Cognitive Walkthrough • A HCI technique, well established in UI design and evaluation. • Instead of relying on pure instinct, CW offers cognitive scaffolding.
  • Typical CW • Stage 1:“Defining Inputs” • describe users • describe task • describe system • list each action required to complete task
  • Typical CW • Stage 2:“Walkthrough” • 1:Will user try to achieve effect? • 4: If correct action performed, will user notice progress towards solution? • 3: Will user associate correct action with the desired effect? • 2: Will user notice correct action available?
  • CW and Serious Games • UI design is not unique in the requirement of the designer to ‘imagine’ the user’s brain • All interaction design requires the designer to simulate how someone else will think • This is also true of game design. • This is important in GBL
  • Bespoke CWs • There are many viable GBL pedagogies • Whatever the underlying theory, there is a risk translating that theory, through design into game implementation. • To be useful, a CW should map to pedagogy
  • CWLTGM • Stage 1:“Defining Inputs” • describe users • describe task • describe system • list each action required to complete task
  • CWLTGM • Stage 1:“Defining Inputs” • describe players • describe task • describe system • list each action required to complete task
  • CWLTGM • Stage 1:“Defining Inputs” • describe players • describe desired learning outcome • describe system • list each action required to complete task
  • CWLTGM • Stage 1:“Defining Inputs” • describe players • describe desired learning outcomes • describe how game entities & behaviours map to subject-domain • list each action required to complete task
  • CWLTGM • Stage 1:“Defining Inputs” • describe players • describe desired learning outcomes • describe how game entities & behaviours map to subject-domain • list actions required that are assumed to support learning
  • CWLTGM • Stage 2:“Walkthrough” • 1:Will user try to achieve effect? • 2:Will user notice correct action available? • 3:Will user associate correct action with the desired effect? • 4: If correct action performed, will user notice progress towards solution?
  • CWLTGM • Stage 2:“Walkthrough” • 1:Will user attempt the game task? • 2:Will user notice correct action available? • 3:Will user associate correct action with the desired effect? • 4: If correct action performed, will user notice progress towards solution?
  • CWLTGM • Stage 2:“Walkthrough” • 1:Will user attempt the game task? • 2:Will user understand which in-game actions might achieve the task goal? • 3:Will user associate correct action with the desired effect? • 4: If correct action performed, will user notice progress towards solution?
  • CWLTGM • Stage 2:“Walkthrough” • 1:Will user attempt the game task? • 2:Will user understand which in-game actions might achieve the task goal? • 3:Will user associate correct action with the progress towards game task completion? • 4: If correct action performed, will user notice progress towards solution?
  • CWLTGM • Stage 2:“Walkthrough” • 1:Will user attempt the game task? • 2:Will user understand which in-game actions might achieve the task goal? • 3:Will user associate correct action with the progress towards game task completion? • 4: If correct action performed, can we expect learning to take place?
  • Step 4 of Walkthrough
  • • In the less successful area of the game, I identified 9 separate logical links required Findings • Of these only 3 appeared safe • Applying CWLTGM in this capacity offered reasonable explanation of confusing results
  • Conclusion • Gap between best pedagogical theory and ‘day to day’ game design • Too much depends on designer instinct and intuitive simulation of users’ mental model • CW is a general purpose tool, not restricted to UI design, that can help structure this process • We will need bespoke CWs depending on pedagogy
  • Future Work • More analyses of (un)successful games with this process • Using CWLTGM during design process
  • Questions? • I’d love to hear from anyone interested! • david.farrell@gcu.ac.uk