A common game mechanic in story-based games is the “quick-time event”. Basically, instead of just presenting the player with a static cut scene, the scene is cut up and at certain points, the player is prompted to trigger input. Either this is a single input that will be used to determine whether the scene is passed or failed (giving the rest of the scene or a game-over death scene next), or the user is prompted to press one of several keys to decide how to continue the scene. Often this happens on a timer, so if the player doesn’t press the right key, one is chosen for them. That’s where the “quick-time” in the name comes from.

Later Telltale games (starting with Jurassic Park) relied heavily on quick-time events to perform their branching in their storytelling, but earlier games like many Tomb Raider games, Revolution 60 or Saints Row IV have been using this technique for some time.

The advantages are numerous:

  • A particular moment in the game is very controlled and can be shown in a very cinematic way, with camera pans, zooms etc.
  • Instead of interrupting the game completely with a cut scene, relegating the player to watching, the player is still in control of the game
  • It is very clear to players where a decision happens

However, I see a number of disadvantages, and postulate that the way quick-time events are currently implemented in most games are a mistake that should be avoided, or at least used sparingly. I’ll give a few reasons for why I dislike QTEs (as quick-time events are called for short), and will offer a toolkit for simple changes to existing QTE-scenes that offer many of the benefits of QTEs while avoiding their downsides.

Monkey Push Button

There are comic books, and there are movies. In the area in between, there is a continuum.

There is bad animation like some of the early Marvel cartoons that were basically fixed images dragged over each other to emulate primitive motion. There is low-framerate animation like some of the 80ies G.I. Joe cartoon that felt a little choppy but was less expensive to produce. There is cheap 3D animation, where a few simple scenes are created as loops, and then the camera is flown through the 3D models to create the illusion of a scene being longer and hiding the looping, and then there are real movies that have a frame-rate that is mostly indistinguishable from real movement to the human eye.

The advantage of the comic book is that you can move through it at your own pace. Whether you are a slow or fast reader, it doesn’t matter. Sometimes it’s even enough to just look at the pictures. Your eyes just move from one panel to the next as fast as you want, or move back and forth if you desire to review a previous panel.

A movie does not offer that freedom. Beyond pausing for a break or painfully rewinding or fast-forwarding, a movie generally progresses at the merciless pace of 24 frames per second, to show what the director intended at the speed they intended. While changing that is possible, it is usually awkward, far from the convenience of a comic book.

And then creators started making “motion comics”: Supposed to combine the best of a comic book and a movie, they often can feel like “bad animation”: Suddenly, each panel has to be triggered to start a simple animation. Intended to make comics more dynamic, it actually often feels like a stunted movie: Every second or so, you need to push a button or the movie will not continue playing. To a fast reader, it also adds a slowdown, as you have to wait for each panel to build up or finish animating before you can switch to the next one.

Quick-time events are similar. Instead of immersing you more in the game by letting you still interact with your cut scene, each quick-time event in a larger cut scene stops the movie and shows a prompt in your face, actually taking you out of the cut scene.

So instead of one context switch that your brain used to perform, where a cut scene started and you stretched your fingers while switching from player to viewer, you actually get that context switch from regular gameplay to cut scene, and another one on each interaction.

But there are many easy ways to “hide” this context switch, to drape a blanket over your QTE mechanics and integrate them into your game with fewer seams:

Use Consistent Prompt Keys

Many game designers try to add urgency and challenge to the “monkey push button” aspect of QTEs by varying what key you have to press on each event. That way, the player can’t just keep pressing the same key whenever a QTE prompt with a single choice comes up, and instead has to search the screen for the prompt, read it, then exercise hand-eye coordination to press the right key. The idea is to add some challenge to avoid the boredom.

Some also try to emulate whatever action you are doing onscreen by having the player hold a key, or repeatedly mash it in a certain rhythm, or hold and release it, to emulate for example the back and forth of a saw being used.

The issue with this is that the rest of the game is not like that. In other situations in the same game, you are given a toolkit, you are introduced to your character’s abilities, and told which button triggers which. WASD or the left stick are used to walk around, the mouse or right stick are used to look around, clicks or number keys or the four buttons and shoulder buttons and D-pad are used to trigger certain interactions etc.

Why not superficially offer the same experience for QTEs? Instead of having the player press a random key to dodge an object, just show a prompt reminding the player of all four dodge keys, and have the enemy slowly lunge at them. The player can now decide what direction to dodge in. The “good” dodge direction should be obvious from set design:

Running bandsaw on the left, enemy in front, running from explosion in the back, so dodge to the right. If the player presses anything else, let that element get the player. Dodge left? Bandsaw death scene, Dodge back? Explosion death scene. Dodge Forward? Enemy gets you immediately instead of when the timer runs out and they’ve reached you.

Or if the addition of two more death scenes is not in your budget, just re-use your “collision” animation from your player character: Dodging back just delays the timer for a split-second, but then the enemy catches up with you anyway. Dodging left makes the player character immediately collide with the bandsaw, seemingly jumping back into the enemy’s path.

If you can reduce all your cut scene actions to actions the player knows from your game, it will feel much more of one piece with the rest of the game, yet you still get to do your cinematic angles and detail shots.

Re-use Pre-existing Interactions for QTEs

As an extension of using consistent prompt keys, you can re-use pretty much any existing game system’s UI for equivalent actions in a QTE-scene.

Why not have the player use the existing crafting system to build that new car? Have them run around the room a bit, maybe add short cut-scenes when they pick up useful items, then have them assemble them in their crafting inventory and interact with parts of the machine’s chassis to apply the newly-crafted items?

Why not switch their weapon to a hammer and have them clang on the sword a few times?

Why not use that existing conversation tree UI to have the player make decisions in conversations by quickly calling out “I can’t save you! I’ll die!” or “I’m coming to help you!”, for example instead of having the QTE prompts “[LEFT] Help Mike” and “[RIGHT] Run away”? Until Dawn kind of gets this one right, although it doesn’t give you the full conversation tree experience.

Lock the Camera

Most QTEs are done to add cinematic perspective to a game. It creates memorable images in the player’s head and makes for good demo clips in your ads.

But you do not need a quick-time event to achieve that. Look at this year’s PS4 title Marvel’s Spider-Man, where one boss fight on the side of a building simply locks the camera. The enemy is in front of you, your player character can’t back up beyond the camera, your web shooters were busted in the transitional cut scene before, but beyond that, all your abilities are still available.

This is basically a variation on the classic Metroid boss fight: You are locked in a room with a big enemy that has a certain pattern you have to figure out. They attack, you dodge, then while they’re charging back up their attack, you get a few punches in.

There are basically 6 “right” keys you can press. Directional dodges, attack, and heal. By implementation under the hood, this is basically a QTE. But it is so well-disguised that it feels much less of a break. You’re used to cut scenes taking over the camera, this scene just doesn’t let the camera go afterwards.

Note that I do recommend doing this carefully and sparsely. Randomly locking the camera can feel very disorienting. Horror games like the original Resident Evil use this technique to great advantage to increase the player’s paranoia, by placing cameras in spots half-hidden behind things, slightly above or below the eye lines, to evoke the feeling of being watched. But in general, you do not want to disorient your players in non-horror games.

Create Mini-Games

Another way to lock the user in without them noticing is by placing objects in the world that, when interacted with, start the QTE-that-is-not-a-QTE. For example the gun turret at the start of Saints Row IV: You jump into it, and as long as you sit in it, you can only move your gun and shoot. None of the other abilities work. But players don’t notice, because their gun is themed to look like the cockpit of a turret they are sitting in.

Until Dawn, as a representative of traditional QTEs, on the other hand, interrupts the player, shows crosshairs over every enemy, and expects you to move your left stick until your crosshairs are over the desired enemy and then makes you press a button to shoot.

This is basically the same thing, just that the UI in Saints Row and the buttons are what you will be using the entire game, and there is a natural way for the player to explicitly start the QTE, instead of it just pausing.

So if you can get the player to get in a turret emplacement, the backseat of a car, or something else that obviously limits them in certain ways, you will still be writing identical game code, but it will feel so much more natural to the player.

Instead of showing players a prompt to “not move any stick”, give them a stealth mechanic. Give them enough rope to hang themselves, and use it a couple of times in your game. Have them start out crouched behind flimsy cover with the enemy approaching, forcing them to leave this cover. Even if there is only one right solution to the situation, the player will experience more agency, and will feel as if they found a solution.

Put the Player on Rails

Although this is basically a combination of all the previous points, it bears repeating that this is a totally legitimate way to get the player through a scene with the camera changes you want, without robbing them of their sense of agency and control.

This is done in a genius way in Saints Row IV when you are rescued: You are dropped out of your pod, and woozily stumble towards the exit. You have no weapons, no clothes, and you are floundering about like a drunk sailor.

There is only one right key you can press: Forward. Any other navigational key just makes the character lurch in that direction for a moment before they precariously regain their balance.

It doesn’t feel that way when you play it. The context of the scene, the animation, the empty inventory, all that combines to make it obvious to you what happens. As you control the speed of your character, you feel like you are really part of the struggle, and even the forward steps make your character lumber dizzily to the sides to support this impression.

You may be forgiven for thinking you had to keep below a certain speed so your character doesn’t fall over or throw up, even though those things happen at predefined locations down the path.

Saints Row IV’s disoriented stumble out of the base is the most ingenious, least obvious quick-time-event I’ve seen so far. You are literally just a monkey pushing a single button.

Use QTE-like Prompts in Other Places of the Game

Many modern games provide some sort of HUD interface to make it obvious to the player which items are decoration, and which are actually interactible. Also, many games show the key to use in these prompts as well. This is good. Many games these days take well over 10 hours to complete, and many working adults have to play these games in instalments when they have time off from work, family and other important things.

People lead a life, so the gap between sessions may be a 2-week business trip, at the end of which the player may not remember the key combinations.

By presenting the keys where they are needed, either permanently, or after a short delay if you see the player pause with movement while facing an interactible object for a longer time, you make the gap between a quick-time event and regular gameplay smaller. By using the same mechanism to show prompts for the QTEs, they stick out less.

Mind you, I’m not saying you should put up huge button prompts on the screen constantly. While de-sensitizing users definitely works, most QTE-games desire a cinematic feel, which is the direct opposite of showing prompts on-screen.

Try to Hide Your QTEs

In summary, be clever about how you implement your QTEs: Soften the context switch between game and QTE, re-use existing game mechanics where possible, and even if you can’t afford to add a full game mechanic for a cut scene, at least attempt to make the existing mechanics do something sensible or provide obvious plot reasons why they wouldn’t work or even be unavailable right now.