Press X to Read This Blog: On Quick Time Events

QTEController

The QTE Controller. Image from Cracked.com

I will be honest at the outset. I pretty much despise Quick Time Events (QTEs) in games. Unlike many who share this dislike, I don’t consider them the mark of “lazy developers”, uninspired design or cloning popular titles. I am also of two minds as to whether they are or aren’t a “real” mechanic or gameplay, though I have agreed with that in the past. I’ve come to realize that the real reason I hate QTEs is because they are very rarely used well. I might argue that the nature of a QTE leads to poor use, but that doesn’t mean it can’t be done well. So, in an effort to better understand the issues and uses (as I personally see them), let’s examine and pick the technique apart.

For those in a rush, it distills down to the following:

If you want to use Quick Time Event-like mechanics, for the love of all things holy, PLEASE—integrate them well with the experience that surrounds them. Maintain the player’s state of flow.

Quick Background

Rather than just assume everyone that trips across this entry knows what I’m prattling on about, I’m going to take a minute for some history and definition.

A Quick Time Event is a sequence in a game where scripted events are presented (often in a format similar to a cut-scene) in a branching format, in which the player must provide input within a specified timeframe in order to navigate the available paths through that sequence. Most commonly, these are of the infamous “Press X to not die” variety, where the only branches are failure conditions—that is, the player must make a series of input actions as prompted by the game to progress through the sequence and if they are not fast enough or make a mistake, they must in some fashion try again.

DragonsLair

Dirk, on the lookout for flashing doors.

The intent is obvious enough, and even laudable. QTEs are an attempt to make what would otherwise be a cut-scene more engaging and interactive and to produce interactive fiction; they are an attempt to put more control in the hands of the player and produce more agency; they are an avenue to produce some breathtaking maneuvers as a result of player action that would be otherwise quite difficult to pull off. They are also frequently cited by players as frustrating, irritating, quickly-boring and bothersome, none of which supports those goals.

Shenmue-QTE

A QTE in Shenmue

The origins of QTEs as we know them lie with Yu Suzuki’s Shenmue released for the SEGA Dreamcast in 1999. This is the first time that we saw them in the form that has been used since, and Suzuki was responsible for coining the term “Quick Time Event” as a part of its development. However, the roots of the QTE reach back farther. Cinematronics’ 1984 Dragon’s Lair is, so far as I know, the originator of the QTE style of gameplay. You can catch some video of the game being played here.

Shenmue arguably popularized the technique, and it started to crop up in other games, even in other genres, but from what I recall of the period, it took another blockbuster game to really cement the use of the QTE.

GodofWar-QTE

The beginning of an era.

In 2005, Sony released God of War, to a great deal of success. Pertinent to this discussion, God of War added to its action beat-‘em-up gameplay foundation by providing elaborate and spectacular finishing sequences to boss fights. These finishing moves are, you guessed it, Quick Time Events. This led to a landslide of similar games incorporating short QTEs for all sorts of things.

So What’s the Problem Anyway?

So. The meat of the topic. What is it about QTE mechanics that make people hate them so much? I suspect it has a lot to do with the same reasons I don’t like them, so I’ll just rattle off what I think.

Primary Issue: Cognitive Dissonance

Flow Cover

Press X to completely ruin this.

This is, I feel, the root of all QTE evils. Anyone that plays games with any frequency can tell you that there is a certain rhythm to each game, a certain rhythm that one falls into where it’s no longer necessary to rationalize everything one does in playing the game. The point at which you free yourself from the minor tasks of playing and can think on a higher level about what you’re doing. I’m simplifying, but it’s part of what Mihaly Csikszentmihalyi describes as a state of flow.

Reacting to QTEs involves a totally different mental model than actions that typically surrounds them, such as cutscene-viewing, combat or exploration. The arrival of a QTE is jarring and takes time to perform the necessary mental switch to overcome. Time that the nature of the QTE is directly at odds with. This, of course, also assumes that the cues for the QTE fall somewhere you’re actually likely to notice them happening.

Imagine playing a game that deals with intense combat scenes built around sequences of button presses that link together to form combo chains. This should sound familiar. Consider where the attention of the activity lies—as we get into the rhythm of the needed button combinations, we begin to think less about pressing them, and more about what we plan to do next. After a while, we think “four-hit combo to this guy, then a reverse-direction thrust to that guy coming up behind me, and I’ll launch the third in the air” and allow our now-trained fingers to worry about “X – X – X – X – Left Stick Away+X – Y”. So we go about our business, and man, we’re doing awesome against this guy! We’ve got a 20x hit multiplier going; we’re dashing out of the way of his axe and then back in and hitting him some more and then—

QUICK PRESS X RIGHT NOW AWWW YOU WERE TOO LATE.

Wait. What? Gawdamn QTEs!!!!!

This is what I feel happens most often in games which use QTE-style mechanics. The QTEs are not predictable while attention is elsewhere, and thus they break the state of flow. This, as should be apparent, is something of a cardinal sin—flow is such a natural and comfortable state of happiness and enjoyment that humans react very strongly when it is broken. QTEs break flow for many people; therefore many people hate QTEs.

Previously—as early as “this morning”—I had quite a few more reasons to underline and particular games to call on the carpet. I have since given it some rational thought and decided neither are necessary. It all boils down to broken flow, and there are ways to avoid that (and thus make QTE suck a lot less).

So Whaddya Wanna Do About It?

This blog is in many ways about identifying problems and finding solutions, so I’m not inclined to just leave it there. Just as the problems with Quick Time Events can be found by examining games, so too can we find the solutions. There are, after all, games that manage to use these without causing teeth-grating frustration, so a close look at those games should give us some ideas.

Solution 1: If You’re Gonna be a Bear, be a Grizzly

HeavyRain-QTE

Sometimes a cigar is just a cigar.

One approach is very simple: don’t make QTE sequences require a shift of thought process by making a game comprised primarily of that variety of play. Dragon’s Lair does this and is still thought of fondly by those that played it. More recently, Heavy Rain does this, and whatever issues I have with that game, I don’t think I’d jump to count the QTEs themselves among them. (Granted, David Cage has leveled some pretty scathing commentary on the idea that the game has QTEs at all, but that’s really not the point of this entry.) I’m not very fond of this approach, but it does work for the purpose.

Solution 2: Inertial Compensators

Sci-Fi geekery aside, another option is to realize that the time it takes to shift gears into account, and give the player a longer period to react. While this is still mildly jarring in practice, it at least gives time to avoid the failure cases that is so frequently the source of frustration that gets amplified by the flow loss. I’m not too fond of this option, either.

Solution 3: Failure is an Option

If the point is more agency and less linear story, you could do worse than to simply make the failure case a viable choice for playing the game. It doesn’t aggravate the player quite as much to fail a button-press if it opens up a new bit of game. I don’t believe I’ve seen this used much, but I basically like the idea.

Solution 4: Let the Player Start It

I don’t have an even remotely clever way to title this one, so… alas, carry on. One of my preferred ways to see QTEs done these days is to allow the player to initiate the sequences. This tends to work best in action games that follow the God of War style. In this case, the player wears down a major enemy until they are given the option to initiate the QTE finishing sequence. this allows the player the opportunity to make the required shift and maintains better agency, especially if the QTE is optional to success. Two games I can think of that go this route are Star Wars: The Force Unleashed and Darksiders. Both of these shine particularly well by avoiding random sequences, as will be discussed a little later.

Solution 5: Build a Little Fence Around It

If there’s a long section that seems like it might be good for heavy QTE work, why not section it off as it’s own level? A break in the action is a good place to have a change in mental positioning, so take advantage of it. I’ve seen a few games that do this, and it works well. I’ll come back to it with an example a little later.

Other Notes

Whatever approach one takes, there are a few places you can still see serious issues:

1. Reaction time. I don[‘t think anything irritates me more about QTEs than blinking and failing a button press. Some otherwise good games only give you a second or even less to react to the demand to poke a button, which can ruin a whole game through frustration. Seriously. If you feel that a QTE needs to be a challenge, something’s wrong with your game. There’s better places for challenge. QTEs should be for feeling badassed with a mild amount of effort.

2. Random Button Sequences. I suspect this is done to address the rote memorization complaint about QTEs, but it just aggravates the other problems. This is especially true in games that use buttons to correspond to given actions. If you use A to jump, X for sword slashes, B to grab, and Y to shoot a gun, so too should your QTEs. Anything else is just confusing and annoying. Also, repeated sequences give the player a better chance to react. The Force Unleashed uses this rather well, as minibosses such as AT-STs and Rancors each have two potential sequences, and the player learns to discern between them quickly.

3. Big colorful flashing icons. Consider some way to handle the cue that don’t stick out of your art direction like an ogre at a gnome’s family reunion. this can be as simple as drawing the button cues in the same overall style as the rest of the game, or finding clever in-setting cues of some sort. I would argue recent Zelda titles’ use of a little music sting and sword glow right before enemies attack is a fair example of managing this.

An Example Done Well: WET

This is subjective, but when considering games I’ve enjoyed—and better yet managed to enjoy without doing so in spite of the QTEs in said game—I usually fall to Bethesda’s underappreciated WET.

WetCarChase

Guns, explosions, car-surfing. What's not to like?

The game manages to pull off acceptable and even—dare I say—enjoyable QTE content by combining a number of the things I’ve outlined above. QTEs come in three basic forms: Quick 1-2 button finishing moves on some of the tougher enemies, such as minigunners, longer sequences wrapped around boss fights, and a couple of highway chase sequences.

The first of these—the short finishers—fall into the category of letting the player initiate the QTE. As in Force Unleashed and Darksiders this works out nicely, since you get to choose when it occurs, and as in those games, it usually takes the form of wearing down the enemy until a button appears over their head, then running in close and pushing it, followed by a second button a couple of seconds later. The result is that it’s not that hard to meet the demands of the event, because they only happen when you’re ready for them to.

The boss finishers are the weakest of the three, but benefit greatly from being well-telegraphed and having button sequences that match the animation work. When Ruby brings her sword around, you know you’re going to be hitting X soon, and that helps it flow better. Additionally, WET tends to use slow motion for the few seconds surrounding the cues, which also helps a great deal.

The car sequences, despite being QTE-heavy, are often cited as some of the best parts of the game. They’re exciting, with a good amount of player agency at work, without the QTE parts breaking the feel of the game. They are their own levels, so there’s a cognitive switch when you encounter them—you know going in that for the duration of the level, you are going to have QTEs mixed in with shooting from the roofs of cars. Like the rest of the game, these QTEs are framed with plenty of reaction time and use logical button choices for the actions involved. Most importantly, these chases are areas where QTE is arguably the best choice to make—navigating jumps from car to car between rounds of shooting under the game’s normal gameplay would be an exercise in frustration; under QTE controls, it’s a rip-roaring thrill ride with minimal frustration.

Wrapping Up

Frankly, as is probably obvious enough from the way I started the post, I expected this to be a short, somewhat rant-y analysis of everything that is wrong with QTE in hopes of stamping out the mechanic entirely. As it turns out, I’ve realized by writing it that it’s not so much QTE I dislike as it is bad QTE, which unfortunately I’d suggest is the rule, rather than the exception. However, I like to think that I’ve helped myself and perhaps some others out there explore and understand better where the problems and pitfalls with this popular technique lie, and maybe even some useful suggestions for using Quick Time Event-style mechanics going into the future.

If nothing else, I suppose I learned something today, which isn’t half bad.

This entry was posted in Game Design, theory. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *