Kory Heath Designs

Katamari Damacy is a game built around a brilliant core concept, but its overarching goal structure nearly ruins the experience for me. Here’s the brilliant part: you push around a growing ball which can grab literally any object in the game world if it grows large enough. Here’s the annoying part: in each of the main “Make a Star” levels of the game, if you don’t grow your Katamari big enough within a given amount of time, you have to start the level over again from the beginning.

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.

More…

My perspective on video games has changed a bit. I used to care primarily about interesting game mechanics, fascinating challenges, and compelling stories. I still care about those things, but nowadays I tend to think of them as means to an end rather than as ends in and of themselves. Nowadays, I care most about the feelings, moods, and emotions that video games evoke, with a particular emphasis on wonder, awe, and mystery. I’ve invented a name for this perspective: I’m calling it evocativism.

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.

More…

Blockhouse is now available on the iTunes App Store!

Give it a download and let me know what you think. I’m working on putting up some solution pages here on the website, but in the meantime, if you get stuck on a puzzle, just post a comment here and I (or someone else) will lend a hand.

Also, I’d like to hear which puzzles were your favorites, and why, since I’m already starting to think about what mix of puzzle-types to put into Blockhouse 2. You can let me know which individual puzzles you liked the best, and you can also tell me which categories of puzzles you preferred. I would divide the puzzles into four main categories:

• Single-block mazes (like puzzles 26-28).
• Single-polyomino puzzles (like 29-32).
• Segmented puzzles (like 33-35).
• Double-polyomino puzzles (like 36-45).

Of course, there are also puzzles that are harder to categorize, like 14-15, 46, 49, etc.

All thoughts are welcome!

By the time I decided that I was going to implement Blockhouse as a commercial iPhone app, the game design was already done. Tilt or swipe in one of the four cardinal directions to cause all blocks to slide as far as they can, and try to put them on their respective targets. What could be easier? Many aspects of the aesthetic design and the user-interface were still up in the air, but I had an inkling of where I was headed: chicklet-style blocks and walls, bright candy colors, minimalist interface. Implementing this stuff wasn’t going to be particularly difficult.

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.

More…

Hi, I’m Kory Heath. Welcome to my new blog!

I have a few year’s worth of pent-up thoughts to share about video game and board game design. Here they come.