Splitting passages without creating more of them

So, I’ve mapped out a large and complex branching story with some 200 passages in total, but some of those passages are going to be very long. I want to limit the amount of text on the screen at any one time to make it easier to read, but it would be easier to follow the flow diagram if there aren’t too many ‘one-choice’ passages that only lead in one direction.

What I’d like to do is combine all contiguous passages with only one choice into a single passage with a customisable ‘continue’ button, just to keep the display neat. I know I could probably do this using <<link>> and <<replace>>, but that could get quite cumbersome and confusing when there’s five or six run-on passages. Ideally I’d like something simpler that I could just drop into a single line to denote something analogous to a ‘page break’. For example something like this would be ideal:

You see a box, and feel compelled to open it.
<<pageBreak "Open the Box">>
You open the box. There's a Cornish pasty inside. Yum!

The expected result would be, when you enter the passage you get the first line and a button marked ‘Open the Box’, but not the last line. When the button is clicked, the screen clears and you get just the third line. This process would need to work with multiple line breaks in one passage.

Is there a way to do this already, or a macro that I could install to provide this functionality?

You can have a passage that displays different text depending on how many times you’ve visited it and keeps linking to itself until the final message is displayed, like this:

<<switch visited()>>
	<<case 1>>
		You see a box, and feel compelled to open it.
		
		[[Open the box|same passage]]
	<<default>>
		You open the box. There's a Cornish pasty inside. Yum!
		
		[[Continue|next passage]]
<</switch>>

You could simplify this even further with this macro. Another way to do something similar is this this other macro, though that’s a little more complicated.

Note that neither of these allow the player to renavigate to the passage and see the “you see a box” message again, if that’s something that needs to happen in your game.

2 Likes

Nice idea, but not ideal since it ruins going ‘back’, and that’s a staple feature of this kind of game. It also results in unsightly circular arrows all over the place in the Twine editor, and since the main point of using this hack is to make it look neater, that’s not ideal.

The second macro looks like it might work, but in terms of boilerplate it’s barely any better than using link and replace commands.

Maybe I should investigate how macros are written and roll my own.

I just tried out the second macro, and unfortunately it messes up the ‘Back’ button too, in the most bizarre way. Revisiting the same passage seems to wind up on either the second or the last page of the content, depending on if you’re going back or forward. It’d be fine if it always reset to the first page, better still if it reset to the last page when going backward and the first when going forward, but its behaviour just isn’t predictable.

Okay, here’s a very simple, very stupid solution. Put this in your Javascript section:

Config.navigation.override = function (dest) {
	if (dest != passage()) {
		State.variables["count"] = 0;
	}
	else {
		State.variables["count"]++;
	}
	return dest;
};

and this in your passage:

<<switch $count>>
	<<case 0>>
		You see a box, and feel compelled to open it.
		
		<<link "Open the box" "same passage">><</link>>
	<<default>>
		You open the box. There's a Cornish pasty inside. Yum!
		
		[[Continue|next passage]]
<</switch>>

This works similarly to the previous example but uses a variable called $count to keep track of how far into the chain you are. What that first function does is this: every time the player navigates to a new passage, it checks whether the passage is the same as the one it’s already on; if it is, it increases $count, otherwise it sets it back to 0. If you want the chain to have more steps, you can use <<case 1>>, <<case 2>>, and so on.

That <<link>> macro links to a passage without creating an arrow. I’d recommend using passage navigation this way over something using <<replace>> or similar because it takes advantage of Sugarcube’s history navigation and playthrough restoration. This way if the player reloads the page they won’t have to reclick the links, and history navigation will work more intuitively (if you’re using that).

1 Like

Hmm. That sounds good in principle, but it doesn’t decrement the count when going backwards, so you end up seeing the last case statement multiple times when you skip backward through them, until you get to the passage before and return to the passage itself proper. Seems like a good starting place though.

Actually, what seems to happen is this: when you use the ‘back’ button to navigate backwards, it undoes the variable change (as it should) but the navigation override then immediately increments it by 1 again, so going back to the previous page always ends up with a value one higher than it should be. There needs to be a way to detect when the user used the ‘back’ button and then ignore the increment.

1 Like

Huh, you’re right. Try this instead:

$(document).on(':passagestart', function (ev) {
	if (State.variables["lastPassage"] != passage()) {
		State.variables["count"] = 0;
	}
	else {
		State.variables["count"]++;
	};
	State.variables["lastPassage"] = passage();
});
1 Like

I think that’s the one! Noice. And since there will never be more than one chain of passages in progress at a time, we don’t need the overhead of multiple variables for different passages.

Thanks for that @svlin, it’s much appreciated. JavaScript isn’t my favourite language and I’ve been having difficulty finding references for what to override in SugarCube.

At some point, I think I’ll drop a suggestion for Twine to allow passages to be grouped together into a single ‘block’ and edited separately, like little sub-stories with multiple entry and exit points. I think that’d be a super-useful feature for larger games.

2 Likes

Have now added a feature request to the Twine GitHub, for those interested.

Yeah, that comes up fairly often: Issue #1345 links to a bunch of the past related issues.