Quick time event
A quick time event also spelled quicktime event and abbreviated to QTE, is a video game mechanic where the game prompts the player for input and the player has a limited time to enter it. If the player fails to enter the expected input in the allotted time, typically something bad will happen. Quick time events are quite decisive in the video game community with many gamers being fine with them or even liking them, while others absolutely hate them.
Personal
I never played any quick time event games in my youth as none of the arcades I went to had any LaserDisc games. I remember seeing game play of Dragon's Lair on YouTube but not really understanding what was going on because the game lacks on-screen prompts for most of the scenes. When I was in my 30s, I watched a friend try to beat Space Ace, but seeing him repeatedly die over and over while trying to memorize a lengthy series of inputs put me off the concept. I finally got a chance to play the original Dragon's Lair in the arcade when I was about 42, and I found it severely lacking. Because I haven't played that many console video games after the mid-1990s, I haven't been exposed to any of the later QTE games, so I don't have a strong opinion of the mechanic one way or the other, although, I'm soured on it from how bad the early games were. I'm a bit curious to see how the mechanic has evolved since then, but most of what I've read about them are gamers with horror stories saying how much they hate them.
Definition
There are a few key aspects of a quick time event that exist in most variations of the mechanic:
- The game prompts the player for input.
- The player has a limited amount of time to enter the input.
Having a prompt for input is extremely important to a QTE because is distinguishes the mechanic from other forms of player input. In pretty much all fast-paced video games, the player looks at the position of objects on the screen and responds to them with input without being explicitly prompted by the game to do so. If you don't require a prompt as part of the QTE mechanic, then pretty much every action game becomes a QTE game, making the term useless. Adding prompts for input to an action game completely changes its feel.
Having a limited amount of time, usually a second or less, is also important, not just because the mechanic is called a "quick time" event rather than a "slow time" event, but, also because it helps distinguish the mechanic from those where the player is given a lot of time to make decisions or unlimited time as in turn-based games. QTEs are meant for rapid-paced action games, but, if the player had minute, or even several seconds to provide input for the QTE, the whole pacing of the game would be ruined.
The following aspects are typical of QTEs, but not necessarily mandatory:
- The expected input is clearly conveyed.
- The expected input is not complicated.
- The player is punished if they fail to enter the expected input.
- Quick time events are separated by game play.
In most games which utilize QTEs, the expected input is clearly conveyed to the player with something like a visual prompt showing a down arrow which informs the player they need to press down on their controller. Clear prompts aren't necessary, some of the early games like Dragon's Lair and Space Ace would flash an object on the screen and require the player to infer the expected input based of the object's direction relative to their character, and these are still QTEs, however, game designers quickly realized that players become frustrated when they think the game expects one thing from them, when it really expects another, especially when such little time is given to get it right.
Also, for most QTEs, the input required from the player is not complicated, usually no more than a couple buttons or direction inputs, and frequently only one. While a QTE could certainly be made from a long sequence of buttons and directions, or even several letters on a keyboard, long strings of input usually change the tone of the game. For example, if a game gave the player a short amount of time to type in a sentence or even a word, it would be more akin to a typing tutor than an action game. In fact, The Typing of the Dead does just this, but the mechanic doesn't feel much like a QTE. Also, the input is typically not tied to anything else, that is, the player has to push a specified button to advance, and that's it. The mechanic also won't feel like a QTE if the game expects the player to perform a difficult cognitive task in addition to responding to an on screen prompt, like is common to trivia video games.
Most games which utilize QTEs punish the player for failing to enter the expected input within the allotted time. This is because QTEs often take the place of the more complicated input more commonly used in action games. In the first games to use QTEs, a single missed or incorrect input is completely fatal. Later games were not as harsh and punished the player by having them take damage or sent the player down a more difficult story arc. The radio communication system Firewatch, which functions similarly to a QTE, doesn't punish the player if they fail to respond. The worst that happens is they don't get experience as much of the story line.
A game may feature a few scenes in rapid succession which use multiple QTEs, especially when a game uses them during combat with a boss, but these are usually separated from each other by a length of game play without them. Nothing prevents a game from having a long series of QTEs, one after another, as is seen in the first several games which used QTEs, but frequent QTEs became a rarity by the end of the 1980s. There is another type of game which essentially uses non-stop QTEs, but we call them rhythm games and treat them as a separate genre.
History
Quick time events were created to add input to early full motion video (FMV) games which, due to the way video was stored at the time, could only support very limited player control, typically with only a binary pass-or-fail result. One of the earliest games that could be said to use QTEs would be Nintendo's 1974 electro-mechanical arcade game, Wild Gunman. The game projected 16mm film footage of bandits whose eyes would flash prompting the player to shoot them. If the player failed to shoot them within a brief moment of time, they would lose.
Quick time events were popularized in video games almost a decade later in 1983 by LaserDisc games, the first of which was Dragon's Lair. In this early use of the mechanic, there are several scenes where something on the screen will flash yellow indicating the player must give input. For example, a doorway to the right of the player's character will flash, and the player is expected to push right on the joystick. However, most of the time, the game doesn't prompt the player for input at all, they are just expected to infer when and which input is required based on the on-screen events. Since a QTE requires the game to prompt the player for input, this means much of Dragon's Lair technically doesn't use QTEs. A few months later, Space Ace was released which uses a similar game engine, but the animation uses far more flashing objects to prompt the user for input, thus making it more of a QTE game. However, the player is still expected to infer which specific input the game expects based on their character's location relative to the flashing object. The modern form of explicitly prompting which input is expected from the player first showed up in October 1984 in a similar FMV game, Super Don Quix-ote, which displays arrows and buttons on the screen to prompt the user for specific input. Subsequent FMV arcade games use the similar explicit on-screen prompting as well, like Ninja Hayate released only a month later.
As computers and video game consoles began adopting CD-ROMs, FMV games moved into the home and brought QTEs with them, like 1992's Sewer Shark. In 1996, one of the first non-FMV games, which used QTEs during the cutscenes between action sequences, was released, the beat 'em up Die Hard Arcade, but the first non-FMV game to really popularize QTEs was Shenmue in 1999. Shenmue also had the benefit of coining a name for the mechanic, which was originally called a "quick timer event" in the game's manual, but gamers quickly dropped the "r" from "timer." Over the years, the mechanic has been further refined with later games adding warnings to prepare the player for when a QTE is about to occur and others adding button mashing, where you must hit a certain button a specific number of times for success. The popularity of the mechanic has even caused existing game franchises which didn't initially use QTEs to adopt the mechanic, like Tomb Raider and Resident Evil.
Usage
The prompt of a quick time event is usually visual, however, any type of prompt may be used. A game could use an auditory prompt, where the player must respond to a sound effect, or even tactile prompt where the user responds to haptic feedback. Though, I don't know of any games which do this.
Although early adopters of the mechanic designed entire games around the QTE, most modern games use QTEs more sparingly, usually during cutscenes or during encounters.
Failing a QTE typically results in the player being punished in some way. Many games simply kill the player's character after a failure and force them to replay from a checkpoint. While games that are not as severe may treat a failure as damage and allow the player to fail multiple QTEs before killing their character. Other games which are more story-driven may just send you down a story arc that isn't as interesting and rewarding.
QTEs have long been criticized as a lazy game mechanic for a number of reasons:
- Since they only allow for very limited player input, they can only give equally limited responses, and therefore can't allow for much nuance in game play.
- Failing a QTE often requires the player to replay a large section of the game, like in the boss battles of Bayonetta.
- Designers frequently use QTEs abruptly in long unskippable cutscenes where failure forces the player to have to rewatch the scene from the beginning.
- They're sometimes used too frequently. The early FMV games required players to go through 20 minutes of non-stop QTEs, but you can still see long sequences after designers should have known better, like the 5-minute long QTE sequence in 2005's Indigo Prophecy.
Due to the vitriol raised by gamers, some games allow players to turn off QTEs entirely to ease player's frustration. In these game, where the player would normally be prompted for input, the game just assumes success every time.
One variation is whether the game will fail on additional incorrect input. For example, if the game prompts the player to push up, but they push left, then correct it to up before the allotted time expires, should that count as a success or failure? Some games don't care what other buttons you press as long as the correct button is included somewhere in the sequence. However, this allows the player to simply mash their all of the buttons on their controller to pass most QTEs.
Another variation is to use random input rather an predetermined input. This wasn't really possible for early QTE games since the game's media was pre-rendered cartoons and the directions the player had to press were based on what was going on in the cartoons. However, once games started incorporating randomness into their scripts, it became possible to also randomize the expected input. This made it impossible for a player to memorize the QTEs the way they could with games like Dragon's Lair and added to the complexity of the games.
Implementation
Adding quick time events to a game isn't very difficult. A game designer determines what kind of prompt the game will use (visual, auditory, tactile, etc.), how the player will be expected to respond and how much time they will have, and what will happen if the player succeeds or fails. An artist designs the prompt based on its type (a graphic artist might draw buttons or arrows, a Foley artist might create sound effects, etc.). Finally, a programmer writes the code to display the prompt at the appropriate time, setup a timer, accept input from the player, verify if the input was correct, then punish or reward the player according to the design specification.
Links
