Two types of game

It’s pretty easy to divide all video games into two groups. “Good” vs. “bad”, for example, is a fairly common (albeit subjective) division. And people like dividing things on that axis, so it’ll probably always be the main one, even if nobody can agree on precisely which games belong in each camp.

But there are other, more descriptive ways to categorise games.

One that I’ve been thinking about a lot recently, during my creation of Game in a Week games is the difference between process-based and content-based games. These days, nearly all professional video games are content-based, whereas a high proportion of independent and freeware video games are process-based. Virtually all traditional tabletop games are process-based, but some newer tabletop games are content-based. Here’s what I mean by these terms:

Some definitions

When I talk about process-based games, I’m talking about games in which there are a fixed set of rules and a fixed context in which to interpret those rules. Examples of process-based games would be Solitaire, Chess, Missile Command, Tetris, Space Invaders, Bejeweled, and the Street Fighter games.

On the other hand, content-based games are games in which there are a fixed set of rules, but the context in which those rules operate changes during the course of a game. Examples of content-based games would be Zork, Ms. Pac-Man, Dig-Dug, Marble Madness, Peggle, and Halo 3.

(I’m ignoring meta-games such as Nomic and Mao in this discussion; games in which the rules of the game allow you to change the rules of the game)

Telling one from the other

The easiest way to recognise a content-based game is to look for “levels” or “stages” or alternate board layouts provided by the creater of the game, in which the game’s optimal strategy differs.

The different ‘levels’ of “Tetris” are all identical to each other; the only difference between them is the speed of play. In the context of Tetris, a ‘level’ is really just a secondary ‘score’ value, and so I consider Tetris to be a process-based game.

The different levels of “Pac-Man” are all identical to each other geometrically, but provide different patterns for the ghost AI to follow. These different patterns are enough to qualify Pac-Man as a content-based game.

The different levels of “Dig-Dug” have different placements of enemies, pre-carved caverns, and rocks, and so are content-based.

The different levels of “Halo 3” have substantially different placements of enemies, different world geometry, different weapons available, and different challenges to be overcome.

In general, if it makes sense to talk about “finishing” a game, you’re talking about having experienced all the content of a content-based game. If it makes sense to talk about “exploring” in a game, you’re probably talking about a content-based game (You would never tell your friends that you “finished” Chess last night, or that you were “exploring” Street Fighter; both process-based games)

Or to look at it from the point of view of implementation, if you have implemented the gameplay and can say “I’m done now,” then you have a process-based game. If you have implemented the gameplay and have to say, “Now I need to make 20 levels for this game,” then you have a content-based game.

Okay.. so what?

A content-based game can prop up a less-than-fun core gameplay mechanic and maintain player interest solely by the novelty of its content. By setting up the game in such a way that new, interesting content is regularly presented to the player as they play (most commonly by passing from one level to another), you can help keep the player from growing bored at doing the same thing over and over again.

A process-based game, on the other hand, lives and dies by how much fun its main activities are on their own merits. Bejeweled works as a match-3 game on its own merits; its matching, pattern recognition, and general postive feedback make the mere act of playing an enjoyable pasttime on its own, even though we never actually clear the game board and move to a new, fancier one, and there’s never a moment of discovering something new, once you’ve learned the basic game rules. On the other hand, Peggle wouldn’t be nearly as satisfying without its slick level progression, and continually reaching new, more complicated levels to work on next.

As is probably self-evident, it takes a lot more time and resources to write a content-based game than it does to write a process-based game, because the game has to be able to cope with varying content, and then you need to actually create that content (levels or AI or what have you). On the plus side, you can have non-programmers create that content. On the minus side, that plus side assumes that you have some non-programmers to do the work, which often is not the case with independant games.

So what do we do?

It seems to me that there are a few options if you’re a programmer and really want to work on a platform game or a scrolling shooter or an RPG or some other project which really demands a content-driven design.

Of course, you could simply sit down and do all the content creation yourself. That’s an option, if you don’t think you’ll tire of the content creation process (though programmers often lose interest during this stage of game creation). Or you can pair up with a non-programmer to help out with the content creation.

If you really want to, you can often convert a content-based game concept into a process-based one by algorithmically creating the context for the game. This is what I did in Muncher’s Labyrinth (where the level is generated pseudo-randomly), and is also what’s done in games such as Illuminati and Zombies!!!. Of course, you usually get better levels, more reliable difficulty curves, etc. if they’re designed by a human rather than by random forces. But the productivity boost of working on something process-based rather than content-based is pretty hard to argue against.

Another possible option is to rely on gathering a community that will build a lot of content for you. Certainly that’s happened with games like N and Knytt, but I suspect that you can’t rely on that happening, and you’ll still have to provide a certain amount of content to kickstart the process. And as a game maker myself, I personally find this option rather unsatisfying; while I’d be thrilled to have others make the effort to mod a game I’d written, I wouldn’t feel like I was doing my job if I just assumed that people would create levels for me, and so didn’t make them, myself.

In the end, if you’re going to create a content-based game, you’re going to need to get content for it, and generating content for a content-based game in traditional manners tends to take at least as much time as creating the base game itself. I’m very interested in “generating content” approaches that others have tried in the past, since I suspect that I’m going to be running into this problem more and more often in the future, especially with my current focus on “Game in a Week” games; if I could find a good method of creating, managing, and testing a lot of content quickly, that’d potentially let me start creating level-based games in these things..

Of course, it’s no coincidence at all that I’m mulling this all over while I’m thinking about Space Maze Express, which is shaping up to be a heavily physics-based game. I’d love to have interesting levels for it, but I’d rather not end up spending many weeks creating them, when I could instead be prototyping new gameplay ideas..