In his recent Learning Trends newsletter, Elliot Masie says: "If the learner sees
re-creation of an application screen, for example, but can only make one
or two limited function choices, this might be closer to an 'emulation'". To echo and elaborate Clark Aldrich's post, "Houston, we've got a problem".
I think Elliot's confounding the underlying implementation from the fundamental experience. And while I endorse that experience is important, certainly from the user/learner's perspective, what's important from a designer/trainer perspective is what our learning goals are and how we achieve them.
Perhaps it's my academic background, but I want to converge on some language. I've decided to start using 'simulation' for a model of an underlying phenomena. It can be interactive, but it's the model that counts. I want to separate that from when we have a simulation with certain initial conditions, and an end-state we want to achieve, perhaps (indeed, ideally) with a story wrapped around it ("Find the antidote to this gas, Dr."). That, I want to call a 'scenario'. And I want to reserve the label 'game' for when we've tuned the experience around a scenario to something the user considers a game (you can't label it a game, only your users can tell you that).
I'm open to debate (yes, you too can post a comment and weigh in here), but technically, a simulation is just a model, and I want to separate that from when you have to actually achieve something.
Not quite sure how to deal with those pernicious quiz show templates and the 'game' label, except to argue that in those few times when you really need to drill rote knowledge, instead of trying to develop meaningful skills, they may have a role. However, it makes talking about games difficult, and we've just got to stop that!
Also, a brief plug for (the other) Clark's book; I've seen a draft and it's good stuff, covering a swath of approaches, and some real nice metaphors to think about the deeper necessities in design.
