Game Design Sketchbook

Game Design Sketchbook: Testing the Limits of Single-Player

Jason Rohrer | 8 Aug 2008 17:00
Game Design Sketchbook - RSS 2.0

The discussion of AI adds a final wrinkle to include in this article's fundamental question, which I will now pose explicitly here:

Can you make an AI-free, randomness-free, physical-challenge-free, single-player game with gameplay depth akin to that of Go?

Is there any hope for the single player art game that seeks to provide that kind of depth at the gameplay level?

I now firmly believe that the answer is "no." The proof comes from considering how one might go about winning, or doing well at, such a game. If there is a single, optimal path to victory, then systematically finding that path is the main task in the game. Once the path has been discovered and documented for future use, the game's depth is exhausted. If there are multiple possible paths to victory, finding the rest after you've found one is an optional act of completionism, an exploration of mechanical depth.

So that's my answer to that question. But my answer to that question didn't stop me from trying to make such a single-player game anyway.

I've tried to create the deepest possible single-player, abstract strategy game that I could. I went with a score for a success metric, because a binary win/loss condition felt too much like a straight puzzle.

The main thing that I noticed during the design process was how incredibly hard it was to wring even the tiniest bit of depth out of any single-player mechanics. I tried out many possible mechanical systems, but most revealed degenerate cases that led to infinite scores or trivial strategies that led to nearly optimal scores. Even after ironing out these problems, it was often easy for me to find a strategy for doing well at the game and then be unable to improve upon that strategy through modification. Adding more layers of mechanics didn't ever seem to help the gameplay. In the end, after finally discovering a mechanic that had some depth to it, removing almost all of the other mechanics made room for that one interesting mechanic blossom to its fullest potential.

This felt like a sharp contrast to my experience designing two-player games, where it seemed that I could pretty much slap down any old mechanics and see quite a bit of depth emerge. Go's extreme mechanical simplicity may seem like a special case, but deep, simple, multiplayer mechanics are more the rule than the exception. For example, using Go equipment, there are even simpler games that offer similar depth, like Gomoku and Hex.

During the design process, I was aware that almost any of the failed single-player mechanics I was exploring would have instantly leaped to life in a two-player environment. The degenerate, trivial-high-score strategies would melt away as the opposing player found simple counters for those strategies.

The resulting game, which I've called i45hg (a nonsense name, so don't read anything into it), is reasonably interesting, at least for a few plays. Still, the play experience is much more akin to chipping away at an optimization problem than playing a real game. Once you discover a reasonable heuristic, you will likely lose interest quickly. Oh, and as a reference point, my high score, so far, is 84.


The Rules of i45hg

During each turn, you must place nine white stones on vacant blue squares. After placing the stones, and possibly retracting and replacing white stones lingering from previous turns, clicking the green arrow will commit your moves. During the commit process, various transformations take place and points are tallied. You then you move on to your next turn, placing nine more white stones. The following three rules govern the commit phase:

1. A white stone that is adjacent to one or more black stones scores a point.

2. A white stone that has less than three white neighbors becomes black.

4. A square that has three or four black neighbors is removed from the game (replaced with a blank, unusable square).

The game gives you hints about the effect of your move before you commit. For example, white stones that will become black, due to rule 2, are marked with gray:


Squares that will be removed, due to rule 3, are marked as ghosted blank squares. In the following picture, the empty square near the middle is adjacent to three white stones that will become black when the move is committed:


Note that ghosted blank squares do not block the placement of white stones during your turn.

White stones that will score points are marked with orange. The following picture shows all the hints in conjunction. Eight of the white stones will become black, so they are marked with gray. Six of the white stones, including four that are marked with gray, have black neighbors, so this turn will score six points when it is committed. Four squares will have three or more black neighbors after this turn, so they will be removed.


After the above turn is committed, the game would look like this:


(Download i45hg)

Comments on