It was decided early on in the project planning stages that we would implement a branching story in the app. This benefits many things:

• Increases replay-ability – a user can intentionally choose a different path during next play to see different outcomes.
• Improves retention – having to think before making a choice means you are more likely to remember the consequences of an action.
• Improves interaction in the app – for example a scene where the user has to decide whether to dial number for help or not is a simple but important interaction.
• Improves discussion and comparison with colleagues – compare story routes and their outcomes.
• By gathering usage data, this helps us to understand popular routes and ascertain what users may or may not be learning as a result. And by gathering usage data from all branching points and decisions made, we can look at any correlations.

Branching example

The way branching works in this app is quite simple in that each decision (or lack or decision if a timer is involved) sets a particular condition. Then its depending on these conditions in certain scenes that decide what is presented graphically and audibly to the user.

So in the example above, Mohamed becomes infected as the user on the left failed to select him before the timer ended. As you see towards the end of the video in the next scene, Mohamed is therefore shown sat in the room with Osman who is suspected of having Ebola.

As a result of this condition set within the app, the user will see variations later in the story. With Mohamed appearing and different audio playing.

 

Conditions

I haven’t worked out the number of variations for the story, but with 11 interactive scenes, 8 of them affecting conditions and 10 different conditions being checked against, there’s quite a few variations!

I’ve shown some screen captures of branching example graphically. Below are some examples using audio only.

 

Examples

Authorities HAVE been contacted early

Authorities were NOT contacted early

With the two above examples,  for this particular scene the audio differs depending on what the user selected in a few previous scenes. For this condition in the app called “Authorities have been contacted early” the user has a few scenes they can select an option which sets this to true. However if they repeatedly take the other route, the second example above will be played out and the result is more people in the story become more sick with Ebola.

 

More complex example 1

• Yaema Has Been Infected : true
• Osman Will Die : true
• Authorities Have Been Contacted Early : false
• Foday Warned : true
• Villagers Saved : true
• Other Community Saved : false
• Mohamed Has Been Infected : true
• Niece And Nephew Infected : false

The above audio example loads in during a later scene after the user has been given the option to set the above conditions to true or false.

 

More complex example 2

• Yaema Has Been Infected : false
• Osman Will Die : false
• Authorities Have Been Contacted Early : true
• Foday Warned : false
• Villagers Saved : false
• Other Community Saved : true
• Mohamed Has Been Infected : false
• Niece And Nephew Infected : true

The above example (2) gets played in the same scene as for example 1. But you’ll notice its quite different due to the conditions set.

The combination of varying graphics and audio for many scenes depending on users choices was quite a complex thing to program. It was also a challenge just to tie the audio together to make sense. For example checks had to be made in the app for if two or more names are played, to add an “or” or an “and” or neither if just one is played. Also you’ll notice the voiceover is in Krio. So tying some words together programatically was made more difficult.

But now this is setup. Its super simple to update and add these conditions and add audio to play against any matched conditions.