You Don't "Always Lose" in Tetris: The Real Nature of Single-Player Competition

This article was originally posted last week on my site at keithburgun.net.

It's often claimed that arguing about definitions is a waste of time, but words are also tools that we use to organize and understand reality. This means that sometimes, if we want to make progress in a certain area, it's useful to clarify a term that was previously a bit fuzzy.

I think that we have a lot to gain as game designers by clarifying the words "win" and "lose".  Let's look at some top definitions for the word "lose".

"be deprived of or cease to have or retain (something)"

"To fail to win; fail in"

There is a significant connection between the two major usages of this word.  I lost my car keys and I lost the game have two different meanings, but the commonality between them is that in both situations, there was some potential thing that was taken away.

In games, losing can only be an outcome of a contest - a thing which you had some potential for winning.  If you never had any potential for winning, then there is nothing to be "lost".  A contest must state, "you must achieve goal X by Y date/time, or else you lose".  There can be no do-overs, undos, or quicksaves in a contest - all of these will destroy the test in contest.

To clarify further, a goal must be clear, and not only must winning and losing be possible, but both outcomes should be reasonably likely.  If I were to play chess against a grandmaster player, that would not be a contest because the skill gap is simply too large.  Some astronomically small chance for me to win is not enough to make something a contest, by a useful definition of the word.

Non-competitive interactive entertainment

We tend to use the terms "win" and "lose" in strange ways sometimes.  Recently in a conversation with Ernest Adams he said something along the lines of "the computer's job in a game is to put up a good fight and then lose".  While he later explained that he's not really talking about "competitive games", I find this usage of the term "lose" very interesting and worth talking about.

Discussing all of interactive entertainment (let's call them apps), we can divide that huge space up into competitive and non-competitive games.  Examples of non-competitive apps would be things that you "play with" such as Minecraft or Garry's Mod (which I call "toys"), things that you solve/complete, like puzzle apps (Portal, Professor Layton) or story-based apps (Mass Effect, The Last of Us) - or any combination, such as the modern Zelda titles, which arguably use all of these non-competitive elements.

In these apps, there is no way you can "lose".  Many tend to make the critical error of assuming that "dying" equals "losing", but in apps like those above, it isn't.  Dying in these systems is much more akin to "thinking you found the right jigsaw puzzle piece for this spot, and then realizing it was the wrong piece".  It is not set inside of a contest - there is an unlimited amount of time and do-overs for you to achieve the goal.  It's only a matter of solving, or even simply doing.

Secret of Monkey Island is not competitive, so you don't need permanent consequences. In fact, an undo feature is a plus in a puzzle-app like this one

"You Always Lose In Tetris!"

Obvious examples of competitive apps are those that are multiplayer, such as Chess, baseball, or League of Legends.  In these systems, we all implicitly know what losing and winning means.  Single-player competitive apps are more rare, but Rogue-likes and abstracts such as Candy Crush Saga or Critter Crunch roughly qualify.

This is because Candy Crush's "stages" each have a specific goal, which can be achieved or not-achieved.  There is a limited set of resources (usually, number of turns), and the player has to work within those limitations to try and win.

People often say that you "always lose" in Tetris.  First of all, there can never be an "always lose" situation.  If you really do "always" lose, then there's no possibility for winning, and therefore there can be no "losing".  What have you lost?  Tetris, at least the most common versions of it, fails to have a goal.  We can - and often do - prescribe a goal to it, such as "get more than 100,000 points" or "beat Ted's high score", but we can and do prescribe goals to a rubber ball, too - that doesn't mean that we can "win at rubber ball".  Rubber ball isn't a contest, and neither is Tetris, because neither includes its own goal.  This is in contrast to Candy Crush or chess, both of which have their own goals as part of what those systems are.

Simply "getting a high score" is unqualified to be a goal in a contest, because they are not achievable on their own.  At what point have you gotten a "high" score?  There needs to be some predetermined threshold, otherwise it's impossible to say whether you failed or succeeded.

"The goal is survival" is also similarly unacceptable, because ultimately you're going to stop surviving, and how do I judge whether the length of time that you survived warranted a win or a loss?  Again, we need a threshold.

So I don't consider score to be "the goal" of Rogue-likes.Then there's completion - reaching the "end of the game".  Probably there as a vestigial element from D&D or other "role-playing games", there is actually an end to Dungeon Crawl, Nethack, and even my own 100 Rogues (wherein I can tell you first-hand that the ending is there "because other Rogue-likes had an ending").  This does technically count as a goal, except for the fact that a tiny percentage of players ever come close to completing them.  So only for players who have played hundreds of matches do Rogue-likes become a reasonable contest - and what's funny is, there are players who get so good that they have almost no chance of losing anymore.  There is just a small slice of players for whom "completion" becomes a reasonable contest.

Take a game that I like a lot - 868-HACK by Michael Brough.  It's a really interesting, innovative single-player competitive game that many would call a Rogue-like (I wouldn't; I think it's just an original single-player competitive game, not much more Rogue-like than Tetris or Klondike Solitaire).  It also suffers from the same problem I'm talking about right now.  When I play a game, I really have no way of knowing whether I've won or lost.  The game ends, and I get some number, and I'm kind of like "Ok..."  What does that number mean?

17 Points... is that... good? That's up to you, I suppose.

Why does it matter so much?

Rogue-likes, Tetris, 868-Hack and many other applications are, at their core "decision-making contests".  There is at least a suggestion of a goal, and the mechanisms are arranged in such a way as to make decision-making interesting.

However, due to the lack of a clear goal in any of them, I'm not getting a crucial part of the equation - the win/loss condition.  The win/loss condition matters a lot, because it is the most important feedback for the series of decisions you made during the game.  Decisions in a game are actually only hard / interesting to the extent that they relate to achieving the goal.  If the goal itself is unclear, then it's impossible to really know when you've made better or worse decisions during a game.

The cost, and my advice

The underlying issue is that most of us have difficulty understanding the real nature of single-player competitive games.  We often still think of them as some kind of fantasy simulation, and that holds us back from creating better systems.  There are people who think that Rogue-like games are "punishing" because (essentially) all games end in death.  That's not punishing, any more than the timer running out in a football game is "punishing".  We are very used to playing story-based / completion-based puzzle/fantasy-simuation single-player apps, that I've met serious game designers even who think that the prospect of Rogue-likes is ridiculous, saying things like "it's not reasonable to lose all your progress!"  In reality, they should be thinking of it as "losing your progress" no more than you're losing your progress when a match of bowling ends.

I think we're really undercutting our designs by having unclear or bad goals.  I've played a lot of games that would be great competitive games but for the fact that they lack a clear, reasonable goal.  What this does, in my opinion, is it causes a good amount of tension in the player's brain.  Not the good kind of tension, where the player is deciding between two difficult and interesting choices.  Instead, the player is forced to choose "what am I even trying to do?"  Ultimately, when we present a system with unclear goals to a player, we're actually giving them work - specifically, design work that they have to do.  They make some design call, like "ok, I'll go for beating... 100,000 points, that's my goal", and all the while they have to pursue that, while at the same time wondering if their design call was a good one.  Maybe they'll gain the first 80,000 points really quickly and start to doubt their original goal mid-game, and then have to re-tweak it halfway through.  It's messy and annoying.  Players should be able to focus on playing a really great game.  It's our job as designers to provide them with that.

This is distinct from people who create toys, because toys don't have a suggested goal.  Rogue-likes, for example suggest that there is some survival/killing-monsters/reaching an end point goal, but no clear goal exists.  Compare this to Garry's Mod, or Legos, neither of which suggest a goal at all.

So what I advocate, for anyone making a competitive single-player thing, is something like dynamic difficulty adjustment, except it happens "between matches". Every time the player plays a match, this match will result in either a win or a loss, depending on whether he reaches, say, 100 points.  Abandoning the game results in a loss.  If the player wins, he gains some meta-game experience points.  Eventually, if he wins enough, he "levels up", and now the system becomes more difficult (note: I recommend not scaling up the amount of points required if possible and instead turning other knobs.  The reason for this is that you don't want to penalize better players by having to play longer matches).  If the player loses a bunch of games, he de-levels and the next match he plays becomes less difficult.  I'm working on a system like this for my 4X-style strategy game, EMPIRE.

Or you can do what my upcoming tactics game, AURO, does.  It's partially inspired by things like golf and bowling - here's how it works.  In our Match Mode, you play online against a random opponent of similar skill (like in many online games).  Once the opponent is found, the game generates a random seed for map generation, monster/item placement, etc.  Then both players play that same seed, and compare scores.  They repeat this until one player has won two rounds, and then a winner is declared.

What's nice about this is that we can generate a super-wide set of completely weird and random situations - maybe one level is FILLED with the giant Yetis who will kill you in one shot, or maybe one level is all bouncy slimes that bounce you all over the place.  We don't have to worry so much about balance because even if the player is presented with something way too hard, or way too easy, the question is, who, of the two of you, can score better with what you're given?

The world of single-player competitive games is full of exciting possibilities, but only when we start to understand the medium a little better.  What we've been doing is failing to draw a clear line between competitive apps and non-competitive ones consistently.  We do it when it comes to multiplayer competitive games, but when it comes to single player, we get confused.  When we figure this out, an entire category of games will be dramatically improved.  Single-player competitive games have the potential to be evergreen - games that you can play for years and years, whereas other kinds of single-player games are generally consumed.  This potential for longevity is huge, and the "Dev Hours : Quality Player Hours" (as Dan C put it) ratio is really excellent, so I hope we have a lot of developers working on these problems.