Thursday, April 28

How not to talk about simulations, Pt 2

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.

2 comments:

Jim Schuyler said...

I like your suggestion that a "simulation" is a complete model. Matches what I would think as a computer scientist and as an engineer. What you're calling a "scenario" (which is also a good choice) is embodied in good business case studies as well - a good clear problem statement, some alternatives, and opportunity for (limited) choice. And in our (my) online "full-immersion" technologies, I also call these set-ups where the learner has limited choices "scenarios." So both of those appellations make sense to me. On the idea of what's a "game" - I half agree with you - it is true that we usually depend on the learner to label it as a game - just as "brand" is in the eye of the beholder (and not dictated by the marketing specialist). But also, a "game" can be a game in the sense of Game Theory (von Neumann & Morgenstern) - a game can be any situation in which there are multiple choices to be made and multiple outcomes which depend on those choices in complex ways. This is where we get the phrase "gaming the system" isn't it? So, from a popular culture perspective a "game" must be fun and it's only fun if the player thinks it's fun, but from a more theoretical standpoint it's still a "game" if there are complex choices and complex outcomes.

Anonymous said...

^^ nice blog!! ^@^

徵信, 徵信, 徵信, 徵信社, 徵信社, 徵信社, 感情挽回, 婚姻挽回, 挽回婚姻, 挽回感情, 徵信, 徵信社, 徵信, 徵信, 捉姦, 徵信公司, 通姦, 通姦罪, 抓姦, 抓猴, 捉猴, 捉姦, 監聽, 調查跟蹤, 反跟蹤, 外遇問題, 徵信, 捉姦, 女人徵信, 外遇問題, 女子徵信, 徵信社, 外遇, 徵信公司, 徵信網, 徵信, 徵信社, 外遇蒐證, 抓姦, 抓猴, 捉猴, 調查跟蹤, 反跟蹤, 感情挽回, 挽回感情, 婚姻挽回, 挽回婚姻, 感情挽回, 外遇沖開, 徵信, 徵信, 徵信社, 抓姦, 徵信, 徵信社, 外遇蒐證, 外遇, 通姦, 通姦罪, 贍養費, 徵信, 徵信社, 徵信社, 抓姦, 徵信社, 徵信社, 徵信, 徵信, 徵信公司, 徵信社, 徵信, 徵信公司, 徵信社, 徵信社, 徵信社, 徵信社, 徵信社, 徵信公司, 徵信社, 徵信, 徵信, 徵信公司, 女人徵信, 外遇, 外遇, 外遇, 外遇

徵信, 徵信網, 徵信社, 徵信網, 徵信, 徵信社, 外遇, 徵信, 徵信, 徵信社, 抓姦, 徵信, 徵信社, 外遇, 徵信社, 抓姦, 徵信社, 徵信公司, 徵信, 徵信社, 徵信公司, 徵信, 徵信社, 徵信公司, 徵信社, 徵信社, 徵信社, 徵信社, 徵信, 徵信社, 徵信社, 徵信社, 徵信