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.
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.