In one of my previous posts, I created a playful DeminGO simulator. If you haven’t tried it yet, I would suggest playing a little with the solution before you move on. This post is about the secrets behind the scenes.

This is a great example of showing how Game Thinking lead to the design of this challenge.

Engage the WORL&D!

 

First of all, I used to struggle with definitions. In this case, whether DeminGO is a “simulator” or a “game” or “gamified simulator” or whatever. However, I’ve found that if you start out with a definition, you lock yourself in a box: “I’m going to build a game. No matter what! Damn it!”

The framework above helped me to approach workplace problems without defining the type of solution. What matters is the goal:

I want to build something engaging that demonstrates/simulates the scooping beads experiment within 2 days and with a budget of max 10 dollars.

Once the goal is defined, I looked for the core loop: what is the user going to do? What is the core activity (NOT CONTENT) the user is doing over and over? It’s scooping beads. It happens 5 times as you need 5 rounds. The core loop must be simple, yet engaging, so users would want to do it again.

Now that I kind of have an idea of the core loop, I focus on the two critical things in application of game thinking: USER EXPERIENCE and ACTIONS (with feedback loop).

See how we abandoned the definition for now? It’s because, based on the framework, I’m NOT doing either gamification or game-based learning. I’m just figuring out the ANGLE. Where it lands, it lands. And honestly, at this point of the process, I don’t know what the solutions will be. It might be a game, might be gamification, might be a true simulation, or might be none of that.

Back to the core loop. What I need for scooping beans is beans. And a “scooper”. I decided to use a game engine (Construct 2) for the core loop. Why? Not because I’m building a game, but because the engine comes with built-in features (game mechanics), and I have only two days to build this demo. I don’t have much free time to fiddle. And you’ll see that time constraint throughout the process.

Now that I decided to use Construct 2, I knew that I can make it engaging by adding physics to the core loop. Users will see the beads really bouncing. This gives a little more credibility (simulation), but also more engaging than just randomly putting out numbers of beads five times.

I needed a paddle (“scooper”) and beads. I built the paddle in 10 minutes in Powerpoint.

 Created a shape. Applied 3D effect. Added 3-4 of this on top of each other to show “depth,” Finally, I added the “holes.” I saved it as an image. Done.

Beads were a different story. Thing is, this whole experiment is about those damn beads. My graphic skills is of a 5 year old, so I just got beads from Adobe. Cost $2.99. I made two: one white (good work), one orange/red (faulty work).

Next, I loaded those into my initial prototype in the game engine. They are the two tiny beads hanging out on top of the screen. So far so good. I also made a “button” of out the beads and put it at the bottom of the screen.

  I love Construct 2. It has amazing features that make my life easy for prototyping and playtesting especially. Once you add the beads and the paddle to the game engine, you simply assign behaviors to them with a drag and drop. Like physics. Done. Now the beads are falling and bouncing like in real life. All two of them. I tested that. Looked good.

Now, the paddle. It was a little more complicated. If I set the whole paddle as one “solid object,” all beads would bounce off of it like in real life. What I needed is for the beads to land in a hole. The trick I used was to create a new image, called hole (which you do not see because I set them invisible) and added them on top of the paddle’s black spots. Now I had holes “to stick” the beads to. Added some logic to capture the beads when they touche the hole. Done.

I added some logic to create like a hundred beads based on my two. Yes, it takes two lines to do that in the game engine. Playtested it. Beads are now coming down and sticking to holes. So far, so good. But. I also have to count how many red and how many white I caught. I added the logic. Construct 2 does not have a “coding” language, you just build logic to control things. It’s pretty quick. Especially, if you know what you’re doing.

Finally, I added a feedback mechanism. Encouraging text from your inspector if you’re doing good, and warning words if not. That was good for one round. But I’ll need five of this for the experiment.

I decided to add a HOT BUTTON at the bottom of the screen. This will trigger the scooping. Now, this is crucial: you want to make sure users WANT to click that button. This is the trigger for the scooping. Users must love to play with the button, otherwise, nothing’s going to happen.

I added three game mechanics to achieve that:

1. Sound! Sound makes a huge difference! I added “Go Team, Go” when user clicks the button. Also, the beads have beads bumping sounds.
2. Motion! Motion captures the mind. The button has an up and down motion but also the paddle. I added an actual scooping motion to the paddle itself.
3. As simple as is, I added a x/5 type of progress counter with an overall percentage for performance. Our brain is wired to close loops. Unfinished progress bothers us.

So, with that, the scooping prototype was ready for action.

So far, we’ve been focusing on the ACTIONS a lot. But what about the USER EXPERIENCE? When people are motivated, they get engaged. So to engage people we need to motivate them. How can we motivate people to play with the simulation?

The bad news is that people are not motivated by what you think should be motivated by. That’s not how it works.

If you don’t know Daniel Pink, Jane McGonigle, Andrzej Marczewski, Yu-kai Chou, Amy Jo Kim, Nicole Lazzaro (just to name a few), you should.

While their theoretical frameworks of motivation differ, they all agree that a system must be well-balanced in terms of motivators in order to sustain motivation and engagement. Throwing points, badges and leaderboards on top this simulation would appeal to some, but not all users.

So, let’s add some other game mechanics to support a more balanced approach. This is where Articulate Storyline comes in.

On the first screen, we establish the story. A human face (even it’s mine) with a short scenario creates the story element, sets the tone. What else do you see on the front?

The core loop is represented: here’s the paddle and the two beads. You already have an idea what to do. Challenge accepted?

Call to action: Let me try Demingo! The button is clearly your choice. You may or may not press that button but aren’t you curious what those faces are on the DeminGO hand? Curiosity can kill felines. Also piques interest.

Lastly, the statement at the bottom if obviously a reference to the wildly popular Pokemon Go game.

Let’s assume that you are now curious enough to take the first step. Maybe you like the challenge to prove that you are better than the guy that was just fired. Let’s bring it on!

Now you’re facing this screen: “You’re hired! Select your Inspector!” At this point, you are invested. If you’re hired, you might as well check it out. It also gives a choice! Choice, as a game mechanic, may appeal to those (free spirits) who wants to explore rather than pushed in one direction.

Choice also comes with revelation! These people are Inspectors. They’re going to give you feedback, judge your work. In real life, you’re not often given the chance to choose. The choice also comes with variety. Playability, is another word for that. The fact that each Inspector comes with different number of beads, feedback tone, and whether you can drag the paddle or not, encourages you to come back and try it again with a different one.

As you click Go, you’re on the way to the core loop. This slide is a transition side. While you’re reading the final instructions, in the background the game is loading. Once the game is loaded, a handshake happens between the game and Storyline. From that moment on, you’ll interact with the game.

 

For the user, it does not matter that they are now interacting with a game engine. The sounds helps solidify a realistic bead simulation. The interface is simple. You see the number of white and red beads, the rounds and your performance.

Once all beads are settled, you are prompted to tap the button to play DeminGo.

Here comes the hand again, motioning towards the button you’re going to use.

 

When you press the button, as we discussed before, the sound effect triggers and also the paddle motion. The beads are thrown up in the air.

This is done by the game engine. You can simply apply some pressure on the beads and here they go bouncing. An algorithm is triggered when a ball hits one of the holes ad it “makes it stick,” so other balls don’t push them out.

Once all beads are captured, we count the read and white ones and calculate the performance. Now, if you remember, we created only one white and one red bead in the game engine. How come I see so many? Because the beauty of the game engine is that you can replicate/duplicate anything in real-time. When the game loads, it actually creates as many beads as you want.

After counting the beads, in each round, you get your performance and feedback from the Inspector. Each inspector has a different “attitude.”

At this point, you may wonder (if not, you really should), how come that I see the Inspector here in the game? How come that I select the Inspector in Storyline and yet, they show up here? Also, the number of beads also differ based on the selection in Storyline.

The answer is JavaScript. When the game is loaded, it calls a JavaScript function that Storyline has. Storyline than passes that information to the game engine: who’s the Inspector, how many beads you need to create, etc.

Then the game engine takes that information and creates the specific layout for this round of DeminGO. Okay, so that’s solved. But what happens at the end of the 5 rounds?

We’re back in Storyline. How does Storyline know that the game is over? Again, it’s the magic of JavaScript. After 5 rounds, the game engines calls a function in Storyline and passes the final performance index (74 in this case). The JavaScript function then changes a Storyline variable to “complete.” In Storyline, there’s a trigger waiting for that variable change. When JavaScript changes the variable, Storyline executes the trigger and we go to the final pages:

This is what it looks like inside Storyline:

You see the trigger waiting? That’s responsible to jump to the last slide. Now, you don’t see the game here but the slide we are currently on also has a WebObject (behind the blue square and text). That is how the HTML 5 output of the game embedded in Storyline.

And one final thing! Always give the users an easy way to repeat! Add that Restart or Try Again button, so they can replay the core loop.

This project was conceived, designed and created in about 4 hours over a weekend. Obviously, you could improve it in various ways but often times in L&D time is one of the biggest constraints. Often we don’t have time for a perfect solution. We need something to Engage the WORL&D and achieve the business goals.

There’s also an Easter egg/Mystery included. A different character shows up if you happen to have 100% white in a round.

If you’re interested in the Game Thinking framework and its application to practical L&D projects, come to the 1.5 day workshop in September. Details are here!