It’s easy to turn a fun, sandboxy pastime into a game by adding a time-pressure to it, but that’s almost always the least interesting way to do it, and it usually has negative side-effects. For instance, Katamari’s final level is 25 minutes long, and most players will need to play through it multiple times in order to win. At the end of my first 25-minute attempt, my Katamari wasn’t even close to the goal of 300 meters. That was okay—at least I’d gotten the lay of the land, and had a better idea of what I needed to do. When the timer ran out at the end of my second attempt, my Katamari was 298 meters large, and rolling at high speed toward a juicy island full of skyscrapers. Oof. Now all I have to do is spend another 25 minutes doing the exact same thing I just did for the last 25 minutes, but a tiny bit faster. This is not good game design.

There’s a more emergent negative consequence of this goal-structure: if you get off to a bad start in a level, you can know before you’re even halfway through that you can’t succeed. In such a case, playing out the rest of the level feels like a waste of time. This is analogous to playing through the last painful stretch of Monopoly when it’s obvious that you’re going to lose. Since Katamari Damacy is a single-player game, I can at least quit and restart without annoying a bunch of other players. But if I’m doing this on almost every level, there’s something wrong with the game design.

The designers of Peggle were faced with a similar design challenge. In Peggle, you’ve got a pachinko-machine screen full of pegs, and you’ve got ten shots to try to hit all of the orange ones. On the surface, this feels nothing like Katamari Damacy, but in fact, the two games bear a deep structural similarity. In Katamari Damacy, you’re trying to collect a given amount of stuff in a given amount of time, and in Peggle, you’re trying to hit a given number of pegs with a given number of shots. The games share a pair of design problems: how do we make it fun to replay levels after failing, and how do we keep players from sometimes feeling hopeless halfway through a level? Peggle’s designers actually managed to solve these problems.

They solved the first problem by randomly distributing the orange, blue, and green pegs at the beginning of each level. The physical layout of the pegs is the same each time—that’s what defines the level—but the distribution of peg-colors within that layout is different each time you play it. You never really play the same level twice, because each replay presents you with a unique situation that you’ve never seen before. Studying the initial layout of a Peggle level is fun in the same way that studying the initial layout of a Settlers of Catan island is fun.

And then there’s the Free Ball Bucket—a steely well that sweeps back and forth across the bottom of every level. The first time I played Peggle, I wondered what it was. After a ball fell into it, I understood, and thought “I wonder why the designers did that?” A few turns later, I realized that it was a brilliant solution to a serious design problem, and is in fact the key to making the whole game work. No matter how badly you’re doing in a level—no matter how many shots you’ve wasted on poorly-aimed or ill-conceived plans—it’s always possible, in principle, that the Free Ball Bucket will save your ass and keep you going long enough to mop up the remaining stragglers. In fact, the more dire your situation, the more glorious your comeback will be if you manage to pull it off. That’s top-notch game design, and like all non-band-aidy design solutions, it doesn’t just solve the immediate problem at hand, but ends up adding strategic depth to the entire game.

There’s no easy way to apply Peggle’s design solutions to Katamari Damacy. I don’t think that randomizing the item layout at the beginning of each Katamari level would improve the game, and while it might be nice to have some way to increase your timer in the middle of a level, it’s still hard to think of a way to do this that’s always capable of providing hope and that improves the fundamental gameplay. I don’t have a good solution to offer for Katamari’s design problem, but my design experience tells me that there there must be a solution—in fact, multiple solutions—out there. The key is to insist on looking for them.

I don’t mean to argue that Peggle is an objectively better game than Katamari Damacy. Katamari Damacy is brilliant. I love the music, I love the art, I love the writing, and I love the gameplay. I just wish the designers had found some way of avoiding the “do it within X minutes” paradigm.

I’ve appropriated the word “evocative” in the same way that expressionism appropriates the word “expressive”. All painting is expressive, so it seems presumptuous to label one particular style expressionist. Similarly, all video games—even Tetris—evoke emotions. However, games like Myst, Another World, Silent Hill, Ico, Shadow of the Colossus, Knytt, Cloud, flOw, Flower, Portal, Braid, and Osmos seem to put a primary emphasis on evoking certain kinds of feelings, moods, and emotions, and that distinctive focus is what I’m referring to as “evocativist”.

One of these days, before I starve to death, I’d like to try my hand at designing and implementing one of these evocativist games. My approach would exhibit:

• An emphasis on exploration and discovery.
• An emphasis on evoking a sense of wonder, awe, and mystery.
• An emphasis on natural environments and natural ambient sound effects.
• An emphasis on minimalism and non-verbalism.
• An emphasis on “artificial life” over “artificial intelligence”.
• A de-emphasis on pre-designed narrative.
• A de-emphasis on violence.
• A de-emphasis on frustration.
• An emphasis on procedurally generated content.

None of these characteristics is essential to my definition of “evocativist”. These just happen to be the characteristics I’m interested in focusing on. Each deserves multiple blog-posts, but here are a few introductory thoughts, just to get the ball rolling.

Exploration and Discovery

This is kind of a no-brainer. Computer games are better than any other artistic medium at creating experiences of exploration and discovery, and, arguably, they’re better at it than they are at creating most of the other kinds of experiences that games try to create. Although the most obvious type of exploration involves moving through a (virtual) physical space, you can also “explore” a game’s mechanics and their dynamic consequences. Portal involves the physical exploration of the Aperture Science lab, but it also involves an exploration of how the portal guns work, and what you can do with them. Even ignoring the “story”, the character of GlaDOS, and the subtext of escape, exploring the dynamics of the portals can evoke a sense of wonder.

Wonder, Awe, and Mystery

There’s a prejudice that states that games are not good at evoking emotion in general. However, games about exploration and discovery almost always evoke a sense of wonder for me, at least to some degree. Games are good at evoking a sense of wonder. In addition, I think they’re good at evoking a sense of loneliness, isolation, and desolation. And recent games like Flower show that they can be great at evoking a sense of exuberance and joy.

Video games have traditionally been bad at evoking complex social emotions. Paintings and symphonies are also bad at this, so our medium is in good company. Many designers are interested in cracking this problem. Although I’m interested in seeing what others come up with, I’m not interested (at the moment) in working on the problem myself. I’m willing to let novels and movies deal with complex social emotions, since that’s what they’re good at. If a computer game can evoke anything like the emotion I feel when looking at the ocean, or a tide-pool full of sea anemones, or the Grand Canyon, or the night sky, that fully justifies it as an artistic medium. (See Flower and Osmos.)

Nature

Wikipedia says: “Characteristics of Impressionist paintings include visible brush strokes, open composition, emphasis on light in its changing qualities (often accentuating the effects of the passage of time), ordinary subject matter, the inclusion of movement as a crucial element of human perception and experience, and unusual visual angles.”

“Ordinary subject matter” is not a logically necessary item on this list. There’s no technical reason why Monet couldn’t have used “visible brush strokes”, “open composition”, and “emphasis on light in its changing qualities” to paint pictures of rotting corpses. But practically speaking, artists who are inclined to use those techniques are probably also going to be inclined to paint scenes of natural beauty. Similarly, game designers with evocativist leanings are probably going to be inclined to focus on beautiful natural environments (Shadow of the Colossus, Flower), or game mechanics that exhibit nature-like dynamics (flOw, Osmos).

I don’t really need to elevate this into a matter of principle. I haven’t played Left 4 Dead, but it seems to exhibit some evocativist tendencies. The movie Blade Runner presents an evocative non-natural environment (although there the absence of nature is part of the point). I’m happy to chalk up my interest in natural beauty as a personal (and maybe even temporary) artistic preference.

Minimalism and Non-Verbalism

More artistic preference here. There’s no technical reason why an evocativist work couldn’t be wordy and baroque. But in practice, aside from completely text-based works of interactive fiction, virtually all of the evocative experiences I’ve had while playing video games have happened while the game was staying the hell out of my way and letting me wordlessly experience something. I enjoy silent protagonists, and many of my favorite games contain companions that either don’t speak the player’s language, or don’t speak at all. I hate explanations. I’m a big fan of silence in general—aurally, narratively, and expositionally. And when it comes to game mechanics, I’m fanatical about simplicity and elegance.

Artificial Life

This idea goes hand-in-hand with the previous one. I find it significantly easier to connect emotionally to characters in video games who mostly don’t speak but act in procedural and life-like ways, than to characters who do speak (whether or not they also act in life-like ways). Somehow, attempting to simulate dialog just shatters my suspension of disbelief. I think the technology just isn’t there yet. I view Yorda in Ico, and all of the beasts in Shadow of the Colossus (including the horse), as instances of artificial life rather than artificial intelligence, but maybe that’s a meaningless distinction in the game-development world.

No Pre-Designed Narrative

This is a tricky one. Years ago, when I loved text adventures and LucasArts games, I thought I loved story. Now I almost consider myself to be anti-story, although that doesn’t really capture the truth, either. I do know that in every one of the “evocativist games” I listed above (except probably Portal), I find the “plot” or “story” (if it exists) to be the weakest element of the game—at best irrelevant to my emotional experience, and at worst an eye-rolling distraction.

I do like the idea of creating a game environment in which events occur that players later spin into narratives. I don’t like the idea of drama-managers. I do like the idea of a game that provides a succession of relatively short (and probably procedurally generated) play experiences with beginning, middles, and ends, rather than one long slog through a pre-designed campaign. I like the idea of providing an overarching narrative context for such an experience, but I don’t like the idea of providing a (pre-designed) narrative spine along with lots and lots of (also pre-designed) side-quests.

I have a lot more thinking to do about this one.

No Violence

It’s hard to talk about this one without sounding self-righteous, so let me first say that I have no moral problems with violence in video games. Instead, I have two non-moral problems with it. First of all, it’s boring. It’s been done to death (no pun intended). The world doesn’t need yet another person (me) making yet another game about killing stuff. But secondly, and more importantly, killing stuff in video games evokes certain feelings. These feelings aren’t “wrong”. Maybe they’re even cathartic. But they’re also in conflict with the kinds of feelings that I want to evoke in my own hypothetical game (like joy, wonder, etc.), so they actively work against my primary purpose.

Once again, this isn’t a matter of principle. Shadow of the Colossus is one of my favorite games, and it’s pretty violent. The game evokes a sense of desolation, isolation, and despair in me, and that’s partially due to the game’s violent gameplay. I’m totally ok with that. But those aren’t the kinds of emotions I’m interested in evoking. If it turns out that the best way to evoke some particular emotion that I’m going for is to allow (or force) the player to kill something, I’ll do it. But I’m not interested in filling my world with things to shoot, stab, or head-stomp, just because I can’t think of anything else engaging for the players to do while they’re exploring.

No Frustration

The ubiquitous fail/redo paradigm is my least favorite aspect of video games. I can’t stand making two successful jumps, failing to make the third jump, and then redoing the first two jumps in order to try the third one again. I’ll admit, it’s hard to see how to avoid this in a game like Ico. The roguelikes represent a theoretically sound alternative, but permadeath is frustrating in a different way. My general take is to start with the Rogue model of playing in a procedurally generated world in which all player’s actions are irrevocable, but make it so that the gameplay doesn’t revolve around killing, and the player can never die (thus eliminating the frustration of permadeath). Of course, this leads to the central game-design challenge of coming up with something interesting for players to do in such a game.

Procedurally Generated Content

I’ve sort of talked about this one throughout, but to recap: I’d like to create games which procedurally generate worlds to explore and play in, and which provide relatively short (say, 1-2 hour) play experiences with beginning, middles, and ends, but which involve styles of gameplay which are different than those found in the typical Roguelike or side-scrolling platformer. It would require multiple blog posts to explain why I’m interested in this, but the short explanation is that I see a lot of potential for creating emotional and atmospheric experiences with proceedural “vignettes” rather than long, designed experiences.

Of course, that explanation hides a host of technological and conceptual difficulties. Not only is it very difficult to procedurally generate compelling game spaces, but the game-design challenge of coming up with compelling things for the player to do within these spaces may be even more difficult. Nevertheless, this is the territory I’m interested in exploring.

I knew that the hard part was going to be actually designing 100 unique puzzles. The only way I could think of to do this was to create some kind of puzzle-building tool that would allow me evolve, tinker, and tweak these puzzles into shape. As it turns out, I spent about six weeks on this task before I even wrote a line of iPhone code. The result was a rather clunky but serviceable OS X app called BlockhouseBuilder.

This was the first time I’d ever implemented a Mac app. Indeed, I’d only been using a Mac since about May of 2008, which is when I’d jumped into iPhone development with both feet. I knew there was going to be a bit of a learning curve. My goal was to make a fully-functioning document-based app, which would allow me to edit puzzles in groups of 100, save them, cut and paste them, undo and redo all editing actions, etc.

None of that was easy, but nevertheless I managed to cobble together an editor that allowed me to create and edit the layout of walls and blocks within a puzzle. It also allowed me to choose the grid-size of each puzzle, and I wrangled for a while about what range of sizes I should allow. Eventually I decided on an aspect ratio of 3:4 for all puzzles. This fit the screen of the iPhone well, leaving some room at the top for UI buttons. It also allowed for a nice range of puzzle sizes: 3×4, 6×8, 9×12, 12×16, and so on.

The really hard part was coming up with some way of displaying the abstract structure of the puzzles I was creating. I wanted to actually see the “puzzle-graph”—a visual representation of every possible position that the blocks could get into, along with the connections between them.

This turned out to be a tough nut for me to crack. There are algorithms for displaying arbitrary graphs, but they aren’t simple, and they often result in winding connections and crossed lines. I wanted all of the orthogonal relationships between states to be retained—in other words, if you can get to one puzzle state by swiping to the right, I wanted that state to appear directly to the right in the puzzle graph. I suspected that someone had already solved this graphing problem—if not for tilt-mazes, then for something isomorphic to them—but I didn’t know enough about graph theory to know where to look, or even to know for sure that what I wanted to do was possible in all cases.

I tried a number of different methods—even some evolutionary ones—but none of them quite did the trick. After working on the problem full-time for almost a week, I started to panic. What if the solution was simply beyond me? I couldn’t afford to keep pouring 8-hour days into it, and yet I couldn’t see how to do what I needed to do without it.

Fortunately, an new idea occurred to me involving a mix of two different techniques I’d tried earlier. I tried arranging all the puzzle positions along horizontal and vertical “struts” or “dowels”, like the beads of an abacus. Each strut contained all the puzzle positions that were connected to each other horizontally or vertically. Each puzzle position was connected to exactly one horizontal strut and one vertical strut. This created a large connected mesh of all the puzzle positions. This mesh was often too compact, overlapping itself at many points, but I could fix that by iteratively pushing the struts away from each other until no two horizontal or vertical struts lay on the same line. The result was a fast algorithm that displayed a flattened, 2D representation of the entire layout of a puzzle, with all orthogonal connections intact. Success!

Here’s a screenshot of BlockhouseBuilder in action, displaying puzzle #16 from the release version of Blockhouse.

The lower left portion of the window displays tiny images of all 100 puzzles and allows me to move between them, change their order, or cut-and-paste entire puzzles from one slot to another. The upper left portion of the window displays a close up of the selected puzzle, which allows me to add and remove blocks and walls, and change their colors. The main window displays the graph of all possible positions that this puzzle can get into, including the starting position (outlined in blue), the ending position (outlined in yellow), and the shortest path between them (represented by the weird black arrows). I can select any starting and ending positions in the graph, and it will instantly show me the shortest path between those two positions. I also created some buttons that automatically find the ending position that’s furthest away from the current starting position (in number of moves), the starting position that’s furthest away from the current ending position, or the longest path between any two positions in the entire puzzle. This was helpful, because in general I wanted the starting and ending positions of a puzzle to be as many moves apart as possible. Finally, I created a button that allowed me to export the collection of 100 puzzles to a property-list file, which I could then include in the iPhone application bundle.

Once I solved the graphing problem and implemented the above functionality, I started adding other features that I knew I was going to need in order to design 100 interesting puzzles. First, I added a bunch of criteria that all puzzles had to meet in order to be exported. Most importantly, all puzzles had to be “connected”. In other words, for any given puzzle, it had to be possible to reach every puzzle state from every other puzzle state. I wanted every puzzle to remain solvable, no matter how you moved the blocks. I did include a reset button in the final game, but it’s always optional. Mostly, it’s there so that people can easily input the online solutions when they give up on a puzzle, but sometimes it’s just nice to get a fresh start on a puzzle when you’re stuck in a rut.

I also implemented some other criteria. For instance, I didn’t want the starting blocks to obscure any portion of their destination footprints. I planned on representing the block destinations using painted marks on the floor of each puzzle, and I wanted these marks to be visible at the beginning of each puzzle. There are plenty of perfectly good puzzles in which two blocks (for instance) swap positions, but I decided to disallow these. Beyond this, there are other criteria that are too obscure to even bother describing.

I didn’t know what percentage of puzzles would still be valid after pruning out all of the ones that didn’t meet my criteria. There was some risk that it would be very low, which would make it a lot harder to come up with interesting puzzles. Fortunately for me, this turned out not to be the case.

After about six weeks of working on BlockhouseBuilder, I was finally ready to actually start working on the iPhone app that would read the property-list file and let me play the puzzles I was creating. The bulk of that work took about a month, and then I spent another couple of weeks integrating the two, adding more features to BlockhouseBuilder as the iPhone app required them.

When it finally came time to start designing all 100 puzzles in earnest, I still felt pretty overwhelmed by the task, even with my fancy new tool at hand. Therefore, I added an “Evolve” button to BlockhouseBuilder. This button caused the program  to create thousands of variations of the layout of the current puzzle, looking for various criteria, like a particular ratio between the longest path and the total number of positions. With the click of a button I could have the program spit out a random variation of the current puzzle that was “better” in some way. Determining what counted as “better” was a black art, and I didn’t bother building a UI to tweak these values, because I had no idea what variables I should even be tweaking. Instead, I just kept changing the actual code for the “Evolve” button, recompiling BlockhouseBuilder, and playing around with the results. So I’d set up the basic situation—the size of the grid, the shapes of the blocks—and then I’d start hitting this button over and over again, cranking out a ton of evolved variations. Of course, on top of this I did a lot “artificial selection” (i.e. tossing out results that were unacceptable for various reasons), and manual high-level tweaking.

It was kludgey, but it worked. Exploring the puzzle-space in this way was fascinating, and because of the evolutionary nature of the process, I didn’t automatically know the solution to each new puzzle that I came up with. Not only did this allow me to play (and enjoy) hundreds of these puzzles myself, but it allowed me to directly test how difficult various puzzles were. It also allowed me to answer a few questions I’d been curious about for years. For instance, what’s a good ratio of path length to total number of puzzle positions? I found that it was somewhere between 1:2 and 1:3. In other words, if it takes 15 moves to solve a puzzle, I wanted there to be about 30 or 40 total positions in the puzzle. How hard do puzzles get as you increase the total number of positions? I found that 100 total positions is usually too hard. Most of the puzzles that I included in the final product have between 30 and 80 total positions. On the other hand, there isn’t a one-to-one correspondence between total number of positions and difficulty. I found some 40-position double-block puzzles that I was incapable of solving after multiple hours of trying.

As I explored the space, the puzzles I came up with fell into four distinct categories, each of which had its own flavor. The most basic type of puzzle contained only a single square block. These puzzles were only interesting on grid-sizes of 9×12 or larger, and I decided that they should all be explicitly maze-like. As it turns out, my evolutionary process wasn’t very good at coming up with maze-like puzzles, so I had to do a lot of manual editing on these. Another type of puzzle contained only a single polyomino. These puzzles were also only interesting on grid-sizes of 9×12 or larger, but unlike the puzzles in the previous category, these puzzles didn’t work well as mazes. Instead, they worked well in more open spaces peppered with single-square walls. Another type of puzzle consisted of two or more single-square blocks, each in its own walled-off compartment. These had a unique flavor, and were too difficult if larger than 6×8. The fourth type of puzzle consisted of two polyominoes together in the same compartment. Most of these puzzles were way too difficult if larger than 6×8, but they became easier if the blocks were large, because large blocks fill the space and cut down on the total number of positions possible. This was my favorite type of puzzle, and they make up about half of all the puzzles in the final product.

All in all, it was a fascinating project, and I hope some people get a kick out of the result. You can count on seeing Blockhouse 2 at some point. The puzzle-space is huge, and I’ve got BlockhouseBuilder burning a hole in my pocket…