I'm not going to take up your time today to tell you what I thought of Limbo; if you want to know how I would review it, you can just read either of Mitch Krpata's pieces about it (1 / 2) as they say almost word-for-word what I would have said if it was my job to review games. Instead, I want to examine Limbo from a game design standpoint. I feel that the game fails pretty dramatically from a gameplay standpoint, but I'm not interested in just listing reasons that I didn't like it. Instead I want to use Limbo as a learning tool, a way to demonstrate some ideas about game design - and especially puzzle game design - that I find to be particularly important.
I'm going to look at four particular areas here: the importance of clear/coherent rules, the importance of clues, the importance of respecting the player, and the necessity of context.
Lesson 1 - Rules Are Important
Limbo kills the player frequently. A great many of these deaths could only be avoided with prescience, dumb luck, or superhuman reflexes. A game in which the player character dies frequently is not necessarily bad, but one in which the player character dies because of poor communication most definitely is.
Communicating the structure and rules of a game is of vital importance. Imagine trying to play a game of Risk without knowing that the defender (typically) rolls less dice than the attacker; imagine trying to play a game of Tetris without knowing that filling up an entire line clears that line from the screen. You would figure it out eventually, sure, but it basically renders the game you've played up until that point useless, since the real beginning of the game is the point at which you actually understand what's going on.
Limbo takes this one step further though by constantly changing the rules. Imagine that you've decided to attack an opponent in Risk because you know the numerical advantage favours you. You win the first battle, but your opponent still has troops left so you attack again. Only this time, after you've declared your attack, an observer suddenly informs you that on this roll, the defender gets extra dice. Limbo has a puzzle that does exactly this - two identical looking platforms just a few feet apart operate in entirely opposite fashions; one of these platforms will kill you if you step on it so you must jump over it, while the platform a few feet away will kill you if you don't step on it.
Lying to the player and arbitrarily changing rules is not clever, it is cheating. Games are about rules; they are about players learning those rules, and how they affect the structures within which the player must work, and then figuring out how to apply those rules to achieve some sort of desired result. Arbitrary rules may work well for a prank (see: the quite funny Mornington Crescent) but they are the death knell of good gameplay. Rules are what hold a game together. Without them, you just have a bunch of unrelated experiences stuck together by a similar aesthetic.
This is not to say that mechanics can not be changed part-way through the game. Braid changes one major rule in every single world. There are two key differences though. The first is that Braid explicitly tells you when you have changed rules with the introductory puzzle in each level, which is a simple demonstration of the new idea. The second is that within each world, the puzzles all build on that idea. Once you have learned what the idea is, the remaining puzzles require you to apply that idea in varying, often challenging ways.
My criticism is also not meant to say that there's anything wrong with throwing new things at players. Metal Gear Solid 4 packs in more gameplay ideas in each of its five chapters that most games do in their entire running time. But with a few exceptions for minigames, these ideas all operate within a defined, understood, and consistent set of mechanics and logic, which means that the player is able to learn how to accomplish later tasks by understanding and completing previous ones.
[Good] Puzzles Have Clues
This is a personal pet peeve of mine, one that applies to many games other than Limbo, but one which is drawn into especially sharp relief by Limbo's arbitrary shifts of logic. A puzzle should be made up primarily of two things: a defined goal, and clues as to how that goal might be achieved. Sometimes figuring out what the goal is is itself a puzzle, and that's OK, but in that case there should also be clues to point the player in the right direction and it should absolute be clear that there is a puzzle.
Limbo frequently ignores this basic premise of puzzle-solving, largely through its constant unexplained changes in logic and mechanics, but also by frequently killing the player with little or no warning. There is very rarely any information anywhere on screen that would indicate to the player what might or might not work. The only way to solve most of the "puzzles" in the game is to die at them, often several times. This is partly a mechanics issue, in that the game often asks for a level of precision that I found unfair, but it is also a puzzle design issue in that the player must typically just keep trying different things until they stop dying.
This all goes back to communication, something that Limbo is either unwilling or incapable of engaging in. Perhaps some of the best examples of how a puzzle is done right can be found in the original Myst, which I count among my favourite games. Everything that happens in Myst makes sense, partly because the world is consistently logical, but also because, so long as the player is thorough and attentive, the game almost always provides them with enough information to solve the puzzle.
One of the earlier, simpler puzzles from Myst as an example: there is a spaceship that the player needs to enter, however it appears to be unusable in its current form. The player notices the first clue, that there is a wire running from the ship to another location on the island. Following the wire, the player reaches a device with various buttons to interact with. Pressing these buttons, the player sees that each one adds a specific amount of voltage to the machine. This clues the player in to exactly what they are trying to do, which is provide enough voltage to power the ship. The game reinforces this by blowing a breaker if the player puts too much power in (which the player must then find and reset).
But how to know what is the right amount of power to provide? Brute forcing the solution could work, but it might take a while. Luckily, the attentive player has earlier found an item which indicates that at some point they will need to set a device to 59 volts. Putting all of these clues together, it only takes a brief amount of time to do the arithmetic and get the machine running.
This is perfect puzzle design - the player finds an objective, finds the puzzle which will complete the objective, and combines clues found in various locations with some logical thinking in order to come to the desired result. By making it clear at all times what the player is trying to do and by not hiding critical information, they are able to determine the correct course of action and are unlikely to spend time chasing after fruitless ideas in the hopes of eventually hitting upon something that works.
A number of other games have done this well. The riddles in Silent Hill 2 & SH3 are well crafted, as are the puzzles of the Professor Layton games. The keys are to let the player know what the objective is and then give them clues to put together.
Lesson 3 - Respect The Player
This is a lesson that I think is best exemplified in the approach of two designers - Sid Meier and Jonathan Blow. The first part comes from Sid Meier of Civilization fame, and I think it's an extremely important point to keep in mind during game development. One of Sid's rules is that "The Player Should Have The Fun, Not The Designer Or The Computer" (see: http://www.gamasutra.com/view/news/23458/Analysis_Sid_Meiers_Key_Design_Lessons.php).
Limbo often seems to be going in the opposite direction. While playing I frequently got the feeling that the people making the game sat around trying to come up with ways that would be interesting for them to kill the player character. I constantly felt like I was being killed not because it improved the game for me in any appreciable way, but because the developers wanted to show off.
I felt the same way about the puzzles and the fact that the game was constantly introducing new rules and ideas for no apparent reason. Why does the last 1/5th of the game rely on gravity switching puzzles? What do those puzzles have anything to do with the parts that came previously? They, like the rest of the puzzles, felt like they were there because the designers wanted to show off - "Look, we can do this too!"
This all goes back to something that Jonathan Blow has said, which is that when designing games we should respect our players and their time (no direct link on that one, sorry). Those arbitrary, constant deaths are disrespectful of my time - they require that I do the same thing repeatedly even though it provides no real benefit to me. This is a waste of my time. I don't buy games to see how great and amazing your ideas are, I buy them so that I can have an interesting experience.
It isn't difficult to respect the player without compromising a game's challenge. Braid and Professor Layton both accomplish this beautifully by rarely requiring the player to complete one specific objective in order to continue; the player must always be completing some objectives, but instead of banging their head against the wall trying to solve one puzzle they just can't get, both games allow the player to simply work on other puzzles until they're ready to give the old one another go.
While it may occasionally work to pit the player and the game in opposition to each other, as in the board game Pandemic, the odds should still generally be in the player's favour; the game, which is just a bunch of code and neither gains nor loses anything based on the result, should only have whatever advantages are necessary to make the experience more interesting for the player. If the game gets advantages just for the sake of making things difficult, something has gone wrong.
Lesson 4 - Context Matters
Limbo never gives the player any indication as to what they are doing or why they are doing it (the tiny throwaway blurb in the game's description notwithstanding). Throughout the experience I had absolute no idea where I was or what I was there for. This is one of the reasons that the puzzles seemed so haphazard. If the game took place in a consistent universe it would likely have to operate under a consistent set of rules, and the existence of all of the challenges would have to have at least some kind of internal consistency to them.
I know that a lot of people are interested in the idea of HUD-less game design, of not having tutorials, and of not putting story in games. To me, Limbo is a perfect example of why these ideas may sound good in theory, but just don't work in execution. I did not even remotely care what happenned at any point in the game, because, by providing the player with literally no context, nothing really happenned. The entire experience was just a set of disjointed ideas layered beside each other.
It started at some point, it ended at some point, but it didn't seem to matter where. The game could have started five chapters in and it could have ended five chapters sooner. Or any other random number. It just doesn't matter.
Context provides for coherent narrative, clearly, but it also provides for clearer gameplay. If the player knew where they were, what they were doing, and had at least some idea why they were doing it, then the game would seem like a cohesive whole and not disjointed set of ideas stuck together. This context, in the form of narrative, helps players make sense not just of the game's story and character, but also of its rules and objectives. I strongly feel that if Limbo had provided the player with better (or any) context for what they were doing, it's far less likely that some of the other problems would have occurred.
Games don't need to have in-depth character motivations or lengthy cut-scenes, but they do at least need to set the stage. Shadow of the Colossus, for example, has very little actual narrative, but it does make all the key information clear - you're there to revive a girl, you must do so by slaying several large creatures, and these creatures exist in a land that was previously inhabited but has since been abandoned and locked away. This is great - I now know what I'm doing, why I'm doing it, and where it's happenning. I not only become invested in the action because of that, but I'm better able to understand it as well, which means I'm able to make sense of what's going on throughout the game and apply that understanding to the way that I play it.
From these smaller lessons, I think there are two larger lessons that are worth noting. The first is that consistency provides a sense of cohesiveness that is necessary from both a gameplay and a narrative perspective. The second is that it is important to communicate effectively to the player. There are many possible ways to communicate, but not communicating at all is not ambiguity, it's laziness, and it's also poor design.