Twine: How to Map Rooms with In-Between Cutscenes?

The Setup:

I’m currently developing a game in Jonah where the player navigates certain floors, and moves through the map by going up and down between the different floors. Each floor has several paths to get to the next floor. So the structure of the game would look something like this (only with a lot more rooms and paths up and down):

The Problem:

The first time a player reaches a new floor, no matter how they get there, I would like to trigger a specific dialogue text (a sort of cut scene if you will). It would a) be the exact same text no mater the path, and b) occur only the first time they reach the new floor (not just the first time they use that specific path). Like so:

I’m not sure what the best way to go about coding this on the backend would be though.

The Solutions?

So far, the solutions I’ve come up with are:

  1. Track a variable that would remember where the player came from, so that once they end up on the dialogue node, it would lead them to the correct location. Like so:

  1. Have identical dialogue nodes after each path, and just code in and exemption that if you visit one or the other they will not play. Like so:

Both of these feel a little inelegant though, and I was wondering if anyone had any better ideas as to how to handle this particular issue. This has been stumping me for a while, so any ideas (even if its just confirming one of the two solutions) are appreciated.

Have you considered a variation of solution 2 using the display macro? In Twine 1 there was a way to display the contents of another node using a display macro and a node reference. If that content node can track how many times it has been displayed, then you should have something closer to a more ideal solution.

Setup as in solution 2, except that the only code in those in-between nodes will be a display reference to a cut scene node. The cut scene node is not connected to the regular map in anyway but it’s content is ‘seen’ through the use of the display macro. When it is seen, you should have the chance to update variables, so you would increment a variable to track how many times it has been displayed. This will allow you to have a one-off cut scene and a generic regular floor transition for every time after that no matter which route is used.

I believe Metrolith uses this technique or a variation of it for character specific cutscenes (node map) (source). If you look at the node map, it will be the left most node with the most links to it.

Solution found using setter links and a variable (ie. [[Link|cutscene 1][$destination = next floor location]])

It’s kinda interesting how such a primitive task has not obvious and intuitional solution in this system.

I’m not surprised - Twine is a very simple language with no world model.

Well yeah (I would say every ‘programming’ language for IF is simple), but still ‘one-trigger events’ or ‘execute-once’ are primitive features and you definetly need them if your game isn’t just simple linear input-response sequence of events.


Well, the simplicity of Tads 3 is different from the complexity of Hugo which is different from the complexity of Choice Of which is different from the complexity of Twine… surely.

FWIW, AFAIK tools like Twine usually* have this in the form of a link that goes to a cutscene, and then deactivate that link (and maybe activate an alternative link that bypasses the cutscene). The feature is there (indeed, the OP found a solution), it’s just not obvious.

Finally, a lot of Twine games that I’ve played are simple linear input-response sequence of events. In fact, some parser IF I’ve played is that too. :slight_smile:

  • meaning, “I’m talking out of my posterior because I’ve never programmed in Twine but I’ve played lots of games and would totally do it this way if it were me”. If Twine doesn’t allow this I’ll refer you to the part where I say “tools like Twine” and be smug. In fact, I seem to remember using similar hackery when I programmed in AGS, activating and deactivating dialog topics this way for similar reasons.