I think most of the regular readers of this blog already know the following from Facebook and Twitter posts and the like, but since I've chronicled the development of this design here from the beginning, I feel that I should wrap things up here as well.
So here's the news: the Railways of the Western U.S. project (which started life as Hammer & Spike and which was known for a while as Rottweiler) is finally complete, and is available for purchase both online and at your favorite FLGS ("friendly local game store").
I received my copies about a week and a half ago; FRED very kindly sent them to me almost as soon as they had arrived from the printer. I am pleased to report that the production quality is excellent. The map neatly matches up with its Eastern U.S. counterpart. The City Rotor pieces are indeed very cool (see photos by my friend Marlin Deckert here and here). Everything's there that should be there, including the Fuel Depot bits that were missing from the Essen copies. And Helen got her urgent request satisfied: the player aid cards have an image of the Rotor Cities' "rainbow pie chart", so you can see the order of the colors.
My copies came before the product had appeared in stores, so I was surprised and gratified when Marlin showed up at game night a few days later with a copy he'd purchased at our own FLGS, Game Kastle in San Jose. This was, in a manner of speaking, the first copy we'd seen "in the wild". We stopped in there last Friday night ourselves, and sure enough, there were two copies sitting out on the Christmas gift suggestion display table.
I've been trying not to pollute this post with a lot of superfluous exclamation points, but they're here in spirit. It's been most gratifying to see the final product, see that people are buying it, and see the ratings going up on its BoardGameGeek page.
So what's next? I'm not sure. I have about a half-dozen half-baked ideas for new game designs, and there is an excellent chance of another expansion for Railways of the World. When I know, I'll let you know!
Showing posts with label hammer and spike. Show all posts
Showing posts with label hammer and spike. Show all posts
Sunday, December 19, 2010
Tuesday, July 28, 2009
Getting Rolling
It's been three weeks since my last post. The major reason for this is that I've been asked not to be too forthcoming with details about the Railways of the World expansion I'm working on. This has put a crimp in my blogging style.
But I suppose I can get away with some generalities. For one thing, I was mistaken in thinking that the expansion would be mostly designed by others; turns out it's mainly in my lap. The board, the cards, the variant rules, all of it. I'll have help and advice from the publisher's developers, of course.
This is not how I foresaw my first publication contract! I thought I'd design a game, get it mostly finished, then get it licensed. After that, just playtest and tweak until the publisher is happy; the rest would be the publisher's problem. I didn't expect to have much left to do at this point. Instead I have to start almost from scratch!
Okay, it's not really "from scratch." The RotW system is well-defined and so are the Hammer and Spike features that I will be adding in; I'm not inventing a whole new game. But I still have to draw the map, define the cards, tune a scoring track (the scoring track in RRT/RotW is also the income track, so it affects the whole game economy), and fine-tune the H&S features (which, after all, were not originally designed for RotW). That's a lot to do. Fortunately I think it will be tremendous fun, and I've definitely been enjoying the process so far.
I've been told what part of the world the map must cover. Given that, I've been studying the history of the region, to see how the railroads grew there and what special conditions obtained. RotW is not a simulation game, so most of the historical detail is pretty useless; but I've gotten some ideas for the cards, and some notions on how to lay out the map (for example, the towns that were important to the railroads back then aren't always the ones that are largest or most important now). In fact I have more ideas than I'm going to be able to use. That's a good thing: it's better to have too much than to not have enough!
I've also been asked to try to make the H&S features into an optional variant that can be used with any RotW map, if you've got the rules and bits from my expansion. I've been testing that out on the Europe map, and I'm pleased to say that I think they will work.
Working on the board is going to be interesting. I've never made a prototype board this big before, and my usual cheap-and-dirty technique of printing it out on 8.5x11" sheets and taping them together may be too big a pain. I think this time I'm going to spend some money and have a print shop do it as a single big sheet, and then maybe have them laminate it so I can draw and erase on it easily. (No, it will not be as big as the original gargantuan RRT board. But it's not small either.)
Finally, and just to head off the questions: no, I don't know when it will be released. I just started working on it a couple of weeks ago! All I can tell you is that it will be a good long while, so there's no point in being impatient.
But yes, when I have it sufficiently developed, some of you will be able to playtest it. In fact, I'm counting on it!
But I suppose I can get away with some generalities. For one thing, I was mistaken in thinking that the expansion would be mostly designed by others; turns out it's mainly in my lap. The board, the cards, the variant rules, all of it. I'll have help and advice from the publisher's developers, of course.
This is not how I foresaw my first publication contract! I thought I'd design a game, get it mostly finished, then get it licensed. After that, just playtest and tweak until the publisher is happy; the rest would be the publisher's problem. I didn't expect to have much left to do at this point. Instead I have to start almost from scratch!
Okay, it's not really "from scratch." The RotW system is well-defined and so are the Hammer and Spike features that I will be adding in; I'm not inventing a whole new game. But I still have to draw the map, define the cards, tune a scoring track (the scoring track in RRT/RotW is also the income track, so it affects the whole game economy), and fine-tune the H&S features (which, after all, were not originally designed for RotW). That's a lot to do. Fortunately I think it will be tremendous fun, and I've definitely been enjoying the process so far.
I've been told what part of the world the map must cover. Given that, I've been studying the history of the region, to see how the railroads grew there and what special conditions obtained. RotW is not a simulation game, so most of the historical detail is pretty useless; but I've gotten some ideas for the cards, and some notions on how to lay out the map (for example, the towns that were important to the railroads back then aren't always the ones that are largest or most important now). In fact I have more ideas than I'm going to be able to use. That's a good thing: it's better to have too much than to not have enough!
I've also been asked to try to make the H&S features into an optional variant that can be used with any RotW map, if you've got the rules and bits from my expansion. I've been testing that out on the Europe map, and I'm pleased to say that I think they will work.
Working on the board is going to be interesting. I've never made a prototype board this big before, and my usual cheap-and-dirty technique of printing it out on 8.5x11" sheets and taping them together may be too big a pain. I think this time I'm going to spend some money and have a print shop do it as a single big sheet, and then maybe have them laminate it so I can draw and erase on it easily. (No, it will not be as big as the original gargantuan RRT board. But it's not small either.)
Finally, and just to head off the questions: no, I don't know when it will be released. I just started working on it a couple of weeks ago! All I can tell you is that it will be a good long while, so there's no point in being impatient.
But yes, when I have it sufficiently developed, some of you will be able to playtest it. In fact, I'm counting on it!
Tuesday, July 7, 2009
Publishing Update
Spatial Delivery
The publisher who has been reviewing Spatial Delivery has (after a year!) finally tested it, and tells me that they are currently looking for lighter games. They haven't quite said "get lost" and the prototype will be tested further at their main office, but the news is not encouraging.
I have contacts at a couple of other publishers who may be interested in Spatial Delivery. My home and life are going to be in some disarray over the next few weeks (we are remodeling) but after that, and if the current publisher hasn't changed their mind, I will build yet another prototype and see if I can get someone else to look at it.
Hammer and Spike
This one got licensed! It's not quite what I had envisioned, because it will not be published as a stand-alone game the way I designed it. Instead, some of its unique features will be folded into a game already being designed by some of the publisher's other developers. But I am not too disappointed: the license is the same as it would have been for a stand-alone game; my name (among others) will be on the box; and the combined product sounds very exciting. I am sure I will someday see a game of my own published, and this is a good first step in that direction.
Update to the update: I can now speak a bit more freely. Hammer and Spike will become a new expansion for the Railways of the World (RotW) game system. RotW is the new (and re-named) edition of Railroad Tycoon being published by FRED Distribution. I've been asked to design an expansion that will merge the unique features from Hammer and Spike with the familiar RotW system. If you've been following this blog, you know that Railroad Tycoon is my favorite game, so you can imagine how excited I am to be given this project!
Monday, May 25, 2009
My Designs at KublaCon 2009
Hammer and Spike suffered a setback recently, when we found a strategy that was successful, simple, and dead boring to play. To fix it I've adjusted the scoring. The bad news is that the scoring is now even more complex, but the good news is that the fix seems to be working. I hosted a four-player game at KublaCon that included a couple of new players and a couple of experienced train gamers, and I liked the way it played out. The winner was JC Lawrence, who also pointed out a problem I hadn't seen before (but which will be easily fixed, I think) and who gave some good feedback and advice.
And there is finally some news about the fate of Spatial Delivery. In our last episode (and the one before that, and the one before that...), the prototype had been sent off to a publisher shortly after winning the KublaCon game design contest in 2008. There followed nearly a full year of dead silence. I restrained myself from attempting to contact the publisher, reasoning that publishers were busy, they'd get to it when they had a chance, and there was no point in making a pest of myself. But this weekend I spoke to a company rep and learned that they'd recently had to fire a clerical worker for incompetence. This worker had made any number of bad-for-business mistakes, and one of them was losing my prototype (along with my contact info, of course). Fortunately the rep I spoke to was the very person who should have received the prototype in the first place. I had just built a new copy and had it with me hoping to play it, but instead I gave it to the rep. He told me it would be played next weekend and that I would hear something back within just a few weeks. So Spatial Delivery is back on track!
Now I just have to hope that the publisher actually likes it. But if they don't, I have a backup opportunity. The KublaCon contest director tells me that she has been talking the game up to a second publisher. I'm going to stick with the first until they make up their minds (at least, if it doesn't take another year for them to do so), but I would be perfectly happy to go with the second publisher if things fall out that way.
The lesson learned is obvious: keep in touch. I still think it's a bad idea to be a pest, but from now on any such publisher who hasn't contacted me within the last three months will hear from me. I don't intend to lose an entire year again.
And now I have two designs being actively evaluated by two publishers, and backup publishers for both. Cross your fingers for me! I'm hoping to have at least one game on its way to market, maybe two, by next year's KublaCon.
Sunday, May 10, 2009
Fires and Recordings and In-laws
I've felt all this past week as if I should be blogging, but I've been too busy and too distracted. The Jesusita Fire in Santa Barbara has occupied much of my attention. The fire not only devastated the foothills, but threatened the town itself. The neighborhood where I grew up was within a mile or or of the fire's perimeter and was under mandatory evacuation for a while; some friends of mine were also prepared to evacuate. I am saddened by the damage to the Botanical Garden, which was one of my favorite places; but it wasn't completely destroyed and I hope the damaged areas will be rebuilt and replanted. The fire is still in progress and is less than 50% contained, but the threat now seems to have lessened and the fire has moved north and west rather than south towards the town and suburbs, so things are looking up.
The in-laws paid us a visit on Friday and Saturday. I'm always happy to see them, and this brief visit was in part to deliver a car we bought from them for our son to use at college next year. We had a couple of nice dinners, some good conversation, and some excellent games with Joan. Although I was feeling a bit overwhelmed and wished the visit could have come either last weekend or next, it all worked out. I even found time to practice.
Why practice? Because on Monday and Tuesday, I'll be recording with Ted Shafer's Jelly Roll Jazz Band. For most of the group, this is a "ho-hum, another recording" event, but for me it's a very big deal. I have recorded before, but never in such professional surroundings; and I have only rarely been privileged to play with such a fine group of musicians. I definitely feel like the junior member of the group (my actual age notwithstanding) and am mostly hoping not to embarrass myself. Fortunately for all concerned I'll be playing second cornet, and for good or ill my efforts won't be too prominent. This, along with the fire, has been the main thing on my mind all week. I've been working hard on it, both at rehearsals and at home.
On the game design front there is little news. I now have two designs in the hands of publishers, and I'm back in the "hurry up and wait" mode. I have nearly completed the Spatial Delivery prototype (still have to paint the spaceships) that I'm building just to have handy, and I finally got off the dime and sent Seth his promised copy of Hammer and Spike. I'm looking forward to his group's feedback on that one.
And that's all for now. I gotta go practice!
The in-laws paid us a visit on Friday and Saturday. I'm always happy to see them, and this brief visit was in part to deliver a car we bought from them for our son to use at college next year. We had a couple of nice dinners, some good conversation, and some excellent games with Joan. Although I was feeling a bit overwhelmed and wished the visit could have come either last weekend or next, it all worked out. I even found time to practice.
Why practice? Because on Monday and Tuesday, I'll be recording with Ted Shafer's Jelly Roll Jazz Band. For most of the group, this is a "ho-hum, another recording" event, but for me it's a very big deal. I have recorded before, but never in such professional surroundings; and I have only rarely been privileged to play with such a fine group of musicians. I definitely feel like the junior member of the group (my actual age notwithstanding) and am mostly hoping not to embarrass myself. Fortunately for all concerned I'll be playing second cornet, and for good or ill my efforts won't be too prominent. This, along with the fire, has been the main thing on my mind all week. I've been working hard on it, both at rehearsals and at home.
On the game design front there is little news. I now have two designs in the hands of publishers, and I'm back in the "hurry up and wait" mode. I have nearly completed the Spatial Delivery prototype (still have to paint the spaceships) that I'm building just to have handy, and I finally got off the dime and sent Seth his promised copy of Hammer and Spike. I'm looking forward to his group's feedback on that one.
And that's all for now. I gotta go practice!
Saturday, May 2, 2009
Progress Report: Not Much
It's been a while since my last post, so I thought I'd issue a brief update, to wit: not much news here. After the excitement of GameStorm and the rush to get a copy of Hammer and Spike off to certain interested parties, little has happened. I've made two new copies (one for me, one for Seth), but haven't had much time to actually play or work with the game.
I've also been building a new copy of Spatial Delivery. I haven't had one since I sent my last copy to a publisher, last June. Having heard nothing since then, I figure it's time to give it some attention. I have no immediate plans for it except to start playing it again, but I should at least have a copy of my own, yes?
Hammer and Spike did get another playtest today, at the Los Altos Games Day. The day was great fun, as always. Helen and I particularly enjoyed a session of Age of Empires III, an excellent game that we've neglected for too long. I finished the day with the four-player H&S session, which seemed to go well on the whole. It did run kind of long, but perhaps that can be chalked up to having three newbies in the game. They all picked it up pretty well, and by the end were building fuel depots and switchyards and making the long deliveries like veterans. Two of them said they would happily play it again sometime, which is always nice to hear (although you have to make allowances; sometimes people are just being polite to the game designer who, after all, is standing right there). A couple of folks who stopped by to watch also expressed interest in playing the game, so I can hope to have more guinea pigs playtesters soon.
It was a good day!
I've also been building a new copy of Spatial Delivery. I haven't had one since I sent my last copy to a publisher, last June. Having heard nothing since then, I figure it's time to give it some attention. I have no immediate plans for it except to start playing it again, but I should at least have a copy of my own, yes?
Hammer and Spike did get another playtest today, at the Los Altos Games Day. The day was great fun, as always. Helen and I particularly enjoyed a session of Age of Empires III, an excellent game that we've neglected for too long. I finished the day with the four-player H&S session, which seemed to go well on the whole. It did run kind of long, but perhaps that can be chalked up to having three newbies in the game. They all picked it up pretty well, and by the end were building fuel depots and switchyards and making the long deliveries like veterans. Two of them said they would happily play it again sometime, which is always nice to hear (although you have to make allowances; sometimes people are just being polite to the game designer who, after all, is standing right there). A couple of folks who stopped by to watch also expressed interest in playing the game, so I can hope to have more guinea pigs playtesters soon.
It was a good day!
Saturday, April 4, 2009
GameStorm Photos
Chris Brooks posted a great report on his experience at GameStorm 11, and published quite a few photos on Flickr. Someone let me know that the photos included a shot of one of the playtests of Hammer and Spike — that's me on the right.
Wednesday, April 1, 2009
GameStorm Fallout
GameStorm was a lot of fun, but I haven't had a chance to relax or breathe until now. Although I brought along Hammer and Spike mainly to show it to Seth, it wound up attracting a good deal more attention than I expected, and some of it was industry attention. The upshot was that after driving 13 hours to get home yesterday, we spent most of today frantically assembling another copy to send to someone who had requested it, and who needed it this weekend. We just got that done and shipped about an hour ago. Another person has also requested a copy, but less urgently, so we'll be making and shipping another in the near future.
This is all very gratifying, and quite astonishing to me. I simply did not expect it, and wasn't prepared for it. It was Helen who saved the day. She invented an amazing new way to make certain prototype bits, and got up this morning and drove around town collecting supplies and packing materials; then returned home and sewed up a couple of drawstring bags (emerging victorious over a cranky sewing machine), reviewed and corrected the rulebook, and finally drove us to the shipping office, just in time. We literally watched them slapping the last stickers on while the UPS guy held the box for them. I could not possibly have done all this without her, and would not have dared to try.
So now it's hurry up and wait again, I guess, just like it's been with Spatial Delivery for the last eight or nine months. If anything comes of it, I'll let y'all know. In the meantime I have to make two more prototypes (one's for me, as I cannibalized some of my original) and get in a lot more playtesting... oh yeah, and I have to run off to a rehearsal tonight.
This is all very gratifying, and quite astonishing to me. I simply did not expect it, and wasn't prepared for it. It was Helen who saved the day. She invented an amazing new way to make certain prototype bits, and got up this morning and drove around town collecting supplies and packing materials; then returned home and sewed up a couple of drawstring bags (emerging victorious over a cranky sewing machine), reviewed and corrected the rulebook, and finally drove us to the shipping office, just in time. We literally watched them slapping the last stickers on while the UPS guy held the box for them. I could not possibly have done all this without her, and would not have dared to try.
So now it's hurry up and wait again, I guess, just like it's been with Spatial Delivery for the last eight or nine months. If anything comes of it, I'll let y'all know. In the meantime I have to make two more prototypes (one's for me, as I cannibalized some of my original) and get in a lot more playtesting... oh yeah, and I have to run off to a rehearsal tonight.
Saturday, March 28, 2009
GameStorm 2009 at Halftime
This weekend I'm at the GameStorm boardgame convention, ostensibly in Oregon but actually just over the border in Vancouver Washington. For me the high points so far have been seeing my in-laws (Joan is an avid gamer), gaming with my design buddy Seth Jaffee, and presenting Hammer and Spike.
GameStorm has a "GameLab" track for game designers and playtesters. I got an appointment to present Hammer and Spike to a panel of local game publishers, not so much in hopes of getting it published but in order to get feedback on the game and its presentation. It was a good session, maybe 20 to 30 minutes. I got good advice and answers to a few questions I had about the industry. (For example, I learned that the game duration shown on a game's box is for new players, not experienced ones! I didn't know that.) There wasn't time to play the game so the panel doesn't really know if a game is any good. But they were impressed with what they saw, which was very gratifying; and I got invited to bring Hammer and Spike to an invitation-only playtest session on Sunday (tomorrow, as I write this) for the best of the games they have reviewed this weekend.
I had one informal playtest yesterday with Seth, his friend Jeremy, Joan, and myself. It went well, but we all agreed that it went too long. I currently set the game at a constant 20 rounds, but the game was definitely "over" after 17 or 18 rounds. This is a point I've been dithering over, and I now think that 20 really is probably too many. I'm going to try 18 for a while: a bigger cut than it sounds like, since the last rounds are analysis-paralysis festivals and take way longer than earlier rounds. I still want a typical game to come in at 2 hours or less.
It's now Saturday morning, and I'm looking forward to playing some of Seth's designs: Terra Prime, Homesteaders, and/or Brain Freeze. I played Terra Prime two years ago and I'm eager to see the changes he's made since then. Homesteaders (designed by Alex Rockwell, but Seth helped with development) and Brain Freeze are games I haven't played yet, and I'm eager to see them.
I'll update this post with a few links later on, but right now it's time to gather our aggies and head for the con. Game on!
P.S. Saturday evening—I've added those links, and here's another: Seth's GameStorm reports.
GameStorm has a "GameLab" track for game designers and playtesters. I got an appointment to present Hammer and Spike to a panel of local game publishers, not so much in hopes of getting it published but in order to get feedback on the game and its presentation. It was a good session, maybe 20 to 30 minutes. I got good advice and answers to a few questions I had about the industry. (For example, I learned that the game duration shown on a game's box is for new players, not experienced ones! I didn't know that.) There wasn't time to play the game so the panel doesn't really know if a game is any good. But they were impressed with what they saw, which was very gratifying; and I got invited to bring Hammer and Spike to an invitation-only playtest session on Sunday (tomorrow, as I write this) for the best of the games they have reviewed this weekend.
I had one informal playtest yesterday with Seth, his friend Jeremy, Joan, and myself. It went well, but we all agreed that it went too long. I currently set the game at a constant 20 rounds, but the game was definitely "over" after 17 or 18 rounds. This is a point I've been dithering over, and I now think that 20 really is probably too many. I'm going to try 18 for a while: a bigger cut than it sounds like, since the last rounds are analysis-paralysis festivals and take way longer than earlier rounds. I still want a typical game to come in at 2 hours or less.
It's now Saturday morning, and I'm looking forward to playing some of Seth's designs: Terra Prime, Homesteaders, and/or Brain Freeze. I played Terra Prime two years ago and I'm eager to see the changes he's made since then. Homesteaders (designed by Alex Rockwell, but Seth helped with development) and Brain Freeze are games I haven't played yet, and I'm eager to see them.
I'll update this post with a few links later on, but right now it's time to gather our aggies and head for the con. Game on!
P.S. Saturday evening—I've added those links, and here's another: Seth's GameStorm reports.
Monday, March 23, 2009
Adventures in Prototyping
My game design blogging has a split personality; much of it goes here, but some also goes up at the Board Game Designers Forum. This weekend I made a more durable board for the Nameless Rail Game, and chronicled the effort in some detail in my journal there. I felt that the content was of more interest to hard-core designers than to the more general crowd that reads this site, but if you're interested, follow the link.
I made the board because a flat, stiff, foldable board is a lot easier to transport than the taped-together big sheets of paper I've been making for home use. Helen and I are about to head up to Oregon to visit family and attend GameStorm, where I hope to get more playtesting done.
And the beast may finally have a name. The new board is labeled Hammer and Spike, which may not be great but is not in use by any other games. It will serve until and unless I hear a distinctly better suggestion. My thanks to all those who suggested alternate names, but I have to live with Helen and she didn't like some of them, so Hammer and Spike it is.
I made the board because a flat, stiff, foldable board is a lot easier to transport than the taped-together big sheets of paper I've been making for home use. Helen and I are about to head up to Oregon to visit family and attend GameStorm, where I hope to get more playtesting done.
And the beast may finally have a name. The new board is labeled Hammer and Spike, which may not be great but is not in use by any other games. It will serve until and unless I hear a distinctly better suggestion. My thanks to all those who suggested alternate names, but I have to live with Helen and she didn't like some of them, so Hammer and Spike it is.
Saturday, March 7, 2009
Picking Up Steam
Two more live playtests, at the Los Altos Games Day! The game was well received, and I was quite pleased with the results.
The changes I made after last week's session worked well. Playtime came in at about two hours, and I suspect would be a bit shorter with experienced players. Players successfully built transcontinental networks and made coast-to-coast deliveries by the end of the game. A few switchyards were built in each game, but never all six. That all seemed just right.
On the down side, my long-standing worries that the scoring system is badly balanced were borne out. The reward for connecting all six cities is so high that a player who fails to do so is almost guaranteed to lose. This would be okay except that it's usually clear which players will fail by around halfway through the game. It's no fun being the goat in a game in which there is almost always one designated goat.
The way to fix that is probably to raise the VP reward for building switchyards. The trailing player has an advantage here, in a way: if he is flexible enough to give up on the six-city goal early enough, he will save several actions and a fair amount of cash. He can then devote those resources to switchyard building, and remain competitive with the six-city players.
I have also recently revised the simulator to play by the new rules, and run another couple hundred thousand simulations or so. These were, as before, mostly explorations of balance. It has become quite clear that an intelligent first player has a huge advantage over his opponents, because the choice of starting locations is not even remotely balanced. This isn't unusual for rail games. The simulations show that it can be balanced by giving the players differing amounts of starting cash. In the game rules, I expect I will express this in two ways: a "standard game" in which the starting cash is simply dictated by the rules, and an "advanced game" in which the players hold an initial auction for turn order. Players will use the standard rules until they feel qualified to judge fine differences in starting positions, and can then advance to the auction rules. (Unlike Age of Steam and Railroad Tycoon, I don't think this game needs a turn-order auction every round. One at the start of the game should be sufficient, and the turn order need not change after that.)
Finally, I came away with a clear understanding about the current inadequacies of the board graphics and the player aids. This is not part of game design (since I have no plans to self-publish), but a well-made prototype really helps newbies concentrate on the game instead of on decoding the board and remembering the rules. I have some ideas for improvements, and I will be playing around in Photoshop to try to turn those ideas into clear graphics.
The changes I made after last week's session worked well. Playtime came in at about two hours, and I suspect would be a bit shorter with experienced players. Players successfully built transcontinental networks and made coast-to-coast deliveries by the end of the game. A few switchyards were built in each game, but never all six. That all seemed just right.
On the down side, my long-standing worries that the scoring system is badly balanced were borne out. The reward for connecting all six cities is so high that a player who fails to do so is almost guaranteed to lose. This would be okay except that it's usually clear which players will fail by around halfway through the game. It's no fun being the goat in a game in which there is almost always one designated goat.
The way to fix that is probably to raise the VP reward for building switchyards. The trailing player has an advantage here, in a way: if he is flexible enough to give up on the six-city goal early enough, he will save several actions and a fair amount of cash. He can then devote those resources to switchyard building, and remain competitive with the six-city players.
I have also recently revised the simulator to play by the new rules, and run another couple hundred thousand simulations or so. These were, as before, mostly explorations of balance. It has become quite clear that an intelligent first player has a huge advantage over his opponents, because the choice of starting locations is not even remotely balanced. This isn't unusual for rail games. The simulations show that it can be balanced by giving the players differing amounts of starting cash. In the game rules, I expect I will express this in two ways: a "standard game" in which the starting cash is simply dictated by the rules, and an "advanced game" in which the players hold an initial auction for turn order. Players will use the standard rules until they feel qualified to judge fine differences in starting positions, and can then advance to the auction rules. (Unlike Age of Steam and Railroad Tycoon, I don't think this game needs a turn-order auction every round. One at the start of the game should be sufficient, and the turn order need not change after that.)
Finally, I came away with a clear understanding about the current inadequacies of the board graphics and the player aids. This is not part of game design (since I have no plans to self-publish), but a well-made prototype really helps newbies concentrate on the game instead of on decoding the board and remembering the rules. I have some ideas for improvements, and I will be playing around in Photoshop to try to turn those ideas into clear graphics.
Saturday, February 21, 2009
I Got Game
Saturday the long-awaited live playtest of the nameless rail game finally happened, and I'm pleased to report that it went very well. My playtesters were Candy Weber, John Portley, Helen, and myself. (John and Candy brought designs of their own that we also tried, and those went well too. But I don't know if they want Internet coverage, so I'm just going to talk about mine for now.)
There was good news, and bad news. The good news was that all players agreed that the game presented interesting and difficult decisions; it wasn't just a matter of turning the crank. (I was worried about that.) The bad news was that it took over three and a half hours to play!
Everyone was very nice about the length of it, and pointed out that it was a learning game for everyone except me, and that we also stopped periodically to discuss the design. True, but I think those excuses only go so far. I don't want the game to last more than two hours. In my playtesting it usually takes only two hours. But you have to allow time for people to chat, and I also don't want a newbie's first experience to be a marathon. So I'm going to give some attention to speeding up play. This probably means reducing the number of rounds and tweaking things to allow players to get stuff done in fewer turns. I received some very good suggestions about how to accomplish that, and I intend to try them out. The best idea I heard was to change a couple of actions into non-actions, so that you can get a bit more done in your turn. I think that will not only speed things up, but also remove some of the major sources of player frustration that I observed.
Between those suggestions and a few tweaks of my own that I've been thinking about for a while, I have a laundry list of things to experiment with. But none of these items are major changes; they all amount to streamlining of one kind or another. I'll try them out in solo play over the next week or two, to see which ones help and which don't. In two weeks there's a Games Day, and I'll probably bring the latest version to that and see if I can get another live test. After that I can bring it to GameStorm in Portland at the end of March, and eventually KublaCon at the end of May. I can hope that by then it will be pretty stable.
There was good news, and bad news. The good news was that all players agreed that the game presented interesting and difficult decisions; it wasn't just a matter of turning the crank. (I was worried about that.) The bad news was that it took over three and a half hours to play!
Everyone was very nice about the length of it, and pointed out that it was a learning game for everyone except me, and that we also stopped periodically to discuss the design. True, but I think those excuses only go so far. I don't want the game to last more than two hours. In my playtesting it usually takes only two hours. But you have to allow time for people to chat, and I also don't want a newbie's first experience to be a marathon. So I'm going to give some attention to speeding up play. This probably means reducing the number of rounds and tweaking things to allow players to get stuff done in fewer turns. I received some very good suggestions about how to accomplish that, and I intend to try them out. The best idea I heard was to change a couple of actions into non-actions, so that you can get a bit more done in your turn. I think that will not only speed things up, but also remove some of the major sources of player frustration that I observed.
Between those suggestions and a few tweaks of my own that I've been thinking about for a while, I have a laundry list of things to experiment with. But none of these items are major changes; they all amount to streamlining of one kind or another. I'll try them out in solo play over the next week or two, to see which ones help and which don't. In two weeks there's a Games Day, and I'll probably bring the latest version to that and see if I can get another live test. After that I can bring it to GameStorm in Portland at the end of March, and eventually KublaCon at the end of May. I can hope that by then it will be pretty stable.
Tuesday, February 17, 2009
Know the score!
A game's scoring system is what motivates the players. It's the carrot that the designer dangles in front of the players, to entice them to go where he wants them to go. A large part of the work I've put into the nameless rail game has been tweaking the scoring system. I want players to build wide, continent-spanning networks, and use their networks to make long deliveries. I want them to compete with each other for the best routes and for connections to cities that not everyone will be able to reach. I want to inspire track-building races.
The scoring system has to reward this kind of behavior. But to be really good, it needs to do more. Jonathan Degann has written about the "big bomb" notion in scoring. A "big bomb" (put simply) is a high-scoring accomplishment that more than one player can strive for, but only one can achieve. Ideally the competition to claim the "bomb" involves some commitment from the competing players: the player who succeeds will see his investment pay off big, while the others will lose whatever they invested. This makes tension during the competition, and a big emotional pay-off when it's over: triumph or tragedy. Drama!
In the nameless rail game, I have been motivating players to build wide networks by designating six widely-separated junctions as cities (as opposed to mere towns). Players are rewarded with victory points for the number of cities in their network at the end of the game. Each additional city gives a bigger bonus than the previous. The first three or four cities are easy to get to, and the rewards are small. The fifth is harder, and gives a big slug of points. The sixth is hardest of all, and yields a really big slug of points. The board is laid out so that not every player can connect to every city, so the competition for fifth and especially sixth cities is fierce. This is one form of Degann's big bomb: for much of the game, players are racing to get to all six cities. Getting there first not only guarantees that you get the big reward, it also virtually guarantees that somebody else won't get there at all.
But I didn't want that to be the only way to get a big score, so I added another kind of bomb. This notion took me longer to come up with, and many iterations to refine. (I'm probably still not done with it.) It is the switchyard. Each of the six cities may have one switchyard built there. The player who builds it gets a big VP reward. This counts as a bomb because only one player can do it (per city), and because of the obstacles that must be overcome before the switchyard can be built.
First, you can't even start trying to build a switchyard until at least two players are connected to the target city. That guarantees competition. Second, you can't build a switchyard until you have made at least one delivery to that city of each of the four different kinds of good. Therein lies the race and much of the tension. Finally, after finishing the prerequisite deliveries, you need to come up with a big payment. Often two players will both finish the deliveries, and then it's a matter of who comes up with the cash first. The player who does will roughly double the value of his cash, while any who don't have wasted much of their effort.
I'd like to make that race more poignant if I can. There's more tension if the players have to invest something real in order to compete for the bomb. Currently, the only real investment is that players may forgo more lucrative deliveries in favor of ones that fill their switchyard prerequisites. And maybe that's enough. But I am considering making the players pay a piece of the switchyard cost up front, every time they "record" a delivery. The total cost of the switchyard is still the same, but you would have to pay some of it just to try to build the switchyard; and if you fail, you won't get any refunds.
What worries me about this notion is that it may become a disincentive: the potential loss may frighten players away from trying to compete for switchyards. If so I might try to lead them into the commitment gently: charge only a little for the first delivery, so it feels safe. But now the player is invested and wants to protect the investment, so if someone starts to compete he may be willing to pay a little more to keep up, and so on. I dunno, I'll have to try it and see how it goes!
Wednesday, February 11, 2009
How many players?
I have a habit of designing my multi-player games for a "sweet spot" of four players, and then testing and tweaking to see whether they will also gracefully support more or fewer players. While I don't recall this being a conscious decision, it makes sense to me. Four is a nice, balanced number: two couples, or a family with two kids. It can mitigate the excessive downtime that some games suffer with more players, and avoids the two-against-one dynamic that can ruin a lot of three-player experiences.
But I don't want to design exclusively for four. Any game will sell better if it can be labeled for "3 to 5" or "2 to 6" players. And any game will be more popular if it actually works for the given range. (All experienced gamers have seen games that really don't play well at the low or high end of the claimed range.)
So recently I broke from my usual simulated four-player rail game sessions, and tried a five- and a three- player to see what would happen. I'm pleased to say that the game survived, and seemed playable. But unsurprisingly the game gives a different experience with different numbers of players.
With four, I've tried to tune things so that the winning player will likely connect all six cities, and build a switchyard: the two highest-scoring achievements. Usually two of the remaining players will get one or the other goal, but not both; and one player will get neither. This makes for vigorous competition to link up the cities, which is one of my design goals. It also often results that most players have little money left at the end of the game: although money is also worth victory points, you're usually better off spending it on connectivity or switchyards if you can. The losing player may actually finish with the most money, having been unable to spend as much of his income on connectivity and switchyards as the others; but sometimes such a player prospers so well just making deliveries that his cash hoard pulls his score up into the middle of the pack.
In the three-player game, there was much more elbow room. All players were able to connect all cities, which soaked up more time and money than in the usual 4p game. It was a less competitive, more open game. I found that I prefer the four-player experience, but some players may enjoy the easier, free-wheeling nature of the 3p game.
In the 5p game, the board was crowded and tight, and competition for connectivity was fierce. Only one player connected all six cities. Also the board filled with track rather faster than in the 4p game, so players could tell early on when (for example) it was clearly impossible for them to reach New York or Seattle. That meant more concentration on switchyards: five were built, and one player built two. This game ended with a lot of money in circulation, because more players were simply making deliveries in the late game rather than building.
Unsurprisingly, the game seems to have a different character depending on the number of players. With three, it's relatively open and easy-going. With four, competition is tight but most players are going to be able to do well. With five, money is tight in the early game as players race for connectivity, then piles up in the late game as players concentrate on lucrative deliveries.
J. C. Lawrence says a game should end when the winner is clear. I think he's right, so I was watching these games to see whether they ended too soon or too late. In the 4p game, 20 rounds seems exactly right. (I originally had a variable end-of-game trigger based on running out of goods, but decided it didn't work well.) I'm prepared to alter the 20-round figure for the 3p or 5p games, but so far it seems to hold up. The 5p game, for example, might have ended at 17 rounds; but then some serious new delivering and building took place in round 20, enough to convince me that the final three rounds weren't empty activity.
Another way to balance the game for different player counts is to alter the map. A smaller map for a 3p (or 2p) game, a larger one for 5 or 6. I haven't gone there yet, but of course I have the possibility in mind. Completely different maps is one way to do it, but it might also work to vary the main map by adding or removing junctions and connections. But before I go there, I want to shake down the current design some more. When (if!) I'm really comfortable with the 4p game, I'll look harder at variations to improve the experience with other player counts.
But I don't want to design exclusively for four. Any game will sell better if it can be labeled for "3 to 5" or "2 to 6" players. And any game will be more popular if it actually works for the given range. (All experienced gamers have seen games that really don't play well at the low or high end of the claimed range.)
So recently I broke from my usual simulated four-player rail game sessions, and tried a five- and a three- player to see what would happen. I'm pleased to say that the game survived, and seemed playable. But unsurprisingly the game gives a different experience with different numbers of players.
With four, I've tried to tune things so that the winning player will likely connect all six cities, and build a switchyard: the two highest-scoring achievements. Usually two of the remaining players will get one or the other goal, but not both; and one player will get neither. This makes for vigorous competition to link up the cities, which is one of my design goals. It also often results that most players have little money left at the end of the game: although money is also worth victory points, you're usually better off spending it on connectivity or switchyards if you can. The losing player may actually finish with the most money, having been unable to spend as much of his income on connectivity and switchyards as the others; but sometimes such a player prospers so well just making deliveries that his cash hoard pulls his score up into the middle of the pack.
In the three-player game, there was much more elbow room. All players were able to connect all cities, which soaked up more time and money than in the usual 4p game. It was a less competitive, more open game. I found that I prefer the four-player experience, but some players may enjoy the easier, free-wheeling nature of the 3p game.
In the 5p game, the board was crowded and tight, and competition for connectivity was fierce. Only one player connected all six cities. Also the board filled with track rather faster than in the 4p game, so players could tell early on when (for example) it was clearly impossible for them to reach New York or Seattle. That meant more concentration on switchyards: five were built, and one player built two. This game ended with a lot of money in circulation, because more players were simply making deliveries in the late game rather than building.
Unsurprisingly, the game seems to have a different character depending on the number of players. With three, it's relatively open and easy-going. With four, competition is tight but most players are going to be able to do well. With five, money is tight in the early game as players race for connectivity, then piles up in the late game as players concentrate on lucrative deliveries.
J. C. Lawrence says a game should end when the winner is clear. I think he's right, so I was watching these games to see whether they ended too soon or too late. In the 4p game, 20 rounds seems exactly right. (I originally had a variable end-of-game trigger based on running out of goods, but decided it didn't work well.) I'm prepared to alter the 20-round figure for the 3p or 5p games, but so far it seems to hold up. The 5p game, for example, might have ended at 17 rounds; but then some serious new delivering and building took place in round 20, enough to convince me that the final three rounds weren't empty activity.
Another way to balance the game for different player counts is to alter the map. A smaller map for a 3p (or 2p) game, a larger one for 5 or 6. I haven't gone there yet, but of course I have the possibility in mind. Completely different maps is one way to do it, but it might also work to vary the main map by adding or removing junctions and connections. But before I go there, I want to shake down the current design some more. When (if!) I'm really comfortable with the 4p game, I'll look harder at variations to improve the experience with other player counts.
Monday, February 2, 2009
Rails: Ready to Roll?
This weekend I put in some more hours on the rail game (now code-named "Iron Horse With No Name" until I settle on a new title). I'm pretty pleased with the results.
It continues to surprise me how much difference a small rule tweak can make sometimes. I recently introduced the notion that deliveries can only go so far without "refueling." You refuel at Stations, which hold Fuel cubes. Each time you refuel, you consume a Fuel cube and your delivery is able to continue for up to another three towns. With multiple refuelings, very long (and very profitable) deliveries can be made. Refueling from your own Station is free; to use someone else's Station, you pay them $2 (equal to a little less than half a Victory Point). When a Station is emptied of Fuel cubes you can pay to refill it.
But a solo playtest with this mechanism produced a game that moved too slowly, and that bogged down at the end. There was not enough incentive to build Stations—every player wanted to wait for the other players to build them—so the long, high-paying deliveries could not be made.
I reworked the costs and benefits to make Stations more attractive, but then I started to worry: maybe the Fuel cubes were unnecessary mechanism. Why not get rid of them and simply always allow refueling at every Station? So I tried that next, and it almost worked. I got the wide networks and long deliveries I wanted. But the players' decisions were not challenging enough. Stations with exhaustible fuel added complexity and interest to those decisions.
So I tried again, putting Fuel back in the game but with the new costs and benefits I'd worked out. And that, thankfully, seems to work. The latest solo playtest had interesting and challenging decisions, players were able to build the big networks and reap the big profits I was after, and the game never bogged down.
Well... I think the decisions were interesting and challenging. I find that very hard to gauge when all the players are me. But I believe it's finally time for some live playtests. (Huzzah!) So I'm going to spend the next week or so re-drawing the board and creating some good player aids, and then I'll start bringing it to local game days and nights and see what other folks think of it.
It continues to surprise me how much difference a small rule tweak can make sometimes. I recently introduced the notion that deliveries can only go so far without "refueling." You refuel at Stations, which hold Fuel cubes. Each time you refuel, you consume a Fuel cube and your delivery is able to continue for up to another three towns. With multiple refuelings, very long (and very profitable) deliveries can be made. Refueling from your own Station is free; to use someone else's Station, you pay them $2 (equal to a little less than half a Victory Point). When a Station is emptied of Fuel cubes you can pay to refill it.
But a solo playtest with this mechanism produced a game that moved too slowly, and that bogged down at the end. There was not enough incentive to build Stations—every player wanted to wait for the other players to build them—so the long, high-paying deliveries could not be made.
I reworked the costs and benefits to make Stations more attractive, but then I started to worry: maybe the Fuel cubes were unnecessary mechanism. Why not get rid of them and simply always allow refueling at every Station? So I tried that next, and it almost worked. I got the wide networks and long deliveries I wanted. But the players' decisions were not challenging enough. Stations with exhaustible fuel added complexity and interest to those decisions.
So I tried again, putting Fuel back in the game but with the new costs and benefits I'd worked out. And that, thankfully, seems to work. The latest solo playtest had interesting and challenging decisions, players were able to build the big networks and reap the big profits I was after, and the game never bogged down.
Well... I think the decisions were interesting and challenging. I find that very hard to gauge when all the players are me. But I believe it's finally time for some live playtests. (Huzzah!) So I'm going to spend the next week or so re-drawing the board and creating some good player aids, and then I'll start bringing it to local game days and nights and see what other folks think of it.
Saturday, January 24, 2009
Concerning Rail Games
I've made more progress on "The-Rail-Game-Formerly-Known-As-Rails-Across-America". The biggest problem I've had with it lately is just that it seems uninspired overall, and perhaps doesn't offer enough interesting or difficult choices to the players. Recently a friend made an encouraging comment, and that gave me some new ideas, and the latest iteration is looking better. It's still a live design.
But it set me to thinking. How interesting, and how difficult, do the choices have to be in order to have a fun and playable game? I tried a wargame design once; it was judged by the KublaCon playtesters to be boring because the decisions were obvious and easy to make. I don't want to repeat that mistake. On the other hand, while it's good to have ambitious goals, as a fledgling designer I can't expect to design the next #1 game at BoardGameGeek. So how good is "good enough"?
For an answer I am looking at my own favorites among the published rail games. These are:
* Ticket to Ride
* The crayon rail games (Empire Builder and its sequels)
* Railroad Tycoon
* Age of Steam
* The 18XX games
* Silverton
What kind of game experience do these successful games offer?
Ticket to Ride has simple rules and simple play, and is over in an hour. At times you spend move after move simply drafting cards into your hand. Your decisions are mostly of the push-your-luck variety: should you grab that route now, before someone else does? Or wait until you can grab several connected routes in quick succession, so as not to tip your hand too soon? The fun comes mainly from the tension of that basic decision. And it is fun, without a doubt. The Ticket to Ride series is far and away the most commercially-successful rail game ever. So we learn this: Tension lends interest and excitement.
Empire Builder and its sequels are straight-forward games of building track and making deliveries. These are flawed games, in my opinion. They take too long to play, especially if you make the mistake of playing with more than four players. There is little player interaction: you don't have to worry very much about what your opponents are doing. And the decisions are simple: which of my nine potential deliveries is the best to do next? Where should I built my next track? Is it time to upgrade my locomotive? The answers are usually fairly obvious, once you've done the gruntwork of figuring out sources and destinations for your potential deliveries (which usually is a lot of work: another flaw). And yet the crayon rail games are fun anyway, popular enough to have spawned a dozen or so sequels, and due to be re-issued this year by Mayfair. Lesson learned: A game can be fun even if its choices are not difficult. Sometimes the activity itself is entertainment enough.
Age of Steam is an amazingly good game, at least if you enjoy high levels of competition. Often described as "a knife fight in a phone booth", AoS crowds players together and forces them to compete viciously for routes and deliveries. A tight economic system makes budgeting a challenging and crucial exercise, and an auction system that controls both player order and access to important actions adds tremendous tension. Lesson learned: Holzgrafe, you will never design a rail game this good! More seriously: budgeting and pacing issues add interest to a game, and player interaction is important.
Railroad Tycoon is my favorite. This game has the same basic notion as Empire Builder (build rail, then make deliveries) but avoids the flaws in the crayon rail system. Spotting viable deliveries is easy and quick; the choices are interesting and difficult; and the game does not outlast its fun factor, even with six players. It has excellent player interaction, because players must compete for track routes, deliveries, and bonuses. It's really more appropriate to compare RRT with Age of Steam because it is directly derived from AoS. RRT is less competitive than AoS. But if Age of Steam is "a knife fight in a phone booth", Railroad Tycoon is still at least a barroom brawl: more spacious and forgiving of errors, but still highly contentious and with plenty of chairs and tables to swing. Lesson learned, from both AoS and RRT: Competition for scarce resources makes for tough, interesting choices.
The 18XX series adds a new element: a stock market. In an 18XX game players build rail and make deliveries. Players compete mainly to acquire stock, drive up the value of companies in which they are heavily invested, and sell high-valued stock to reap the gains and ruin the stock's value for others who still own shares. 18XX games are complex, long, and deeply strategic. I have played only once and I'm not competent to discuss them in detail, but there is a lesson learned: A volatile, interactive market adds a whole new level of interest to a game.
Silverton is the rail game that has most recently grabbed my attention, although it's now over 15 years old. Silverton features a volatile market, but it is a goods market rather than a stock market. Players compete not only to lay track, but to claim mines. Mines are worked to produce goods, which you then convert to money by delivering to market cities. Market prices vary, partly at random and partly influenced by recent sales. Taking a big load to market can drop market prices ruinously for anyone who shows up late. Silverton combines a fairly standard build-and-deliver mechanism with features such as the market, the high-risk nature of mining, and the difficulties of winter operations in the Rockies, resulting in a fascinating game with good levels of player interaction. Lesson learned: Volatility forces pacing, making players choose between urgent actions and important actions.
So what does this all imply for my own design? I'm still evaluating that, but I'm encouraged. My latest rules revision (with the compelling sobriquet of "Straw Man 6") adds complexity in a way that improves player interaction and gives players more to worry about. I think the game is now at least as interesting as a crayon rail game, because it has more interaction, more complex decisions to make, and more tension. But maybe not—maybe the decisions, for all their complexity, still have obvious solutions. I need to work with it some more to find out whether that's true.
And then there's this whole business about volatility. There isn't much, in the current design. I need to think about adding some, and I have a few ideas to play with. I'll keep y'all posted, and I may even post the latest rules sometime soon.
But it set me to thinking. How interesting, and how difficult, do the choices have to be in order to have a fun and playable game? I tried a wargame design once; it was judged by the KublaCon playtesters to be boring because the decisions were obvious and easy to make. I don't want to repeat that mistake. On the other hand, while it's good to have ambitious goals, as a fledgling designer I can't expect to design the next #1 game at BoardGameGeek. So how good is "good enough"?
For an answer I am looking at my own favorites among the published rail games. These are:
* Ticket to Ride
* The crayon rail games (Empire Builder and its sequels)
* Railroad Tycoon
* Age of Steam
* The 18XX games
* Silverton
What kind of game experience do these successful games offer?
Ticket to Ride has simple rules and simple play, and is over in an hour. At times you spend move after move simply drafting cards into your hand. Your decisions are mostly of the push-your-luck variety: should you grab that route now, before someone else does? Or wait until you can grab several connected routes in quick succession, so as not to tip your hand too soon? The fun comes mainly from the tension of that basic decision. And it is fun, without a doubt. The Ticket to Ride series is far and away the most commercially-successful rail game ever. So we learn this: Tension lends interest and excitement.
Empire Builder and its sequels are straight-forward games of building track and making deliveries. These are flawed games, in my opinion. They take too long to play, especially if you make the mistake of playing with more than four players. There is little player interaction: you don't have to worry very much about what your opponents are doing. And the decisions are simple: which of my nine potential deliveries is the best to do next? Where should I built my next track? Is it time to upgrade my locomotive? The answers are usually fairly obvious, once you've done the gruntwork of figuring out sources and destinations for your potential deliveries (which usually is a lot of work: another flaw). And yet the crayon rail games are fun anyway, popular enough to have spawned a dozen or so sequels, and due to be re-issued this year by Mayfair. Lesson learned: A game can be fun even if its choices are not difficult. Sometimes the activity itself is entertainment enough.
Age of Steam is an amazingly good game, at least if you enjoy high levels of competition. Often described as "a knife fight in a phone booth", AoS crowds players together and forces them to compete viciously for routes and deliveries. A tight economic system makes budgeting a challenging and crucial exercise, and an auction system that controls both player order and access to important actions adds tremendous tension. Lesson learned: Holzgrafe, you will never design a rail game this good! More seriously: budgeting and pacing issues add interest to a game, and player interaction is important.
Railroad Tycoon is my favorite. This game has the same basic notion as Empire Builder (build rail, then make deliveries) but avoids the flaws in the crayon rail system. Spotting viable deliveries is easy and quick; the choices are interesting and difficult; and the game does not outlast its fun factor, even with six players. It has excellent player interaction, because players must compete for track routes, deliveries, and bonuses. It's really more appropriate to compare RRT with Age of Steam because it is directly derived from AoS. RRT is less competitive than AoS. But if Age of Steam is "a knife fight in a phone booth", Railroad Tycoon is still at least a barroom brawl: more spacious and forgiving of errors, but still highly contentious and with plenty of chairs and tables to swing. Lesson learned, from both AoS and RRT: Competition for scarce resources makes for tough, interesting choices.
The 18XX series adds a new element: a stock market. In an 18XX game players build rail and make deliveries. Players compete mainly to acquire stock, drive up the value of companies in which they are heavily invested, and sell high-valued stock to reap the gains and ruin the stock's value for others who still own shares. 18XX games are complex, long, and deeply strategic. I have played only once and I'm not competent to discuss them in detail, but there is a lesson learned: A volatile, interactive market adds a whole new level of interest to a game.
Silverton is the rail game that has most recently grabbed my attention, although it's now over 15 years old. Silverton features a volatile market, but it is a goods market rather than a stock market. Players compete not only to lay track, but to claim mines. Mines are worked to produce goods, which you then convert to money by delivering to market cities. Market prices vary, partly at random and partly influenced by recent sales. Taking a big load to market can drop market prices ruinously for anyone who shows up late. Silverton combines a fairly standard build-and-deliver mechanism with features such as the market, the high-risk nature of mining, and the difficulties of winter operations in the Rockies, resulting in a fascinating game with good levels of player interaction. Lesson learned: Volatility forces pacing, making players choose between urgent actions and important actions.
So what does this all imply for my own design? I'm still evaluating that, but I'm encouraged. My latest rules revision (with the compelling sobriquet of "Straw Man 6") adds complexity in a way that improves player interaction and gives players more to worry about. I think the game is now at least as interesting as a crayon rail game, because it has more interaction, more complex decisions to make, and more tension. But maybe not—maybe the decisions, for all their complexity, still have obvious solutions. I need to work with it some more to find out whether that's true.
And then there's this whole business about volatility. There isn't much, in the current design. I need to think about adding some, and I have a few ideas to play with. I'll keep y'all posted, and I may even post the latest rules sometime soon.
Sunday, December 21, 2008
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.
Anyway, if you're a copyright lawyer you can stand down. I'll find something else to call my design.
Friday, December 19, 2008
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!
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!
Tuesday, November 25, 2008
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.
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.
Saturday, November 15, 2008
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.
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.
Subscribe to:
Posts (Atom)
