I spoke at an NMC conference with Jess Hammer in New Haven in the fall of 2005. At the conference an erstwhile designer from Boston College was showing a 'game' that had been developed for members of the nursing program. The problem was that to the development team, the aspects that made it a game were all of the surface trappings of game play. It had nice graphics. It had audio feedback on mouse over. It didn't look like a standard web page. There was only one problem.
It was really a multiple choice/matching test in which there was exactly one correct arrangement of four possible solutions that the students had to figure out.
That was it. Nothing else.
I blogged about it extensively on the Eggplant Lab blog (long since disappeared) detailing how several of us in the audience used the Q&A period to extend the design to make it a game.
I wish that I still had the post.
The problem that I see repeatedly is the mis-mapping of the game's appearance or the game's engine to be the critical component of what makes a digital artifact a game. What makes the design a game is the choice of actions within the systems presented to the player.
To be fair, I made this same mistake in my first attempt to create a game for instruction back in 2003. It had the feeling of being an experience, but it was not a game.
So what brings me to rant about this at time?
Another example, this one out of the Utah State University. The project is a virtual environment that is intended to help engage students with the poem Voices of Spoon River. I was reading the research write-up (Need the link) and the author was quoting John Kirriemuir about the paucity of instructional 'games ' actually having interesting game play. And then in the implementation section the author asserts that using the Quake 3 engine for his project meets Kirriemuir's requirement, completely missing the point! Aaaaauuuughhhh!
I haven't yet played the game, so my criticism is of the write up rather than the 'game'. But I'm not too hopeful of what awaits me.
Comments