The Invisible Man

"Not wanton killing, but a judicious slaying. The point is, they know there is an Invisible Man — as well as we know there is an Invisible Man. And that Invisible Man, Kemp, must now establish a Reign of Terror. Yes — no doubt it's startling. But I mean it. A Reign of Terror. He must take some town like your Burdock and terrify and dominate it. He must issue his orders. He can do that in a thousand ways — scraps of paper thrust under doors would suffice. And all who disobey his orders he must kill, and kill all who would defend them." — H. G. Wells

About three years ago, I had an idea to make a game based on H. G. Wells's The Invisible Man. In the novel, a scientist discovers how to make himself invisible, then goes on a mad rampage. (I'm oversimplifying here—the novel is not a mere hackneyed mad-scientist tale. If you haven't read it, you should!) My idea was to have the players cooperate in trying to defeat the Invisible Man, while the Invisible Man attempted to complete his Reign of Terror. I came up with a nifty mechanism whereby the Invisible Man could be a non-player character, moving around a map according to a set of rules, in such a way that the players would not always know exactly where he was.

And there it stalled for some time. The problem is that I don't much care for cooperative games, yet the theme seemed to demand cooperation. What could the players possibly be competing for in the face of such a fearsome common threat? A week or two ago I finally got an inspiration. The Invisible Man had a treasure: his scientific journals detailing the invisibility process. A competitive game would involve the players cooperating to defeat the Invisible Man, but competing to find clues to the place where he has hidden his journals. If the Invisible Man wins, all players lose. If he is defeated, the player with the most clues wins the journals and the game.

The novel is old enough to be in the public domain, so there would be no need to license the title and characters, and no problem including quotes for flavor. I think it would be a fun theme, but I've got a lot of work still to do to build a good game around it.

"This announces the first day of the Terror. Port Burdock is no longer under the Queen, tell your Colonel of Police, and the rest of them; it is under me — the Terror! This is day one of year one of the new epoch, — the Epoch of the Invisible Man."

A Question of Balance

"Is it balanced?" is a question that many game players, and all game designers, ask about a game. But it can mean different things to different people.

Most generally, "balanced" means that a game has—at the outset—an even chance of being won by any player at the table. If the game heavily favors the first player (for example), then the game is unbalanced: it's not fair to the other players.

But there are other ways to consider the matter. A common design problem is the runaway leader, where the first player to gain an advantage will almost certainly win. Even if the chances of winning are even at the start of the game, they may quickly become very uneven.

Some players take this notion to extremes, and consider any game unbalanced if the final scores show much separation. Others reject this idea on the grounds that it renders all of the game except the final few moves irrelevant to the outcome.

One of the reasons I built the Rails Across America simulator was to test the balance of the game. I instrumented the simulator to record scores over runs of thousands of games, and to print out relevant statistics. The results were enlightening, and somewhat depressing.

I was looking for evidence of all three kinds of imbalance. After a fair amount of work I was able to tune the rules and map to the point where there was no significant starting imbalance in the four-player game: all players had a roughly equal chance of winning at the start of the game. (This was not quite as simple as looking at the stats for which player won most. A start-player advantage may only apply to intelligent players, and my so-called AI doesn't qualify. So I was also looking for imbalances in the choice of starting location. Turns out it's a bad idea to start at New York, but when I was done tuning, the other five Major Cities on the board were about equal.)

Next I looked at the scoring curves. What was the range of final scores, what was an average score, how sharply pointed was the bell curve? Also I looked at the bell curve for the point spread: what was the difference in final scores between the winner and the biggest loser in each game? Since I want to avoid a runaway leader problem, but don't feel that every game needs to be really close, I was satisfied with curves that showed reasonable but not excessive grouping of final scores. Often a couple of players may be in a tight race for the win, while one or two others lag behind. Sometimes one player dominates, but certainly not always. That's a good distribution, in my opinion.

So what's depressing about all this? It's good, but only for the four-player game. With five, the game is badly imbalanced—at least one player is screwed from the start. The three-player game is worse. And I learned that the biggest factor affecting the balance is the map itself: merely playing with costs, rewards, and setup would not repair the imbalances. To have a good three- or five-player game, I'll need well-tuned three- and five-player maps. That's upsetting. The more restricted the recommended number of players, the fewer copies will sell. To make it less restrictive I have to add more boards, which adds expense.

Probably the best compromise is a two-sided board, with the 4p map on one side and the 5p on the other, and forget about the three-player game. If I'm lucky and work hard at it, I might also be able to make a subsection of one map serve for three players.

The next question is: Is it worth the trouble? But that's an issue for another post.

Adventures in Simulation

Rails Across America seems to be shaping up nicely, but it's clear that it will need a lot of careful tuning. Is there a first player advantage, and if so how can I eliminate it? Is there a clearly dominant strategy? How many rounds does an average game last? How many components (track, money, etc) are required? How should costs and payouts best be balanced? And so on—a myriad questions.

To answer these questions, I decided I needed a simulator, a program that would actually play the game—and play it quickly, so that I could whip through hundreds of games in an evening. With a good simulator, I can test lots of things just by tweaking input parameters: # of players, # of goods colors, # of goods cubes, costs, payouts, starting money, and much more. For more radical experiments I may have to recode the simulator for changed rules or variant strategies, but that's not too hard once the first version is built and running.

Well, I'm a computer programmer. This is the kind of challenge that usually makes me go "oboy!" and code madly for a few hours—then give up in disgust when I realize how difficult it's really going to be. This time, I went "oboy" and coded madly for a few hours, and actually had the bones of a decent simulator at the end of it. So far so good!

"Bones" aren't enough, though. The first version played very stupidly, and that's no good because it skews the results. I don't need it to play at grandmaster level, but it needs to play at least a plausible beginner's-level game. That's the big challenge; the rest is just boiler-plate code. After several days of work, I'm pleased to report that the gadget now plays a passable game: not as good as an experienced live player, but credible. And it is fast: it can play 10,000 games in five minutes or less.

I've given it two forms of output. If I have it play just one game, it prints out every action taken by every player, then summarizes each player's accomplishments at the end. If I have it play multiple games, it collects statistics and just prints those.

Just to set expectations, here's what this gadget is not: It is not a device for playing the game interactively against a computer, or against human opponents without a board. Also it is not a general-purpose boardgame simulator. When I want a simulator for the next game I design, I'll have to start coding from scratch again.

Here's another thing it's not: It is not a substitute for real playtesting. I hope it will tell me a lot about my game, but it won't tell me whether the game is fun, or has rules that irritate or confuse live players, or induces too much AP, or simply takes too long to play. I don't want to waste real people's time making experiments that I can perform on my own. But if the game survives the simulations, I'll start badgering friends to try it out.

Forgive me, but I feel like I have to add this: If you are a game designer and would like a simulator for your own designs, please do not ask me to build one for you. I'll just say no. This project has taken me days, with more yet to go, and I haven't got enough to spare. I'd never get any of my own projects done if I started coding for other folks.

But if it continues to go well, and anybody shows any interest, I might be willing to post the Java source code for download. I doubt it will be useful to anyone, but ya never know.

Rails Across America

After another playtest this evening, with new components and scoring, I've decided the rail-game design is showing enough promise to make it more official. I've given it a name—Rails Across America—and begun a Game Journal for it here, at the Board Game Designers Forum. Further details about the game's rules and components will appear there. I'll post here also if and when any more "milestones" occur.

Wait, I Did That Already...

In my recent post I Wanna Design Railroad Tycoon! I expressed my desire to (a) build a rail game, and (b) build one where ownership or development of the junctions was a primary goal. I had the notion that (b) hadn't been done before, or at least not often.

The other day I had a penny-dropped moment: I have already designed such a game. It's Spatial Delivery, in which players build trade routes ("rails in space") to reach prime locations for trade stations.

So now I feel kind of stupid for characterizing the new design's goal in that way. Fortunately, I can add a little verbiage and perhaps make it plain why the new design really isn't Spatial Delivery warmed over.

In SD, players build routes, but once built the routes are held in common. There is no ownership of the routes, and no reward is given for building them, beyond the fact that the route-builder gets to build a station at the end of each new route. Players do own the stations they build, receive substantial rewards for building them, and may receive further rewards if other players use them.

But in the more traditional rail game I'm now trying to design, the rails will be owned by the players who build them. As in SD, there may be no immediate reward simply for building rail. But there will likely be rewards for building a given strategic route before other players can do so, because by doing so you can get some rewards from late-comers who want to share the route, and you can block others from using the route altogether. The race for connectivity, for expanding your network strategically, will be an integral part of the game. This isn't the case in SD, where connectivity isn't much of an issue (because if anybody can get from point A to point B, so can everybody else).

Another difference is that in SD, making deliveries gets you Victory Points. In the new design, I think that deliveries will get you cash, which you will then spend to build more rails and to build train stations. (I say I think because the design is still up in the air.) There's nothing new about this mechanism, of course; it's just different from SD.

Reiner Knizia was the first person who told me (at a seminar, not face-to-face) that the victory conditions have a huge effect on gameplay. It's a fairly obvious point, yet before that I was thinking in terms of coming up with a bunch of nifty mechanisms, and then just slapping a win condition onto the end of the rules. But of course, the goal of the game informs all of the players' decisions. In my rail game, I have a set of reasonable mechanisms that might contribute to a good game. But I won't be able to tell until I've tuned the scoring system correctly (or given it up as a bad job). I want connectivity to be important, but I also want the stations to be significant. I want the famous "multiple paths to victory", so that a player might win by building stations, or by building the best network, or by making the most money from deliveries. To do that will require some careful tuning and balancing.

And that's my next goal for this design: to come up with a reasonably well-tuned scoring system. If I can do that, I'll have a game. After that, it'll just be playtest, tune, and repeat until it's good enough.

Well, that's the plan, anyway. Nothing ever goes that smoothly!

Later: I tried a solo playtest of the latest rules (including scoring) this evening. It worked fairly well. The biggest problem may simply be the lack of anything very new or different from other rail games. It's a mix of familiar mechanisms, with nothing in it you haven't seen before. But while originality is nice, few games offer anything really new. I won't worry about it too much.

California Academy of Sciences

Helen and I visited the California Academy of Sciences in Golden Gate Park in San Francisco last weekend. This museum-and-research institution was founded over 150 years ago, and recently re-opened in new digs following its partial destruction in the 1989 Loma Prieta earthquake.

The new Academy is amazing. I don't know any better word to use to describe it. Check out the Web site (see link above) and see for yourself a little about what it's like—but you won't really understand until you can visit.

I could ramble on for pages. To avoid that, I'll just briefly describe the most amazing feature. This is the Rain Forest, contained inside a glass sphere 90 feet in diameter. The sphere contains maybe 10 feet of water at the bottom, in which hundreds of fish swim (and some of them are huge). From ground level, trees go up four stories, and are filled with birds and butterflies. Side exhibits include a bat cave (we watched a curator hand-feeding little bits of fruit to the hanging bats) and a large leaf-cutter ant farm. You enter at ground level, and follow a ramp that spirals up the inside of the dome. At each level there's something different to see: the fish, the plants, the birds, and the omnipresent butterflies that float around you. From the top, a glass elevator takes you down under the water for a close-up view of the underwater life. It is stunning; I think I could spend all day there, just in that one dome.

And there's more: the Morrison Planetarium (which we missed, for lack of time), the Steinhart Aquarium (still reigned over by the resident albino alligator), and even the roof which is covered with earth and planted with low-maintenance native groundcover.

Go, see it, it's wonderful. But don't drive there. We had an absolutely terrible time finding parking, and the traffic jams were horrific. Take BART to the city, then grab one of the buses that will take you straight to the Academy's door. Oh, and buy your tickets ahead of time on the Web, it will save you time getting in.

I Wanna Design Railroad Tycoon!

It's my favorite game, is Railroad Tycoon. And I like most rail games in general. They offer a type of competitive problem that I particularly enjoy. Every design is different, but often you are competing with other players for real estate and scarce resources, while constrained by connectivity and budgeting. In Railroad Tycoon, the real estate is the rail you lay between cities, and the connection points to those cities. The scarce resources are the goods to be delivered. Laying rail costs money; to raise money you can issue shares or make deliveries to increase your income.

Games like this offer the player a rich matrix of decisions. With a limited number of actions to complete your goals, every action is a significant choice. You need to build as early as possible, to grab scarce real estate before someone else does. But you need money to do that. Make deliveries first, to raise money? Or issue shares to get instant money? But shares will cost you more money, and penalty points, later; and if you delay the deliveries, someone else may "steal" them from you. No wonder rail games are fascinating!

This isn't a new or original pattern. There are dozens, if not hundreds, of rail games. Many form easily-extensible systems: the 18XX series, Age of Steam and its many expansions, the crayon rail games. Rail games are easy to extend because once you have a good basic game, you can vary it with new maps and minor rule tweaks to keep it fresh.

So with all these excellent rail games already available, why would I want to design another? The real answer is that I like rail games, so I'd like to have the experience of designing one myself, hopefully a good one. But I could also reply that new rail games come out every year, and if they're good, they get bought and played. There's clearly room for a few more yet.

Of course, I can't design Railroad Tycoon. (As Helen told me: "You know it's been done, right?") So I needed a new idea. Seth Jaffee has a nice design called Reading Railroad, which has a new twist: he's melded a word game with a rail game. The result is much more rail game than word game; it's fresh and different and it works well. But I wasn't looking for anything quite that radical.

What I came up with is this. In most rail games, you compete for the connections between locations. The locations themselves are usually not owned or monopolized by the players. I decided to try a design in which the rail network is built as a means to the end of "owning" the junctions: you are building stations and switchyards. (I'd be surprised if this actually hasn't been done before; but I haven't seen it and it doesn't seem to be common.)

I followed my usual design procedure: did a lot of thinking, wrote it up on the computer, refined it until it looked good. Then I made a quick-and-dirty mockup and tried a solo game, pretending to be four players at once. As usual, the initial design didn't work very well. I took the lessons learned, rethought things for another couple of days, and came up with a different variation, and tried that one. And it was better, but still flawed... I'll spare you the details, but I'm still trying out different ideas. I may wander away from the original notion altogether; I've learned not to be too wedded to my original notions.

What surprises me, again and again, is how difficult it is to design a truly interesting, playable game. More than once I've started with a successful but complex game (someone else's, of course) and tried to trim it down into something similar but simpler. And every time, it's failed. Yesterday I played a Railroad Tycoon variant, designed by a fan of the game. It's pretty much the same rules as the base game, just a few variations for interest's sake, and (the main difference) a new map. And it was... lackluster. It worked, but money wasn't tight and there wasn't as much interaction between the players as there should have been. I don't want to damn the variant on the basis of one play; maybe the map was designed for more than the four players we had, for example. Still, either of the two official versions (the original Railroad Tycoon and the Rails of Europe expansion) offer much superior play experiences.

And there's my own design. I borrowed some notions from RRT, some from other rail games, added a notion of my own... as I said, there are bazillions of good rail games. How hard can it be to come up with another one?

Apparently it can be pretty tough. So far I'm not impressed with my own design. But... at least it's not a complete heap of trash. Used to be, all my new designs turned out to be steaming heaps. Lately they've been almost-playable, with a strong sense that there might be a real game lurking in there somewhere, if I can only find it. I guess I'm getting better at this game design stuff, but I clearly have a long way to go.