Blog

The Concept

I’m a big fan of using colors, but this week’s eLearning Challenge was all about using a black and white color palette in course design. I took this as an opportunity to play around with something I haven’t really focused too much, which are games and gamification in eLearning. My previous experience was one project, Hi Ho Cherry-O, also built in Storyline. I just started listening to the eLearning Guys podcast and in episode 3 Nejc Žorga Dulmin talks about the bouncy ball concept he made while testing out Storyline 360.

Nejc was kind enough to record a Peek video explaining the thought process behind his build. I decided to use this as my concept to see if I could figure out the nitty gritty details based on his description and if so, if I could add to the design and make it even more interactive. Note: this can only be built in Storyline 360 or Storyline 3 because it relies heavily on the “object intersects” trigger condition.

The Method

My process for this interaction was very iterative. After it was all complete, I ended up with 50 triggers on the gameplay slide and three variables:

1. Movement- a text variable that stores the direction of the ball (UR, UL, DR, DL)
2. Lives- a numerical variable that stores the health score of the game (3 through 0)
3. QuestionsPosed- a numerical variable that stores the number of questions given to the learner

I first started out by building just the gameplay components: four walls, a line for a paddle, and the ball. For the ball, I used Nejc’s description of four directions (upper right, upper left, down right, down left) as motion paths to build. Once the paths were built, they each required triggers to restart their motion when the animation completes.

Next, I built a ton of triggers to allow the ball to change direction when it hit the left, right, or top wall or the paddle. For instance, if a ball was traveling in the upper right direction and it hits the right wall, the direction should change to the upper left. The triggers included both the object the ball intersected (hit) as well as the variable to track the direction it was going before it made contact. The triggers change the Movement variable, which caused other triggers that looked for that variable’s changes to move the ball on a different motion path.

I ended up deleting the bottom wall (which was originally off screen) and just used the “object leaves screen” trigger condition to determine if the learner failed to catch the ball with the paddle. For the paddle itself, I also added two triggers that redirect the paddle back on the screen if the learner takes it too far to the left or too far to the right. This diagram shows these gameplay triggers and where they went:

One problem I ran into with the basic gameplay was the length of the motion paths. The longer the motion paths were from the center of the ball, the more the ball “jolted” when it hit a wall or the paddle. Shortening the paths was the obvious solution, but I also had to balance that against the time of the motion path animation. The shortest duration of an animation is .1 of a second, but when you’re only moving a few pixels, that can make for a slow-moving ball. I found it was a balancing act between having smooth visuals and having exciting and challenging gameplay.

Another minor problem I discovered during testing was the need for the learner to click on the screen in order for the keyboard controls to work on the paddle. That was a simple fix of adding a button to start the game play. I also had the timeline pause when the timeline started, then had the button resume the timeline when clicked in order to truly have 60 seconds of gameplay, rather than 60 seconds sitting on that slide.

After I had finished the basic gameplay and tested it out, I wanted to add additional complexity to the game. I started with adding a health/battery meter to allow the learner to try again rather than going straight to the failure slide. I played around with a couple of options and finally settled on a Lives variable to track the health score. This would allow me to send the learner back to the gameplay slide (the same one they’re on) which is set to reset itself upon revisiting. The Lives variable is used in triggers to change the state of the battery to half power or empty, which would make the learner unaware that they’re back on the same slide.

In addition to the health meter, I also added triggers to adjust the difficulty of the game as time progresses. I couldn’t figure out a way to speed up the animation using a trigger (nor do I think I could due to the minimum time restriction discussed above), which would have been my preferred option. Instead, I decided to adjust the size of the paddle to get smaller at two points during the 60 seconds. This was done with simple state changes and associated “timeline reaches” triggers.

Finally, I decided that I wanted to add an education component to the game through quiz questions. I decided to send the learner to a quiz question if they missed the ball during the 60 seconds. If they answered the question correctly, they wouldn’t lose any battery power and they could try again. If they didn’t, they’d lose one step of battery power, which could either send them back to the game or make them lose the game depending on the power level prior to the wrong answer. In addition, I didn’t want the game to go on forever, so I set a limit of 10 question opportunities. This flowchart represents the logic involved with the triggers to make that happen:

Although I would love to say I came up with that flowchart ahead of time, it was after the fact. If you’re designing a game, I’d highly recommend sitting down and making something like this because it will save you a lot of time and tweaking.

My original idea with the question was to use one slide and a question bank. However, I discovered that you can’t revisit a “draw from question bank” slide and have it pull out a new question. Therefore, I built a variable to keep track of how many questions the learner has seen already. I then incorporated the QuestionsPosed variable into a number of triggers to control navigation to the question slides. For instance, if the learner has seen questions #1 & #2, the next time he or she fails in the game, triggers would send the learner to question #3. In the project, I had one scene for the gameplay and one for the questions just to keep them organized:

Finally, the last touch I added on was changing the START button to TRY AGAIN if someone is attempting the game again. Since the slide goes back to its original state, I took advantage of the QuestionsPosed variable and used triggers and told the slide to hide the START button but display the TRY AGAIN button if the number of questions posed was greater than 0.

Uffda, that’s a lot going on. If you’ve made it this far, congrats, you are one dedicated developer!

The Result

To see this in action, [iframe_loader type=’open_link_in_new_window’ href=’/wp-content/uploads/articulate_uploads/Arkanoid-Game/story.html’ link_text=’launch the game!’]

If you want to pick apart the Storyline 360 file (which I highly encourage), download it here.

One thing I wanted to do but couldn’t figure out (without using 60 states and 60 triggers) was a custom timer in the top portion of the game with the battery. That would have allowed me to get rid of the default player seekbar, which is a bit confusing with the pause and reset controls. It might be possible with JavaScript, but I’d have to do more research to be sure. This was a really intense but rewarding build and I definitely feel like a trigger master because of it!