Black Christmas

We had a pretty good Christmas (in spite of the title of this post) but it was not without its surprises and setbacks.

We had intended to travel to Oregon to spend the holiday with Helen's relatives, and to celebrate our nephew's fourth birthday. But our hosts, her parents, got snowed in. On the evening of the 22nd, we had to call off our anxious weather-watching and admit that nobody was going to gather in Oregon that week. (It is now Saturday after Christmas, and they're still trapped! They're safe, but likely won't get out until Monday or so.)

So we had two days to suddenly gear up for Christmas at home. A tiny turkey (store was sold out of the larger ones), mashed potatoes and gravy pre-made from Whole Foods (very good, too), salad fixings, Pillsbury crescent rolls (and cinnamon buns for breakfast), bottle of wine, and a mince pie made a very nice, small-scale feast. Helen had already spent a couple of days baking cookies: she has a half-dozen recipes that are all incredibly good, and she makes plenty every year.

We meant for dinner to be ready at 6, and we have no idea why that tiny turkey took so long to roast. It was 10pm before we sat down to eat! But it was very good (even without allowing for hunger as a sauce), and there was enough for everybody plus a little left over for a couple of sandwiches the next day.

The weather was odd. Periods of bright, calm sunshine alternated with the most amazing squalls, one of which took down a power line across the street. We weren't affected, but half of our neighbors had no power from about 9am Christmas morning until maybe 6pm the following evening. (They are the ones who had the "black Christmas"!)

We spent much of Christmas Day playing games (we had a lot of time while waiting for that turkey). We played Pandemic, Stone Age, and Ice Flow: all fairly new games for us. It was the first time in quite a while that the four of us had all played a game together, the kids now being grown enough to have their own social lives. It was a good day.

We have a number of new games in the house: unable to go to Oregon, we spent some of the traveling money on games to console ourselves. Le Havre and Siena we had already recently bought as Christmas presents for ourselves. We then went out and got Stone Age, Ice Flow, and Princes of Machu Pichu. And then Christmas is also Helen's birthday: I got her a copy of Galaxy Trucker, but it turned out her mother had gotten her that also! So we took the one I bought back to the store and traded it for EuroRails, TransAmerica, and Set. And we know there are more games coming, as soon as the relatives dig themselves out and can reach a post office. I think it's time to get that "Owner of Too Many Games" microbadge over at BoardGameGeek.

Stone Age looks like a hit. Ice Flow is interesting, but may be a bit dry, or else just sensitive to the number of players. We've played Princes of Machu Picchu just once so far, two-player, but we liked it. It's by the designer of two of our other favorite games, Antike and Imperial, so we had high hopes and it looks like we won't be disappointed. I want to play it again, soon. (And I want to get Brass back on the table, too!)

Not much game design news from me, but I have had a couple of ideas for spicing up the rail-game-formerly-known-as-Rails-Across-America. I hope to work with it some today, and I'll let y'all know how it comes out.

I hope you've all had good holidays too, and we can all hope for a Happy New Year.

All the Good Names Are Taken

Stumbled across a reference today, and discovered that there's a PC game named Rails Across America. Oh, well—my design will probably never be published anyway. But it's frustratingly difficult to come up with a good name for a rail game these days. Even Martin Wallace's latest has a poor name: Steel Driver (with its picture of John Henry on the box) would be a great name if the game were primarily about building rail. But it isn't; it's primarily about buying stock in railroad companies, an activity that I suspect the Steel-Drivin' Man never indulged in.

Anyway, if you're a copyright lawyer you can stand down. I'll find something else to call my design.

The Blahs

"Christmas is coming, the goose is getting fat..."

That would be me, that goose. About a year and a half ago I strained something in my wrist and had to lay off fencing for a few months. Then it got better (or so I thought) and I returned; but a month or so ago it was getting bad again. Now I'm again not fencing—and at Christmas, when there's far too much tempting, fattening food available. So far I haven't gained more than a couple of pounds. My wrist is feeling better and I hope to return to fencing in January.

An old friend of mine just got laid off from a job he'd held for well over a decade. That's not news in this economic climate, but it's depressing. Fortunately he got a good severance package and a lot of notice. He may need both; I have other friends who've been out of work for years.

Other "blah" non-news: no advances on any of my game designs. Somehow inspiration hasn't been striking. Had to work about ten days of intensive overtime, finishing up last week: fortunately it was not in vain, and we met the deadline. Really not much new, and really I'm writing this entry just to show that I haven't given up on the blog.

I have had a minor revelation (not an especially helpful one, alas) about my Rails Across America design, which has been languishing because I don't find it very original. It's that even my starting notion of a rail game that focusses on junctions as much as connections is not very original. I just wasn't remembering a number of games with that mechanic. One of them, embarrassingly, was my own Spatial Delivery. Another is Martin Wallace's excellent Brass. I played this game last May and enjoyed it, and Helen and I now have our own copy (after waiting months for a pre-order of the second edition). I can't recommend Brass enough, at least for experienced gamers. It's a tightly competitive game of linking towns and cities in Lancashire during the Industrial Revolution, and although the canal and rail links themselves are worth victory points, you get most of your score from building industries in the towns (using the links to transport building materials, and later products) and making them pay off.

Brass is great fun, but the rules are not trivial and are filled with difficult-to-remember exceptions. The second edition's rulebook was re-written and is apparently much improved over the original; but the rules themselves are still somewhat baroque. It's hard to play the game correctly the first couple of times. But if you stick with it, it's a great game. Helen and I were pleased to find a two-player variant on BoardGameGeek that some fan of the game designed. It works quite well. There are other two-player variants that we haven't tried, as well.

Finishing on an up beat: it turns out that idle blogging is not completely useless. Just talking here about Brass and Rails Across America gave me a new idea to spice up my design. Something to think about over the holidays!

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.