Wednesday, January 14, 2009

Press X to Not Die

The Minigame Court (an offshoot of Chris Bateman's blog Only a Game) currently has Quick Time Events (QTEs) on trial. For the game uninitiated, QTEs encompass any action where the player must suddenly (and sometimes repeatedly) hit a button or series of buttons to preform an action during a non-gameplay moment. It has, perhaps most famously, be characterized as "Press X to Not Die".

You may read the prosecution and defense here:
Vote here:

My comments become so meandering, I decided to post them here.

Quick Time Events for the sake of keeping the player awake are a gross misinterpretation of their original purpose. QTEs were intended to provide game designers a means to include complex, often context sensitive actions, without the benefit of a complex interface or simulation.

Let's go back to their origin: Dragon's Lair. This is a game about simple controls resulting in complex action. To rescue the princess, Dirk (the stalwart hero) must dodge, jump, attack, avoid, and many other action-y things. The interface is a single joystick and a single button. A direction and an action. As the game context changes so does what the direction and/or action mean. But that's okay, because that is all that the game ever asks of you, pick the right direction or action to continue.

Fast forward to today, where in many games you have a wide range of controls available throughout the active gameplay segments. In many 3D platformers, shooters, and action games there are as many as a dozen different verbs given to the player at ANY time via the increasingly complex controllers. Movement on one joystick, camera view on another. Then jump, shoot, use, pick up, drop, equip, etc. The user is expected to do many things through the rich interface provided.

Until the game reaches a cut scene and promptly removes all control. Then the game demands you press a button, or complete an input sequence (sometimes randomly generated), to continue.

The complex control for complex actions is suddenly suplanted by a simple control for a very specific complex action. That sudden shift of interface and control is the killer leap.

Press X for Lazy Design
Truth be told, I don't hate QTEs all that much. I understand (sometimes) why they are used. However, in many cases they are used an excuse to be lazy and not design a better metaphor for interaction.

Case in point: I've just started playing Bioware's Mass Effect. I'm a self-declared Bioware fanboy, but certain choices made in the interface of this game are already starting to irritate me.

Hacking, for instance, is done via a short Simon Says mini-game. A QTE that scales in difficulty with the lock strengths and your skill attributes. And to some small degree it meshes with the metaphor of the task without pulling the user out of the game too much. But at the same time it could have been better. Repeating the sequence steps, as they appear, within the limited time turns the job of hacking into a skill of reflex instead of intellect. Fail to have the reaction time needed and you suffer the penalty of using onmigel (in-game resources) to overcome your failure. It makes me wonder how much I'll simply be relying on omnigel to get things done as I progress through the game.

Alternatively, Fallout 3 uses a system where hacking takes you to a terminal-style screen. You have to examine a jumbled output of data/text/randomness and try to guess the password by playing Master Mind. Words highlight as you select them. Choosing one gives you an idea of how much of it was right. Finding matched braces in the jumble can also help you by removing bad options or resetting the screen. Solving these takes a lot more skill, or sometimes luck, than a QTE, and fits better with the narrative world that it exists in.

My, now much belabored, point is that QTEs are fine so long as they make sense within the interface, context, and overall storytelling method that your game employs. Too often though they are used as gimmicks or cheap challenges to replace real game design. This shouldn't be so. Most of all, though, is the argument that if you are going to include QTEs, then make them a regular part of the game. Introduce them often and use them regularly. Give the players a fighting chance of getting them right, and if they fail, perhaps provide an easy exit so they don't have to suffer your poor design choices to continue.


  1. I think you hit the nail on the head. It's quite a simple lesson that QTEs must fit in with the overall interface scheme. If most of the game A is jump X is shoot etc then the QTEs should fit in that scheme. However for games where most of the buttons are various forms of swing stick, I can't see how it can't end up like a cheesy simon says game.

  2. Damn, if I'd found this a little earlier I could have linked to it. Oh well... nice summary of your position. I know plenty of people agree with you! :)