Sunday afternoon and it’s raining. After two hours of R (Data Science course), I needed a break. Hence the Articulate eLearning Heroes challenge below.

I wanted to create an old-school (choose your) adventure game where the user makes a series of decisions. These are simple YES or NO decisions. However, the story has many branches and paths to get through. Click the image above to experience it before you move on to the how it’s made.

How it’s made?

There two parts to this story: the Storyline framework and the scenario logic. Let’s start with the Storyline. Basically, it’s four slides.

An Intro slide sets up the story of the Flemmings. The Game slide is where you spent all your time. And the Success and Failure are the outcome slides.

The Game slide is where all the interaction happens. It’s using a couple of tricks to make it engaging.

The blue mountains in the background is actually a slider. The thumb of the slider is the image of the mountain. As your Flemmings get closer and closer to their destination the slider reflects that. Basically, the variable of distance left controls the slider. The smaller the variable the more the slider moves to the right. The giant hotspot above the slider makes sure that the user can’t drag the slider anywhere.

The Scenario is a variable to show the current scenario where the user should make a decision. It is a variable to make sure we can dynamically show the correct scenario as the user can go through the story in various ways.

You may noticed that with every decision the number of Flemmings can change, their energy can go up or down, and the distance (measured in pixies) can change. These are variables of course. But the change is not happening in a flash to just update the variable. You can see the update digit by digit. This is done by JavaScript that keeps updating the number every half a second or so until we reach the new amount.

Our Flemming friend is jumping up and down, waiting for to be saved in the middle. This is an old trick but you may not have seen it before: how to create a continuous loop?

It’s using two motion paths. One that goes Up and one that goes Down. You start the Up when the slide starts. That takes care of the first move. The Down move is triggered when the Up animation ends. That brings it back down again. And lastly, Up is triggered when Down is finished. And these three three triggers are going in loop forever. (You can use that for adding an arrow to your screen pointing out something, for example).

Additionally, our friend also moves his eyes (actually only on of them). This is done by having two states. The states change depending on Up or Down animation has finished.

Game logic

Playing with the game you may think it’s a simple story with a simple logic. Then consider this:

… and it didn’t even fit in in one screenshot.

I used Twine to create the branching story. Zooming in it’s easier to see how the structure is set up:

Twine is an interactive tool, one of the best free tools out there to build branching scenarios. This story includes various tricks in “branch design.” True branching (every decision takes you to a new branch) gets so complicated (imagine 10 decision points with 2 choices = 2^10 = 2*2*2*2*2*2*2*2*2*2).

Instead you can build branching scenarios where the user ends up at the same point through different routes. There’s a whole bunch of ways to design branching for games. Check this out!

In my design a scenario is followed by a Yes or No impact. Each of these may have different impacts on your lives, energy, and distance left. I used Twine to run through the story itself but the implementation was done in JavaScript (we’ll get there later).

To increase replayability (ability to play it over and over again without repeating the same pattern), I added one randomized element. The bricks are randomly placed somewhere in the story.

Game logic implementation

After the story was created in Twine I put it in practice in JavaScript. JavaScript is the engine behind keeping track of the scenarios, where you’re going, and the impact you make with your choices. It also throws the random bricks into the story at the beginning.

Each event has an id (10 in this case), a description that shows up in Storyline in the Scenario variable, and the two branch ids where the user is going depending on choosing Yes or No.

The other two elements are the impacts: 10y for Yes and 10n for Now. You see the feedback and the change for each item: lives, energy, and distance left.

With building out the content this way, the actual logic that handles the game does not really need to change. It does not care what scenario you’re doing. The structure is the same for every round. If we need to change the story, we can just change the scenarios and where they branch without changing the code that handles it.

Lessons learned

This was a quick design and implementation with some shortcuts. First, I tried to design the branching in Storyline with using lots of variables that stores scenario and impact. I got lost quickly. You need Twine or something similar tool to be able to build and test your branching.

The story itself currently resides with JavaScript in an array. Ideally, it would be in a separate file in XML or JSON. That way you completely separate the code logic and the content. It is better for translation or choosing stories on the fly, for example.

Calibration of impact takes a long time. Lots of playtesting. You want to design a good balance of challenge and dead ends. It’s the fine line between between being challenged and frustrated.

Finally, I had to tweaked the bricks a couple of times to make sure there’s not only one way to make it to the end. Introducing randomness in a game makes it more engaging and replayable. At the same time, too much randomness makes the game unpredictable.