Game Pacing - with Puzzles or Implementation Depth [moved]

This I agree with. It’s a definite worry in design. It’s astonishing how varied transcripts can be, with some players easily blowing past the things you thought might be too hard, and other players getting hopelessly stuck on things you thought would be a breeze. I’ve finally gotten to a place where I simply accept that no one will EVER play a game like you thought they would, and no amount of testing will ever control for the incredible variation in players’ approaches to the game.


Oh yes. Definitely. The experience of the game’s pacing will always depend on a difficult-to-grasp sweet spot of mutual give-and-take. The pacing of an IF-piece emerges from the player engaging with the author’s work. So you’re right, pacing in IF is at its core less (much less, depending on the type of game) in the author’s hands than with a book or a film.


I mean, parser is perfect for environmental storytelling where a player can peruse all the objects, read every note, open every drawer, make inferences about a filing cabinet missing documents and take as long as they want to investigate. A very natural text adventure plot is “observe and discover what has already happened” - the text equivalent of a “walking simulator.” But museums are fun for many people, even with no buttons to push!

You can somewhat control the pace based on how deeply items are implemented beneath the general room description layer. That runs the opposite risk of the player skipping all your well-researched-lore placement and just blithely proceeding.

But I get your point - if you insert a choke-point puzzle the player has to solve to proceed, there’s less of a sense of how long a player will take to get past it. This can be mitigated and controlled somewhat via hinting, or the author can even just close a gap and solve a puzzle for a recalcitrant player: “It suddenly hits you, you have a lighter, a piece of string, and some gunpowder so you can surely fill that lock with explosive material and light the string as a wick. In fact that’s exactly what you do. Kaboom, the passage to the east is open now that the locked door has been blown to smithereens.”


I had the puzzle-pacing come up recently in a game I’m working on. There’s a character that steals something and disappears through the doorway. The tester ended up ignoring the thief and completed an unrelated puzzle elsewhere. When they finally came back and entered the door, the game said that they were chasing after the thief and was right behind them, which was really incongruous. So that made me have to go back to the drawing board for a bit.


I think that it can be said that a story has a capacity for pacing. The chaos factor is the player. But really, we talk about mimesis and the player can likewise blow that to hell by licking everything in sight. I think it’s more productive to wonder whether the narrative is capable of pacing. We often separate player conduct from the narrative when talking about mimesis. It’s only consistent to consider other characteristics in this way.

I think it’s also true that sometimes it’s hard to recognize adequate pacing in a traditional narrow-wide-narrow structure until you’ve seen it handled badly. Take the difference between Enchanter and Sorcerer, for instance. In Enchanter, the word deteriorates as the days go by. Enemies grow more aggressive. Nights grow longer. That doesn’t feel like much until you play the sequel, in which time makes no difference at all. In fact, the protag can goof off at an amusement park for a hundred turns. I wouldn’t call some of those early Zorkian games well-paced, but they at least are not badly paced in that limited context.


This is a super interesting subject and I’m excited to weigh in, but I’m wondering whether as a courtesy to @walktothesun it’d make sense to separate out this pacing conversation from the original thread?

(tagging @HanonO in case that makes sense)


I think it helps if one treats the pacing more like live jazz than a jazz CD.

The moment one puts in a non-linear element with different lengths to the ideal path to a program, it is necessary to take into account pacing will vary according to which path was used. For anything with more than a handful of possible paths (which affects parser games - including those without intentional puzzles for people unused to parsers - but also some categories of choice games), there are enough differences in the amount that pace varies that pacing is nearly impossible for a single coder to predict ahead of time.

On the other hand, there’s more tolerance for variation in pacing over the broader work if the pacing in the moment makes sense, and the transitions back into “intentional” pathway(s) are written sufficiently smoothly. Minature narrative elements like adaptive hints, a certain amount of state tracking and/or careful writing are likely to be needed for this to work. However, when it does work, you are likely to find no two transcripts quite felt the same way about the pacing. Thus, it was more like a live jazz performance (where every performance sounds unique despite being prompted by the same music) than a jazz CD (which sounds identical whether played straight through or stopped for two hours in the middle to do something else).


Very welcome point of view. This helps me think about this topic.

1 Like

Yeah, I think it’s important, in most cases, to think of the pacing (tempo, use of space, and so on) in the gameplay and the pacing in the narrative as independent but coupled things.

The main thing to make pacing “work” for the narrative segments is to always supply enough self-contained context to remind the player what’s going on, why it’s important, set the mood, and so on. You can see this done well in a lot of story-heavy open-world games (like the Sega/RGG Studios Yakuza games, where the player might decided to spend an hour playing mahjong or fishing or doing fetch quests between the “main plot” beats). Basically whenever you’re transitioning into a major narrative segment, treat it as if it’s the next episode of a TV show or something like that, and the audience might need a gentle reminder of what happened in the episode they watched the week before.

In terms of controlling the pacing of the gameplay elements, I think the important thing to remember is that it isn’t just being unable to solve a puzzle that makes the player feel like they’re stuck/bored/whatever. It’s when they feel like they’ve exhausted everything they can think of to try, and all they’re getting is responses to actions that they’ve seen before. You can manage this a lot by making all the stuff surrounding difficult puzzles as reactive as possible. If the player is still seeing new content, especially if it’s obviously crafted for the specific situation they’re in, they’re more likely to feel like they’re actively working their way through the puzzle, instead of merely being stuck.

You can also help steer the way a puzzle is solved by progressive hinting. This can be spoiler-y if you really want to move the player along, but it doesn’t have to be. If you have a puzzle where the player is looking for a key, you can keep track of which objects the player has tried to >LOOK UNDER, respond to each with “Nope, the key isn’t under there.”, “The key isn’t there either.” and so on instead of the stock messages, and then after they’ve looked under three or four things give them "The [widget] wasn’t hiding the key either. Nothing else in the room seems to be a more likely hiding place for the key, so maybe the butler didn’t hide it in here. " Or whatever. The basic idea being that you want to identify ways the player might be banging their head against the problem (trying to apply every inventory object to an environmental object, trying to look through every container, trying to lawnmow through every NPC conversation, or whatever), test for those actions, and respond to them reactively.