Manumation

The major advantage that video games have over board games is automation. Video games can track far more variables present a wider range of options by type and degree than a board game can. This is because board games must track everything in a verifiable, physical state.

As the number of items and their possible states expands, the players can quickly be overwhelmed by the mere physical size of the board, not to mention the need to calculate things like "how many of this are there?" (the latter can be helped by summary charts, but that is another thing players must update every time an action is taken and it increases the physical size of the game yet further).

Most people think of Doom and its descendants (or, really, Castle Wolfenstein and its descendants) when the phrase "video game" is bandied about. However, there are far more interesting examples that take advantage of a computer's information tracking and presentation capabilities, such as the renowed Sid Meier's Civilization series.

One such game is the Caesar series. I was reading a review of the latest incarnation over at Gamespy. I cannot emplain the thrust of the game better than they do, so go skim it here. One paragraph can sum up my interest in the game:

The difference between Caesar IV and other city builders is that it's based around daisy-chained economic relationships and intelligent citizens, rather than the more standard "building influence" model of the SimCity games. Players place production, service and residential buildings on an empty map. Virtual Roman citizens move in, take up jobs appropriate for their social class, start producing goods and services to give them happy lives, provide lots of tax revenue for the player, and hopefully have enough stuff left over for the incessant demands of the Empire. It's in this intricate dance of supply and demand that Caesar IV is at its best.

As I've said before, economics and its underlying activities have always been a passion of mine. A free market is the best expression of balanced game design. The players are rewarded for acting in their own best interest, which is how good multiplayer games should be (as opposed to some games where people act out of spite to their own detriment). And if any path to "victory" (good or service to sell) is too easy (profitable), other players will compete in that particular strategy (similar or substitute goods or services), making it harder (less profitable).

Let's get back to the topic at hand: automation. Video games have in the past usurped board game genres. For example, real-time strategy games running on silicon and electricity can trace their roots to wargames played on cardboard and plastic. Even straight conversions have occurred, porting a board game directly into an electronic version (see: ). The reason for this is that computer automation of information and rules (which is all board games are in a logical sense, information and rules) makes gaming more convenient and allows for an increase in complexity with less risk of overwhelming players.

Recently, however, we have seen the opposite process. Boardgames such as Warcraft and, ironically, Sid Meier's Civilization, are inspired by computer games of the same name. I have played both of these games, and it is interesting to see the difference between them and their computer versions.

Instead of producing and controlling 50 infantry units on a computer screen, the player controls less than a handful. Instead of those units having 100 hit points each (representing 101 different states of health), they all have 1 hitpoint (meaning they are either alive or dead). Production costs are similarly scaled down. These are all examples of reducing the range of states: size of army, health of unit, cost to produce. The games also reduce the number of strategic options. There are less than half a dozen different units each player can control, as opposed to 20, 30, 40, or more in their computer versions.

If the process of putting a game onto a computer is called automation, a sensible person would call this reverse process of putting games back into board form deautomation. But I've never been sensible, so I am choosing to coin a new phrase: manumation. Say it often, and smile knowingly when you do.

Back to Caesar IV. As I read the review, a particular sentence jumped out at me:

A simulation this complex means that the player is going to require a boatload of information to properly manage their city.

That sentence screamed to me "This kind of game is exactly what video games are good for. This could never be a board game." Of course, this caused my ego to kick in with "I betcha I could turn it into one."

I started thinking about the core mechanics of Caesar and what makes it interesting. The heart of the game is about planning a city infrastructure around commodity production. What makes it interesting is balancing competing demands for goods with limited space and resources. I sketched out some ideas for representing such demands in a boardgame and forcing a player to react to them.

Then I realized I was creating a single-player game, much like Caesar. I've never been a fan of single-player board games, as I feel the challenge is extremely arbitrarily embedded in the design. I prefer pitting myself against another human being instead of the absent designer. A designer's job is to create a framework for players, not to be one himself. So then I abandoned the idea of designing a cardboard Caesar.

And I took up the idea of designing a competitive, city-based commodity production game. I already have progressed very far with my Conglomerate prototypes. If you don't want to click the link to read about it, Conglomerate is a game where an entire economy is controlled by player actions. Players create resources, which are then used by themselves or other places to build structures and facilities. Facilities allow players to produce goods, and structures provide demand for those goods.

In developing the different versions of Conglomerate, I learned alot about how to create an interesting and balanced multi-good marketplace mechanic. This means I'll have a head start on this new game, but on the flip side it means I have to make certain I differentiate the two games.

The key to this differentiation lies in my initial inspiration, Caesar. Conglomerate takes place in a very abstract location. This new game, let's call it . . . hmmm. I have no idea what to call it. I'll need a name to organize the design files on my computer. Alright, let's call it Mercatus (Latin for market). Mercatus can take place in a Roman city. This gives it a far different theme than Conglomerate, which takes place slightly in the future. It also gives it a way to be concrete as opposed to Conglomerate's abstract placement.

This also suggests mechanics for Mercatus that Conglomerate could not have. Player's profit could be based not only on demand for a good, but how difficult it is to get that good to the people who want it. Street traffic could also be an interesting mechanic to deal with, as it creates a way for players to interact that is not just direct competition to sell a particular good. Players would have to be wary of avoiding the traffic created by other players, lest their labor costs increase. A street traffic mechanic makes placement of buildings very important, as opposed to Conglomerate where players' facilities are just placed in front of them.

It will be interesting to try to develop two games that address some of the same mechanics simultaneously. Possibly the need to keep them distinct will give my creativity a harder push, making each game better in the process.