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…

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…