Quick-Time Events are the result of developers who think that games should be more like movies; so they insert cinematic sequences involving their player-protagonist.

Putting something fundamentally non-interactive into an interactive medium is a horrible mistake. But then, it seems, many developers recognise this mistake… and attempt to correct it by slapping some button-mashing over the top – itself an even bigger mistake!

~

The first time I experienced a QTE was in some rubbish triple-A port to the PSP. At the time I had no idea what a QTE was – so coming across one unprepared was a rather unpleasant surprise.

The game in question was a fighting game of sorts involving pressing button combos to trigger various moves and powers. You’d start with a few available combos, and unlock more as the game went on.

After pushing through some fairly mediocre gameplay, I came to the first boss. At the end of a typical boss fight, the camera angle changed and a button icon started blinking on the screen. Again, I had no idea what this meant – so my brain quickly synthesised a possible explanation.

My design for a good quick-time event is based on what I was thinking at the time:

“I’m playing a game where the primary mechanic is button-based combos. It seems to have started a cutscene-esque sequence to finish off the boss. It wants me to press a specific button, which is similar to the game’s button-combo mechanic. I expect that the moves my character makes within the cutscene will correspond to the actions that these buttons trigger during regular gameplay (eg: press X to punch).”

“Furthermore, I expect that, if I don’t press the right buttons, I can still kill the boss in the regular way, except without the cool finishing animation.”

“Finally, this appears to be a sequence of buttons I haven’t used before – so perhaps I unlock a new move after this boss fight, and this doubles as the tutorial. That’s a pretty clever design, right there! This is going to be amazing!”

“…”

“Oh. So it’s just a bad game of Simon, shoving completely random button-mashing prompts in my face without rhyme or reason? Well that sucks.”

~

What made this even worse was the fact that I had barely, but legitimately, defeated the boss within the regular game mechanics. To then be forced to beat a stupid QTE to claim my legitimate victory was downright insulting.

…

Especially as I failed the QTE! What did the game expect!? I had never seen a QTE before! There was no explanation for it beyond a blinking icon on screen. Clearly I press that button – but do I press it repeatedly? Hold it down? No idea.

So I was then forced to defeat the boss again, only this time without all of the resources that I had expended in the first fight. And then again. And again. Until I died and had to start over. Terrible.

~

After such an awful experience with quick-time events, I’ve mostly managed to avoid the kind of game that includes them. So you will have to excuse me if I’ve somehow missed great advances in QTE technology.

Even so, it seems to me that QTEs have evolved little over “press X to not die”. Most games seem to have simply added new input methods, like “waggle stick to not die” or “play one of those old-school golf games to not die”. These don’t actually solve any of the fundamental problems with QTEs.

(This is except for one very excellent example, which I will mention towards the end.)

~

So, here is my quick set of rules for making a good QTE: (Keeping in mind, of course, that QTEs are basically terrible in the first place.)

The first rule: quick-time events should be reserved for a few epic moments in the game. Save it for a cutscene after the player defeats a big boss. QTEs are fundamentally a sub-mechanic of cutscenes; if you’re using them as part of regular gameplay then you are really doing it wrong. (*cough* Resident Evil 6 *cough*)

It helps to analyse how cutscenes sit within your game mechanics. Generally cutscenes act as a reward. It is possible to use them for eliciting various emotions, building tension, and so on; that’s a more advanced use, which I won’t go into – but the principles here can be applied. In any case the cutscene itself must already make mechanical sense before we even think of adding QTEs to it.

The second rule: If the cutscene is a reward, we probably want to make the player feel like a badass. They’ve probably just defeated a challenging boss through your regular game mechanics. Why are we adding an additional challenge on top? Especially when that challenge isn’t especially fun or intrinsically rewarding? And especially when it breaks the cutscene’s pacing and immersion!

So: aggressively dial back the challenge. Go so far as to make the QTE a single, untimed button-press that advances through the next action in the cutscene. You want the player to still feel in direct control of their character – so why would you break immersion (besides puking incongruous button icons onto the screen) by arbitrarily making that character harder to control than normal?

With the camera pulled in, time slowed down subtly, the player still buzzing with energy from working hard to defeat the boss – having but a single button press to obliterate a formerly-imposing foe is going to release all that tension and make the player feel awesome.

(There is another reason to dial back the challenge: A QTE must be either optional or impossible to fail. It sucks for a player to get stuck in a game just because they can’t beat your stupid QTE.)

The third rule is the final ingredient that will make everything sing: The buttons/actions that the QTE asks the player to perform must be ordinary actions available to the player within regular gameplay.

There’s already an important rule for a satisfying cutscene: it cannot have the main character performing feats that they cannot do in-game. I think some designers have gotten the idea that this rule doesn’t apply if they make the cutscene interactive. WRONG! It applies doubly.

Making the actions the same between QTEs and gameplay keeps the player feeling in control of their character. So if your player normally presses X to punch, in-game, then they should press X to punch within the cutscene. Of course, as long as you keep the verbs the same, do what you can to make the cutscene rewarding – you should absolutely add some spiced up animations and, probably more importantly, sound effects!

~

In addition to these rules, it is also worth thinking about what to do with the ugly QTE button prompt.

You could just leave it there. It is somewhat immersion breaking. Although, if you follow these rules, and get rid of all the blinking and meaningless challenge, it might be acceptable.

I am rather fond of the “tutorial” idea I mentioned in the first half the article: Having a QTE double as a finishing move for defeating a boss and as a tutorial for the same move which you unlock by defeating said boss, would be a beautifully tight piece of game design. As far as I know, this hasn’t been done before.

But, allow me to close by mentioning a game that follows these rules so well that it didn’t even need a button prompt. In fact, you might not have even noticed that it was giving you a quick-time event at all! Let’s quickly recap those rules – see if you can guess the game:

1. You need to be in an epic cutscene after defeating a major or final boss.
2. You need to make the event trivially easy to complete
3. It has to trigger an action available within regular gameplay

I can think of one example of a game so amazingly excellent that even its single QTE was fantastic. That game… is Portal 2. I won’t spoil the ending, in case you haven’t played it yet (you really should). But those of you who have played it will know exactly what I’m talking about.

If only all games’ QTEs were that good.