One of my favorite puzzles: Given a barometer, find out the height of a tall building. The pysics answer involves atmospheric pressure differentials and equations, but my friennds and I tried to find other answers to this puzzle:
All these answers were right, though some were more right than others.
I thought Scott's article on puzzles was interesting, but I wish it addressed the migration of a puzzle to a game, as the result of repeat play, as opposed to the puzzles that you experience once or twice, and then move on. One of my favorite pasttimes (I'm ashamed to admit) is the 15-square sliding tile puzzle. I've practiced it a lot and I can solve it regularly in under 30 seconds. To me this puzzle has become a game, perhaps because it's no longer novel, but certainly because, as Chris Crawford would say, I use the clock as an opponent.
As Kim later discusses whether Solitaire is a game or a puzzle, it seems to me that the line between puzzle and game is crossed when a player understands the full mechanics of the structure of the puzzle, while still trying to solve the instance of the puzzle. By this definition, solving a given jigsaw puzzle once is a puzzle, but doing it for the 4th time, presumably to beat some sort of secondary time goal, is a game. Similarly, I would say that solitaire is a puzzle when it is novel, but as the strategies become set it becomes a game to see what percentage of the time you can solve it, instead of whether you have the ability to solve it.
I really liked this article. While reading it, whenever I though "but wait, what about this kind of puzzle? Bob would address it with his next bulletpoint. After reading through the types of puzzles, I couldn't help but wonder if this fully covered the venn diagram of possible puzzles, or just those commonly used in games. I can't quite wrap my head around the puzzle space to see how comprehensive the classifications were, though any example I could think of was covered by one definition, though sometimes more than one, implying a venn overlap.
Bob really spells out the common puzzle-creation pitfalls clearly.
My only regret reading this article is that the puzzle always seems to be a concrete thing inside a game. Each puzzle can be described in a self-contained definition. It seems like most puzzles fall into a 'the game won't proceed until you solve this' structure that, intentional or not, can turn almost any game into a narrative story with locks and keys to advance.
I'm excited by the idea of puzzles without single right or wrong answers, but simply consequences and other consequences. You can do things that fit in with the goals of the puzzle, or things that don't, and you do better or worse as a result. For example, the building of various structures in warcraft or Starcraft can be seen as a puzzle. Given your goals there is an optimal sequence and apportionment of resources, but if you don't meet it you can still do fine. In fact you're probably not even aware when you're on the optimal path: It's simply better than the other paths.
Warcraft building doesn't seem to fall into Bob's puzzle definition, though it's the kind of pervasive, essential puzzle I think may be most effective in a game. This puzzle overlaps completely with the entire gameplay, though it can be abstracted from the fighting and positioning aspects of the game. In my opinion, the downfall of so many puzzles are that they make the player switch into another mode. They're not just playing the game, but they're playing the game where the character they're playing has to solve a puzzle now. Maybe the best puzzles are those so ingrained into the game that solving them simply means playing the game better?
Reading the first paragraph about dropping the player into action before filling in the world and player's backstory reminded me of the movie Resident Evil. There the main character has lost his memory and gradually gets it back over the course of the movie/game. (If you haven't seen it, this movie was essentially like watching someone play a strategy FPS).
I like what Bob has to say, but it's not easy to drop someone into an FPS with no training and expect them to survive. Most FPSes have a training regimen, "Oni" being an excellent example. I wish Bob addressed how to have the user steer their character through training, then justify the plot where they're suddenly in hostile territory, when a moment ago they were on a training level.
I almost never pay much mind to cut scenes beyond the relevant plot points they portray and the pretty pictures. When I see the buff CGI model that represents the 2.5D sprite I've been tooling around the mesa, I almost never relate the two to each other. If anything, it makes me wish that the whole game could be like the cut scene, and I'm disappointed when I go back to my little simulcrum after seeing the rich 'real world' of that story. Am I alone in this?
I've never read any books or articles on game design before. Both Bob's article on designing puzzles and on plot seem so completely relevant and 'oh duh, why didn't I know that?' that I'm really pretty amazed. He really gives a good treatment of the structure behind gameplay, without pushing me on a path of the 'right game' that would resemble the game anyone else would make after reading this chapter. I think I'll buy the book.
This week's classes got me thinking a lot about why I like the games I like. When I sat down to work on my dice game, I took out my write-up of my five favorite games and isolated the particular traits that make those games my five favorite. I used this list of traits as a starting point for making my game.
I'll save the full write-up of those traits and the game's evolution for my project write-up, but it really got me thinking about the puzzle of the game structure vs the puzzle of playing against an opponent. When designing my game I wanted to apply at least two simultaneous puzzles in the hopes that, as a player's understanding of the game's structure (what I'd call the game's inherent puzzle) increased, the game remained playable because the weights and balances within the game were dynamic.
Fluxx is a great example of this kind of mutating structure. No matter how often you play, the game can fall into gameplay states that the player hadn't seen. Creating my (as yet unnamed) dice game, I tried to emulate that, so that with a minimum of structure, there was still a great deal of subtlety.
I haven't written about Nine Men's Morris much if at all yet, but that game was amazing to me because my father and I learned it at the same time, and would only play against each other. We would learn attacks, counterattacks, and so on, and whenever we thought we'd defeated the game by creating a play-first, assured-win strategy, the other would come up with a defeat. Like cat's cradle in its evolutionary complexity, I was amazed by its emergent properties.
(stream of consciousness in full effect) That's what I'm really after: Chaotic games. Not games filled with mayhem, but games that have extremely simple structures, but gameplay that can get incredibly deep by virtue of the strategies of the players. Go, Pente, Chess and Assassin (the one where you try and 'kill' people in the real world) all have simple rules, but deep latent structures.
As I mentioned in an earlier essay, my favored way of making a game is to find that kernel, that seed to build off of and design around, balancing if need be, to create a game that can make even expert players go "aha! I hadn't thought of this solution". After making that, I plan on finding a metaphor that fits the structure of the game and building a theme for the game using that metaphor, to make the game more appealing and accessible to wider audiences.
This class is so fun, and though I assume I'm preaching to the choir, each week I'm finding that the strategies for designing games apply to designing anything interactive. Make it accessible, make it engaging, make it responsive, and make it make you smarter. This is cool stuff.