Yesterday I wrote about examples as stories. And I received a comment that prompted some reflection. The comment suggested that scenarios were stories too. And I agree!  They’re not examples, but they are stories. With a twist.

So, as I’ve said many times, simulations are just a manipulable model of the world. And a motivated, self-capable learner can learn from them. But motivated and self-capable isn’t always a safe bet. So, instead, we put the simulation in an initial state, and ask the learner to take it to a goal state, and we choose those such that they can’t get there until they learn the relationships we want them to understand. That’s what I call a scenario.  And we can tune those into a game. (Yes, we turn them into games by tuning; making the setting compelling, adjusting the challenge, etc.)

Now, a scenario needs a number of things. It needs a context, a setting. It needs a goal, a situation to be achieved. And, I’ll suggest, it should also have a reason for that goal to make sense. If you see the alignment that says why games should be hard fun, you’ll see that making it meaningful is one of the elements. And that, I say, is a story. Or, at least, the beginning of one.

In short, a story has a setting, a goal, and a path to get there. We remove boring details, highlight the tension, etc.  We flesh out a setting that the learner cares about, provide a sense of urgency, and enable the goal achievement.  But it’s not all done.

The reason this isn’t a complete story is we don’t know the path the protagonist uses to accomplish the goal, or ultimately doesn’t.  We’ve provided tools for that to happen, but we, as designers, don’t control the protagonist. The learner, really, is the the protagonist!

What I’m talking about is that the story, certainly for the learner, is co-created between the world we’ve developed, and their use of the options or choices we provide. Together, a story is written for them by us and them.  And, their decisions and the feedback are the story and the learning!  It’s, voilà, a learning experience.

Learning is powerful. Creating experiences that facilitate learning are creative hard fun for the designer, and valuable hard fun for the learner. Learning is about stories, some told, some c0-created, but all valuable.

The game we designed (as I talked about yesterday), Quest for Independence, was actually a fair bit of a hit. While we couldn’t talk to kids still, anecdotally we heard that the kids were playing it. And, as the design intended, it led them to talk to the Care counselors. That was good enough, but there was more.

First, the Aussie science program Quantum had a bit on it. They even interviewed me (with a big production about bringing stuff to our house), but never used the footage.  They also couldn’t talk to the kids ‘in care’, but it turns out Quest was being used by kids not in care!  High schools were using it to explore life after school as well. That was a nice outcome.

Another occurrence brought new action. Sometime after the game launched, I became aware of the Common Gateway Interface (CGI) standard for the web. What this did was allowed web pages to do backend processing based upon user actions, and then programmatically change the front end.  In short, web pages could react based upon what had happened before.

For Quest, this meant that we could port it to the web!  That is, you started the game, the player’s actions were sent to the web, the program could calculate the outcome and render an appropriate new page, with the graphics assembled to represent the game variables, the current location, and more.  This was exciting.

And, again, I had a student wanting to do a project. So the project was to take the game graphics, and the programming, and make the game web-playable. And lo, it was done; the game could be played over the web.  Most wonderfully, it still can be!  (Yay, standards!)

Naturally, I wrote it up (with the student; a principle I always stuck to: even if I usually ended up writing it all, they got credit for their work and ideas).  And, as far as I know, it was the very first web-delivered serious game. At the least, without Flash.

The underlying principles in the game also became part of a couple of chapters, and ultimately the alignment between effective education and engaging experiences formed the core of my book on serious game design, Engaging Learning.  

One final reflection is that working on this, on a project that really helped real kids, was still one of the most rewarding projects I’ve ever worked on.  It’s nice to help clients deliver outcomes, but saving lives that were at risk?  That’s just too good.  Anyone up for some more ‘hard fun’?

When I was a young academic in Australia, a colleague asked me if I would talk to some folks about a game. He knew that I had designed games before returning to grad school, and had subsequently done one on my thesis research. This group, the Australian Children’s Welfare Agency, had an ‘After Care’ project to assist kids  who needed to live independently. They’d spent their budget on a video, comic book, and a poster, but now realized that the kids would play games at the Care centers. I had a talented student who wanted to do a meaningful honours project, and so I agreed.

Following best principles, we talked not only to the project leaders, and the counselors, but more. We weren’t allowed to talk to youth ‘in care’ (for obvious reasons), but they did get us access to some recent graduates. They gave us great insights, and later they playtested the prototype for fine-tuning.

One of the lessons from this was important. The counselors told us that what these kids needed were to learn to shop and cook. While I could have made a game for that, when we talked to the kids we learned that there was more. (My claim: you can’t give me a learning objective I can’t make a game for, though I reserve the right to raise the objective in a taxonomic sense.)  They said what was important were the chains. That is, you could get money while you looked for a job, but… They wouldn’t give you money, however, they’d deposit in a bank account. BUT, to get that, you needed ID.  To get that, however, you needed references. And so on. So that was the critical focus.

I taught my interface design students HyperCard, to have a simple language to prototype in. This meant that we had an environment that we knew games could be built in.  My student did most of the programming, under my direction.  When that wasn’t quite sufficient to finish the development, I used some grant money to hire her for the summer to finish it.

The resulting play was good, but the design was lacking (neither my student nor I were graphic designers). I ended up going with the project team leaders to get philanthropic funding to add graphics. (Which introduced bugs I had to fix.)  They also had it ported to the PC, which ended up being a mistake.Their hired gun used a platform with an entirely different underlying model and wasn’t able to translate it appropriately. Ouch.

The resulting game, had some specific design features:

• It was exploratory, in that the player had to wander around and try to survive.
• It was built upon a simple simulation engine, which supported replay.
• There were variables, like health and hunger and sleep that would get worse over time, driving action.
• The audience was low literacy, so we used graphics to convey variable states, interface elements, and location.
• Success was difficult. Jobs were difficult to obtain, and better jobs were even harder. And, of course, you had to discover the chains.
• There was coaching: if you were struggling, the game would offer you the opportunity for a hint. If you continued to struggle, eventually you’d get the hint anyway.
• There was also a help system, where the basics were laid out.
• There were random events, like getting (or losing) money, or having drugs or sex. (We were trying to save lives, and didn’t worry about upsetting the wowsers.)

There was more, but this characterized some of the important elements.  In reflecting upon the experience, I realized the alignment between effective education and engaging experiences that means you can, and should, make learning hard fun.  I wrote a journal article (with my student) that captured what I will suggest are critical realizations (still!).

They held an event to launch the entire project, including the game (and they gave me a really nice sweater, and Dana something too ;).  Tomorrow, I’ll pass on some of the subsequent outcomes.

At the recent Realities 360 conference, I saw some confusion about the difference between a simulation and a game. And while I made some important distinctions in my book on the topic, I realize that it’s possible that it’s time to revisit them. So here I’m talking about some conceptual discriminations that I think are important.

Simulations

As I’ve mentioned, simulations are models of the world. They capture certain relationships we believe to be true about the world. (For that matter, they can represent worlds that aren’t real, certainly the case in games.). They don’t (can’t) capture all the world, but a segment we feel it is important to model. We tend to validate these models by testing them to see if they behave like our real world.  You can also think about simulations as being in a ‘state’ (set of values in variables), and move to others by rules.  Frequently, we include some variability in these models, just as is reflected in the real world. Similarly, these simulations can model considerable complexity.

Such simulations are built out of sets of variables that represent the state of the world, and rules that represent the relationships present. There are several ways things change. Some variables can be changed by rules that act on the basis of time (while countdown timer = on, countdown = countdown -1). Variables can also interact (if countdown=0: if 1 g adamantium and 1 g dilithium, Temperature = Temperature +1000, adamantium = adamantium – 1g, dilithium = dilithium – 1g).  Other changes are based upon learner actions (if learner flips the switch, countdown timer = on).

Note that you may already have a simulation. In business, there may already exist a model of particular processes, particularly if they’re proprietary systems.

From a learning point of view, simulations allow motivated and self-effective learners to explore the relationships they need to understand. However, we can’t always assume motivated and self-effective learners. So we need some additional work to turn a simulation into a learning experience.

Scenarios

One effective way to leverage simulations is to choose an initial state (or ‘space of states’, a start point with some variation), and a state (or set) that constitutes ‘win’. We also typically have states that also represent ‘fail’.  We choose those states so that the learner can’t get to ‘win’ without understanding the necessary relationships.   The learner can try and fail until they discover the necessary relationships.  These start and goal states serve as scaffolding for the learning process.  I call these simulations with start and stop states ‘scenarios’.

This is somewhat complicated by the existence of ‘branching scenarios’. There are initial and goal states and learner actions, but they are not represented by variable and rules. The relationships in branching scenarios are implicit in the links instead of explicit in the variables and rules. And they’re easier to build!  Still, they don’t have the variability that typically is possible in a simulation. There’s an inflection point (qualitative, not quantitative) where the complexity of controlling the branches renders it more sensible to model the world as a simulation rather than track all the branches.

Games

The problem here is that too often people will build a simulation and call it a game. I once reviewed a journal submission about a ‘game’ where the authors admitted that players thought it was boring. Sorry, then it’s not a game!  The difference between a simulation and a game is a subjective experience of engagement on the part of the player.

So how do you get from a simulation to a game?  It’s about tuning.  It’s about adjusting the frequency of events, and their consequences, such that the challenge moves to fall into the zone between boring and frustrating. Now, for learning, you can’t change the fundamental relationships you’re modeling, but you can adjust items like how quickly events occur, and the importance of being correct. And it takes testing and refinement. Will Wright, a game designers’ game designer, once proposed that tuning is 9/10’s of the work!  Now that’s for a commercial game, but it gives you and idea.

You can also use gamification, scores to add competition, but, please, only after you first expend the effort to make the game intrinsically interesting. Tap into why they should care about the experience, and bake that it.

Is it worth it to actually expend effort to make the experience engaging?  I believe that the answer is yes. Perhaps not to the level of a game people will pay $60 to play, but some effort to manifest the innate meaningfulness is worth it. Games minimize the time to obtain competency because they optimize the challenge.  You will have sticks as well as carrots, so you don’t need to put in $M budgets, but do tune until your learners have an engaging and effective experience.

So, does this help? What questions do you still have?