One of the most common Twine projects I see are people wanting to create a role-playing experience. Be it a fantasy setting with brave knights of yore, a modern-day investigation of a murder, or even a post-apocalyptic space station, there is a clear desire to make a nonlinear space for players to explore in Twine stories and games. And, of course, often an author just wants an exciting setting for their characters and players.

Last year, I experimented with a project I created in Twine called Cnossus: Lost in Darkness where I had players wander around a maze. It was based on an idea I had to reduce the total number of passages in a Twine story to only a handful, each representing the cardinal directions and conditionally linking to each other based on the player’s current location in the maze. At the time, I released it as one in a number of attempts to make a Twine story, game, or experiment per week.

However, with the start of a new year and with Twine 1.4 now out, I thought I would re-visit that game and explain in detail how to re-create what I did to make it.

First, I used an array of arrays for the maze itself. In JavaScript, there are a limited number of data structures. Beyond functions, objects, and the various number types, there really is only arrays for storing connected data in one structure. Here, I used a two-dimensional array, linking the position of the player to the indices of the first array to the second array.

Each location in the maze was a (X, Y) placement. Starting at (1,1), the player moved a single position in one direction, if they could, with the code increasing either the x-position or the y-position each time. Then, a series of Boolean values (1 or 0) were set, one for each of the directions.

In practice, this meant calling a macro called ‘navigate’ with the loading of a new passage, checking each time the position of the player in the maze. If the space (the [x][y] position) to either the North, South, East, or West was a ‘1’, that meant the player could move there and thus the direction was enabled (set to ‘1’, true). Because the exit, a ‘2’, could appear in any direction each direction conditional had to also check for this value.

Since the loading timing of script passages in Twine cannot be guaranteed, I also needed to use an older Twine hack of creating a variable, making it a function, and then calling ‘print’ on it immediately after it is set. Having another passage ‘display’ it, such as the Start passage, triggers this process and loads everything on demand. (It is not always an elegant solution to the loading problem, but it is one that will work.)

From Start, I used a “Enter Cave” passage to link to each direction, if after calling the macro ‘navigate’ they were available. For each directional passage, they updated either the x-position or the y-position accordingly and then called ‘navigate’ themselves each time. The player then moved around the maze until they came across a link to the ‘exit’ passage.

As a final touch, I used the Jonah story format and the few lines of JavaScript that forces only one passage to be displayed at a time (by removing all others from the storage area each time).

(For those wanting to use the below complete code, be sure to copy and paste it into a file with a “twee” suffix. While I can have GitHub show you Twine code, it does not recognize the file format itself and I have thus needed to select ‘JavaScript’ for it to highlight some of the code.)