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.
Saturday, February 21, 2009
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.
Subscribe to:
Posts (Atom)
