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.