Series Info...Trials, Triumphs & Trivialities #185:

Designing Strategy: Computerized Board Games

by Shannon Appelcline

For the last six months or so I've been contributing to a group blog called Gone Gaming. It's about tabletop board games and covers the spectrum from my own thoughts on American & Eurodesigns to discussions of wargames & more casual conversations.

Last week I reviewed six computerized board games at Gone Gaming and I followed that up with a discussion of how to design computerized board games in this week's posting. Since we have our own computerized board games here at Skotos and since they've been a topic of past columns (such as The Disconnect Dilemma and Some Thoughts on Artificial Intelligence), I decided that my newest Gone Gamine article deserved to be reprinted over here as well, for its thoughts on game design.

So, here you go. You may wish to read my board game mini-reviews first, because they offer some of the examples used in this piece.

Last week I wrote up mini-reviews of six different computerized board games. This week I'd like to enlarge on that topic a little bit by describing some lessons learned: my own personal "do's" and "don't's" list for computerized board game design, offered as advice to future computerized board game designers.

Choosing a Game

To start off with, I think there's a very specific type of game that works best as a computerized board game. It has to have good depth of play and variability, though I'm not sure that straight-out complexity is needed (or even desired).

The reason for this is that a good computerized board game will get played a lot. For me my most popular tabletop board games might rack up 10-20 games a year. Contrariwise a computerized board game could easily score 10x that many plays. In January I had to build a new computer system, and since then I've played my computerized version of Carcassonne (plus expansions) a mind-number 252 times. That's 3-4 times a day.

If a game's too light, or if it doesn't change enough from game to game, it won't stand up to that many plays, and thus it's not an optimal choice for a computer version.

Contrariwise, as I said, pure complexity may not be the way to go. There's something less visceral about playing a computerized version of a board game, and for me at least that makes it harder to keep track of what's going on in a game with a lot of variables.

Looking at the games I reviewed in my previous column, Samurai was on the slightly too light side, El Grande and Puerto Rico were on the slightly too heavy side, and Ticket to Ride, Carcassonne, and Iron Dragon were all dead-on what I think works when choosing a tabletop board game to convert.

Displaying a Game

The first tricky question in converting a tabletop game to computer form is figuring out how to display it. The average game player, or at least the average game player who plays these games of ours, has a fairly small monitor. According to current stats at RPGnet, 53.9% use 1028x768, 18.26% use 1280x1024, and 8.99% still use 800x600. It's pretty hard to fit a four-panel or six-panel board onto less than a million pixels.

Computer games tend to have two solutions for this:

First, some scrunch the board down into the resolution available. This can be the best solution if you've either got a fairly simplistic design to start with, or if you're willing to simplify the design to make it look better on the computer screen. Carcassonne: Hunters & Gatherers actually redrew all of its tiles in the computer version to make them much clearer and easier to read.

Second, only show part of the board. This works best in a game like Iron Dragon where you really do only need to concentrate on a small part of the board at a time. Still, you have to keep a player apprised of what's going on in other parts of the board, or you start to isolate your player from the game. (Samurai, contrariwise, was a game that didn't jump to different parts of the board when other players took their actions, and it was to the games' detriment.)

Computerized board games also tend to have a unique problem: they use pregenerated, hand-drawn artwork, and so they might not display well at different sizes. This is notably a problem on LCD screens, which often can't resize on the fly the way a CRT can. We've seen this issue on the recent releases of both Ticket to Ride and Puerto Rico. A first fix for this problem may be to offer the graphics to your game in a few different pre-generated sizes. A second fix is to not run your game full-screen, particularly if you're running on a screen larger than your game can really support.

Offering a UI

Ultimately it's the User Interface (UI) that makes or breaks a computerized board game.

To start off with, you have to make it really easy for a player to follow what the other players are doing. Here's some ways to do this:

  • Show all opponents' actions as animations, with cards moving across the screen, pieces moving onto the screen, etc. Our eyes are attracted to movement, and so this is an easy way to get players' attention.
  • Always include delays in AI moves, preferably with that time filled with your animation. This ensures that players have the time to see what's going on, but the animation makes them feel like something's really going on, and they're not just sitting around waiting. Also, let players adjust this delay as they see fit.
  • If it's at all possible, highlight the last piece that each player played or moved, and keep it highlighted, so that when it gets to be a player's turn he can easily scan the board at that time and be reminded of what all was done.
  • Do include an action log listing the last few moves, and use emphasis to make that action log easy to read. You might note different player's actions in their player colors or note the starts of new phases of action with bold or with a blank line. You don't want to go overboard, but almost every action log I've seen is useless because it's a solid block of text, like a book with no paragraphs. Samurai is a rare game that did a good job by using different colors in its log and by separatin turns with horizontal rules.
  • Always let a player acknowledge taking his own action, even if it's obvious what has to be done, because a player needs to know when his personal status changes. If you're afraid of slowing the game down (for multiplayer play), put a timer on that acknowledgement and then take the action if a player hasn't responded by then.
  • Alert players when they need to take an action with high-contrast, easy-to-read text or graphics that always appear in the same location. You don't want them to scan the whole screen because you've decided to put different notices in different places.
  • Also make good use of audio effects. This isn't just about making your game sound cool; instead audio effects should be used as a secondary method to convey information. Have a standard sound to mark the start of a player's turn, and use clear, obvious, and distinct sounds to mark actions that other players take which the player should know about.
One of the biggest failures of a computerized board game can be a feeling of isolation. Using video and audio cues to help a player keep track of how the game is progressing can dramatically overcome this.

The other side of UI, how a player actually takes his actions, doesn't deserve as much attention; game designers tend to have a better idea of how to do that because the same rules apply to computer programs of all type.

There's one notable rule for computerized board game player actions, however: always give players a chance to undo. All the way up to the end of his turn (or a point where he finds out the result of a random die roll or arbitrary card draw) a player should be able to undo a mistake that he made. Most games do this pretty well, but the ones who don't are that much more painful.

Offering an AI

I'm astounding by how bad the Artificial Intelligence (AI) is on many computerized board games. Otherwise good games like El Grande, Ticket to Ride, and Iron Dragon are hampered to various degrees by AIs that win very small amounts of the time.

If you think AI isn't important, you're wrong, because if there's one thing that all these computerized board games have taught me, it's that it's very hard to actually develop a good online community of players. Of the six games I reviewed in my previous article, Ticket to Ride succeeded dramatically at developing their online community (and had done so even before their SdJ win). None of the other games have. Even at Days of Wonder's own site, it's hard to get people to play their Fist of Dragonstones and Queen's Necklace.

I've played around with some expert-rule sets, but in general I don't know how to program good AI (despite taking a class in the same back in college). I have to presume that it's a pretty hard task, to some extent depending on the openness and the strategies of the game. But my advice here is simple: if you don't know how to either, get someone who does.

Offering Ranking

When you develop your computer game, you're probably going to want some way to record player wins. My simple advice here is: use ELO ratings. I've written more extensively on them elsewhere in an article on competitive rankings. ELO is a mathematical construct which measures the probable result of a game, then awards a player more if he defeated a better opponent and less if he defeated a worse opponent. The math is a bit hairy, but a computer's taking care of it for you, so who cares? ELO ratings work particularly well if you have multiple levels of AI, as is the case with the Carcassonne games.

The purpose of rankings (using ELO, or any other competitive ranking system) is to give players a metagoal to strive for. They're not just trying to win an individual game, they're also trying to improve their ranking until it's better than their opponents'.

If you don't want to use ELO rankings, you should still include some type of metagame. From worst to best, you can: do nothing; post high scores; post high scores divided by specific type of play; use win-loss rankings; and use full ELO rankings.

Managing the Aftergame

Even after your game is out, there's going to be a few additional things you have to deal with.

The first is the inevitable technical support. Hopefully you tested your game pretty extensively, but even if you did you're going to run into some problems. The more clever developers nowadays build ways to auto-update programs from the 'net, which resolves all but the worst crashes in a way pretty invisible to the users.

As more and more games are sold online, an increasingly big problem is that of how to manage license files. Before I changed machines in January, my "Program Files" directory on my old machine was wiped out, and so when I got onto my new machine I had to rebuild everything from scratch. This involved redownloading and relicensing the six computerized board games that I had on my computer at that time: three versions of Carcassonne, El Grande, Iron Dragon, and Samurai.

Downloading all of the programs was a snap. In each case I just had to go to the site in question and click a link. Relicensing Carcassonne and El Grande was pretty simple because my full license info was available at the website I bought the games from. For Iron Dragon and Samurai I had to email the developers to get new copies of my registration & licensing info. An automated website, where I could have saved the information with a standard login & password would have saved everyone a lot of time.

(And, do you want an idea for the next great dot-com company? It's "", where you can login and save your registration information each time you purchase a new product. It's paid for with a micropayment, just $1 each time you login to record one or more registration numbers at the same time. I'd like a 10% cut of the company if you think this is a great idea and go and do it.)

In any case, think about the aftergame, and make sure you have good, automated ways to update your game and relicense it.


As I said in my previous column on this topic, I hope to see a lot more computerized board games in the future. They're not a replacement for real play, but they're a nice complement. However, before I see a lot more games, I'd like to see a lot more people actually applying the lessons learned thus far, and delivering the right games, with good displays, good UIs, and good AIs, because a bad game can be a lot more frustrating than none at all.

[ <— #184: The Skotos Articles Archives: Five Great Miniseries | #186: Online Games & The Law, Part Five: Property Rights —> ]

Miniseries ...