Branching Scenarios with Twine

Screenshot of a branched story created in twine.

Many years ago I heard about interactive stories, or gamebooks, that allowed readers to make decisions that would alter the course of the plot.

This idea was revised on reading Cathy Moore’s excellent blog: which in turn recommended a few examples such as this L&D specfic one:

Cathy also mentions the tool used to create them: – which is open source and cross platform.

I was suitably impressed and wanted to see what was feasible for creation of scenario or simulations online.

I set out to build myself a set of building blocks that could then be used with whatever storyline was needed. If you are familiar with flow charts this is a very similar process. (NBTwine uses the term “passage” to refer to what you could consider a page or node.)

Narrative with proceed to the next passage. A way of breaking up information so it might be as simple as:

You are in this situation. Click next to proceed

Narrative with choice. This time there is a decision to be made:

Something is happening and you can:
Do this
Do that
Do other

Where this, that and other are separate passages, which can each provide another choice to be made and options to take.

Those two components have the potential to be combined to allow our reader to control their way through the permutations of plot that we write for them.

At first glance this might look like any basic multiple choice question. The key difference is that as an author, I do not need to be constrained by a binary right or wrong answer. The option selected could determine the next situation.

But I wanted to see what other features I could incorporate. I was looking for a constrained choice. For example, you have a fixed budget and each option has an associated choice:

At the start of the year you have a budget of £10,000. 
Do you invest in:
  • Health and Safety training: £4,000
  • First Aid Training: £7,000
  • Safety Equipment: £5,000

I also wanted to be able to carry a variable across an entire story. So in the example above, the budget may be £10,000 but after you have made your first investment you will have some change remaining. You may also encounter a later situation where you either receive reward or face a fine.

I have assembled this into a functioning demo:

At this stage I have focused on the technical or functional aspects.

From a learning point of view, my next consideration would be the story. The plot is simply a way of illustrating the concept it, doesn’t have any additional goal.

Finally, the appearance of this story is the default white or blue text on black with no images. Once the technical and story aspects of the project are finalised this can be brought to life.

Please let me know what you think.

Why are we scared of sorry?

Two hands offering single flower

What makes it so hard for us to apologise?

Is it pride? Fear? Or as I have often heard, because it is an admission of guilt?

Perhaps a combination of all three.

The last reason one seems quite pervasive in customer service roles, where a I suspect a reluctance to apologise stems from a desire to avoid compensation at all costs*.

True, there is a risk of devaluing the word sorry if it is overused. It can lead to a feeling of helplessness on one side and of annoyance on the other.

Last year we were travelling abroad and our train was delayed. We were kept waiting for several hours. That was unacceptable so we complained.

The response, via email, arrived a couple of days later. After a formal salutation, the first few words were:

“Thank you for your email.

I am very sorry…”

The remainder of the first paragraph summarised the cause of our problem (the delay) and expressed an understanding of the impact that it had on our trip.

The next two paragraphs explained that we would have our ticket refunded in full and a voucher that we can use on a subsequent booking.

Only then was there an explanation of the cause of the delay. It was detailed enough to provide the multiple factors and the steps taken to rectify the problem.

The structure:

  • Gratitude
  • Apology
  • Empathy
  • Solution
  • Explanation

The result? We remain happy customers and will continue to use the service.

The company?

*I remain open to anyone who can provide documented evidence of situations that have been made worse by a sincere and genuine apology.

Photo by Lina Trochez on Unsplash

Is your project SMART or STUPID?

Luna rover on the moon

Any project or plan needs a bit of preparation, a bit of structure to ensure that everyone and everything is aligned.

SMART goals are often discussed, usually positively, occasionally less so. It usually comes down to their interpretation. For starters, the nemonic isn’t fixed – many interpretations feature duplication and have their own built in limitations.

Specific: What are you looking to achieve? If this isn’t clearly defined then the hard work could be all wasted. Without a specific goal it is too easy to be distracted along the way. “Conquer space” is vague, “Put a man on the moon” is specific. Put a man on the moon and bring them back alive might be better still.

Measurable: How will you be able to gauge completion and success? Will it be enough to place a footprint on lunar surface or will it need a photograph of someone holding a flag against a black and starry background. In most businesses, this is more likely to be a numerical target: output to 25giga widgets

Achievable: The first of the contentious points. What defines achievable? Why is it important? If it is too hard will people be demoralised from the start? The risk here is that you use past performance as a guide to what is achievable – “We’ve done 22giga widgets so 25 is achievable.”

The problem is that is very limiting. Putting a man on the moon wasn’t something that had been done before – not even close. It wasn’t the previous goal with a 10% increment. provides an example of when a stretch goal is needed to bring in new thinking.

What both of those projects, rockets and trains, demonstrate is a willingness to take bold new steps and that the collective investment was sufficient in terms of people and resources.

Relevant: Where does this goal sit in the scope of your overall mission? Putting a man on the moon was a huge scientific and explorational achievement. It was also highly political at the time, potentially the only reason it got the funding necessary and why we haven’t put a foot on the moon since 1972.

While many lists put realistic here that seems to close to achievable to be worthwhile.

Timebound: When would this need to happen? “I’ll paint the shed” might be specific but if it is followed with “when I get around to it” it isn’t likely to happen in this lifetime. Putting times & dates in place doesn’t automatically mean that is when the project will be completed – breaking it up in to chucks with an option to review can increase the success rate as it enables changes mid project to be accounted for. Third party suppliers or even the weather can add delays.

In 1961 “end of the decade” was good enough for JFK. End of the quarter might be more appropriate for your next project.

So how do you avoid being STUPID?

Spontaneous: Ah, that knee jerk reaction to something that doesn’t get thought out properly. Don’t let people convince you that this is a good thing by calling it Agile. Even Agile methods have a clear structure.

Traumatic: If you don’t ensure your team are happy with the project you are likely to find you are doing this alone.

Unplanned: Even if the next step is to plan this properly it is a plan. Fail to plan, plan to fail.

Peacemeal: Don’t rush into something without considering what will happen next. There may be discovery along the way, especially so with new goals but it should still form part of a bigger plan or mission.

Insular: Otherwise known as working in silos. Where one team makes great changes without considering the effect on others. Or where huge amounts of work are duplicated, probably with a few tiny details that make merging the projects impossible.

Doomed: The result of STUPID goals.

Be careful what you wish for

Hand drawn five bar gates and stopwatch

If you don’t measure it you can’t improve it.

That was what a previous senior manager of mine used to say. I was working in a customer service centre and part of my role was to collate the measurements that were used to evaluate the team’s performance.

The team was split in two: One half took incoming phone calls, the other half dealt with written  communication. This was in the mid 1990’s and written meant paper. Email was just starting to become adopted internally and the workflow used a fledgling digital system. Customer’s letters would be scanned automatically and those scans added to a queue to be dealt with in turn.

That queue also had requests from the phone team that were deemed complex and needed escalating as the paperwork team was generally more senior. 

The phone team were measured for total number of calls taken and the average duration of call.

So the aim was to take as many calls as possible and to keep them short.

Calls came in via an automated switchboard and would be non stop unless you clicked DND (Do Not Disturb). This was a feature of the phones and it prevented the next call coming through. It was measured but did not have the same weighing as call number or duration.

So to meet individual targets, many of the call team would make notes (pen and paper) during the call, press DND, type the request and add it to the queue for the paperwork team.

So rather than dealing with the majority of caller requests in the moment, a significant volume were added to the queue for the other half of the team. The phone team looked good because call volumes were high and duration was short. Yet two people were involved for a task that could have been completed within the duration of a call.

All because the measurements encouraged gaming the system.

So when you want to know the performance of your team be careful what you ask for.

Focusing on certain Key Performance Indicators rather than gaining a broader understanding can inadvertently lead to encouraging behaviours that reduce your overall effectiveness.

For further reading about how using rewards may actually lower output see

Problems are great

Lightbulb and ideas cloud

Don’t bring me problems, bring me solutions.

I’m not a fan of that much used phrase.

From a leadership perspective, the start is a blocker – Don’t come to me.

Then it goes on to explain that if you are in need of help I am not interested. I only want to know about things once you have worked out how to fix them.

Why? So that I can make the final decision only when you’ve done all the hard work?

The spirit of the phrase is meant to empower, to encourage reflection so that the request becomes one where the risk has identified and a plan been created. That’s great when it is within normal boundaries and presents no additional side effects. Not so much a problem as simply business as usual.

What makes problems so good?

They tell us that we are looking forward. Actively seeking a way of doing things better.

Problems also indicate that people are talking.

And here’s the really delicate bit. By discussing problems earlier you get the combined input of a wider range of people. Note, that doesn’t mean relinquishing responsibility nor does it mean showing weakness.

Instead, it prevents two significant risks:

Of making decisions without key pieces of information. We frequently have to make decisions without all the information otherwise there would be no case to deal with ambiguity. If you wait for perfect conditions, you will never get anything done. However we may not realise the significance of what we are proposing without gaining outside view. Anyone who has worked in software development will be familiar with how easily a seemingly small change in one area of a project can have huge repercussions in another.

It also gives an opportunity to break the pattern of “we’ve always done it this way.” If you ask the same people you will tend to get the same advice so consider going outside your usual circle of contacts. That might mean a coach or consultant who specialises in this topic.

Finally, sharing problems is good for you. We sometimes get things out of proportion, get blinded by our own desire to be unshakeable that when we do get stuck we don’t know how to deal with it. Our vision drops, our creativity suffers and that small glitch becomes all consuming.

So keep talking to me.

Problem solving with digital watches

…most of them were miserable, even the ones with digital watches.
The Hitchhikers Guide to the Galaxy by Douglas Adams.

At a few times each year, a digital watch is handed to me with a request for it to be set to the current time. British Summer Time, GMT or some far flung timezone the trigger event. The owner of the watch does not know how to do it and despite several attempts, can not change the time.

But I don’t know how to complete this task.

I don’t do it frequently enough for it to be worthy of a place in my memory.

From an L&D perspective this should be a suitable case for a resource. A short set of instructions for me to follow to set the new time.

Yet it is typically completed in less time than it would take to search for and read such a guide.

So how would you develop someone to be able to do a task or solve a problem without having seen it before?

What I think I do is look for patterns:

  • One of the buttons will make one of the digits flash
  • One of the buttons will make a different digit flash
  • One of the buttons will change the digit
  • One of the buttons will stop everything flashing

Is four steps enough? Probably not. There are a few alternatives or exceptions that should be encountered:

  • It might be necessary to hold a button longer to achieve the desired result
  • Holding a button longer may make undesirable things happen
  • Not pressing any button may make everything stop flashing
  • Rather than a single press it may be necessary to press two buttons at once

Is that sufficient?

Again, probably not. Some personal attributes are necessary:

  • Be able to endure a number of failed attempts
  • To have good short term memory to prevent repeating unsuccessful patterns
  • To be motivated to compete this task with no expectation of reward

Finally, none of this would work without a well designed user interface. Because even though I can do this with the digital watch, twice a year the cooker is reset by the watch owner following the manual.

Can you do everything?

Pint of beer on wooden bar

My first job was behind the bar in a country hotel.

My boss was very proud of being able to do any job in the place – he could join me serving food & drinks, he could and did make up the rooms, cover shifts in the kitchen, wether as chef or washer up and he’d drive the minibus to take regular customer home after a long and enjoyable evening. If anyone was off sick he would step in without fuss.

That ethos stuck with me for a long time – that the manager should be able to step in and do the job of anyone they are responsible for.

It was many years later that I found myself working in a team where all of us had amassed a great deal of technical knowledge in our respective areas of expertise. We had been hired as trainers based on our prior professional experience.

After one leadership restructure, we noticed our new manager couldn’t do any of our roles. Not one.

And they were great.

Supportive, challenging and focused on our development and our results but they couldn’t do what we did. Yet it wasn’t significant.

Understanding the people and the roles of those you are responsible for is vital. Being able to do their job is not.


Picture credit: Photo by mnm.all on Unsplash

About me

This is a place that I can use to share thoughts that interest me. The likely topics are related to my work in Learning and Development or my outside interests, mostly travel.