Yesterday at the Training 2006 conference (sorry for the break, but Disney’s internet plan is too silly, and Sprint’s new upgrade is too restrictive) I heard Stephen Johnson (author of “Everything Bad is Good For You”) make a compelling case for the thinking skills required to successfully play computer games. His argument is that playing such games develops new and necessary skills like systems-thinking and systematicity (both of which I support as curricular items).

I agree that such games require them, but not that they develop them. I cited two data points in a question to him: that there’s much evidence that kids ask around for solutions rather than solving the problems, and normally reflective kids will turn ‘twitch’ in the presence of a computer game. He responded well that they’ll only ask about the tough questions, and (I hope I’m recalling correctly) that there are some concerns about twitch but you can’t succeed well in the complexity of modern games without reflection.

Both true, but they sort of avoid the point. I’m willing to wear that (some) kids will develop such skills, but I also want to suggest that they won’t develop and transfer without support. Parents/mentors have to be involved until we build problem-solving coaching into the games (and we can, but that’s another story).

In Gamasutra, Tom Heaton’s come up with a framework for the cycle of interaction between the player and the system. He talks about the player (I keep writing ‘learner’ :) perceiving the system’s response, analyzing the situation, and implementing an action which is then executed, and the game engine calculates a response. He carries it forward as a tool to analyze a game, where if the play experience isn’t sufficient you can use the framework as an way to look for problems.

The problem is, of course, that Don Norman’s ‘Gulfs of Execution and Evaluation’ model does it far better in my opinion (it’s in his Design of Everyday Things book, which is highly recommended). It’s designed to understand the usability of a system so is very cognitively-oriented, and it may not capture the emotional side without some work, but overall it’s richer and consequently more practically useful.

I was reminded about the Narrative in Interactive Learning Environments conference from a brief email exchange, and I have to laud it. I missed the first workshop, but (caveat) was an invited speaker to the second, and have been reviewing the programme submissions as a committee member subsequently.

Set in one of my favorite cities, Edinburgh, Paul Brna (a luminary in the AI & Education community, which really is the best cognitive learning technology group despite the uninviting title) runs a delightful event with a good speaker selection, varied and inspired extra-curricular events, and consequent heady discussion. Held in conjunction with the Edinburgh Festival, it’s an unbeatable combination.

This year I queried the Narrative element in the title (finding it hard to shake people out of ‘telling a story’, I have an aversion to any hint of linearity), and he wisely noted that the user experience is a narrative, even if the design is not, and there is a reason to focus on what the outcome is. Besides, it’s a great acronym…

Consider this a strong recommendation for the conference.

I’m currently downunder, in Oz, so I’m not quite as involved as usual. Fortunately, in the interim there’s a lively discussion on games going on in ITFORUM, with guest host Lloyd Rieber. Lloyd’s not only a wise and nice guy, but more importantly here is that he’s done serious experimentation with what works in game design, and has shared his article on research on games/simulations/microworlds. Highly recommended.

As I work with more folks in developing learning games (er, sorry, scenarios or simulations, we can’t use the ‘g’ word :)), I refine my understanding of how to streamline the process (and make it more pragmatic). I’ve just added two tools to the resources on the site for the book: templates/guides for a concept document and the storyboard.

I’m now focusing on using the notion of decisions, with correct choices (in a setting) and consequences, and misconceptions and their consequences, as the core design framework.

In developing a design, I use a concept doc to capture the initial objective, representative decisions and associated misconceptions, etc. It also pragmatically captures a proposed storyline (to advance the discussion).

Once the concept doc is signed off, you start work on the storyboard, which captures the look and feel, each screen (or screen type), prose, rules, variables, etc.

I welcome feedback on either, as well.