Recently, I’ve been writing a lot of selection-based hyperfiction. There are two reasons: firstly, it’s a lot faster to go from idea to playable game, and secondly, I can show it to people who “can’t” play text games and they get it.
Then there’s the third problem: pacing. And that one’s hard.
A good story is all about pacing, and an exciting story-game is all about its set-pieces. This is true in IF and main-stream computer games, and another thing that’s true is that set-pieces are incredibly hard to build, incredibly hard to debug, and incredibly, indomitably hard to pace.
Pacing is bad enough in normal static writing, because the speed at which you write is different than the speed at which people read. What feels like a well-developed action sequence turns out to be a blink of an eye on re-reading; and what feels like a slow-burner, tense development turns out to be a lot of irrelevant descriptions.
In the interactive context, this problem just gets worse, because writing a set-piece doesn’t even approximate how long it takes to read, or even, how you would go about doing that reading.
Back in the days when I wrote a lot of Inform 6 games, one of the standard things I’d do at the start of any scene was to make a daemon that looked like this:
daemon [; switch(self.counter++)
1: "The wind howls louder.";
3: "The door bangs against the frame.";
9: self.counter = 1;
10: "Inside the house, you are sheltered from the wind. But who knows what will get you instead...";
…the idea being that when the player solved the first puzzle – getting into the house – the counter would be set to 10 and continue on printing a new set of atmospheric messages.
This daemon could then also act as a drama manager: if the counter value was high, it might offer hints, or solve steps of the puzzle for you. It might even forcibly carry you through into the next section by some other means. Whatever suited the flow of the game.
This was my pacing muscle: if a scene was too long, or too short, I just fiddled with the numbers in this daemon, to push events quicker or more slowly. The effect was quite good, and I certainly never found a better way to do it.
The only problem is, as soon as you put a daemon like this in front of a player who doesn’t understand IF very well, they take three times as long as anyone else to get through your sequence, and your pacing is shot.
Writing a well-paced IF scene, then, seems a bit like writing a novel that works read normally, but also spelt out letter-by-letter using phonetics.
For a while, I started wondering about real-time gameplay. This is what console games do: players are put into dynamic emerging scenarios and asked to react quickly and effectively. These sequences, done well, are exhilarating to play and even gripping to watch. The drawback is you generally have to train up on each scene, getting it wrong a few times – running into walls, getting blown up, falling off things – before you can get it right.
Of course, when you’re typing your commands, real-time turns the game into a weird typing tutor program.
The issue is really one of flow. Sequences should be exciting but they should proceed naturally, from one narrow escape to another, from one cunning manoeuvre to the next. But they still have to provide scope for the player to fail and flounder because otherwise the player is not directing the action. (Though saying that, it worked okay in Heavy Rain.)
One approach I’ve always liked is time-variation on difference actions, so different verbs take different amounts of game-time. In particular, EXAMINE, INVENTORY and LOOK – the main info-gathering verbs – take no time at all. Varicella did this, although it kinda became a puzzle element. A few other games have followed suit.
But somehow this doesn’t feel quite right. Partly it’s because it’s unpredictable and introduces more pseudo-random timing into events, rather than less. And partly, it’s because floundering players are often not just doing passive actions, they’re doing something active but ineffective, like trying a halfway solution repeatedly, because it’s all they’ve got. (PUSH THE STONE. PUSH THE STONE. PUSH THE GODDAMN STONE!!) It’s that comical in-game effect where, as the world collapses around them, the main character is the one in the middle of the explosion pushing the same lever back and forth…
Okay, so, games should probably respond to that kind of thing with adaptive time, too: on the first try, it’s a real action; on repeated tries, the protagonist says, “That didn’t work, remember?”, and the input becomes an error rather than a move.
The second major issue is the “loss of good text”. If the player is constantly, repeatedly examining and inventorying, the real, in-the-moment text will quickly disappear off the top of the play screen. IF has this problem a lot anyway, with error messages cluttering up the field of view.
So maybe what I’d like to do to solve the set-piece problem is a combination of tightly streamlining the game-design – so that useless, passive or repeated commands take up no time for the player – with an interface tweak that removes these commands from the main flow – gracefully, when they’re done with.
So the result would be a tightly-held, constrained flow through a sequence of high action, but in which the player must “solve” every stage in order to move the story forwards – and indeed, their method of solution can change the way the sequence pans out.
I can’t wait to try and make and demo for this. The technology is finally almost ready. I’m talking, of course, about Juhana Leinonen’s excellent Vorple interface library. Specifically, I’m interested in the ability to hide and edit the text that’s already onscreen.
That’s the missing element, I think. We already have the triangle of player-character, player and author. Now it’s time to welcome a fourth agent: the Editor, who cleans up the text as the other three work to produce it.
(Of course, in hyperfiction, the pacing problem goes away. The pacing is set by the options offered to the player. They can’t fall off track. Your set-pieces can barrel along smoothly. So smoothly sometimes, of course, that the player feels like it’s nothing to do with them, but that’s a problem for another post.)