Another great possibility to improve the gaming experience for your interactive story is to have the player find items. This not only gives you the opportunity to insert more player choices, making the story even more interactive and diverse, but you can also show the player theprogression of their character . More items found usually mean more options for the player character and thus a “stronger” character.
Let us return to the example with the king. In this story the hero might receive a reward from the king. They could be given the choice of either a rope or a lantern. If the player decides to take the rope, the corresponding variable “rope” is assigned the value of 1. If they pick the lantern instead, the variable “lantern” is set to 1.
TWIST image: Items using the rope example (A)
At a later point in the story you can check these variables and, based on their value, have different events take place for the player. If the player took the rope and then reaches a ravine, you could, for example, ask them whether they wish to use it to climb down. If they do not have the rope, they will either have to climb down the walls of the ravine with their bare hands which could lead to injury or some other kind of damage, or they have to make a detour to reach the bottom of the ravine, prolonging their journey.
This would also allow you to remove the rope from their inventory after they use it since the player has no means to recover the rope once they reach the bottom. An approach like this can help you to keep the amount of items the player has within limits. Otherwise you will get into the predicament of having to offer additional options and paths at every player choice for all of these tools and pieces of equipment. And variables are supposed to give you a playing field to generate exciting events, raise expectations, and reward the player, not force you to write complex stories that are getting out of hand.
Therefore better to use items that have a limited life or can only be used once. Offering the possible use of an item a second time is still advisable, the advantage being that the player has to make another decision.
Thus, in our example story, you could construct another event in which the player can use the rope. For instance, if the player has overpowered an enemy, you could check in TWIST whether the player has the rope in their possession. If yes, you could present them with the option of tying up the enemy and thus completely incapacitate them. If, when you check the variable, it shows that the player does not have the rope (anymore), you could still reference their earlier decision and output a text like, “Bending over the guard, you ask yourself how you can prevent him from sounding the alarm once he regains consciousness. Well, this would have been much easier if you had taken the rope with you.”
TWIST image: Items using the rope example (B)
Apart from the fact that these items should of course fit within the setting of your story, there are no bounds for your creativity. So use different and interesting items to enrich your player’s experience. And design the obtainment and use of those items in a way that makes it both easy for you and exciting for the player.
You can achieve this by having the player choose between two items, meaning the player is offered two different pieces of equipment but can only take one of them.
One way is to award items depending on the success of the player. If the player manages to convince the king in a dialogue sequence of their noble intentions, the king will give them an item. If they fail, they receive no item or an item of lesser value.
Alternatively, an item can produce a negative side effect. The bright lantern may help the player in finding their way through the dark. But at the same time it will draw enemies to them and involve them in more fights.
Sometimes the player performs an action that has no immediate effect on events, but will be relevant later in the story.
For example, at the beginning of the adventure the player character pulls a lever in the alien base that operates a secret door that the player will only encounter much later. Or the player character sees a picture on the wall in the home of a witness, showing that victim and suspect did actually know each other. You may want to record these things so that you can later have certain events take place that result from these player actions.
You can basically treat these player actions in the same way you would abilities and items. If the player performs action ‘X’, the associated variable receives the value of 1. Later in the game you check this variable. If it has the value of 1, you can either offer an additional Player Choices to the player or automatically lead them on a different story path to incorporate the result of that earlier action into the scene.
In the example of the pulled lever you set the variable “lever pulled” to 1. Once the player reaches the corridor where the secret door has opened, you check the variable and offer the way through the door as an additional Player Choice.
In the example of the picture in the home of the witness you set the variable “evidence photo seen” to 1. In the final confrontation with the murderer, you can check the variable and then put the player onto a different story path where they confront the culprit with the fact that, contrary to his claims, he did know the victim.
In the same way, you can use this method to record different statuses of player actions. Let us assume the secret lever in the alien base does not only have one setting but two, each opening a different door. If the player puts the lever in position one, the variable “lever pulled” receives the value 1. If they bring it to position two, the variable “lever pulled” gets the value 2. By checking this variable later on, you not only find out whether the player activated the lever at all, but also which position they pulled the lever to then offer them different choices depending on which secret door was opened.
While items should only be used at specific points, resources will allow you to include a full, continuous game mechanic in your story.
What does this look like? Imagine an interactive story where the player is stuck in a damaged space ship. Their goal is to reach the bridge to start up the systems again before the ship is being pulled into a black hole or crashes onto a planet. There are several ways to reach the main computer and regain control over the ship.
The crux of the story is the pressure being put on the player. There is only a limited amount of oxygen supply, and each action will consume more or less of it. You should of course, one way or another, inform the player about this at the start of the game. This can be done through a help text, a short tutorial, or be directly embedded into the story. In the latter case, the AI of the space ship could contact the player at the beginning and inform them about this plight. This approach would have another advantage: the AI can occasionally give the player hints or calculate them chances of success for specific actions.
TWIST image: Resources using the oxygen supply example (A)
But back to our example. The player awakens in a small cabin and begins with an “oxygen” amount of 100. Only one way leads out of this cabin, but it is blocked by a metal door with a computer terminal beside it. The player now has the following options: they can try to open the door by brute force which will definitely be successful; or they try to activate the door mechanism by using the terminal which may or may not be successful. While option one will use up a lot of oxygen (variable “oxygen” minus 20), option two is physically less demanding (variable “oxygen” minus 10).
The catch is that the player does not know whether the option using the terminal will be successful. If they fail to hack the terminal and has to prize open the door anyway, they have not lost 20 but 30 percent of their oxygen supply. But if they succeed, they would have chosen the best possible path. Thus, the “oxygen” resource has turned a rather inconsequential Player Choice into a meaningful event. In this way, you can generate decisions full of suspense from almost every situation where the player has to carefully weigh up the risk versus the chance of success.
TWIST image: Resources using the oxygen supply example (B)
This game mechanic also works the other way around. Discoveries like charge stations, oxygen tanks, or oxygen masks that allow the player to fully or partly regenerate their oxygen supply can make for interesting rewards. And they can also be a motivation to enter a dangerous hanger or risk a difficult climb.
Resources can also be used at isolated points in the story, for example for a chase scene where the growing or shrinking distance between hunter and hunted is recorded with the variable “lead”. Similar to the oxygen example, the player’s actions take different amounts of time, increasing or decreasing the lead. Or the player could occasionally find gold throughout the story that they can use at certain points in the game to buy a weapon or obtain information. As you can see, resources offer many possibilities to continuously and effectively use one specific variable throughout the whole story.
Sometimes, things will happen in the game world that are not directly influenced by your player or their attributes, items, and resources. If the player reaches a certain point in your adventure, you might want to randomly have one of two possible events take place; or the player character participates in a luck-based game to hopefully refill their money pouch.
In a traditional gamebook, the player would use dice to resolve these things. While most people only have the customary, six-sided dice at home, tools like TWIST allow you to randomly generate all kinds of number ranges, whether you want to represent two possible events, each with a 50 % chance of occurring, or many different events, each with a different chance of occurring.
Let us return once more to the example with the oxygen supply and the terminal. Instead of checking the attributes of the player character to determine whether they can hack the terminal, you could leave the player’s success to chance.
TWIST image: Random numbers using the terminal example
But you do not want the probability to be 50:50. Instead you want the player to have only a 35 % chance of being successful because the display of the terminal shows an error that is very hard to bypass. For this situation, you would generate a random number in the range from 1 to 100. If the resultant number lies in the range of 1 to 35, you direct the player to the box where they are successful. If the resultant number lies in the range of 36 to 100, you direct the player to the box where they fail.
As you can see, random numbers give you many possibilities to deliberately influence the game and increase its replay value.
You could, for example, surprise your player if they decides to play your story a second time. Thinking of a specific event at the end of the story, the player might choose to navigate through the character generation in such a way to best be prepared for this event. How big will their surprise be then if, during the showdown, the story follows a completely different course than what they expected and the mafia boss, instead of waiting for them with a shark tank trap, is now being aided by four heavily armed gang members.
Or you wish to write a crime story with different solutions. One time, the butler is the culprit, another time it is the gardener. To achieve this, you generate a variable named “culprit” at the beginning of the story with the value “1” for butler or “2” for gardener. Now, every time when the player receives any clues about the murder or the murderer, you check the variable “culprit” and then give those clues to the player that are relevant to the corresponding version of the story.
If you are using random elements, you should be aware that the player is relegated to the sidelines at that moment and cannot influence what is happening in the story. Therefore, you should consider carefully when the use of random numbers actually makes sense and in all other cases leave the player in control of things.